用 AI 修 Bug 最常见的问题是：它改了代码，解释得头头是道，但你并不确定问题是否真的解决了。更可靠的做法是：先让 AI 写一个能复现 Bug 的失败测试，确认它确实失败，再让 AI 修改代码直到测试通过，最后跑全量测试确认没有引入新问题。

为什么先写测试

  • 验证理解：AI 能写出复现测试，说明它理解了问题；写不出来，往往说明问题描述还不够清楚
  • 防止假修复：没有测试时，AI 可能只是绕开了症状，比如加了一个空值判断把错误吞掉
  • 防止回归：这个测试会留在代码库里，以后有人改动相关代码时能及时发现

完整流程

第 1 步：描述症状，不急着要修复

现象：调用 calculate_discount 时，购物车里同时有满减券和折扣券，总价变成了负数。
复现输入：……
期望结果：……
实际结果：……
请先不要修改业务代码。阅读相关文件后，告诉我你认为可能的原因，以及你打算如何写一个测试来复现它。

先让 AI 说出思路，你可以在它动手前纠正方向。

第 2 步：写失败测试并运行

请在 tests/ 下为这个问题添加一个测试用例，测试名清楚描述场景。
写完后运行这个测试，确认它失败，并把失败输出贴给我。

如果测试意外通过了，说明复现条件不对，回到第 1 步补充信息。这一步本身就能帮你发现「问题其实在别处」。

第 3 步：最小修改让测试通过

现在修改业务代码让这个测试通过。要求：
- 只做解决该问题所需的最小改动
- 不要修改测试本身的断言
- 改完运行该测试和相关模块的全部测试

「不要修改测试断言」这一条很重要，否则 AI 可能通过放宽测试来「让它通过」。

第 4 步：审查改动

  • 看 diff：改动范围是否超出预期？有没有顺手重构了不相关的代码？
  • 看根因：修复是在数据产生的地方，还是只在显示前做了截断？
  • 看边界：再让 AI 补充两三个边界用例，例如只有一种券、券金额等于总价

第 5 步：提交时写清楚

提交说明里写上 Bug 现象、根因和新增的测试名，方便日后排查。

什么情况下不适用

  • 难以自动化测试的问题，例如纯视觉样式问题，可以改用截图对比或手动检查清单
  • 生产环境偶发、无法稳定复现的问题，先补充日志收集信息，再回到这个流程

常见坑

  • 让 AI 同时写测试和修代码，它可能写出一个为当前实现量身定制、并不能真正复现问题的测试
  • 没有实际运行测试就相信 AI 说「测试已通过」
  • 一次修多个 Bug，测试和改动混在一起难以审查

相关阅读