大多数”AI 帮我 debug 一下”都死在同一个地方：你贴个报错，模型猜个原因、写个修复，你一跑，换了种方式挂掉，四十分钟后多了三个新 bug，还分不清是哪次改动造成的。模型其实从头到尾就没拿到足够信息去推理，只能靠模式匹配硬猜。下面这套流程的核心，就是先诊断、后修复。
一句话总结
- 先复现。 AI 调不了你自己都没法稳定触发的东西。
- 收集三样东西： 完整 stack trace、触发它的输入、期望 vs 实际输出。
- 让它列排序后的假设，而不是直接给修复。 “按概率列 3 个最可能原因，每个配一条诊断检查。”
- 跑检查、回报结果。 这一步在模型猜错坑你之前就把错误拦下来。
- 确认原因后再要最小修复， 应用，然后重跑一次复现。
- 补一条回归测试， 让同样的 bug 不会再悄悄回来。
整套流程的目的，是把模型的推理花在你提供的证据上，而不是花在猜测看不见的上下文上。
这篇适合谁看
卡住时会打开 ChatGPT、Claude Code 或 Cursor 的开发者，尤其是那些总收到”听起来很对、用起来不行”的修复的人。如果你曾经套用过一个”看着挺对”的 AI 修复、结果把别的地方搞坏了，这篇就是写给你的。
什么时候适合用
你有一个具体、可复现的失败：一段 stack trace、一个错误的返回值、一个 HTTP 500、一个能反复触发的间歇性崩溃。复现越确定，这套流程收敛得越快。
什么时候不建议用
- 性能回归：要的是 profiler 或火焰图，不是 stack trace。
- flaky 测试：根因是环境、执行顺序或共享状态，而不是单个逻辑 bug。
- 被伪装成 bug 的设计问题：所谓”修复”其实是一个重构决策。
要整体扫一类问题（重渲染、导航死循环、原生模块崩溃），请改用用 AI 审计 React Native 项目，那是普查式流程，而不是单 bug 流程。
7 步工作流
- 确定性地复现 bug。 找到每次都能触发它的确切输入或操作序列。如果只是 10 次里挂 1 次，就在第 3 步里明确写出来。
- 收集证据。 完整的 stack trace（不是只有最后一行）、触发输入，以及清楚的”期望 X、实际 Y”。
- 把三样东西放进一条消息。 一条上下文完整的消息，胜过五条挤牙膏式的补充。把报错那段函数、以及 bug 依赖的数据一起附上。
- 要排序后的假设 + 检查，先别要修复。 用下面那段 prompt。逼模型给出诊断检查，等于把它的推理摊开，让你能逐条验证。
- 跑它建议的检查，再回报。 “检查 1 通过。检查 2 发现那个环境变量在 CI runner 里是 undefined。“这是最有价值的一步：在幻觉原因浪费你时间之前就抓出来。2026 年的调查显示，只有约 27% 的用户会稳定地核对 AI 输出（All About AI）——这一步让”核对”变成默认动作。
- 确认原因后，再要最小修复。 应用它，从第 1 步重跑复现，确认失败消失、别处也没被搞坏。
- 写回归测试。 让模型写一条测试：在旧代码上失败、在修好的代码上通过，专门针对这个 bug。
实例：一个只在 CI 里挂的 HTTP 500
一个 handler 在 CI 里返回 500，本地却正常。你收集 trace、请求体和”期望 200、实际 500”，然后要它给三个排序原因。模型给出：(1) CI runner 里缺一个环境变量，(2) Node 版本不同，(3) 数据库迁移在 CI 里没跑。你跑检查：那个环境变量只在 CI 里读出来是 undefined，确认假设 1。最小修复是把变量加进 CI secrets，再加一条启动断言——缺变量时直接报错退出，而不是默默返回 500。你补一条测试：变量缺失时 handler 抛出清晰的配置错误。总耗时约 15 分钟，对比一小时的随机换修复。
如果 bug 只在 Firebase Hosting 的生产环境出现，可配合AI Firebase 部署检查工作流——多数”本地能跑、上线就挂”的情况都追溯到 firebase.json 的 rewrites 或 Cloud Function 的 region 不一致。
哪种 AI 工具配哪类调试任务（2026 年 6 月）
不同工具适合不同阶段。最实际的分界线：聊天模型靠你粘贴的内容来调试，而 agent 类工具能读你的代码库、跑命令、自己加日志。
| 工具 | 最适合 | 备注（截至 2026 年 6 月） |
|---|---|---|
| ChatGPT（GPT-5.5） | 粘 trace + 代码，要排序假设 | 免费档限制紧，Plus 每月 $20。agentic 推理强，Terminal-Bench 2.0 拿下 82.7%。 |
| Claude Code（Opus 4.7 / Sonnet 4.6） | 跨文件 bug，让它自己读 import、跑命令 | 随 Claude Pro（每月 $20）打包提供。Opus 4.7 在 SWE-bench Verified 上以 87.6% 领先。只跑 Anthropic 自家模型。 |
| Cursor（Sonnet 4.6、Opus 4.7、GPT-5.5） | 编辑器内调试，bug 就在代码旁边 | Hobby 免费，Pro 每月 $20。后台 agent 可并行跑多个诊断任务。 |
做 agent 式调试时，有效的循环不太一样：让工具在可疑路径上加详细日志、跑复现、把输出喂回去。它会靠不断累积证据收敛到核心问题，这一点 Anthropic 在它的 Claude Code 最佳实践 里有写。下面那段假设排序 prompt 依然适用，只是改由 agent 替你跑检查。
容易踩的坑
- 只贴报错信息。 没有触发条件和期望行为，模型无从推理，只能瞎猜。
- 原因没确认就让 AI 写修复。 AI 最危险的输出就是”听起来很对其实错了”的那种；对着错误原因写出的自信修复，常常再引入第二个 bug。
- 一连试五个修复都不行。 停。从头重读整段 trace。真正的故障点，通常在你一直盯着的位置往上一两帧。
- 跳过回归测试。 没测试的修复，意味着同样的 bug 会在下一次重构时悄悄回来。
- 截断 stack trace。 最后一行是症状，原因往往在更上面。整段都贴上。
进阶技巧
- 间歇性 bug： 问”什么顺序或时序假设会让它只是偶尔挂？“竞态和共享可变状态就藏在这里。
- “我这能跑”类： 把环境差异明写出来——Node / Python 版本、操作系统、以及两台机器之间不一样的那几个环境变量。
- 模型反复给错原因时： 喂它反证。“不是网络问题，也不是权限问题；检查 2 已确认数据库连接正常。“这能快速剪掉搜索空间。
- 很长或跨文件的 trace： 贴 trace + 它引用到的相关函数体，别把整个仓库都倒进去。精准上下文胜过一股脑全贴。
可直接复制的诊断 Prompt
报错 / trace（完整，从头到尾）：
[粘完整 trace]
触发：[复现它的输入或步骤]
期望：[应该发生什么]
实际：[实际发生什么]
复现概率：[每次 / N 次里 1 次]
按概率列 3 个最可能根因，从高到低排序。
每个给出一条具体的诊断检查，让我能跑。
先别写修复——我会先回报检查结果。FAQ
要附代码，还是只贴报错就行？ 附上报错那段函数，以及 bug 依赖的任何数据。模型猜不出它从没见过的函数体，大多数”原因猜错”的回答都来自上下文缺失。
AI 编造原因怎么办？ 它有时候会。诊断检查那一步就是你的护栏：没有一条检查确认之前，绝不接受某个原因。把每个排序假设都当作”未经验证”，直到你跑过它的检查。
2026 年 6 月调试用哪个模型最好？ 要粘 trace、要排序假设，GPT-5.5 和 Claude Opus 4.7 都很强。跨文件 bug、需要工具读仓库并跑命令时，Claude Code（Opus 4.7，SWE-bench Verified 87.6%）或 Cursor 的 agent 更合适。按你想要”纯聊天推理”还是”能动手的 agent”来选。
这和直接说”帮我修 bug”有什么区别？ “帮我修 bug”没有证据就直接打补丁。这套流程强插一个诊断步骤，让修复对准已确认的原因——这正是终结”猜了改、改了坏”循环的关键。
真的每次都要写回归测试吗？ 只要这个 bug 进了别人也会用到的分支，就要。一条测试只花一分钟，却是唯一能防止同样的 bug 在下次改动时悄悄回来的东西。