RootCause Pilot · 根因分析（5 Whys / 鱼骨图）
站在 丰田 · 质量管理 立场，把两条经典方法论变成可执行的检查引擎：
- 大野耐一（Taiichi Ohno）· 5 Whys：对现象反复追问「为什么」，直到找到可采取措施的那一层——停在表面现象不算根因，追到失控的宇宙起源也不算。
- 石川馨（Kaoru Ishikawa）· 鱼骨图 6M：用 人 / 机 / 料 / 法 / 环 / 测 六个维度穷尽原因，避免归因盲区；且多数质量问题根源于 「法」（流程/管理/机制），不是个人失误。
引擎不只画两张图，它做四件人容易偷懒的事：校验追问深度、校验证据完备度、检查归因是否偏向「人」、把根因翻译成可执行且有验证指标的三级对策。
何时使用
- 「为什么会发生这个问题」「帮我找根因」「做个 5 Whys」
- 「用鱼骨图分析一下」「按 6M 归个类」
- 「这个问题复盘一下 / 排查一下」「写个 8D 的根因部分」
- 「大家都说是某人不认真，我该怎么验证？」
快速开始
cd /workspace/rootcause-pilot
python3 scripts/analyze.py \
--input examples/causes.csv \
--out examples/report/ \
--name "订单交付延迟根因分析"
零依赖、零安装（仅 Python 3 标准库）。输出 examples/report/ 三件套：
| 文件 | 内容 |
|---|---|
report.json |
结构化数据：节点链、根因、6M 分布、证据完备度、三级对策、诊断提示 |
report.md |
可直接贴进复盘文档的 Markdown（含 5 Whys 表、分布表、三级对策） |
report.html |
自包含交互报告：SVG 因果链树 + SVG 鱼骨图，节点可点击高亮整条链、类别筛选、对策卡折叠 |
输入格式
CSV（推荐）
表头：层级,问题,原因,类别,证据
层级,问题,原因,类别,证据
1,,订单交付延迟,,有
2,订单交付延迟,产线产能不足,机,无
3,产线产能不足,排产计划变更频繁,法,有
4,排产计划变更频繁,需求预测准确率低,法,无
5,需求预测准确率低,缺少历史数据沉淀与复盘机制,法,无
| 列 | 说明 |
|---|---|
| 层级 | 1..N。1 = 表面现象/问题（该行「原因」列填现象本身），其后逐层追问；最深一层即根因 |
| 问题 | 本层被追问的现象（= 上一层的「原因」）。留空会自动继承，可整列省略 |
| 原因 | 本层的答案（为什么会出上一层的问题） |
| 类别 | 鱼骨 6M：人 / 机 / 料 / 法 / 环 / 测（可空，空则计入「未分类」） |
| 证据 | 有 / 无，也可直接写文字证据（如「近 8 周排产变更 37 次」），写了即算有证据 |
同一层级写多行 = 分支（并列原因），引擎会画成树并分别判定根因/分支末端。
JSON
{
"name": "订单交付延迟根因分析",
"problem": "订单交付延迟",
"rows": [
{ "层级": 1, "原因": "订单交付延迟", "证据": "交付准时率由 92% 降至 71%" },
{ "层级": 2, "问题": "订单交付延迟", "原因": "产线产能不足", "类别": "机", "证据": "无" }
]
}
顶层也可以是数组，或用 causes / data 代替 rows；列名支持中英文别名（level/problem/cause/category/evidence）。
引擎算什么
| # | 能力 | 规则 |
|---|---|---|
| 1 | 因果链构建 | 按层级与「问题→原因」对应关系建树；「问题」列留空时自动继承上一行原因；支持多分支 |
| 2 | 根因识别 | 最深层级（Lmax）的末端原因 = 根因；浅于 Lmax 就终止的分支标为「分支末端·待追问」，不冒充根因 |
| 3 | 深度校验 | 层级 < 3 →「追问不足，尚未触及根因」；> 7 →「追问过深，可能已偏离可控范围」 |
| 4 | 鱼骨 6M 聚合 | 统计各类原因数量与占比（现象层 L1 不计入分母），识别主导类别 |
| 5 | 证据完备度 | 有证据环节数 ÷ 总环节数。< 60% → 强烈提示「多个环节为推测，补数据验证后再下结论」；60–80% → 待补；≥ 80% → 可进入对策 |
| 6 | 三级对策 | 每个根因生成：临时（0–48h 遏制）/ 长期（2–8 周根治）/ 预防（1–3 月防再发 + 横展），含行动项、责任人建议与验证指标 |
| 7 | 归因纠偏 | 「人」类占比 ≥ 40% → 提示先查法/机/料是否防呆；「法」类主导 → 提示对策应落在流程与标准 |
对策模板按 6M 分化，例如：
- 类别 = 法 → 长期对策指向「修订流程文件、增设关键控制点 KCP、RACI 明确职责」
- 类别 = 机 → 长期对策指向「设备改造 + 点检基准 + FMEA 补失效模式」
- 类别 = 测 → 长期对策指向「MSA / GR&R ≤ 10%、统一数据口径」
- 类别 = 人 → 长期对策指向「SOP/OPL + 技能矩阵 + 防呆，而非追加处罚」
报告怎么看
- 先看证据完备度：低于 60% 时，报告里的根因只是假设，先补数据（现地现物）再定责。
- 再看主导 6M 类别：集中在「法」说明是管理机制问题；集中在「人」要警惕把管理责任转嫁给个人。
- 最后看三级对策：每条对策都有责任人与验证指标；验证不达标则回到「为什么」继续追问。
交互用法：点击因果树任一节点 → 高亮该节点所在的完整链条并展示详情；切换到「鱼骨图」看 6M 归类；用类别筛选快速看某一类原因。
输出约束
- HTML 自包含：内联 CSS/JS，图形为内联 SVG，无任何外部 URL / 字体 / CDN，断网可渲染。
- 不生成任何 PNG/JPG 位图。
参考
references/methodology.md：5 Whys 与鱼骨 6M 的完整方法、证据分级、三级对策写法、常见误区。README.md：目录结构、命令参数、输入输出字段说明。
