用 AI 修一个小 bug 的工作流

一句话摘要：别一上来就甩给我「看看哪儿错了顺手改掉」——那是我越改越乱、顺手多改五个文件的高发场景。给我一条固定流水线：先复现、再定位、只做最小修复、用一个能复跑的检验收尾。

工作流：5 步修一个小 bug

1. 先复现，落成一个失败的测试。 让我写一个当前会失败的测试（或一条可复跑的复现命令），把 bug 钉成红灯。没有红灯，就没有「修好了」的客观标准——别让我凭「我觉得是这里」开改。
2. 定位根因，先说再改。 让我用一两句话讲清「根因是什么、为什么触发」，先讲给你听、别动手。讲不清的，多半是在猜——这时让我加日志 / 读真实运行信息，而不是盲改。
3. 最小修复。 只改根因那一处；明确禁止「顺手」重命名 / 重构 / 改格式。改动越小，回归风险越小，review 越快。
4. 跑检验，由红转绿。 跑第 1 步的测试 + 相关测试 + lint / 类型检查，让我贴出真实输出，不是「应该过了」。
5. 快速 review。 对照 PR review 清单扫一眼 diff 是否越界、有没有顺手改别的。

可直接说给我的话：
"先给这个 bug 写一个会失败的测试复现它；先讲清根因再改；只改根因那一处、
别动别的；然后把测试和 lint 跑出来贴给我看；最后自查 diff 有没有越界。"

适用边界

适合什么时候用

• 范围清楚、影响面小的缺陷修复（一个函数 / 一个模块内）。
• 你想避免「让 AI 随便改改」滑成反复试错、越修越糟。

不适合什么时候用

• 根因不明、牵涉多模块的疑难故障——那更接近一次小型调查 / 重构，走大重构工作流。
• 改动本质是设计问题（要改接口 / 数据模型），别用「修 bug」的最小 diff 心态糊过去。

使用前请替换

• 把「测试 / lint / 类型检查」换成你项目里真实的命令。
• 没有测试基础设施的项目，第 1 步用「可复跑的复现命令 + 期望输出」替代失败测试。