Systematic Debugging 是一个用于排查和修复技术问题的四阶段调试框架，核心理念是：在尝试任何修复之前，必须先找到根本原因，仅修复表面症状被视为失败。
用途
该框架用于处理任何技术问题，包括测试失败、生产环境中的 Bug、不符合预期的行为、性能问题、构建失败以及集成问题。它特别强调在以下情形中使用：时间压力很大（紧急情况容易让人凭猜测行事）、看起来“只需要改一处”就 obvious 能解决、已经尝试过多次修复、之前的修复没有生效、或者尚未完全理解问题本身。同时，文档明确反对因为问题看似简单、自己赶时间、或管理者要求立刻修复就跳过流程。
主要能力
框架由四个必须依次完成的阶段组成，并附有可复制的进度检查清单。
第一阶段：根因调查。 在尝试任何修复之前，需要：仔细阅读错误信息与堆栈追踪，注意行号、文件路径和错误码；稳定复现问题，确认触发步骤和是否每次都发生，无法复现时应继续收集数据而非猜测；检查最近的更改，包括 git diff、近期提交、新依赖、配置变更和环境差异；在多组件系统中，在提出修复前于每个组件边界添加诊断性观测，记录进入和离开组件的数据、验证环境与配置的传递、检查每一层的状态，运行一次以收集证据显示“在哪里”出了问题，再分析证据定位失败组件；当错误位于调用栈深处或无法判断非法数据来源时，向后追踪数据流，使用“五个为什么”加回溯调用链找到最初的触发点，从源头修复。文档给出了跨层系统（工作流、构建脚本、签名脚本、实际签名）的示例，以及用于追踪调用链的代码示例；当调用链不清楚时，可临时添加带 // debug-shim 标记的观测代码。所有临时调试代码必须包含 // debug-shim 标记，以便通过 grep 可靠清理，并在完成第四阶段前用 grep -r "debug-shim" . 搜索并移除。文档还列出若干战术性调试技巧：二分搜索/代码二分、最小复现、策略性日志与观测、运行时断言、差异分析、多组件系统调试。
第二阶段：模式分析。 修复前先找模式：在同一代码库中寻找可工作的相似示例；对照参考实现时要完整阅读每一行，不要略读；列出工作版本与故障版本之间的每一处差异，不论多小；理解依赖关系，包括需要的其他组件、设置、配置、环境以及它所做的假设。
第三阶段：假设与测试。 采用科学方法：形成单一假设，明确表述“我认为 X 是根因，因为 Y”并写下来；做最小改动来验证，一次只改一个变量；继续之前先验证结果，成功则进入第四阶段，失败则形成新的假设，而不是在原有基础上叠加更多修复。当确实不知道时，应直接说明、求助或进一步研究。
第四阶段：修复实施。 修复根因而非症状：先创建失败测试用例（尽可能自动化，必须存在于修复之前）；实施单一修复，一次只改一处，不做“顺手”的改进，不捆绑重构；应用纵深防御，在根因修复之外于各层添加验证（入口点校验输入、核心逻辑校验前置条件、环境守卫如 NODE_ENV 检查或目录限制），使 Bug 即使在将来代码变化后也难以重新引入；验证修复，确认测试通过、没有破坏其他测试、问题确实解决；如果修复无效，计数已尝试的修复次数，小于三次则回到第一阶段用新信息重新分析，达到三次及以上则停止并质疑架构，与人类伙伴讨论，而不是继续尝试第四次修复。
使用方式
使用时，复制文档提供的调试进度清单并逐项勾选，确保在进入下一阶段前完成当前阶段的全部条目。文档还给出“红旗”信号：一旦发现自己想“先快速修一下，之后再调查”“试试改 X 看行不行”“一次改多处再跑测试”“跳过测试手动验证”“大概是 X，我来修”“我不完全理解但也许能行”等想法，或提出解决方案之前没有追踪数据流时，都应停止并回到第一阶段。
适用场景
除了各类工程 Bug 排查，该框架还可与写作测试（writing-tests）、基于条件的等待（condition-based-waiting）、完成前验证（verification-before-completion）、日志阅读（reading-logs）等技能配合使用。文档还提供了调试完成后的报告模板，包含根因、问题所在、修复内容与验证清单，并说明当系统化调查发现确实没有根因（环境、时序或外部因素）时，应记录所调查的内容、实施重试/超时/错误信息等适当处理并添加监控，同时提醒 95% 的“没有根因”情况其实属于调查不完整。
限制
文档强调这是流程性框架，需要严格遵守阶段顺序；其关于首次修复率（95% 对 40%）、耗时（15-30 分钟对 2-3 小时）等数据来自调试会话的经验性描述。除此之外，该框架不包含具体的安装命令、代码库集成方式或平台要求，相关资料暂未提供。