很多人第一次用 AI 编程工具修 Bug，都会直接把报错贴进去，然后等它改代码。这个方法在小脚本里可能有效，放到真实项目里就容易翻车：AI 不知道复现路径、不知道哪些行为不能动，也不知道你最后要用什么标准验收。
更稳的做法，是把“修 Bug”拆成一条可检查的流水线：先复现，再定位，再做最小改动，最后跑测试和回归检查。站内已经写过 2026年AI编程工具推荐：Cursor、Claude Code、Codex、Windsurf怎么选，也整理过 AI编程工具专题。本文不再比较工具，而是讲一套新手也能照着执行的调试流程。
第一步：不要先改代码，先让 AI 写复现说明
调试的起点不是“哪里错了”，而是“怎样稳定看到错误”。你可以先把报错日志、页面路径、输入数据、最近改动和预期结果交给 AI，让它输出一份复现清单。
一个可用提示词是：
请先不要修改代码。根据我提供的报错、操作路径和预期结果，整理一份 Bug 复现步骤，列出需要确认的输入、环境变量、相关文件和可能的影响范围。最后告诉我还缺哪些信息。
这一步适合在 Cursor 里做，因为它能快速结合当前文件上下文，也方便你手动补充页面、接口或测试入口。不要急着接受 AI 的修复建议，先看它有没有把问题讲清楚。
第二步：让 AI 缩小范围，而不是全仓库乱搜
复现路径清楚后，再让 AI 做定位。这里的关键是给它一个边界：只读相关模块、只解释调用链、只列候选原因。比如前端按钮失效，就让它先看组件、状态管理、接口请求和事件绑定，不要让它顺手重构一大片。
如果你用 Claude Code，可以让它先做只读分析；如果你用 Codex，则可以让它搜索相关符号、读测试、整理可疑文件。此前这篇 Claude Code怎么用？从安装、权限到提交代码的新手工作流 讲过基础流程，Codex CLI权限怎么设置？沙箱、审批模式和安全自动化实战 则适合用来补安全边界。
第三步：只允许最小改动，并要求解释风险
AI 修 Bug 最大的问题，不是不会改，而是太容易顺手“优化”。你要明确要求它只做最小改动，并在改完后说明三个问题：
- 真正修改了哪些文件；
- 为什么这些改动能覆盖复现路径；
- 哪些相邻功能可能被影响。
这一步特别适合用在多人项目、WordPress 主题、小程序、后台系统和 API 服务里。只要你说清楚“不要重构，不要改无关格式，不要替换已有架构”，AI 通常会收敛很多。
第四步：让测试先证明问题，再证明修复
如果项目有测试，先让 AI 找到最接近 Bug 的测试文件；如果没有测试，就让它补一个最小可运行用例。理想顺序是：先写一个会失败的用例，再改代码让它通过。即使做不到完整 TDD，也要让 AI 输出手动验证清单。
可以这样要求：
请基于刚才的复现路径补一个最小测试或手动验收清单。测试只覆盖这个 Bug，不要扩展到无关行为。改完后运行项目已有检查，并把失败日志和处理结果列出来。
如果你经常忘记跑检查，可以参考 Claude Code Hooks怎么用？把格式化、测试和安全检查自动接进AI编程流程，把格式化、测试、安全扫描放进固定流程。更多真实工作流也可以看 老达AI实践专题。
第五步：回归检查要覆盖“没坏掉的东西”
很多 Bug 修完又引入新问题，是因为只验证了报错消失，没有验证相邻功能仍然正常。比如登录问题修完后，要看注册、退出、权限跳转；发布按钮修完后，要看草稿、定时、预览和失败提示。
我通常会让 AI 输出一张回归表：
- 必须通过：原 Bug 复现路径已经修复；
- 高风险相邻功能：同一模块的核心流程；
- 低风险抽查：页面渲染、日志、权限、异常提示；
- 不在本次范围：明确记录，避免 AI 自己扩边界。
不同工具怎么分工
Cursor 适合在 IDE 里快速理解局部代码、补齐类型和改组件；Claude Code 适合长上下文分析、规划修复步骤、跑命令和整理解释；Codex 适合在项目工作区里执行更完整的读文件、改代码、测试和核验流程。它们不是只能三选一，关键是让每个工具做它最擅长的环节。
如果你还在选择工具，可以先读 Cursor、Windsurf还是Claude Code，再结合 AI编程学习路线怎么走？零基础到能用 Cursor、Claude Code、Codex 做项目 制定练习路径。
老达建议：把修 Bug 当成一次小型交付
AI 编程调试的核心，不是让模型看起来很聪明，而是让结果可复现、可解释、可回滚、可验收。新手最该养成的习惯，是每次修 Bug 都留下复现步骤、改动说明、测试结果和回归清单。
当你把这套流程跑顺后，AI 修 Bug 的稳定性会明显提升。它不会让每个问题都秒解，但能减少“越改越乱”的概率，也能让你更快判断：这个问题是交给 AI 继续推进，还是该自己接手。
