Bug 定位 Prompt：让 AI 像高级工程师一样诊断
粘贴报错信息与相关代码，强制 AI 走完整流程：复现条件、根因假设、最小化复现用例、修复方案、验证判据。适合能稳定复现但还没定位根因的场景；线上正在出血时先回滚止血，再用它复盘。
发布 2026-06-21更新 2026-09-23用法
把出错信息和相关代码粘进来，配合下面的 prompt：
什么时候用：已经能稳定复现、但还不知道根因的时候。这条 prompt 的价值在于拖住 AI 别急着改代码。
什么时候别用：
- 线上正在出血、要先止血——那时需要的是回滚 / 降级，不是诊断。先止血，再用这条 prompt 复盘
- 偶发、无法复现——先去把复现条件固定下来（加日志、抓现场、缩小输入），否则「5 个可能原因」只是 5 个猜测
- 你只想要一行修复——这条 prompt 故意绕远路；想要快答案就别用它
喂什么进去才有效（比 prompt 本身更关键）：
| 必给 | 可选但强烈建议 |
|---|---|
| 完整报错栈（不要只截最后一行） | 最近一次成功与失败之间改了什么（git log --oneline -10） |
| 触发步骤（能复现的最短路径） | 环境差异（Node 版本 / 系统 / 是否容器） |
| 相关代码片段 | 已经排除掉的假设（避免它重复走老路） |
Prompt
我遇到了一个 bug，请按以下步骤诊断（不要跳步）：
1. **复述现象**：用 1-2 句话总结这个错误是什么。
2. **列出 5 个可能原因**：从最可能到最不可能排序。每条 1 句话。
3. **要求验证**：对最可能的 2 个原因，告诉我需要看哪些代码 / 跑什么命令来确认。**不要直接猜结论。**
4. **等我反馈**：在我提供验证结果之前，**不要给修复方案**。
如果信息不够诊断，告诉我**具体缺什么**，不要泛泛说"提供更多上下文"。
错误信息：
```
<paste here>
```
相关代码（可选）：
```
<paste here>
```
为什么有效
- "5 个可能原因排序"逼 AI 做 hypothesis ranking，而不是抓第一个想法
- "等我反馈"切断了 AI 一上来就给伪修复的冲动
- "具体缺什么"避免 AI 说"need more context"这种废话
进阶
如果是诡异 bug（错误信息不指向真正原因），追加：
"这个错误的真实原因可能不在堆栈最上层。请考虑：是不是上游某个数据 / 配置 / 环境差异导致下游表现出这个错误？列出 3 种这类间接原因。"
变体 A：先要「观测清单」，不要结论
先别给修复方案。给我一张表，每行一条：
| 我需要你提供的信息 | 为什么它能区分假设 | 怎么拿到（具体命令/操作） |
只列 3-5 条，按信息量排序。
变体 B：二分定位（适合大范围改动后挂掉）
用二分法帮我定位：
1. 给出 git bisect 的具体命令序列（good/bad commit 我用占位符 <good> <bad>）
2. 每一步要验证什么
3. 如果 bisect 不可用（无法自动判定），给出等价的手工二分方案
不要猜测原因，只给定位流程。
变体 C：先写失败测试，再谈修复
在给修复方案之前，先给我一个能稳定复现这个 bug 的最小测试用例
（测试框架：<jest|pytest|go test>，要求：现在必须是红的）。
我看到红测试后再让你修，修完它必须转绿。
变体 C 是三个里最有用的——「先红后绿」把「修好了没」从主观判断变成机器判定，也顺手留下了一个防回归的用例。
验收判据：这套流程有没有真的在排查
- 它有没有向你要过信息？ 如果第一轮就直接给了修复方案，说明「等我反馈」这条约束没生效——通常是你的报错信息太完整，它觉得够判断了。
- 假设是否可证伪？ 好的假设长这样：「如果是 X，那么执行 Y 命令应该看到 Z；如果看到 W 则排除」。不可证伪的假设（「可能是环境问题」）等于没说。
- 修完之后有没有留下测试？ 没有测试复盘的 bug，三个月后大概率会以另一种形态回来。
一个必须记住的边界：模型给出的「根因」是基于你给的信息做的最佳解释，不是事实。只有跑起来的测试、抓到的真实返回值、bisect 到的那个 commit 才算证据——在这之前，所有结论都叫假设。参见 幻觉。
效果对比
同样丢一个 TypeError: Cannot read property 'id' of undefined：
不用这条 prompt —— AI 往往直接给"修复方案"：
"在访问
.id前加个判空：if (user && user.id)。"
加了判空，错误是不报了，但根本没诊断"user 为什么是 undefined"——可能是上游接口返回了 null、可能是异步竞态、可能是字段名写错。治标不治本，下次换个地方又崩。
用这条 prompt —— AI 被迫先排序假设：
- 复述：访问 user.id 时 user 为 undefined。
- 5 个可能原因（按概率）：① 接口返回体里没有 user 字段；② 异步未 await，数据还没到；③ 解构时字段名拼错；④ 数组为空时取了
[0]；⑤ 缓存返回了旧的空值。- 验证：先看接口真实返回（贴 Network 响应），再看这行代码上游是怎么拿到 user 的。
- 在你给我这两项前，我不给修复方案。
第二种才是真排查——它逼你去看真实返回，往往发现是接口字段问题，判空只是掩盖。
反例（AI 默认会写的烂版本）
默认输出：「可能是依赖版本问题，试试 rm -rf node_modules && npm install」——不问现象、不看日志、直接给一堆试试看的清单。
加了 prompt 之后：先复述可观测事实（报错栈、触发条件、最近改动），提出 3 个可证伪假设并按可能性排序，每个假设给一条最小验证命令，验证完再进入下一轮。
延伸阅读
- PR Review 第一道筛 Prompt · 测试生成 Prompt
- 什么是幻觉 — 为什么"等我反馈"能压住 AI 编结论
- Claude Code 深度评测 — 最适合跑这类诊断流程的工具