技能介绍

为什么需要这套纪律

线上按钮点了没反应，第一反应往往是「改一下试试」。改两次之后问题依旧，改动记录里堆了三处临时补丁，没人说清当初为什么改。系统化调试针对的就是这种状态：首次修复率只有 40% 左右，而每一次「快改」都在为下一个 bug 埋种子。

这套技能不提供补丁模板，它做的是把调试过程变成可审计的流程——动手之前先走完根因调查、模式分析、假设验证、实施四个阶段，每个阶段留下证据与判断记录。

四阶段流水线

阶段 1 · 根因调查。 铁律是「未查根因，不得提出修复」。这一步要求：

完整读错误信息与堆栈，关注行号、路径、错误码，而不是只看最后一行；
先稳定复现并记录步骤，无法复现就继续收集数据，而不是猜；
用 git diff 和环境配置差异排查近期变更；
多组件系统（CI → 构建 → 签名、API → 服务 → DB）在每个边界加诊断日志，跑一次定位断在哪一层。

阶段 2 · 模式分析。 找同类可用代码，完整读完参考实现（不跳读），列出工作版本与损坏版本之间的每一处差异——再小也别假设「无关」，同时理清依赖、配置与隐含假设。

阶段 3 · 假设与验证。 把假设写成「我认为 X 是根因，因为 Y」的清单，用最小改动逐一验证。验证不通过就换新假设，绝不在旧假设上叠加修复。确实不懂的地方明说「我不理解 X」，然后查资料或求助。

阶段 4 · 实施。 先写一个修复前必然失败的用例，再只改根因那一处，不夹带顺手重构，验证测试通过且无回归。

适用边界

它不是加速器，而是减速器。在「不调查就开改」的场景里这套纪律明确不适用——它明令禁止跳过根因直接给修复方案。已试修两次仍失败的任务会触发红旗：此时不是继续改，而是回到阶段 1 补证据，输出 phase、root_cause、hypothesis、failing_test 等结构化记录，让下一次修复有据可依。