系统化调试

要解决的问题

线上故障来了，最常见的应对是先猜再改：看到报错就改代码，改完发现别的地方又炸了。这种做法的问题在于，你修掉的往往只是症状，真正的根因还留在系统里，等待下一次爆发。Systematic Debugging 就是为解决这个问题而生的——它把调试从「凭经验碰运气」变成「按步骤做调查」，核心原则只有一句话：在动手修复之前，先彻底理解 bug。

技能如何工作

该技能采用四阶段（4-phase）的根因调试流程，围绕 root-cause 与 investigation 两个关键词展开：

• 先理解，再动手：在修改任何一行代码前，先回答「这个 bug 到底是什么、为什么会发生」，而不是「怎么让它不再报错」；
• 结构化调查：通过系统性的问题排查（troubleshooting）收集证据，缩小怀疑范围，而不是在代码里漫无目的地翻找；
• 根因导向：只有定位到真正的根因，修复才有意义；否则改动只是把问题推迟到下一次部署。

从元数据看，它与 test-driven-development、plan、subagent-driven-development 等技能形成互补：你可以用规划类技能理清思路，用本技能做故障定位，再用 TDD 确保修复不引入回归。

适用边界

• 它是方法论层面的调试引导，不是自动化工具，不会替你读日志或改代码，执行效果取决于使用者是否真正遵循流程；
• 适用于开发过程中的 bug 调查与根因分析（problem-solving），对于纯环境配置、基础设施故障等非代码问题，帮助有限；
• 该技能由 Hermes Agent 基于 obra/superpowers 改编，MIT 许可，可在 Linux、macOS、Windows 上使用。