Systematic Debugging（系统化调试）
任何 bug 都必须先完成根因排查再提修复方案，明确禁止「先随手改一下试试」
为测试失败、生产缺陷、构建失败、性能问题和集成异常提供了清晰的四阶段根因调查流程，能减少猜测式修复和回归风险。适用范围明确，但“任何技术问题都必须先完成全部阶段”的绝对规则可能不适合紧急缓解、已知简单故障或需要先恢复服务的场景；其相对收益主要来自文档主张，缺少独立验证。
步骤结构化、检查点明确，并规定单一假设、最小化测试、失败后重新分析以及三次失败后质疑架构。提供了根因追踪、条件等待、纵深防御和污染测试脚本等配套材料。证据不足之处包括未证明这些材料在不同语言、测试框架、平台或实际项目中可复现；脚本依赖 Bash、find 和 npm test，且会忽略单个测试命令失败，可能掩盖诊断问题。
技能本身不自动执行外部操作，也没有要求联网、凭据读取或数据外传，因此直接权限风险较低。但示例明确记录环境变量、密钥可用性、密钥链身份和调用栈，缺少敏感信息脱敏、最小日志范围、存储期限和删除要求；调试中的 git init、测试运行和文件状态检查也缺少明确的用户确认、隔离和回滚规范。绝对禁止先缓解再调查的规则在生产事故中可能扩大业务损失。
SKILL.md 和配套文件提供了可追踪的步骤、示例和测试场景；CREATION-LOG.md 声称四项验证测试全部通过，并声称有实际测试结果和影响数据。但本次仅进行静态审查，无法确认这些测试确实执行、测试环境、样本、版本或结果；“95%”“60%到100%”“1847 tests passed”等数字没有独立证据，事实与作者总结未充分区分。
触发条件、阶段划分、反模式、成功标准和若干命令示例较清晰，读者可直接形成调查清单。缺口包括没有统一的输入输出模板、诊断记录格式、适配不同语言和工具链的说明，也没有系统说明日志敏感性、成本控制、并行测试影响、权限要求和无法完成某阶段时的退出或升级路径；相关技能引用也假定其他技能可用。
仓库提供 MIT 许可证、包版本 6.1.1、创建日志和贡献/更新说明，具备一定治理线索。选定技能自身没有版本号、变更历史、维护责任人、兼容性矩阵或明确的技能级更新路径；创建日志日期为 2025-10-03，但不能据此确认当前有效性。发布者未经过 FollowSkills 企业注册表验证，因此身份和治理责任只能视为未知，不能额外加分。
- 不要直接复制示例中的环境变量、密钥链身份或凭据可用性日志；先脱敏、限制范围并确认日志不会进入共享或持久化系统。
- 生产事故中应由人工决定是否先采取有回滚的临时缓解措施；不要把“无根因不得修复”当作无条件替代事件响应策略。
- 运行 find-polluter.sh 前应在隔离工作区确认测试副作用、命令权限和清理方案；该脚本会逐个运行测试并忽略测试命令错误。
- 创建日志中的测试通过和效果数字仅是未验证的作者声明，不应视为独立质量证明。
它能做什么 & 适用场景
把调试拆成四个必须依次完成的阶段：根因排查、模式分析、假设与验证、实施修复，铁律是「没做完第一阶段就不能提修复方案」。文档收录了大量真实场景下的「合理化借口」原句（比如「问题看起来很简单」「先随便试一下改这个」）并逐条给出反驳，还内置一条「连续 3 次修复都失败要停下来质疑架构本身」的规则，防止在错误方向上无限打补丁。
Phase 1 根因排查：完整读错误信息和堆栈、确认能稳定复现、检查最近改动、多组件系统要在每个组件边界加诊断日志定位故障发生在哪一层；Phase 2 模式分析：找同代码库里能正常工作的类似例子、逐条列出和故障代码的差异；Phase 3 假设与验证：只提一个明确假设、做最小改动验证、不行就换新假设而不是在旧修复上叠加新修复；Phase 4 实施：先写一个能复现问题的失败测试（结合 test-driven-development skill）、只做一处改动、验证通过且没有连带破坏其他测试。如果同一问题连续 3 次修复失败，规则要求停下来跟人讨论是不是架构本身有问题，而不是继续尝试第 4 次修复。
- 测试失败、生产环境报 bug、性能异常等任何技术问题排查的默认前置步骤
- 跨组件的问题（比如 CI → 构建 → 签名这种多层系统）先加诊断日志定位到底哪一层出的问题，而不是凭直觉猜
- 同一个 bug 已经改了两次没解决，第三次修复失败后触发「停下来质疑架构」的规则，而不是继续硬着头皮改第四次
优缺点一览
- 把「随手改改试试」这种最常见的低效调试模式，用铁律+合理化借口对照表的形式明确禁止，而不是泛泛建议「要仔细排查」
- 「连续 3 次修复失败要质疑架构」这条规则很有实际价值，能防止在错误方向上无限投入时间
- 文档给出了「95% 的『找不到根因』其实是排查不彻底」这类具体判断标准，而不是含糊的经验之谈
- 只在会自动读取和遵循 SKILL.md 指令的 harness 里可靠工作（Claude Code、Codex CLI 等）；纯聊天式界面里等于一份说明文档，需要人工照做。
- 四阶段流程对真正简单的 bug（比如明显的拼写错误）也要求走完整套排查步骤，在这类场景下略显繁琐
- 多组件诊断日志的方法需要能实际执行命令、读日志输出的环境，纯静态代码分析场景用不上
如何安装
作为 obra/superpowers 插件的一部分安装，不能单独安装某一个 skill：
- Claude Code：官方市场
/plugin install superpowers@claude-plugins-official；或先注册 Superpowers 自建市场/plugin marketplace add obra/superpowers-marketplace，再/plugin install superpowers@superpowers-marketplace - 也支持 Antigravity、Codex App/CLI、Cursor、Factory Droid、GitHub Copilot CLI、Kimi Code、OpenCode、Pi 等 harness，具体命令见仓库 README
装好后这个 skill 会和其余 13 个 Superpowers skill 一起启用，由 using-superpowers 统一引导、按场景自动触发，无需单独调用。
如何使用
遇到任何 bug、测试失败或非预期行为时自动触发，提出修复方案之前会先走完根因排查流程；时间紧张、看起来是「简单问题」时反而更强调不能跳过（红旗清单里专门列了这类合理化借口）。
对比同类
跟没有这个 skill、直接让模型看到报错就试着改代码相比，这套四阶段流程加了强制的根因确认步骤，实测能显著降低「改了但没真的修好」和引入新 bug 的概率（文档给出的数字是系统化排查 15-30 分钟对比乱改 2-3 小时，首次修复成功率 95% 对比 40%，但这是作者自述的经验数据，不是本站复测验证过的结果）。