系统化调试（systematic-debugging）的核心原则是：必须先找到根本原因，再尝试修复；只处理症状视为失败。技能提出一条“铁律”：在没有完成第一阶段根本原因调查之前，不得提出修复方案。
适用场景
该技能适用于任何技术问题，包括测试失败、生产环境缺陷、意外行为、性能问题、构建失败和集成问题。尤其应在以下情况下使用：时间压力大、看似存在“快速修复”、已经尝试过多次修复、上一次修复没有生效、或者尚未完全理解问题。文档同时强调，问题看起来简单、时间紧迫或管理者要求立即修复时也不应跳过流程，因为系统化调试通常比反复猜测更快。
四个阶段
第一阶段是根本原因调查：仔细阅读错误信息和完整堆栈跟踪，记录行号、文件路径和错误码；稳定复现问题并记录确切步骤，无法复现时应继续收集数据而不是猜测；检查近期变更，包括 git diff、提交、依赖和配置变化；在多组件系统中，先在每个组件边界添加诊断日志，记录进入和离开组件的数据、环境与配置传递情况以及各层状态，运行一次以确定故障发生在哪一层，再深入该组件；对于调用栈深处的错误，可参考目录中的 root-cause-tracing.md 进行反向追踪，找到错误值的来源并在源头修复。
第二阶段是模式分析：在同一代码库中寻找可工作的类似实现，完整阅读参考实现而不是略读，列出工作版本与故障版本之间的所有差异，并理解相关依赖、配置、环境和假设。
第三阶段是假设与测试：提出单一、具体的假设并写明理由；做尽可能小的改动来验证假设，一次只改变一个变量；验证结果，成功则进入第四阶段，失败则提出新假设，而不是在原有修复上继续叠加。不知道原因时应明确说出“我不理解 X”，并寻求帮助或继续研究。
第四阶段是实施：先创建最简单的失败测试用例，最好自动化；然后针对根本原因做单一修复，不夹带顺手改进或重构；最后验证测试通过、其他测试未被破坏、问题确实解决，并建议在声称成功前使用 verification-before-completion 技能。
修复失败与架构质疑
如果修复没有生效，应停止并统计已尝试的修复次数。少于三次时，带着新信息回到第一阶段重新分析；达到三次及以上时，应停止继续尝试第四次修复，转而质疑架构。文档给出的架构问题信号包括：每次修复都在不同位置暴露新的共享状态或耦合、修复需要大规模重构、每次修复都在别处制造新症状。此时应与人类伙伴讨论是否应重构架构，而不是继续修复症状。
危险信号与常见借口
文档列出多种应立即停止并回到第一阶段的思维信号，例如“先快速修复，之后再调查”“先改 X 看看行不行”“一次加多个改动再跑测试”“跳过测试，我手动验证”“大概是 X，先修它”“我不完全理解但也许能行”“再试一次修复”等。还列出人类伙伴的提醒信号，如“不是没发生吗”“能让我们看到……吗”“别再猜了”“深入思考一下”“我们卡住了？”，这些通常意味着应回到根本原因调查。
常见借口部分逐条反驳了“问题简单不需要流程”“紧急情况没时间”“先试一下再调查”“修复后再写测试”“一次多个修复省时间”“参考太长只做适配”“看到问题就直接修”等理由，并指出三次以上修复失败通常意味着架构问题，而不是继续修复。
快速参考与支持技术
文档提供四阶段快速参考表：第一阶段理解是什么和为什么；第二阶段找出差异；第三阶段确认或提出新假设；第四阶段解决缺陷并保证测试通过。目录中还包括 root-cause-tracing.md（沿调用栈反向追踪原始触发点）、defense-in-depth.md（找到根本原因后在多层添加校验）、condition-based-waiting.md（用条件轮询替代任意超时）等支持技术。
关于“没有根本原因”
如果系统化调查发现问题确实是环境性、时序相关或外部原因，流程仍然算完成：应记录调查内容，实施适当的处理方式（重试、超时、错误信息），并添加监控和日志以便未来调查。但文档提醒，95% 的“没有根本原因”案例其实是调查不完整。
限制
该技能是一套调试流程和纪律，不绑定特定语言、框架或调试工具；文档没有提供安装命令、收费信息或平台支持说明，这些内容暂未提供。