关于 parallel-debugging
一种使用竞争假设分析（ACH）和并行 Agent 调查复杂问题的调试框架，适用于需要系统化根因分析的开发团队。它要求按多类故障模式提出假设，并依据证据、置信度和反证进行评估。
主要功能
- 01按六类故障模式生成假设
- 02区分不同强度的证据
- 03要求文件与行号引用
- 04按置信度评估假设
- 05仲裁结果并确定根因
- 06验证修复及相关测试
适用场景
- 01排查存在多种可能原因的缺陷
- 02分析跨模块或组件的问题
- 03减少调试中的确认偏误
- 04根据证据验证修复结果
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/parallel-debugging确认已加载。
附带文件references/hypothesis-testing.md
详细介绍
并行调试
使用竞争性假设分析（ACH）方法论并结合并行 Agent 调查来调试复杂问题的框架。
何时使用此技能
- Bug 有多个可能的根本原因
- 初步调试尝试未能定位问题
- 问题跨越多个模块或组件
- 需要基于证据进行系统化的根本原因分析
- 希望在调试中避免确认偏差
假设生成框架
跨 6 个故障模式类别生成假设：
1. 逻辑错误
- 条件逻辑不正确（运算符错误、遗漏分支）
- 循环或数组访问中的差一错误
- 缺少边界情况处理
- 算法实现不正确
2. 数据问题
- 输入数据无效或不符合预期
- 类型不匹配或强制转换错误
- 预期有值处出现 Null/undefined/None
- 编码或序列化问题
- 数据截断或溢出
3. 状态问题
- 并发操作之间的竞态条件
- 陈旧缓存返回过期数据
- 初始化或默认值不正确
- 共享状态被意外修改
- 状态机转换错误
4. 集成失败
- API 契约违规（请求/响应不匹配）
- 组件之间的版本不兼容
- 环境之间的配置不匹配
- 环境变量缺失或不正确
- 网络超时或连接失败
5. 资源问题
- 内存泄漏导致逐渐退化
- 连接池耗尽
- 文件描述符或句柄泄漏
- 磁盘空间或配额超限
- 低效处理导致 CPU 饱和
6. 环境
- 缺少运行时依赖
- 库或框架版本错误
- 平台特定行为差异
- 权限或访问控制问题
- 与时区或区域设置相关的行为
证据收集标准
什么构成证据
| 证据类型 | 强度 | 示例 |
|---|---|---|
| 直接 | 强 | file.ts:42 处的代码显示 if (x > 0) 应为 if (x >= 0) |
| 相关性 | 中 | 提交 abc123 后错误率上升 |
| 证言 | 弱 | “在我的机器上能正常工作” |
| 缺失 | 不定 | 代码路径中未发现 null 检查 |
引用格式
始终使用 file:line 引用标注证据：
**Evidence**: The validation function at `src/validators/user.ts:87`
does not check for empty strings, only null/undefined. This allows
empty email addresses to pass validation.
置信水平
| 级别 | 标准 |
|---|---|
| 高（>80%） | 多条直接证据、清晰的因果链、无矛盾证据 |
| 中（50-80%） | 部分直接证据、因果链合理、存在轻微歧义 |
| 低（<50%） | 多为相关性证据、因果链不完整、存在一些矛盾证据 |
结果仲裁协议
在所有调查者报告之后：
第 1 步：对结果分类
- 已确认：高置信度、强证据、清晰的因果链
- 可能：中等置信度、有一些证据、合理的因果链
- 已证伪：证据与假设相矛盾
- 无结论：证据不足以确认或证伪
第 2 步：比较已确认的假设
如果多个假设得到确认，按以下顺序排序：
- 置信水平
- 支持证据的数量
- 因果链的强度
- 无矛盾证据
第 3 步：确定根本原因
- 如果一个假设明显占优：将其确定为根本原因
- 如果多个假设可能性相同：可能是复合问题（多个促成原因）
- 如果没有假设得到确认：根据收集到的证据生成新的假设
第 4 步：验证修复
在宣布缺陷已修复之前：
- 修复解决了已识别的根本原因
- 修复未引入新问题
- 原始复现用例不再失败
- 相关边界情况已覆盖
- 已添加或更新相关测试
评论
支持 Markdown