反复修改几个可疑位置，偶尔也能让错误消失，但很难知道为什么有效，或者下一次是否还会发生。systematic-debugging 把排查分为明确阶段，要求先解释错误来源，再决定修复位置，适合测试失败、运行异常和跨环境差异。
安装并开始
在 Claude Code 会话内运行下面的插件命令，安装整套 Superpowers，保留各技能之间的衔接。Codex 用户在插件界面搜索并安装 Superpowers；两个客户端需要分别安装。安装后开启新会话，在项目目录里明确提出使用 systematic-debugging，再交代任务范围。
/plugin install superpowers@claude-plugins-official
先把失败讲清楚
以下是可按项目调整的首次输入：
使用 Superpowers systematic-debugging。订单测试本地通过，但 CI 在时区断言失败。先读完整错误、CI 配置和近期相关变更，复现或收集足以定位的证据；一次验证一个假设。不要先改超时或删断言，找出根因后添加回归测试并做最小修复。
输入尽量包含完整错误、复现步骤、预期行为、实际行为和最近变更。只给最后一行日志，可能丢掉真正的调用链。CI 与本地不同，还应比较运行版本、时间或区域设置、测试数据和命令，而不是一开始就判定“CI 不稳定”。
沿着边界收集证据
第一阶段先稳定复现；暂时无法复现时，增加能区分原因的观察。问题经过客户端、接口和数据库时，分别检查输入输出与失败点，缩小是哪一层开始偏离预期。日志记录应围绕必要字段，不需要为了调试把全部环境变量或用户数据打印出来。
接着找一个真正工作的类似路径，比较配置和数据差异。提出一个可以被证伪的假设，例如同一日期在两种时区下被不同解析，再用最小实验验证。一次同时修改三个因素，即使变绿，也难以判断哪一个是原因。
根因确定后才做修复
将失败条件转成回归测试，让测试在修复前确实失败，而且失败原因对应缺陷。随后只修改处理根因的代码，重跑相关测试与项目需要的检查。报告中应说明错误从哪里来、哪段证据支持判断、修复改变了什么，以及还不能覆盖什么。
上游流程在连续多次修复失败后要求重新审视架构，而不是不断叠补丁。若三个尝试都把问题推到别处，应停下来讨论共享假设或设计边界。外部服务波动也可能是真正原因，但应有证据后再选择重试、监测或超时策略。
最终产物应让另一个开发者能复现原问题并理解修复理由。这个技能提供的是排查纪律，并不保证每个问题都能在一次会话内定位；环境不足时，清楚列出下一份需要的证据，比给出没有依据的确定答案更有帮助。
第二个例子：重复扣费从哪一层开始
用户报“点一次付款却收到两笔扣费”时，先保护敏感信息，只用请求 ID、订单 ID、时间和脱敏日志定位两笔交易。沿浏览器请求、网关、业务服务和支付接口逐层对照：浏览器是否发了两次？网关是否重试？服务端是否为同一订单创建了两个支付意图？这几种原因需要不同修复，不能只在按钮上加 disabled 就宣布解决。找到第一处从一次变成两次的边界，是比猜测更可靠的起点。
提出假设后用最小实验检验。例如“网络超时后的重试复用了相同幂等键吗？”先核对请求记录，再构造重复请求的隔离测试；不要在真实支付环境随意复现扣费。确认根因后，把同一订单重复请求的预期结果写成回归测试，修复对应边界，并核查已受影响订单是否需要运营处理。测试只覆盖本地代码时，仍需明确第三方回调、网络重试或旧数据的未验证范围。
部署事故还要单独复盘
先用这个 Skill 找能复现的技术断点：在哪一步、什么输入、哪条日志开始偏离预期。若问题是一次发布事故，还要另做事故复盘，不要把“修好一行代码”当成所有原因都查清。曾有使用者在部署失败后只得到一串表面观察，后来才按时间线拆出机器、材料、人员与操作流程等原因。处理类似事故时，把时间线、影响范围、直接技术故障和流程性成因分开记录；修复技术故障后，再给每个流程原因一个能验证的改进动作。