Systematic Debugging 是一个严格约束的调试工作流技能，适用于遇到 bug、测试失败或预期外行为时。它的核心目标有三点：修复原因而非症状；阻止基于猜测的修改；先把失败用测试固定，再进行修复。
主要能力与硬性规则：在未建立可复现或可观测状态前不得修改；在未明确写出根因假设前不得修改；在未建立失败测试或等效复现装置前不得修改；一次只验证一个假设；修复时禁止顺手重构；若连续三次修复失败，应先怀疑结构性问题而非继续打补丁。违反流程即视为调试失败。
适用场景：测试失败、本地或线上出现 bug、响应/状态/渲染/查询结果与预期不符、性能下降、超时、竞态条件和间歇性失败，以及修好后又复发的场景。
工作流分七个阶段：1）用一句话定义问题，格式为 Problem: <expected> but got <actual> under <condition>；2）复现或加观测，优先用现有测试、最小集成测试、单元测试、复现脚本或日志；3）收集证据，包括错误信息与完整堆栈、失败输入、最近改动、环境差异、调用路径与数据流，多组件问题需逐边界检查；4）隔离根因，只提出单一假设，格式为 Hypothesis: <root cause> because <evidence>；5）锁定失败，建立自动化失败测试、回归用例或最小复现脚本；6）只做一个修复，禁止捆绑重构、格式化或吞异常；7）验证并收尾，要求原复现路径不再失败、失败守卫通过、相关测试未破坏，并说明修改如何阻断根因。
限制与停止条件：无法复现时不得改代码；三次修复失败应转向结构讨论；没有失败守卫不得宣称完成。适用于需要可追溯、可验证调试流程的开发与测试场景。