# Root Cause

> Apply 5 Whys + Fishbone (Ishikawa) + Pareto when something already broke and you need to find the root cause, not the symptom. Use whenever 用户 says "为什么会这样" / "找根因" / "这个 bug 怎么发生的" / "用户为什么流失" / "数据为什么跌" / "上次也踩过这个坑" / "incident postmortem" / "事故复盘". Forces 5-level "why" probing past the first surface answer, distinguishes proximate cause from root cause, uses Fishbone's 6M categories (man/machine/method/material/measurement/environment) for systemic issues, applies Pareto 80/20 to prioritize fixes. Stops "fix the symptom" pattern. Self-contained methodology — no external docs required.

- Skill: `marsloting/root-cause` (Agent Skill)
- Install (CLI): `npx skillmds@latest add marsloting/root-cause`
- Raw SKILL.md: https://api.skillmd.com/api/skills/marsloting/root-cause/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: marsloting (https://skillmd.com/u/marsloting)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/marsloting/root-cause

---


# 根因分析（5 Whys + Fishbone + Pareto）

## 何时触发

- 已经发生的问题 / bug / incident / 数据异常
- "为什么 X" 类问题
- 重复出现的同类问题（"上次也踩过"）
- 用户流失 / 转化下降 / 留存崩盘
- 上线后事故复盘
- "这次修了，下次还会不会"

## 何时不触发

- 上线前的风险预测 → 用 `pre-mortem`
- 多个候选项排序 → 用 `rice-prioritization`
- 用户需求挖掘 → 用 `jtbd-framework`

## 默认起点：5 Whys（Toyota 经典）

最简单最有效。从症状开始连问 5 个 why，每个 why 的答案是下一个 why 的输入。

### 标准模板

```
症状：<具体观察到的问题>
↓ Why 1?
答案 1：<直接原因>
↓ Why 2?
答案 2：<更深一层>
↓ Why 3?
答案 3：<更深一层>
↓ Why 4?
答案 4：<更深一层>
↓ Why 5?
答案 5：<根因，通常是流程 / 文化 / 系统设计层>
```

### 经典案例（Toyota）

```
症状：机器停转
Why 1? 保险丝烧了
Why 2? 电流过载
Why 3? 轴承润滑不足
Why 4? 润滑泵工作不正常
Why 5? 润滑泵的轴磨损（根因 → 替换轴 + 增加维护流程）
```

如果只修到 Why 1（换保险丝），下次还会烧。修到 Why 5（替换轴 + 加流程），从根上解决。

### 5 Whys 红线

- **不允许在 Why 3 之前停**：到 Why 3 大概率还在症状层
- **不允许全程指向同一个人**："因为 X 没做好"5 次出现 = 你在找替罪羊不是找系统问题
- **不允许循环回路**：Why 4 答案 = Why 1 答案 → 你在原地打转
- **每层 why 必须可证伪**："因为大家不重视"不是答案，要继续问"什么导致大家不重视"

## 升级：Fishbone (Ishikawa) Diagram

5 Whys 假设单一因果链。当问题是**多因素叠加**时（症状有多个并行原因），用 Fishbone。

### 6M 分类（生产 / 工程标准）

```
                                    ┌─ Man (人)
                                    │
         Method (方法) ──┐         ┌─┘
                          ↓         ↓
症状 ←────────── 原因汇集 ─────────────
                          ↑         ↑
         Machine (机器) ─┘         └─ Material (材料)
                                    │
                                    └─ Environment (环境)
                                       Measurement (测量)
```

### 6M 在软件 / 产品场景的映射

| 类别 | 软件 / 产品场景含义 |
|---|---|
| **Man（人）** | 用户行为 / 团队技能 / 沟通 / 培训缺失 |
| **Machine（机器）** | 基础设施 / 服务器 / 第三方依赖 / 工具链 |
| **Method（方法）** | 流程 / SOP / 协议 / 评审机制 |
| **Material（材料）** | 数据 / 文档 / 内容 / 素材 |
| **Measurement（测量）** | 监控 / 日志 / 指标定义 / 告警阈值 |
| **Environment（环境）** | 部署环境 / 时间窗口 / 业务背景 / 合规约束 |

每个类别下列至少 2 条可能原因 → 6 × 2 = 12 个起点 → 找出真正贡献度最高的 2-3 个。

## 收敛工具：Pareto 80/20

Fishbone 列出 12+ 原因后，**80% 的影响通常来自 20% 的原因**。

### 评估流程

1. 每条原因估算"贡献度百分比"（团队投票或数据估算）
2. 排序 → 累计百分比达到 80% 的项是关键少数
3. 优先 fix 关键少数，其余记录但不主动 fix

### Pareto 红线

- **不允许把所有原因平均分配权重**：12 条原因每条 8% = 没分析
- **关键少数通常 2-4 条**：超过 6 条说明你没真正归因
- **数据估算 > 团队投票**：能量化用量化（错误率 / 用户数 / 工时）

## 5 步标准流程

1. **症状陈述**：写下"具体观察到什么"，不写解读。"用户流失" → 不行。"用户在 onboarding 第 3 步流失率从 20% 上升到 45%" → 行
2. **5 Whys 起步**：从症状开始连问 5 个 why。卡在 Why 3 之前 = 没到根因
3. **多因素信号检测**：5 Whys 答到 Why 3-4 时如果出现"原因有好几个"——切换到 Fishbone
4. **Fishbone 6M 列原因**：每个 M 类别至少 2 条
5. **Pareto 收敛**：排序 → 关键少数 → 优先 fix

## 模板（完整根因分析）

```markdown
# <事故 / 问题> 根因分析

## 症状
- 具体观察：<可量化的描述>
- 时间范围：<开始 - 持续>
- 影响范围：<用户数 / 业务影响>

## 5 Whys（如单因素链）
- Why 1: ... → 答案
- Why 2: ... → 答案
- Why 3: ... → 答案
- Why 4: ... → 答案
- Why 5: ... → 根因

## Fishbone 6M（如多因素）

### Man
- 原因 A1 (贡献度 估 X%)
- 原因 A2 (贡献度 估 X%)

### Machine
- 原因 B1 ...
- 原因 B2 ...

### Method
...

### Material
...

### Measurement
...

### Environment
...

## Pareto 排序
| 原因 | 贡献度 | 累计 |
|---|---|---|
| C1 | 35% | 35% |
| C2 | 25% | 60% |
| C3 | 20% | 80% ← 关键少数线 |
| C4 | 8% | 88% |
| ... |

## 修复动作
- 关键少数 (top 3)：
  - C1 → <具体动作> / Owner / 截止
  - C2 → <具体动作> / Owner / 截止
  - C3 → <具体动作> / Owner / 截止
- 其余记录但不主动 fix（accept）

## 系统性预防（重要）
此根因导致下次 X 还会发生吗？如果会，加什么流程 / 监控 / 协议防止？
```

## Anti-Rationalization

| 逃逸路径 | 为什么不行 |
|---|---|
| "Why 2 已经找到原因了" | Why 2 几乎都是症状层。强制问到 Why 5，到流程 / 系统 / 文化层才是根因 |
| "因为 X 没做好" 重复 5 次 | 你在找人背锅不是找系统问题。换问题：是什么让 X 没做好的环境 / 流程 / 工具？ |
| "5 Whys 太呆板" | 呆板是 feature 不是 bug。强制深挖防止思维断在第一层 |
| "Fishbone 太正式不适合 startup" | 6M 是分类工具不是仪式。startup 团队 30 分钟跑完 Fishbone 比"凭感觉找原因"准 5 倍 |
| "Pareto 估贡献度不准" | 不准也比不估好。team 三人独立估 → 取中位数 → 偏差 ±10% 内已经足够指导决策 |
| "只修关键少数其他不管" | Pareto 是 80/20 不是 100/0。关键少数优先 fix，其他记录 + 监控，发现升级时再处理 |
| "找到根因就行了不用管系统预防" | 只 fix 实例 = 同根因第二次还会发生 = 重复劳动。系统性预防（加流程 / 加监控 / 加协议）是根因分析的必要产出，不是 nice-to-have |
| "incident postmortem 模板我们公司有" | 公司模板 ≠ 5 Whys。多数公司 postmortem 停在 Why 2-3 层（"修了 bug 加了监控"）。本 skill 强制 Why 5 + 系统预防 |

## 关联

- 找到根因后修复优先级排序：用 `rice-prioritization`
- 系统性预防方案要 review：用 `pre-mortem`
- 重大事故升级到全局复盘：写到 `methodology/internal-retrospective-YYYY-MM-DD.md`（参考 retrospective-hygiene 5 条偏差）
- 同根因第二次出现 → 触发 cross-domain-defense 第三层熔断

## Status

v1.0 — 2026-05-08 product-thinking plugin v0.1.0 首发。