zouyangxiaohao111
zouyangxiaohao111/javaclawbot
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/zouyangxiaohao111/javaclawbot --skill systematic-debugging命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 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 - 用条件轮询替换任意超时相关技能：
来自调试会话：