根因链拆解
对已暴露的问题连续追问，拆到可干预的根因层
用这个方法分析
上传录音或转写文本即可，未登录会先引导登录
产出长什么样
示例下面是一段虚构场景的示例产出，用来说明形态。真实分析会锚定你自己录音里的原话。
场景：某科技公司产品上线前的项目延期复盘会，30分钟。
| 维度 | 内容 |
|---|---|
| 现象与直接原因 | 功能X未按计划在版本V2.1中上线。直接原因：技术依赖库LibY引入时间晚于计划，导致联调窗口被压缩。 |
| 根因链 | 1. 直接原因：依赖库引入晚于计划。 |
- 上一层根因：技术负责人未在需求评审阶段识别出对
LibY的强依赖，导致未提前规划。（原文无依据/推断：会议未明确讨论“需求评审流程”，此为从“未识别依赖”的现象推断出的流程执行层问题。） - 更深层根因：新依赖评估未作为产品-技术联合评审的强制检查项。 | | 可干预层定位 | 第三层根因“新依赖评估流程缺失”是可干预层。技术负责人表示：“如果当时有强制检查，我肯定会提。” | | 治标 vs. 治本方案代价对比 | 治标（下个版本强制加班追赶）：即时成本：额外15人日开发工时，消耗团队精力，可能引入新缺陷。 治本（将依赖评估纳入联合评审清单）：前期成本：需0.5人日修订流程文档并组织一次短训；长期收益：避免类似延期，预计可减少未来10%的此类风险。 |
结论：优先启动治本流程优化。张经理总结：“根子上是流程缺项，不能光催进度，要把检查点前置。”
什么时候用它
用在内部会议这类录音上。当内容里出现下面这些信号时，它最派得上用场：
反复出现同类问题
输出的 4 个模块
产出形态是对照矩阵，不是一段分析文字——有形态才能沉淀、才能被下游用。
- 1现象与直接原因
- 2根因链
- 3可干预层定位
- 4治标与治本方案的代价对比
它怎么保证不瞎说
亲证锚定
置信分层
约束与代价
证据不足时它会说「本场没有可供分析的对象，缺的是什么」，而不是编一个结论—— 这是硬要求，不是客套话。
常见问题
- 根因链拆解适合分析什么样的录音？
- 适用于内部会议。典型触发信号：反复出现同类问题。一场录音即可。
- 用根因链拆解会拿到什么？
- 产出形态是对照矩阵，包含 4 个模块：现象与直接原因、根因链、可干预层定位、治标与治本方案的代价对比。
- 根因链拆解不做什么？
- 不得把推断当事实使用；不得据此对个人做定性评价