关于 systematic-debugging
systematic-debugging 是引导技术问题排查的技能，强调先查明根因再修复。四个阶段包括收集证据、对比模式、验证假设，以及实施和核验。
主要功能
- 01四阶段调试流程
- 02修复前调查根因
- 03收集证据并复现问题
- 04以最小改动验证假设
- 05实施后进行核验
适用场景
- 01调查测试或构建失败
- 02追查异常行为的原因
- 03分析多次修复仍失败的问题
- 04处理性能或集成问题
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/systematic-debugging确认已加载。
包含的文件
除 SKILL.md 外，安装时一起下载的参考资料和脚本。
condition-based-waiting-example.tscondition-based-waiting.mdCREATION-LOG.mddefense-in-depth.mdfind-polluter.shroot-cause-tracing.mdtest-academic.mdtest-pressure-1.mdtest-pressure-2.mdtest-pressure-3.mdreferences/debugging-signals.mdfour-phases-detailed.mdscripts/diagnose详细介绍
系统化调试
概述
随机修复会浪费时间，还会引入新的 Bug。快速打补丁会掩盖根本问题。
核心原则： 尝试修复前，务必先找到根本原因。只修复症状就等于失败。
只遵守流程的字面要求，却违背其精神，就是违背调试的初衷。
铁律
NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
如果尚未完成第 1 阶段，就不能提出修复方案。
适用场景
任何技术问题：测试失败、Bug、意外行为、性能问题、构建失败、集成问题。
尤其适用于： 时间紧迫、“先快速修一下”看起来显而易见、已经尝试过多种修复，或尚未完全理解问题时。
不要跳过流程： 即使问题看起来很简单、时间紧迫，或经理要求立即修复。
快速参考 — 四个阶段
| 阶段 | 关键活动 | 成功标准 |
|---|---|---|
| 1. 根本原因 | 阅读错误信息、复现问题、检查变更、收集证据 | 弄清楚是什么问题以及为什么发生 |
| 2. 模式 | 查找可正常运行的示例、进行比较 | 找出差异 |
| 3. 假设 | 提出理论、进行最小化测试 | 得到确认或提出新假设 |
| 4. 实施 | 创建测试、修复问题、验证结果 | Bug 已解决，测试通过 |
各阶段的详细分步说明，请参阅 references/four-phases-detailed.md。
危险信号 — 停下并遵循流程
如果你发现自己在想：
- “先快速修一下，之后再调查”
- “试着改一下 X，看看有没有用”
- “做几处改动，然后跑测试”
- “跳过测试，我手动验证就行”
- “问题大概出在 X，我来修一下”
- “我还没完全弄懂，但这样也许能行”
- “主要问题如下：[未调查就列出修复方案]”
- 尚未追踪数据流就提出解决方案
- “再试一次修复”（已经尝试过 2 次或更多时）
- 每次修复都会在别处引出新问题
以上任何一种情况都意味着：停下，回到第 1 阶段。
如果 3 次或更多修复都失败了： 重新审视架构（见详细参考中的第 4 阶段）。
辅助技术
root-cause-tracing.md— 沿调用栈反向追踪 Bugdefense-in-depth.md— 在多个层级添加验证condition-based-waiting.md— 用条件轮询替代任意超时
相关技能：
- test-driven-development — 创建失败的测试用例（第 4 阶段）
- verification-before-completion — 在宣称成功前验证修复是否生效
有关用户信号、合理化借口表和“找不到根本原因”的处理指南，请参阅 references/debugging-signals.md。
评论
支持 Markdown