Claude Code 系统调试流程：找到真正的 Bug

用 Claude Code 系统调试，不是让它猜一个补丁，而是按顺序走：先复现、再定位、提一个可验证的假设、只改确认的根因，最后用回归测试锁死结果。顺序对了，就不会改到本来没坏的代码。

为什么靠猜总会返工

AI 最擅长给出看起来合理的补丁，这恰恰是风险。接受第一个让报错消失的修复，你并不知道根因有几个、是否还藏在别处。

六步流程

• 1. 复现： 用最小用例让 Bug 稳定出现，记下命令、输入和环境。
• 2. 定性： 各用一句话写清预期与实际行为、Bug 何时出现。
• 3. 定位： 把故障收窄到一个组件或函数，一次只排除一个嫌疑对象。
• 4. 假设： 只提一个根因，并说清哪个实验能证实或证伪它。
• 5. 修复： 只做确认根因所需的最小改动，一次只改一处。
• 6. 防范： 补一个旧代码失败、新代码通过的回归测试，再全库搜同样的模式。

这正是 Systematic Debugging 的骨架：强制执行上述阶段，不让会话滑向打补丁。还没装过 skill 的话，先看安装指南。

能直接抄的提示词

• 复现： “先不要改代码，写出最小复现：命令、输入、预期与实际输出。”
• 定位： “跨文件追踪这个值，告诉我它最先在哪一步出错，并给出证据。”
• 假设： “按可能性列出前三个根因假设，每个配一个能证实或证伪的实验。”
• 修复： “只修确认的根因，做最小改动，不要顺手重构无关代码。”
• 防范： “写一个回归测试，并搜一遍全库有没有同样的模式。”

共同点是先要证据再行动。

三振规则与回归测试

连续三次修复都失败，就别再盯着代码了。这通常是架构或需求假设错了。跨组件的疑难 Bug，可搭配 Diagnosing Bugs 的诊断循环。

没有回归测试的修复只是传言。同一区域反复出 Bug，缺的往往是更早发现问题的测试——Test-Driven Development 的红绿重构循环正是补这一块的。

结论

调试的大头时间花在收拾修错根因的烂摊子。下次遇到 Bug，先按六步走一遍。