用 AI 修 Bug 先写复现测试：从 bug 报告到回归测试的完整流程
用 AI 修 Bug 最稳的顺序是：先让它根据 bug 报告写一个会失败的测试，确认测试确实复现了问题，再让它修代码直到测试通过，最后跑全量测试。 这样修复有证据，以后也不会悄悄复发。
为什么要先写测试
- 直接让 AI 修，它可能修的是它“以为”的问题；
- 一个失败的测试，把模糊的 bug 描述变成了精确、可验证的目标；
- 修好后这个测试留在代码库里，成为回归保护。
第一步：准备 bug 信息
给 AI 的信息越具体越好：
- 复现步骤、输入数据、期望结果、实际结果；
- 错误日志或堆栈；
- 相关的函数或文件（不要一次把整个仓库塞进去）；
- 项目使用的测试框架和测试文件位置。
第二步：写复现测试
下面是一个 bug 报告和相关代码。请不要修改业务代码。
任务：在【测试文件路径】中新增一个测试，用最小输入复现这个 bug。
要求：
1. 测试名清楚描述 bug 行为；
2. 断言写“期望的正确行为”，因此在当前代码下应当失败；
3. 说明你预期它会以什么错误或断言失败。
bug 报告：【粘贴】
相关代码：【粘贴】
运行测试，确认它失败，而且失败原因和 bug 一致。如果它意外通过了，说明测试没有抓住问题，要回去补充信息。
第三步：修复
刚才的测试失败如下：【粘贴失败输出】
请做最小改动修复这个问题，让该测试通过。
要求：不修改测试本身；说明根因；列出可能受影响的其他调用方。
第四步：检查清单
- 新测试通过，原有测试全部通过；
- 阅读 diff：改动是否最小、有没有顺手“优化”无关代码；
- 根因说明是否合理，是否需要补充边界情况测试；
- 提交信息里关联 bug 编号，说明根因和修复方式。
常见坑
- AI 改了测试让它通过：在提示词里明确禁止，并在 diff 里检查。
- 测试依赖外部服务：复现测试尽量用固定数据或模拟，避免不稳定。
- 一次修多个 bug：一个测试对应一个问题，更容易审查。