Menu
The review-first prompt is selected by default. You can switch to a direct command or download a local copy.
Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
npx skills add https://github.com/zouyangxiaohao111/javaclawbot --skill systematic-debuggingThe command stays on one line. Scroll horizontally to inspect it before copying.
Prefer a local copy? Download the files currently available to SkillsMP.
Based on SOC occupation classification
Showing SKILL.md
| name | systematic-debugging |
| description | 当遇到任何 bug、测试失败或意外行为时使用，在提出修复方案之前 |
随机修复浪费时间并制造新 bug。快速补丁掩盖潜在问题。
核心原则： 在尝试修复之前始终找到根本原因。修复症状是失败。
违反此流程的字面意思就是违反调试的精神。
没有根本原因调查就不能修复
如果你还没有完成阶段 1，就不能提出修复方案。
用于任何技术问题：
特别在以下情况使用：
不要跳过：
你必须完成每个阶段才能进入下一个。
在尝试任何修复之前：
仔细阅读错误信息
一致地复现
检查最近的更改
在多组件系统中收集证据
当系统有多个组件时（CI → 构建 → 签名，API → 服务 → 数据库）：
在提出修复之前，添加诊断埋点：
对于每个组件边界：
- 记录进入组件的数据
- 记录离开组件的数据
- 验证环境/配置传播
- 检查每层的状态
运行一次收集证据，显示在哪里中断
然后分析证据识别故障组件
然后调查该特定组件
示例（多层系统）：
# Layer 1: Workflow
echo "=== Secrets available in workflow: ==="
echo "IDENTITY: ${IDENTITY:+SET}${IDENTITY:-UNSET}"
# Layer 2: Build script
echo "=== Env vars in build script: ==="
env | grep IDENTITY || echo "IDENTITY not in environment"
# Layer 3: Signing script
echo "=== Keychain state: ==="
security list-keychains
security find-identity -v
# Layer 4: Actual signing
codesign --sign "$IDENTITY" --verbose=4 "$APP"
这揭示： 哪层失败（secrets → workflow ✓, workflow → build ✗）
追踪数据流
当错误在调用栈深处时：
请参阅本目录中的 root-cause-tracing.md 了解完整的向后追踪技术。
快速版本：
在修复之前找到模式：
找到工作示例
与参考对比
识别差异
理解依赖
科学方法：
形成单一假设
最小化测试
验证后再继续
当你不知道时
修复根本原因，而非症状：
创建失败测试用例
zjkycode:test-driven-development 技能编写正确的失败测试实现单一修复
验证修复
如果修复不起作用
如果 3 次以上修复失败：质疑架构
表明架构问题的模式：
停止并质疑基础：
在尝试更多修复之前与你的伙伴讨论
这不是失败的假设 - 这是错误的架构。
如果你发现自己在想：
所有这些都意味着：停止。返回阶段 1。
如果 3 次以上修复失败： 质疑架构（见阶段 4.5）
注意这些重定向：
当你看到这些：停止。返回阶段 1。
| 借口 | 现实 |
|---|---|
| "问题很简单，不需要流程" | 简单问题也有根本原因。流程对简单 bug 很快。 |
| "紧急情况，没时间走流程" | 系统化调试比猜测检查的盲目尝试更快。 |
| "先尝试这个，然后调查" | 第一次修复设定模式。从一开始就做对。 |
| "我会在确认修复有效后写测试" | 未测试的修复不会持久。测试先证明它。 |
| "一次多个修复节省时间" | 无法隔离什么有效。导致新 bug。 |
| "参考太长，我会适应模式" | 部分理解保证 bug。完整阅读。 |
| "我看到问题了，让我修复它" | 看到症状 ≠ 理解根本原因。 |
| "再尝试一次修复"（2 次以上失败后） | 3 次以上失败 = 架构问题。质疑模式，不要再修复。 |
| 阶段 | 关键活动 | 成功标准 |
|---|---|---|
| 1. 根本原因 | 阅读错误、复现、检查更改、收集证据 | 理解什么和为什么 |
| 2. 模式 | 找到工作示例、对比 | 识别差异 |
| 3. 假设 | 形成理论、最小化测试 | 确认或新假设 |
| 4. 实现 | 创建测试、修复、验证 | Bug 解决，测试通过 |
如果系统化调查揭示问题确实是环境、时序依赖或外部的：
但是： 95% 的"没有根本原因"案例是不完整的调查。
这些技术是系统化调试的一部分，可在本目录中找到：
root-cause-tracing.md - 通过调用栈向后追踪 bug 以找到原始触发点defense-in-depth.md - 在找到根本原因后在多层添加验证condition-based-waiting.md - 用条件轮询替换任意超时相关技能：
来自调试会话：