Bug 定位 Prompt：让 AI 像高级工程师一样诊断

用法

把出错信息和相关代码粘进来，配合下面的 prompt：

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 种这类间接原因。"

效果对比

同样丢一个 TypeError: Cannot read property 'id' of undefined：

不用这条 prompt —— AI 往往直接给"修复方案"：

"在访问 .id 前加个判空：if (user && user.id)。"

加了判空，错误是不报了，但根本没诊断"user 为什么是 undefined"——可能是上游接口返回了 null、可能是异步竞态、可能是字段名写错。治标不治本，下次换个地方又崩。

用这条 prompt —— AI 被迫先排序假设：

1. 复述：访问 user.id 时 user 为 undefined。
2. 5 个可能原因（按概率）：① 接口返回体里没有 user 字段；② 异步未 await，数据还没到；③ 解构时字段名拼错；④ 数组为空时取了 [0]；⑤ 缓存返回了旧的空值。
3. 验证：先看接口真实返回（贴 Network 响应），再看这行代码上游是怎么拿到 user 的。
4. 在你给我这两项前，我不给修复方案。

第二种才是真排查——它逼你去看真实返回，往往发现是接口字段问题，判空只是掩盖。

延伸阅读

• PR Review 第一道筛 Prompt · 测试生成 Prompt
• 什么是幻觉 — 为什么"等我反馈"能压住 AI 编结论
• Claude Code 深度评测 — 最适合跑这类诊断流程的工具