【让AI修Bug的最佳实践：先写测试，再动手修】

用AI写代码的人大概都经历过这种循环：报了个Bug，AI立刻开始修，改完发现又引入了新问题，然后继续修，继续出问题……

Nathan Baschez分享了一个简单但极其有效的方法，直接写进CLAUDE.md或AGENTS.md里：

“当我报告一个Bug时，不要急着修复。先写一个能复现这个Bug的测试，然后让子代理去修复，并用通过的测试来证明修复有效。”

"When I report a bug, don't start by trying to fix it. Instead, start by writing a test that reproduces the bug. Then, have subagents try to fix the bug and prove it with a passing test."

这个方法的精妙之处在于，它强迫AI在动手之前必须真正理解问题。很多时候AI修Bug的方式是模式匹配，看到错误信息就条件反射地贴个创可贴。但当你要求它先写测试时，它必须精确描述失败状态是什么，这本身就是一次深度理解的过程。

有人说这不就是TDD吗？确实是。但实践中发现，对AI来说需要把步骤拆得更细。简单说“用TDD修复”往往效果不如明确写出完整流程。

Geoffrey Litt补充了一个细节：对于复杂的UI Bug，让AI先输出一份Markdown格式的测试计划。因为模型在长对话中容易忘记如何复现问题，有了书面计划就能随时回溯。

这个方法还有一个隐藏收益：自动获得回归测试。每修一个Bug就多一个测试用例，防止“修好了A结果B又坏了”的经典困境。

有人开玩笑说，小心子代理写出一个“删掉整个功能”的测试然后宣布通过。这虽然是调侃，但也提醒我们：清晰定义什么叫“修复成功”，这仍然是人类的工作。

能把失败状态精确到可测试的程度，这才是与AI协作中真正需要人类判断力的地方。

x.com/nbaschez/status/2018027072720130090