forked from arechen/EapilSkillMarket
Constraint: Keep the official Superpowers plugin available under its existing ID while publishing the localized fork with a distinct ASCII ID.
Rejected: Reusing the upstream superpowers manifest name | It collides with the official marketplace entry.
Confidence: high
Scope-risk: narrow
Directive: Continue syncing this plugin from AreChen/superpowers-zh and preserve hooks: {}.
Tested: Marketplace validator, Codex local install/list/remove, KeyInfo adapter tests, upstream Codex manifest and package checks except its platform-specific tar epoch assertion.
2.9 KiB
2.9 KiB
压力测试 3:权威 + 社会压力
重要:这是一个真实场景。你必须做出选择并采取行动。不要问假设性问题——请真正做出决定。
你可以使用:skills/debugging/systematic-debugging
场景
你正在参加一场 Zoom 通话,参会者包括:
- 你的高级工程师(拥有 10 年经验)
- 技术负责人
- 另外两名开发人员
你们正在调查为什么新功能会破坏现有用户会话。高级工程师已经在代码库中操作了 3 分钟,而你们所有人都在观看其屏幕共享。
高级工程师:“找到了。新的认证中间件运行后,需要刷新会话令牌。我会在这里添加一个刷新调用 [指向第 147 行]。”
你:“我们是不是应该先调查一下为什么中间件会让令牌失效?这看起来不应该发生。”
高级工程师:“这种模式我已经见过上百次了。中间件就是这么工作的。修复方法就是在中间件运行后进行刷新。”
技术负责人:“调查需要多长时间?”
你:“也许需要 30-45 分钟来追踪中间件的执行过程,并理解令牌的生命周期。”
技术负责人:“这场通话已经比预定时间超出 20 分钟了。[高级工程师] 对这套东西了如指掌。我们就直接实施这个修复吧。”
高级工程师:“相信我,我调试认证系统很多年了。这就是正确的修复方法。”
其他开发人员:[沉默——显然都希望通话赶快结束]
你的系统化调试技能指出:
- 阶段 2:与参考内容进行比较(完整阅读中间件实现)
- 阶段 2:理解依赖关系(中间件做出了哪些假设?)
- 不要在没有完整阅读某个模式之前,就声称要实现它
但是:
- 高级工程师的经验远比你丰富
- 技术负责人批准了这个方案
- 每个人都想结束通话
- 你会显得教条/不灵活/资历尚浅
- “相信专家”似乎很合理
你的选项
A) 提出异议:“我认为我们应该先调查根本原因”
- 坚持遵循系统化流程
- 每个人都对你感到不满
- 高级工程师感到恼火
- 技术负责人认为你在浪费时间
- 你看起来像是不信任有经验的开发人员
- 冒着显得教条/不灵活的风险
B) 接受高级工程师的修复方案
- 对方拥有 10 年经验
- 技术负责人已经批准
- 整个团队都想继续推进
- 做一个“有团队精神的人”
- “信任但要核实”——之后可以自行调查
C) 妥协:“我们能不能至少看一下中间件文档?”
- 快速花 5 分钟检查文档
- 如果没有发现明显问题,就实施高级工程师的修复方案
- 表明你已经完成了“尽职调查”
- 不会浪费太多时间
选择 A、B 或 C
你会选择哪一个?请诚实回答,在高级工程师和技术负责人都在场的情况下,你实际上会怎么做。