简介
systematic-debugging 是一个很适合开发者工作流的技能，尤其适用于那种面临项目交付时间即将到来，但系统仍然有不少 Bug 的情况 —— 因为在这种情况下，团队可能会下意识地规避对问题根因的定位，转而寻求短期解决方案 —— 能用但可能会掩盖问题的本质根因。这个技能最重要的价值，就是强行打断这种治标不治本的冲动。它不鼓励你直接补丁式修复，而是要求先复现、先收集证据、先把异常一路追溯到根因，最后才动手改代码。
这听起来比“直接试试”更慢，但实际往往更快。随机修修补补很容易掩盖真正的问题，systematic-debugging 的设计目标，就是尽量把这种反复试错扼杀在起点。
核心原则
这个技能围绕一系列硬性规则展开：
- 没有完成根因调查之前，不要提修复方案
- 症状只是信号，不是停止分析的位置
- 证据比直觉更重要
- 一次修复失败代表假设不成立，不代表可以继续堆更多猜测
也正因为这样，它在高压场景里反而特别有用，因为整套流程就是为了抵抗“先快速改一下看看”的冲动而写的。
何时使用
下面这些场景，用 systematic-debugging 会很合适：
- 线上 Bug 反复出现，前面已经做过几次表层修补
- 故障跨越多个层次，例如 CI、构建脚本、API、服务层、数据库或签名流程
- 团队处于时间压力下，大家开始觉得“先猜一个改法”更省事
不适用场景
下面这些情况，不建议把它当成主要工具：
- 当前任务本质上是功能设计或需求探索，而不是故障诊断
- 你已经完成了充分调查，剩下只是做外部兜底或运营层处理
- 你不愿意在修复前先建立最小失败复现
这套流程怎么工作
阶段 1：先查根因
- 把错误信息和完整堆栈读完
- 先把问题稳定复现，而不是凭一次偶发报错下判断
- 检查最近的代码、配置、依赖和环境变化
- 在多组件系统的边界处加日志或诊断信息
- 顺着坏值、坏状态或错误调用链一路往回追，直到找到最初触发点
阶段 2：做模式对比
- 找同仓库里相似但正常工作的实现作参照
- 参考实现要完整读完，不要只扫几眼就开始照抄
- 列出所有差异，哪怕看起来很小
- 明确依赖项、环境前提和隐藏假设
阶段 3：一次只验证一个假设
- 明确写出一个具体的根因假设
- 每次只改一个变量
- 验证结果后再决定下一步
- 如果假设不成立，就回到分析阶段，不要叠更多“顺手修一下”
阶段 4：实现并回归验证
- 先建立最小失败测试或最小复现
- 修根因，不修表象
- 跑相关测试，确认没有带出新的 Bug
- 如果连续三次修复都失败，就应该质疑架构模式，而不是硬上第四个补丁
配套技能
除了主技能，该技能还配套了几个延伸的技能
root-cause-tracing追查问题根因的技能defense-in-depth分层数据有效性校验的技能
这个技能为什么值得用
- 它对抗了人性中想偷懒的天性。强制找出 Bug 的根烟而不是试图掩盖过去
- 它对 Bug 复现定位的日志建议很具体，不只是抽象地说“多打点日志”
- 它把 Bug 复现验证视为调试流程的一部分，而不是“改完再看运气”
- 它对失败修复有明确退回规则，能显著减少无效试错
安装使用
有很多种方法可以安装 skill：
- 安装方法 1：在 OpenClaw 或 Hermes Agent 的聊天窗口，直接告诉 Agent：请帮我安装
systematic-debugging技能。 - 安装方法 2：访问 skillhub 网站，先安装 skillhub 商店，再安装对应技能。
- 安装方法 3：访问 Skills.sh 网站，搜索
systematic-debugging后使用页面提供的命令安装。 - 安装方法 4：访问 Clawhub 网站，搜索技能名后下载压缩包，并放入本地 skills 目录。