这篇主要解决什么问题
大多数”AI 帮我 debug”会议变成 AI 在乱猜。下面这套结构让你更快到根因。
这篇适合谁看
每天写代码、卡住时打开 ChatGPT / Claude / Cursor 的开发者。
什么时候适合用
具体的失败（stack trace、错输出、间歇性 bug）能稳定复现。
什么时候不建议用
需要 profile 的性能回归；环境导致的 flaky test；被伪装成 bug 的设计问题。要整体扫一类问题（重渲染、导航、原生模块），看用 AI 审计 React Native 项目。
具体步骤
- 先复现。AI 调试不了你自己复现不了的东西。
- 收集：完整 trace、触发输入、期望 vs 实际。
- 一条消息把三个都贴上：“报错：[trace]。触发：[input]。期望：X。实际：Y。”
- 问：“列 3 个最可能原因按概率排，每个给一条具体的诊断检查。先不要写修复。”
- 跑检查。把结果回报：“检查 1 通过，检查 2 发现：…”
- 现在再要确认原因的最小修复。应用、再复现一次。确认。
- 修完让 AI 给这个 bug 写一条回归测试。
建议的操作流程
一个 500 错误：trace + 输入 + 期望 → 3 个假设 → 跑假设 2 的检查（测试环境缺环境变量）→ 最小修复 → 回归测试 → 完。15 分钟 vs 一小时乱猜。如果 bug 只在 Firebase Hosting 生产环境出现，可配合AI Firebase 部署检查工作流——多数”本地能跑”的 bug 都是 firebase.json rewrites 或 function region 不一致引起。
容易踩的坑
- 只粘报错不写触发 / 期望。AI 瞎猜。
- 原因没确认就让 AI 写修复。常常修错地方。
- 一连试 5 个修复都不行。停。重读 trace。bug 大概在别处。
- 忘了加回归测试。同样的 bug 还会回来。
进阶技巧
- 间歇性 bug 问：“什么顺序 / 时序假设会让它有时挂？”
- “我这能跑”类 bug：把环境差异明写（Node 版本、OS、env vars）。
- AI 反复给错原因时给反证：“不是网络问题，不是权限问题。“
可直接复制的 Prompt
报错 / trace：{粘完整 trace}
触发：{什么输入 / 步骤}
期望：{应该发生什么}
实际：{实际发生什么}
按概率列 3 个最可能根因，每个给一条具体诊断。先不要写修复。FAQ
- 要不要附代码？: 要——报错那段函数 + bug 依赖的任何数据。AI 猜不到。
- AI 编造原因怎么办？: 它会。验证那一步会抓出来。