多假设并行排障

要解决什么问题

遇到复杂 Bug 时，常见的做法是逐一试错：改一个条件、重启一次服务、清一遍缓存。这种方式在故障原因单一时有效，但面对多因素交织的问题时容易陷入两个陷阱——一是过早锁定第一个看似合理的解释（确认偏误），二是证据散落在日志、代码和配置中无人系统归纳。当 Bug 跨模块、且初次排查未能定位根因时，更需要一套结构化的假设—验证—裁定流程。

工作原理

该技能基于竞争性假设分析（ACH）方法论，让多个调查代理并行排查，再按证据强度裁定结论。

1. 假设生成：围绕 6 类故障模式展开——逻辑错误、数据问题、状态异常、集成故障、资源耗尽、环境差异，避免遗漏常见根因类别。

2. 证据收集：区分证据强度——直接证据（如 file.ts:42 处 if (x > 0) 应为 if (x >= 0)）强于相关性证据（某次提交后错误率上升），证言类（"我机器上没问题"）最弱。所有证据均以 文件:行号 形式引用。

3. 结果裁定：调查完成后，假设被分为 Confirmed、Plausible、Falsified、Inconclusive 四类；多个候选根因按置信度、证据数量、因果链强度排序，必要时判定为复合问题；若无一通过则基于已有证据生成新假设。

4. 修复验证：修复前逐项核对：

• 修复针对已识别的根因
• 未引入新问题
• 原复现用例不再失败
• 相关边界用例已覆盖
• 对应测试已补充或更新

适用边界

技能默认将命令与代码作为参考输出，不自动安装依赖、修改系统权限、创建持久化任务或执行下载内容；涉及发送、发布、删除、部署等外部写入操作时，先展示目标与影响并取得明确确认。凭据仅用于用户指定的官方服务，不回显、不记录、不转发到无关地址。