Menu
Le prompt qui vérifie d'abord la source est sélectionné par défaut. Vous pouvez passer à une commande directe ou télécharger une copie locale.
Lisez SKILL.md et les fichiers associés affichés par SkillsMP avant de décider de l'installer.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
npx skills add https://github.com/linxuan-sys/opencode-skills-chinese --skill systematic-debuggingLa commande reste sur une seule ligne. Faites défiler horizontalement pour la vérifier avant de la copier.
Vous préférez une copie locale ? Téléchargez les fichiers actuellement disponibles dans SkillsMP.
Affichage de SKILL.md
Basé sur la classification professionnelle SOC
| name | systematic-debugging |
| description | 在提出修复方案前，遇到任何bug、测试失败或意外行为时使用 |
随机修复浪费时间还会引入新bug。快速补丁会掩盖根本问题。
核心原则： 在尝试修复前必须找到根本原因。仅修复症状等同于失败。
违反本流程的字面要求就是违背调试的核心精神。
未先开展根本原因调查，绝不提出修复方案
如果你还没有完成第一阶段，就不能提出修复方案。
适用于所有技术问题：
尤其在以下场景必须使用：
以下场景也不要跳过：
你必须按顺序完成每个阶段才能进入下一阶段。
在尝试任何修复前：
仔细阅读错误信息
稳定复现问题
检查最近的变更
在多组件系统中收集证据
当系统包含多个组件时（CI → 构建 → 签名，API → 服务 → 数据库）：
在提出修复方案前，添加诊断埋点：
对每个组件边界：
- 记录进入组件的数据
- 记录离开组件的数据
- 验证环境/配置传递
- 检查每一层的状态
运行一次收集证据，明确哪里出了问题
然后分析证据确定故障组件
再针对该特定组件展开调查
示例（多层系统）：
# 第一层：工作流
echo "=== 工作流中可用的密钥: ==="
echo "IDENTITY: ${IDENTITY:+已设置}${IDENTITY:-未设置}"
# 第二层：构建脚本
echo "=== 构建脚本中的环境变量: ==="
env | grep IDENTITY || echo "IDENTITY不在环境中"
# 第三层：签名脚本
echo "=== 钥匙串状态: ==="
security list-keychains
security find-identity -v
# 第四层：实际签名
codesign --sign "$IDENTITY" --verbose=4 "$APP"
这会揭示： 哪一层出了问题（密钥 → 工作流 ✓，工作流 → 构建 ✗）
跟踪数据流
当错误出现在调用栈深处时：
查看本目录下的root-cause-tracing.md了解完整的反向跟踪技术。
快速版本：
在修复前找到规律：
找到可运行的示例
对照参考实现
识别差异
理解依赖关系
科学方法：
提出单一假设
最小化测试
验证后再继续
当你不确定时
修复根本原因，而非症状：
创建失败测试用例
superpowers:test-driven-development技能编写规范的失败测试实现单一修复
验证修复
如果修复没有生效
如果3次以上修复失败：重新审视架构
表明存在架构问题的模式：
停下来重新审视基础设计：
在尝试更多修复前和你的人类伙伴讨论
这不是假设失败 - 这是架构错误。
如果你发现自己有这些想法：
所有这些都意味着：停止，回到第一阶段。
如果3次以上修复失败： 重新审视架构（见第四阶段第5点）
注意这些提示：
当你看到这些时： 停止，回到第一阶段。
| 借口 | 现实 |
|---|---|
| "问题很简单，不需要走流程" | 简单问题也有根本原因。流程处理简单bug更快。 |
| "紧急情况，没时间走流程" | 系统化调试比猜测试错快得多。 |
| "先试试这个，之后再调查" | 第一次修复会定下调子。从一开始就做对。 |
| "确认修复生效后我再写测试" | 未测试的修复不牢靠。先写测试才能证明修复有效。 |
| "同时改多个地方省时间" | 无法确定哪个改动生效了。还会引入新bug。 |
| "参考实现太长，我改改用就行" | 一知半解肯定会出bug。完整阅读参考实现。 |
| "我知道问题在哪，我来修复" | 看到症状 ≠ 理解根本原因。 |
| "再试一次修复"（失败2次后） | 3次以上失败 = 架构问题。重新审视模式，不要继续修复。 |
| 阶段 | 核心活动 | 成功标准 |
|---|---|---|
| 1. 根本原因 | 阅读错误、复现问题、检查变更、收集证据 | 理解是什么问题以及为什么会发生 |
| 2. 模式分析 | 找到可运行示例、对比差异 | 识别出差异点 |
| 3. 假设验证 | 提出理论、最小化测试 | 假设被证实或提出新假设 |
| 4. 实现修复 | 创建测试、修复问题、验证 | bug解决，测试通过 |
如果系统化调查显示问题确实是环境相关、时序依赖或外部因素导致的：
但是： 95%的"没有根本原因"情况都是调查不完整导致的。
这些技术是系统化调试的一部分，可在本目录中获取：
root-cause-tracing.md - 反向跟踪调用栈找到bug的原始触发点defense-in-depth.md - 找到根本原因后在多层添加验证condition-based-waiting.md - 用条件轮询替代任意超时相关技能：
来自调试实践的数据：