一键导入
systematic-debugging
在遇到任何 bug、测试失败或意外行为时使用,在提出修复方案之前先进行系统排查
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
在遇到任何 bug、测试失败或意外行为时使用,在提出修复方案之前先进行系统排查
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | systematic-debugging |
| description | 在遇到任何 bug、测试失败或意外行为时使用,在提出修复方案之前先进行系统排查 |
随机修复浪费时间并制造新的 bug。快速补丁掩盖了潜在问题。
核心原则: 始终在尝试修复之前找到根因。修症状而非根因就是失败。
违反此流程的字面意义就是违反调试的精神。
没有根因调查就不能提出修复方案
如果你还没有完成第一阶段,就不能提出修复方案。
用于任何技术问题:
特别适用于以下情况:
不要跳过的理由:
你必须在进入下一阶段之前完成每个阶段。
在尝试任何修复之前:
仔细阅读错误信息
稳定复现
检查近期变更
在多组件系统中收集证据
当系统有多个组件时(CI → 构建 → 签名,API → 服务 → 数据库):
在提出修复方案之前,先添加诊断工具:
对于每个组件边界:
- 记录进入组件的数据
- 记录离开组件的数据
- 验证环境/配置的传播
- 检查每一层的状态
运行一次以收集显示在哪里断裂的证据
然后分析证据以识别失败的组件
然后调查该特定组件
示例(多层系统):
# 第一层:工作流
echo "=== 工作流中可用的密钥: ==="
echo "IDENTITY: ${IDENTITY:+SET}${IDENTITY:-UNSET}"
# 第二层:构建脚本
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 - 用条件轮询替代任意超时相关技能:
来自调试会话:
桌面/网关运行时内置的计划创建技能,用于生成可落盘、可调度、可批次执行的结构化计划包。
桌面/网关运行时内置的计划执行技能,用于按批次执行结构化计划包中的单个任务文件。
Use when demonstrating or verifying VibeWindow local plugin packaging, including plugin skills, MCP servers, hook declarations, and interface metadata.
当需要在编码前创建或更新实施计划时使用,尤其适用于多步骤功能开发、重构、包含多个活动部件的缺陷修复,或需要拆分为可独立执行并跟踪进度的任务文件的请求。
当你有书面实现计划需要在单独会话中执行,并带有审查检查点时使用
通过 `rustcodegraph` 命令行界面使用 RustCodeGraph 理解、导航或脚本化操作已索引代码库。当用户要求使用 RustCodeGraph、需要高性能搜索检索代码、需要符号/源码/调用流上下文、调用方/被调用方/影响分析或受影响测试选择时使用。