语言: 简体中文
免费试用 14 天

官方技能 · 商业思想家的原则

借鉴大野耐一的 5 个为什么根因分析

v1.0.1 · 更新

用大野耐一举例说明的 5 个为什么找出问题的根本原因：可衡量的差距、每一步都有证据的为什么链条，以及针对原因而非症状的对策。

Not affiliated with or endorsed by Taiichi Ohno or their companies. About these principles: Taiichi Ohno's ideas, explained.

添加到团队的 Pod 下载 SKILL.md

可在 Claude、ChatGPT 和编程智能体中使用。在 Team 和 Business 套餐中，Pod 里的官方技能会在我们改进后自动更新到最新版。

适用场景

你需要提供

你会得到

一张每步附证据的为什么链条表、倒读核对、根本原因、带负责人的应急处置和根因对策，以及怎样确认有效。

工作方式

  1. 把问题写成差距 “订单发货延误：上周 140 单中有 12 单，标准是 15:00 前下单当天发货。” 具体、可衡量，并写出标准（原则 4）。
  2. 问第一个为什么 差距为什么会出现？写出直接的、可观察到的原因，并附证据。
  3. 继续追问（原则 1） 对每个答案再问它为什么会发生。每一步一行，各附证据。如果一个答案有两个原因，就分叉，两条都追下去。
  4. 核对每一环 用“所以”把链条倒着读一遍：“没有滤网，所以金属屑进去了，所以泵轴磨损……”。如果某个“所以”说不通，链条就在这一步出了错。
  5. 在根本原因处停下（原则 2） 下一个为什么已超出你能控制的范围（天气、法律）时停下；或者找到的原因是你能消除、消除后故障就不会再发生的，也停下。可能问三次就到了，也可能要问七次。
  6. 制定对策（原则 3） 一条针对根本原因（装滤网）；需要的话，再加一条眼下的应急处置（换保险丝）。分别标明；只有应急处置不算解决。
  7. 写明负责人、日期和验证方法 两周后怎么确认问题没有再发生？

SKILL.md 全文

这就是 AI 读取的完整文件。 下载

---
name: ohno-style-five-whys
description: 按大野耐一为丰田生产方式举例说明的方式，对一个问题做 5 个为什么（5 Whys）根因分析——把问题写成与标准之间的差距，对每个答案继续追问为什么，直到找到能消除的原因（五次只是参考，不是规定），用事实核对每一环，并针对根本原因而不是表面症状采取对策。出现事故、缺陷、延期、客户投诉或反复出现的故障需要找根因，团队总在给同一个症状打补丁，或者有人要做 5 Why、根因分析（RCA）、想知道“为什么老是出这种事”时使用。
---

# 借鉴大野耐一的 5 个为什么根因分析

以下是大野耐一在他关于丰田生产方式的著作中公开阐述过的原则，依据精益企业研究院（Lean Enterprise Institute）词典的概述，以及丰田对他所起作用的介绍。本技能与大野耐一本人及其公司无任何关联，也未获得其认可或背书。本技能针对一个问题，沿着为什么的链条逐步追问、每一步都附证据，最后给出针对根本原因的对策。

## 基本规则

- 不要把引用的出处以外的话或观点归于大野耐一。
- 不要扮演、模仿大野耐一，也不要以他的口吻写作；按下面的原则检查用户提供的材料。
- 链条中的每个答案都要有事实支撑（日志、记录、观察，或亲眼看到的人）。没有的标为“[待确认：...]”，链条在这里停下，核实之后再继续。
- 追问的是流程，不是人。“因为小王忘了”永远不是根本原因；要问流程为什么让人有可能忘。
- 不编造与这次事件有关的事实。

## 原则

1. **反复问为什么。** 问题一出现，就一遍又一遍地问为什么，越过表面症状，找到根本原因。出处：精益企业研究院词典，“5 Whys”。
2. **五这个数字不是重点。** 一直问到找到并消除根本原因为止。出处：同一词条。
3. **消除原因，而不是症状。** 大野耐一自己举的例子是一台停机的机器：过载烧断了保险丝，因为轴承没有润滑，因为油泵抽油不足，因为泵轴磨损了，因为没有滤网挡住金属屑。只换保险丝或只换油泵，故障还会再发生。出处：同一词条，引用大野耐一 1988 年著作第 17 页。
4. **从与标准的差距出发。** 词典把这一方法放在解决问题的过程中：具体定义问题、设定目标、分析根本原因、制定对策。出处：同一词条。
5. **背景。** 丰田认为大野耐一帮助建立了丰田生产方式，其目的是彻底消除浪费、缩短交付周期。出处：丰田，“Toyota Production System”。

## 适用场景

- 事故、故障停机、缺陷或延误交付需要找根本原因。
- 同一个问题“修好”之后又回来了。
- 客户投诉指向的是流程，而不是一次性的意外。
- 团队对一个项目的整体复盘不适用（用 retrospective），把客服工单整理成 bug 报告也不适用（用 bug-report-from-ticket）。

## 需要准备

- 问题：发生了什么、在哪里、什么时候、多频繁，以及本该是什么样（标准）。
- 手头的事实：日志、时间线、记录、谁看到了什么。
- 已经试过的办法。
- 谁能核实你还没有的事实。

## 步骤

1. **把问题写成差距。** “订单发货延误：上周 140 单中有 12 单，标准是 15:00 前下单当天发货。” 具体、可衡量，并写出标准（原则 4）。
2. **问第一个为什么。** 差距为什么会出现？写出直接的、可观察到的原因，并附证据。
3. **继续追问（原则 1）。** 对每个答案再问它为什么会发生。每一步一行，各附证据。如果一个答案有两个原因，就分叉，两条都追下去。
4. **核对每一环。** 用“所以”把链条倒着读一遍：“没有滤网，所以金属屑进去了，所以泵轴磨损……”。如果某个“所以”说不通，链条就在这一步出了错。
5. **在根本原因处停下（原则 2）。** 下一个为什么已超出你能控制的范围（天气、法律）时停下；或者找到的原因是你能消除、消除后故障就不会再发生的，也停下。可能问三次就到了，也可能要问七次。
6. **制定对策（原则 3）。** 一条针对根本原因（装滤网）；需要的话，再加一条眼下的应急处置（换保险丝）。分别标明；只有应急处置不算解决。
7. **写明负责人、日期和验证方法。** 两周后怎么确认问题没有再发生？

## 输出格式

```markdown
# 5 个为什么：[一句话说明问题]
以下是大野耐一公开阐述过的原则。本内容与大野耐一本人及其公司无任何关联，也未获得其认可或背书。

## 问题
**发生了什么：** [可衡量的描述] · **标准：** [本该如何] · **始于：** [日期]

## 链条
| # | 为什么？ | 因为 | 证据 |
|---|---|---|---|
| 1 | | | |
| 2 | | | |
| 3 | | | |

## 倒读核对
[根本原因]，所以 [……]，所以 [问题]。是否成立：是 / 在第 [n] 步不成立。

## 根本原因
[一句话，关于流程]

## 对策
| 类型 | 行动 | 负责人 | 日期 |
|---|---|---|---|
| 应急处置（现在） | | | |
| 根本原因 | | | |

## 怎么确认有效
[衡量指标和日期]

## 使用的原则
[编号，附出处]
```

## 示例

**输入：** “网店。上周 140 单里有 12 单晚发了一天。我们承诺 15:00 前下单当天发货。打包员说有好几个下午面单打印机卡纸。面单在 14:30 集中打印一批。打印机上次保养是 18 个月前；说明书要求每 6 个月一次。打印机没有人负责。”

**输出（节选）：**

```markdown
以下是大野耐一公开阐述过的原则。本内容与大野耐一本人及其公司无任何关联，也未获得其认可或背书。

## 链条
| # | 为什么？ | 因为 | 证据 |
|---|---|---|---|
| 1 | 为什么 12 单晚发？ | 面单没能及时打出来 | 打包员的说法 |
| 2 | 为什么面单没能及时打出来？ | 14:30 那一批打印时打印机卡纸 | 打包员的说法 [待确认：打印机错误日志] |
| 3 | 为什么会卡纸？ | 已超过保养周期 12 个月 | 保养记录；说明书要求每 6 个月一次 |
| 4 | 为什么没做保养？ | 打印机没有人负责，所以没人去约保养 | 输入：“打印机没有人负责” |

## 根本原因
面单打印机没有负责人，所以保养从来没被排进日程；而只在 14:30 打一批，让任何一次卡纸都会变成订单延误。

## 对策
| 类型 | 行动 | 负责人 | 日期 |
|---|---|---|---|
| 应急处置（现在） | 本周给打印机做保养 | [姓名] | [日期] |
| 根本原因 | 给打印机指定负责人，并在日历上排好每 6 个月一次的保养 | [姓名] | [日期] |
| 根本原因 | 面单分两批打印：12:00 和 14:30 | [姓名] | [日期] |
```

## 发送前检查

- [ ] 输出中有出处说明和无关联声明。
- [ ] 问题写成了与标准之间可衡量的差距。
- [ ] 每一步都有证据，或标为 [待确认]。
- [ ] 用“所以”倒读链条时没有断档。
- [ ] 根本原因关于流程，而不是某个人。
- [ ] 有针对根本原因的对策，不只是应急处置，并写明负责人和日期。

## 常见错误

- 停在第一个看似合理的答案上（“打印机卡纸了”）。
- 硬凑正好五步。
- 以某个人的失误收尾。
- 链条全凭看法写成，没有一步有证据。

与团队共享

把它添加到 AI Skill Pod，团队里的每个人（包括外包人员）都能在自己的 AI 中使用同一个版本。 了解与团队共享 AI 技能的最佳方式

添加到团队的 Pod

更新记录

参考来源

  1. 5 Whys - Lean Enterprise Institute lexicon (2026-11-04 查阅)
  2. Toyota Production System - Toyota Motor Corporation (2026-11-04 查阅)