用途
Systematic Debugging 是一套用于调查缺陷、修复测试失败和排查异常行为的四阶段调试方法论。其核心原则是：未先做根因调查，绝不修复。它反对只针对症状打补丁、掩盖底层问题的做法，强调在动手修复前先理解“为什么失败”。
主要能力
该方法论提供了一套结构化的调试流程，包括：
- 根因调查：在接触代码前，彻底阅读错误信息、稳定复现问题、检查近期变更、收集日志与堆栈等诊断证据，并沿调用链追溯数据流，找到坏值的来源。
- 根因追溯技术：观察症状、找到直接原因、追问“是谁调用了它”、持续向上追溯、定位原始触发点。关键原则是不要只在错误出现处修复，而要追溯到最初的触发点。
- 模式分析：寻找可正常工作的相似代码，完整对比实现，找出工作版本与损坏版本之间的差异，并理解代码依赖。
- 假设与测试：运用科学方法，一次只改变一个变量，形成单一清晰假设，设计最小测试，预测结果，运行并验证，再迭代或推进。
- 实施修复：先创建能捕获缺陷行为的失败测试，再针对根因实施单一修复，验证测试通过，运行完整测试套件确保无回归。若修复失败则停止并重新评估假设。
使用方式
该技能以流程规范的形式使用，适用于调试过程中的各个阶段。它给出了明确的停止规则：如果连续三次或更多次修复失败，必须停止，因为这通常意味着存在架构问题，需要讨论而非继续打补丁。
它还列出了需要立即停止的“红旗”思维，例如：“先快速修复，以后再调查”“再试一次就好”（在多次失败后）、“这应该能行”（却不理解原因）、“让我先试试”（没有假设）、“在我机器上是好的”（却不调查差异）。
对于更深层问题的警示：连续修复在不同区域暴露新问题，说明可能存在架构问题，应停止打补丁、记录发现、与团队讨论，并考虑设计是否需要重新思考。
适用场景
该技能覆盖多种常见调试场景，并给出对应步骤：
- 测试失败：阅读完整错误信息与堆栈，识别失败的断言及原因，检查测试环境、测试数据（mock/fixture）是否正确，追溯意外值的来源。
- 运行时错误：捕获完整堆栈，定位抛错行，检查哪些值为 undefined/null，向后追溯坏值来源，并在源头添加校验。
- “以前是好的”：使用 git bisect 找到引入问题的提交，与之前可用版本对比，识别哪个假设发生了变化，在假设被破坏的源头修复。
- 间歇性失败：排查竞态条件、共享可变状态、异步操作顺序、时序依赖，并添加确定性等待或正确的同步。
限制与检查清单
在声称缺陷已修复前，需满足以下检查项：根因已识别并记录；假设已形成并测试；修复针对根因而非症状；已创建可复现缺陷的失败测试；测试在修复后通过；完整测试套件通过；未使用“快速修复”的合理化借口；修复最小且聚焦。
资料称，系统化调试可实现约 95% 的一次修复率，而临时性方法约为 40%。做对的标志包括：修复不会引入新缺陷、能解释缺陷为何发生、类似缺陷不再复发、代码在修复后变得更好而不只是“能跑”。
该技能可与其他技能集成，例如 testing-patterns：在修复前先创建能复现缺陷的测试。
关于该技能的收费、价格、平台支持情况，资料中暂未提供。