Back to Details

parallel-debugging

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Parallel Debugging

并行调试

Framework for debugging complex issues using the Analysis of Competing Hypotheses (ACH) methodology with parallel agent investigation.
这是一个使用竞争性假设分析（ACH）方法结合并行Agent调查来调试复杂问题的框架。

When to Use This Skill

何时使用此技能

  • Bug has multiple plausible root causes
  • Initial debugging attempts haven't identified the issue
  • Issue spans multiple modules or components
  • Need systematic root cause analysis with evidence
  • Want to avoid confirmation bias in debugging
  • Bug存在多个合理的潜在根本原因
  • 初步调试尝试未定位到问题
  • 问题涉及多个模块或组件
  • 需要结合证据的系统性根本原因分析
  • 希望在调试中避免确认偏差

Hypothesis Generation Framework

假设生成框架

Generate hypotheses across 6 failure mode categories:
从6个故障模式类别生成假设：

1. Logic Error

1. 逻辑错误

  • Incorrect conditional logic (wrong operator, missing case)
  • Off-by-one errors in loops or array access
  • Missing edge case handling
  • Incorrect algorithm implementation
  • 错误的条件逻辑（运算符错误、遗漏分支）
  • 循环或数组访问中的差一错误
  • 遗漏边界情况处理
  • 算法实现错误

2. Data Issue

2. 数据问题

  • Invalid or unexpected input data
  • Type mismatch or coercion error
  • Null/undefined/None where value expected
  • Encoding or serialization problem
  • Data truncation or overflow
  • 无效或意外的输入数据
  • 类型不匹配或强制转换错误
  • 预期有值但出现Null/undefined/None
  • 编码或序列化问题
  • 数据截断或溢出

3. State Problem

3. 状态问题

  • Race condition between concurrent operations
  • Stale cache returning outdated data
  • Incorrect initialization or default values
  • Unintended mutation of shared state
  • State machine transition error
  • 并发操作之间的竞态条件
  • 缓存过期返回过时数据
  • 初始化或默认值错误
  • 共享状态被意外修改
  • 状态机转换错误

4. Integration Failure

4. 集成失败

  • API contract violation (request/response mismatch)
  • Version incompatibility between components
  • Configuration mismatch between environments
  • Missing or incorrect environment variables
  • Network timeout or connection failure
  • API契约违反（请求/响应不匹配）
  • 组件之间版本不兼容
  • 环境间配置不匹配
  • 缺失或错误的环境变量
  • 网络超时或连接失败

5. Resource Issue

5. 资源问题

  • Memory leak causing gradual degradation
  • Connection pool exhaustion
  • File descriptor or handle leak
  • Disk space or quota exceeded
  • CPU saturation from inefficient processing
  • 内存泄漏导致性能逐渐下降
  • 连接池耗尽
  • 文件描述符或句柄泄漏
  • 磁盘空间或配额不足
  • 低效处理导致CPU饱和

6. Environment

6. 环境问题

  • Missing runtime dependency
  • Wrong library or framework version
  • Platform-specific behavior difference
  • Permission or access control issue
  • Timezone or locale-related behavior
  • 缺失运行时依赖
  • 错误的库或框架版本
  • 平台特定行为差异
  • 权限或访问控制问题
  • 时区或区域设置相关行为问题

Evidence Collection Standards

证据收集标准

What Constitutes Evidence

什么是有效证据

Evidence TypeStrengthExample
DirectStrongCode at 
file.ts:42
shows 
if (x > 0)
should be 
if (x >= 0)
CorrelationalMediumError rate increased after commit 
abc123
TestimonialWeak"It works on my machine"
AbsenceVariableNo null check found in the code path
证据类型可信度示例
直接证据高
file.ts:42
处的代码显示
if (x > 0)
应改为
if (x >= 0)
关联证据中提交
abc123
后错误率上升
陈述证据低"在我的机器上可以正常运行"
缺失证据可变代码路径中未找到空值检查

Citation Format

引用格式

Always cite evidence with file:line references:
**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.
始终使用
文件:行号
的格式引用证据：
**证据**: `src/validators/user.ts:87`处的验证函数
未检查空字符串，仅检查了null/undefined。这导致空邮箱地址可通过验证。

Confidence Levels

可信度等级

LevelCriteria
High (>80%)Multiple direct evidence pieces, clear causal chain, no contradicting evidence
Medium (50-80%)Some direct evidence, plausible causal chain, minor ambiguities
Low (<50%)Mostly correlational evidence, incomplete causal chain, some contradicting evidence
可信度等级判定标准
高（>80%）有多条直接证据，因果链清晰，无矛盾证据
中（50-80%）有部分直接证据，因果链合理，存在轻微歧义
低（<50%）主要为关联证据，因果链不完整，存在矛盾证据

Result Arbitration Protocol

结果判定流程

After all investigators report:
在所有调查人员提交报告后：

Step 1: Categorize Results

步骤1：分类结果

  • Confirmed: High confidence, strong evidence, clear causal chain
  • Plausible: Medium confidence, some evidence, reasonable causal chain
  • Falsified: Evidence contradicts the hypothesis
  • Inconclusive: Insufficient evidence to confirm or falsify
  • 已确认：可信度高，证据充分，因果链清晰
  • 合理：可信度中等，有部分证据，因果链合理
  • 已证伪：证据与假设矛盾
  • 不确定：证据不足以确认或证伪假设

Step 2: Compare Confirmed Hypotheses

步骤2：对比已确认的假设

If multiple hypotheses are confirmed, rank by:
  1. Confidence level
  2. Number of supporting evidence pieces
  3. Strength of causal chain
  4. Absence of contradicting evidence
如果存在多个已确认的假设，按以下优先级排序：
  1. 可信度等级
  2. 支持证据的数量
  3. 因果链的强度
  4. 无矛盾证据

Step 3: Determine Root Cause

步骤3：确定根本原因

  • If one hypothesis clearly dominates: declare as root cause
  • If multiple hypotheses are equally likely: may be compound issue (multiple contributing causes)
  • If no hypotheses confirmed: generate new hypotheses based on evidence gathered
  • 如果某个假设明显占优：将其判定为根本原因
  • 如果多个假设可能性相当：可能是复合问题（多个原因共同导致）
  • 如果没有假设被确认：根据收集到的证据生成新假设

Step 4: Validate Fix

步骤4：验证修复方案

Before declaring the bug fixed:
  • Fix addresses the identified root cause
  • Fix doesn't introduce new issues
  • Original reproduction case no longer fails
  • Related edge cases are covered
  • Relevant tests are added or updated
在宣布Bug修复前，需确认：
  • 修复方案针对已识别的根本原因
  • 修复未引入新问题
  • 原始复现案例不再失败
  • 相关边界情况已覆盖
  • 已添加或更新相关测试