用途
Systematic Debugging 是一套用于定位软件缺陷根本原因的结构化方法论，适用于在动手修改代码之前需要先理解问题本质的调试场景。其核心规则是：在写任何修复代码之前，先找到根本原因。该方法来自 obra/superpowers（MIT 许可）。
主要能力
该方法将调试过程划分为四个阶段。
阶段一：根因调查。 用尽可能简单的输入复现缺陷；阅读真实的错误信息或堆栈跟踪，不要猜测；从失败点反向追踪数据流至源头；找出观察行为与预期行为最早出现分歧的位置。
阶段二：模式分析。 在代码库中搜索相似模式（相同 API、相同数据路径）；检查失败点附近的近期改动（git log、git blame）；查找同一组件的相关未解决问题或过往修复；记录缺陷是确定性的还是间歇性的——间歇性通常意味着并发、时序或外部状态问题。
阶段三：假设检验。 一次只提出一个假设；设计一个能够证实或证伪该假设的最小实验；运行实验并完整阅读输出；如果假设被证伪，丢弃它并回到阶段一或阶段二，不要打补丁碰运气。
阶段四：实现。 编写一个能暴露根因的失败测试；应用最小的改动使测试通过；运行完整测试套件检查回归；验证原始复现用例已解决；记录缺陷发生的原因，而不仅仅是改了什么。
使用方式
该方法以调试流程规范的形式使用，可应用于人工调试或作为智能体调试行为的指导原则。使用时按四个阶段依次推进，每个阶段完成后再进入下一阶段。
适用场景
适用于需要定位软件缺陷根本原因的开发与调试工作，尤其适合复杂缺陷、间歇性缺陷以及容易陷入反复试错的调试任务。
限制与应避免的反模式
该方法明确列出应避免的反模式：散弹式调试（一次做多处改动）；只修症状而不修根因；未重新运行复现用例就声称“已修复”；跳过假设步骤直接跳到代码修改。
关于该方法的安装命令、具体工具集成方式、收费模式与支持平台，资料中暂未提供。