diagnose — 先拿到一条会变红的命令

难 bug 的纪律。在有一条已经在「这个」bug 上变红的命令之前，不许开始推理——直接跳到"我觉得是这里"正是这个技能要防的失败：没有信号的推理无法被证伪，你会一直在改写一个听起来合理的理论。

先脱敏

命令、输出、抓下来的产物里，每一处凭据都要先打码（写 <REDACTED>）。环路尽量从环境变量读凭据，让密文留在环境里而不是留在你要展示的东西里。抓包/日志常带 auth header——只引用有信号的那几行。打码后信息不够定位，就直接说，别绕着走。

Phase 1：建立反馈环路（这个技能的本体）

有一条紧的 pass/fail 信号（在这个 bug 上会红），你就一定能找到原因；二分、验证假设、加埋点都只是在消费这条信号。没有它，盯代码盯多久都没用。在这里花不吝啬的力气。

构造顺序大致如下：

1. 在能触达 bug 的接缝上写失败测试（单元 / 集成 / e2e）
2. 对着跑起来的服务写 curl / HTTP 脚本
3. CLI 调用 + fixture 输入，把 stdout 与已知good快照 diff
4. 无头浏览器脚本（Playwright）驱动 UI，断言 DOM / console / network
5. 重放捕获的轨迹：把真实请求/事件日志落盘，隔离重放
6. 一次性 harness：只起系统最小子集（mock 掉依赖），一次调用就走到 bug 路径
7. 属性 / 模糊测试：症状是"有时输出错"时，跑上千组随机输入找失败模式
8. 二分 harness：bug 出现在两个已知 good 状态之间时，自动化"在状态 X 启动 → 检查"，然后交给 git bisect run
9. 差分环路：同一输入跑旧版 vs 新版（或两种配置），diff 输出
10. 驱动人的脚本：最后手段。必须人点的时候，写脚本驱动人，让环路依然结构化

把环路当产品一样收紧：能更快吗（缓存 setup、跳过无关初始化、缩小范围）？信号更利吗（断言用户的具体症状，而不是"没崩"）？更确定吗（固定时间、固定随机种子、隔离文件系统、冻结网络）？30 秒且偶发的环路约等于没有；2 秒且确定的是超能力。

非确定性 bug：目标不是干净复现，而是更高的复现率。循环触发上百次、并行化、加压力、缩窄时间窗。50% 偶发可调，1% 不可调——提到可调为止。

真的建不出环路时：停下，明确说"建不出"，列出试过什么，向用户要 (a) 能复现的环境访问权，(b) 打码后的产物（HAR、日志、core dump），或 (c) 允许加临时埋点。不要在没环路的情况下进入假设阶段。

完成判据：你能说出一条命令（脚本路径 / 测试调用 / curl），且你已经至少跑过一次（贴出调用与输出，已脱敏），并且：

• 能变红：驱动真实的 bug 路径、断言用户描述的那个症状
• 确定：每次结论一致（偶发 bug 则是已固定的高复现率）
• 快：秒级，不是分钟级
• 可无人运行

Phase 2：复现 + 最小化

跑到它红，并确认：红出来的就是用户说的那个失败（不是附近另一个）；多次可复现；症状已捕获（报错 / 错误输出 / 耗时）以便后面验证修好了没有。

然后把复现缩到仍然会红的最小场景：输入、调用方、配置、数据、步骤一次砍一个，每砍一刀重跑环路，只留对失败有承重的部分。做完的判据是：去掉任何一个剩余元素都会变绿。

没复现、没最小化，不要往下走——最小化不是洁癖，它同时缩小了假设空间和将来的回归测试。

Phase 3：先写 3–5 条假设，再验

只写一条会锚死在第一个像样的念头上。每条必须可证伪，写出它预测什么：

如果 <X> 是原因，那么 <改 Y> 会让 bug 消失 / <改 Z> 会让它更严重。

写不出预测的是感觉，丢掉或磨利它。把排序后的清单给用户看再开验——他们常有领域知识能瞬间重排（"我们刚发过 #3 的改动"）。别阻塞；用户不在就按自己的排序走。

Phase 4：埋点（一次只改一个变量）

每个探针都要对应 Phase 3 的某条预测，否则你只是在收集数据而不是在排除假设。优先级：调试器 / REPL > 有目标的日志（打在能区分假设的边界上）> 绝不"全打日志再 grep"。

每条调试日志带唯一前缀（如 [DEBUG-a4f2]），收尾时一个 grep 全清。

性能回归分支：日志通常没用。先建基线测量（计时 harness、profiler、查询计划），再二分——先量后修，否则你改的是自己想象中的热点。

Phase 5：修 + 回归测试

先写回归测试，再修——但前提是存在正确的接缝：测试要能在调用点复现真实的 bug 模式。接缝太浅（单调用方测试 vs 需要多调用方才出现的 bug）只会给假信心。

没有正确接缝，这本身就是结论：记下来，说明架构让这个 bug 无法被钉死，然后把它当成一条新 issue 走主线。

有正确接缝时：把最小复现变成失败测试 → 看它红 → 修 → 看它绿 → 拿 Phase 1 的原始场景再跑一遍。

Phase 6：收尾（宣布完成前逐条过）

• 原始复现不再出现（重跑 Phase 1 环路）
• 回归测试通过（或「无正确接缝」已记录）
• 所有 [DEBUG-...] 埋点已清除（grep 前缀）
• 一次性原型已删除，或移到明确的调试目录
• 把最终成立的那条假设写进 commit / PR 说明，下一个排查的人能学到东西

与流程的衔接

排查通常是一个内联单元，不要为它开 /graph——并行解决不了一个还没被理解的 bug。定位清楚之后：如果是修 bug，按主线的单点改动走（实现 → 项目门禁 → /review-it → /ship-it）；如果结论是"这里缺一个好的接缝"，把它写成 issue，走 /to-issues 产物同一条路。