Debugging 是一套系统化调试框架，结合了系统化调查、根因追踪、纵深防御校验与验证协议。
核心原则
未先调查根因，不得修复（NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST）。随机修复会浪费时间并引入新缺陷。应先找到根因，在源头修复，在每一层校验，并在宣称成功前完成验证。
适用时机
始终适用于：测试失败、缺陷、异常行为、性能问题、构建失败、集成问题，以及在宣称工作完成之前。
尤其适用于：时间压力下、“快速修复”看起来显而易见时、已尝试多种修复时、尚未完全理解问题时、即将宣称成功时。
四项技术
- 系统化调试（references/systematic-debugging.md）
四阶段框架，确保调查到位：
阶段 1：根因调查（阅读错误、复现问题、检查变更、收集证据）
阶段 2：模式分析（寻找可工作的示例、对比、识别差异）
阶段 3：假设与测试（形成理论、最小化测试、验证）
阶段 4：实施（创建测试、一次性修复、验证）
关键规则：完成每个阶段后再进入下一阶段。没有阶段 1，不得修复。
加载时机：任何需要调查与修复的缺陷或问题。
- 根因回溯（references/root-cause-tracing.md）
沿调用栈反向追踪缺陷，找到最初的触发点。
技术：当错误出现在执行较深层时，逐层反向追踪，直到找到无效数据的来源。在源头修复，而非在症状处修复。
包含：scripts/find-polluter.sh，用于二分定位测试污染。
加载时机：错误位于调用栈深处、无效数据来源不明时。
- 纵深防御（references/defense-in-depth.md）
在数据流经的每一层进行校验，使缺陷无法发生。
四层：入口校验 → 业务逻辑 → 环境防护 → 调试埋点。
加载时机：找到根因后，需要添加全面校验时。
- 验证（references/verification.md）
在宣称成功前运行验证命令并确认输出。
铁律：没有新鲜的验证证据，不得宣称完成（NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE）。
运行命令。阅读输出。然后宣称结果。
加载时机：即将宣称工作完成、已修复或通过时。
快速参考
缺陷 → systematic-debugging.md（阶段 1-4） 错误位于栈深处？ → root-cause-tracing.md（反向追踪） 找到根因？ → defense-in-depth.md（添加分层校验） 即将宣称成功？ → verification.md（先验证）
危险信号
若出现以下想法，应停下并遵循流程：
“先快速修复，之后再调查”
“先改一下 X 看看行不行”
“大概是 X，我来修一下”
“现在应该能用了” / “看起来修好了”
“测试通过了，搞定了”
以上都意味着：回到系统化流程。