five-whys-skill

name	five-whys-skill
description	五个为什么（5 Whys）的结构化根因分析思维工具。基于 Taiichi Ohno、Eric Ries、Jeff Bezos 等 一手来源的深度调研，提炼 5 个核心原理和完整的操作协议。 触发词：「五个为什么」「5 Whys」「五问法」「根因分析」「为什么会这样」「追问到底」。

五个为什么（5 Whys）· 思维工具

"重复问五次'为什么'，你就会找到问题的根本原因。" —— 大野耐一（Taiichi Ohno），《丰田生产方式》，1978

激活条件与触发词

• 直接调用：「用五个为什么分析...」「5 Whys这个故障」「五问法追查根因」
• 语义触发：用户面对一个具体问题/故障/事故，想知道"为什么会发生"，希望找到根本原因而非仅处理表面症状
• 组合调用：「先用鱼骨图梳理可能原因，再用五个为什么深挖根因」「先用五个为什么定位根因，再用 PDCA 制定改善计划」

方法框架概览

五个为什么的核心是通过连续追问"为什么"穿透表面症状直抵系统性根因，它通过 5 个原理来将模糊的问题转化为可行动的根本解决方案。

核心原理（3-7个，每个须附 ≥2 个跨域证据）

原理 1: 因果链的深度穿透——症状与根因之间存在多层因果关系

一句话定义：每一个可见的问题背后，都有一连串未被审视的因果链条，直到抵达系统性的根本原因。

跨域证据：

1. 制造业（丰田）：大野耐一的经典案例——机器停机，表面原因是保险丝熔断，逐层追问后发现根因是油泵没有过滤网导致金属碎屑进入泵轴（来源：Ohno, Toyota Production System: Beyond Large-Scale Production, 1978）
2. 航空安全：NASA 在事故调查政策 NPR 8621.1 中明确规定，根因分析必须追问"为什么"直至识别出所有系统性贡献因素，而非停留在直接原因（来源：NASA, NPR 8621.1 NASA Procedural Requirements for Mishap Investigation, Appendix I）

应用方式：面对任何故障或问题，不要在第一个答案处停下来，至少追问 3 层以上，直到触及"可以通过改变流程/系统来永久解决"的层面。

局限：因果链条并非总是线性的，复杂问题可能有多条因果分支交汇于不同节点。

原理 2: "五"是指导而非教条——追问深度取决于问题的复杂度

一句话定义：追问的次数不必须恰好五次，关键在于穿透到可采取系统性行动的层面。

跨域证据：

1. 精益管理：大野耐一本人从未硬性规定"恰好五次"。Lean Blog 的分析指出，大野耐一经典案例中实际追问了七层才抵达真正的系统性根因（来源：Lean Blog, "Even Ohno's Classic 5 Whys Example Deserves Another Why", 2026）
2. 软件工程：Google SRE 团队在故障复盘（Postmortem）中不限定追问次数，而是追问到"我们能改变什么系统来防止再次发生"为止（来源：Google SRE Book, Blameless Postmortem for System Resilience, 2016）

应用方式：以"是否已经到达一个可以设计系统性对策的原因"作为停止条件，而非机械地数到五。

局限：对于缺乏经验的执行者，"五次"作为硬性规则仍有其训练价值，避免追问过浅。

原理 3: 根因往往指向系统和流程，而非个人

一句话定义：连续追问会自然地将责任从"谁犯了错"转移到"什么系统允许这个错误发生"。

跨域证据：

1. 互联网/电商：2004 年 Jeff Bezos 在亚马逊仓库亲自主持 5 Whys 分析，一名工人在传送带上夹伤手指，逐层追问后根因指向预算约束导致的编制不足和培训缺失，而非工人个人的疏忽（来源：Brad Stone, The Everything Store, 2013）
2. 创业管理：Eric Ries 在《精益创业》中强调"每一个看似技术问题的根因都是一个人的问题"，5 Whys 应用于组织流程改进而非追责个人（来源：Eric Ries, The Lean Startup, 2011; Eric Ries, "The Five Whys for Start-ups", HBR, 2010）

应用方式：在每一层追问时，如果答案是"某人犯了错"，继续追问"为什么系统允许这个错误发生"，直到找出流程/制度/工具层面的改进点。

局限：在某些场景下（如蓄意破坏、严重渎职），个人责任确实是根因，强行转向系统可能掩盖真正的责任问题。

原理 4: 追问质量取决于提问者的领域知识

一句话定义：同样的问题，不同知识背景的人会构建出不同的因果链条，抵达不同的"根因"。

跨域证据：

1. 可靠性工程：Mark Galley（ThinkReliability 创始人）指出 5 Whys 的最大弱点之一是"受限于调查者的知识面"——同一事件由不同人分析会得出不同的根因，缺乏可重复性（来源：Mark Galley, "Top Criticisms of the 5-Why Approach...and What the Critics Don't Understand", LinkedIn/ThinkReliability）
2. 医疗安全：美国医疗机构评审联合委员会（The Joint Commission）在根因分析框架中强调，RCA 团队必须包含多学科成员，单一视角的分析会导致根因遗漏（来源：The Joint Commission, Framework for Conducting a Root Cause Analysis and Action Plan; AHRQ Patient Safety Network, Root Cause Analysis Primer）

应用方式：执行 5 Whys 时，邀请至少 2-3 个不同职能/视角的人参与，或在每一层验证"还有没有其他可能的'为什么'"。

局限：即使多人参与，仍然受限于团队集体的认知盲区——团队不知道自己不知道的东西。

原理 5: 线性追问的本质是简化的因果模型——适用于单链因果，不适用于多因素耦合

一句话定义：5 Whys 假设问题存在一条从症状到根因的主因果链，但现实问题常由多条因果链交织而成。

跨域证据：

1. 可靠性工程：Mark Galley 明确指出 5 Whys "基于线性的因果推理"，强制产生单一因果链，无法捕捉多因素并行作用和反馈回路，因此"不是一个完整的根因分析方法"（来源：Mark Galley, ThinkReliability Blog, "5-Why is as Simple as a Shovel"）
2. 航空安全：NASA 的学术研究对比了传统 5 Whys 式的单根因分析与"多重系统性贡献因素"分析方法，发现在复杂近失事件中，单根因分析会遗漏关键的系统交互效应（来源：ResearchGate, "Multiple Systemic Contributors versus Root Cause: Learning from a NASA Near-Miss", 2016）

应用方式：如果问题可能涉及多条因果链，在每层追问时同时问"还有其他原因吗？"并画出分支，或将 5 Whys 与鱼骨图（Ishikawa Diagram）结合使用。

局限：对于高度耦合的复杂系统（如大型分布式系统故障、金融危机），仅靠 5 Whys 无法充分刻画因果网络。

原理 6: 根因分析的终点必须是可行动的对策

一句话定义：找到根因不是目的，基于根因设计出能防止问题再发的系统性对策才是。

跨域证据：

1. 精益管理：丰田生产方式中 5 Whys 的每一层追问都要求对应"对策（Countermeasure）"，而非仅停留在"为什么"（来源：Ohno, Toyota Production System: Beyond Large-Scale Production, 1978）
2. 医疗安全：The Joint Commission 的 RCA² 框架（Root Cause Analysis and Action Plan）强调，根因分析必须以"强 corrective action"结尾，且每个行动项须有负责人和完成期限（来源：The Joint Commission, RCA² Framework; Joint Commission Journal on Quality and Patient Safety, "The Effectiveness of Root Cause Analysis"）

应用方式：完成 5 Whys 链后，对最终的根因设计"具体行动项"——谁、在什么时间、做什么改变、如何验证效果。

局限：如果组织文化只奖励"找到原因"而不要求"落实对策"，5 Whys 会沦为纸上谈兵。

操作协议（Agentic Protocol）

Step 1: 问题分类 — 判断 5 Whys 是否适用于当前问题

适用信号：

• 问题有明确的起始事件或可描述的故障现象（"服务器宕机了""客户投诉退款延迟"）
• 问题疑似有单一主因果链（"为什么会这样？"有比较明确的方向）
• 需要快速定位根因并制定对策，而非进行全面的系统分析

不适用信号：

• 问题高度复杂、涉及多个系统交互且因果网络不清晰（如整体架构设计问题、战略方向选择）
• 问题本身就是探索性的（"为什么用户不爱用我们的产品？"——这是研究问题，不是根因分析问题）
• 目标是预测未来而非解释过去

输出：适用 / 不适用（附理由）/ 部分适用（附建议）

Step 2: 5 Whys 式分析 — 研究维度须从核心原理推导，禁止使用通用"搜索相关信息"

研究维度（每个维度必须能追溯到具体的核心原理）：

1. 起始事件定义：用一句话精确描述问题现象

   • 来源原理：原理 1（因果链的深度穿透——需要明确的起点）
   • 操作方式：问题陈述必须客观、可观测、不含归因。例如"2024年3月15日14:30，3号产线机器停机"而非"机器又坏了"

2. 逐层因果追问：从起始事件出发，每一层问"为什么会发生上一个答案描述的事？"

   • 来源原理：原理 1（因果链深度穿透）+ 原理 2（追问深度取决于复杂度）
   • 操作方式：在每一层记录答案，并验证"这是直接原因还是更深层原因"。如果答案指向个人行为，触发原理 3 的追问——"什么系统允许了这个行为？"。当抵达"可以通过改变流程/工具/制度来防止"的层面时停止

3. 分支验证：在每一层检查是否存在其他并行原因

   • 来源原理：原理 5（线性简化的局限）+ 原理 4（知识偏差）
   • 操作方式：在每一层追问后，暂停问"还有其他可能导致上一层答案的原因吗？"如果存在，为每个分支单独继续追问

4. 根因到对策映射：对每个终端根因，设计可执行的对策

   • 来源原理：原理 6（终点必须是可行动的对策）
   • 操作方式：格式——"根因 → 对策：[谁]在[何时]做[什么]，验证标准是[什么指标]"

禁止：使用"搜索相关信息"、"全面了解背景"等通用指令。所有研究维度必须从核心原理推导。

Step 3: 5 Whys 式输出 — 基于分析结果的格式化输出

输出格式要求：

起始事件：[一句话描述]

Why 1: [问题] → [原因]
Why 2: [问题] → [原因]
Why 3: [问题] → [原因]
...
Why N: [问题] → [根因]

分支原因（如有）：
- 在 Why [X] 处存在的替代原因链

根因总结：
- 根因 A：[描述] → 置信度：[高/中/低]
- 根因 B：[描述] → 置信度：[高/中/低]

对策建议：
- 对策 1：[谁]在[何时]做[什么]，验证指标[...]
- 对策 2：[谁]在[何时]做[什么]，验证指标[...]

• 标注置信度（高/中/低）
• 如果置信度低，明确说明原因（如"该层原因缺乏数据验证，仅为推测"）和建议的下一步（如"建议查看XX日志/访谈XX角色来验证"）

适用/不适用判断

问题类型	适用度	说明
单一故障/事故的根因分析	高	经典场景——机器故障、服务宕机、客户投诉的具体事件
生产质量问题追查	高	制造业核心应用场景，丰田的原始应用领域
DevOps/SRE 事故复盘	高	Google SRE 和 Atlassian 等广泛采用 5 Whys 进行 Blameless Postmortem
组织流程问题诊断	中	可以使用，但需注意因果链可能涉及多人/多部门互动，建议与鱼骨图结合
复杂系统级故障（多系统耦合）	低	因果网络过于复杂，建议先用系统思维/故障树分析（FTA）降维，再用 5 Whys 针对子问题深挖
开放性探索问题	低	"为什么用户不爱用我们的产品"不适合 5 Whys，更适合用户调研或 Jobs-to-be-Done 分析

典型案例库

成功案例

1. 丰田车间机器停机（制造业/1970年代）

   • 问题：丰田车间一台机器突然停机
   • 方法应用：大野耐一带领现场人员连续追问——Why 1: 保险丝熔断 → Why 2: 轴承润滑不足 → Why 3: 润滑油泵供油不足 → Why 4: 泵轴磨损振动 → Why 5: 油泵没有过滤网，金属碎屑进入泵轴
   • 结果：根因不是"保险丝质量问题"，而是"油泵缺少过滤网"这一系统性设计缺陷，安装过滤网后问题永久解决
   • 来源：Ohno, Toyota Production System: Beyond Large-Scale Production (1978)

2. Jeff Bezos 亚马逊仓库员工手指受伤（电商物流/2004）

   • 问题：一名仓库工人在传送带上夹伤了手指
   • 方法应用：Bezos 亲自主持 5 Whys——Why 1: 手指被传送带夹住 → Why 2: 工人在清理传送带卡堵 → Why 3: 没有专人负责维护和清理 → Why 4: 班次人手不足 → Why 5: 预算约束导致削减编制
   • 结果：根因从"工人操作失误"追溯到"组织预算决策"，促使亚马逊重新审视仓库人员配置策略
   • 来源：Brad Stone, The Everything Store (2013)

3. Eric Ries 精益创业中的 5 Whys 应用（创业管理/2008-2011）

   • 问题：IMVU（Eric Ries 的创业项目）的技术故障反复发生
   • 方法应用：每次故障后，团队用 5 Whys 分析——例如一次服务器崩溃的根因不是代码 bug，而是"新人没有 code review 流程"这一组织流程缺陷
   • 结果：建立了渐进式流程改进机制——每次只增加一个"适度比例"的流程，避免过度制度化
   • 来源：Eric Ries, The Lean Startup (2011); Eric Ries, "The Five Whys for Start-ups", HBR (2010)

失败案例

1. 停在表面原因的 5 Whys（普遍误用）

   • 问题：工厂产品次品率上升
   • 误用方式：Why 1: 工人操作失误 → Why 2: 工人培训不足 → 停在这里，把原因归结为"工人素质差"，直接开除工人
   • 教训：停止在"个人原因"层面违反了原理 3（根因指向系统而非个人），真正的根因可能在于"培训流程缺失"或"操作界面设计不合理"
   • 来源：Eric Ries, "The Five Whys for Start-ups", HBR (2010)——Ries 明确警告不要用 5 Whys 追责个人

2. 多人分析得出不同根因（可靠性工程/普遍）

   • 问题：同一工业事故由不同工程师分别用 5 Whys 分析
   • 误用方式：工程师 A 认为根因是设备老化，工程师 B 认为根因是维护流程缺失，工程师 C 认为根因是备件采购延迟
   • 教训：单人执行 5 Whys 时，因果链条受限于个人知识面和偏见（原理 4），必须多角色参与并交叉验证
   • 来源：Mark Galley, ThinkReliability, "Top Criticisms of the 5-Why Approach"

误用检测器（≥3 种误用模式，须覆盖：方法与问题不匹配、跳过关键步骤、复杂度超限）

误用信号	检测逻辑	警告信息	建议动作
方法与问题不匹配	用户的问题陈述是开放性/探索性的（如"为什么市场不好""为什么产品没人用"），缺乏明确的起始事件	"你在用 5 Whys 分析探索性问题。5 Whys 适用于有明确起始事件的具体故障/问题，不适合因果不明的开放性研究。建议用用户访谈或 JTBD 分析。"	推荐替代方法：用户调研、JTBD、Design Thinking
停在个人归因层面	Why 链中某一层的答案是"XX人操作失误/疏忽/不负责任"，且分析在此处终止	"5 Whys 要求在触及个人原因时继续追问'什么系统允许了这个错误发生'。停在'工人失误'是追责，不是根因分析。"	继续追问系统层面的原因
单人分析缺乏验证	5 Whys 由单人完成，且没有标注每层答案的替代原因	"5 Whys 的分析质量受限于分析者的知识面。建议至少邀请 1-2 个不同职能的人交叉验证因果链，或在每层检查是否存在其他并行原因。"	引入多角色参与、标注分支
复杂度超限	问题涉及 3 个以上相互依赖的系统/模块/部门，因果链条出现明显的分支和交叉	"这个问题涉及多系统耦合，5 Whys 的线性因果链可能无法充分覆盖。建议先用鱼骨图或故障树分析（FTA）梳理全貌，再用 5 Whys 对子问题逐个深挖。"	推荐组合使用：5 Whys + 鱼骨图/FTA
找到根因但没有对策	5 Whys 分析完成后没有对应的行动项	"5 Whys 的终点不是'找到根因'，而是'基于根因设计可执行的对策'。没有对策的根因分析只是学术练习。"	要求为每个根因设计具体行动项

诚实边界（≥3 条具体局限，禁止"不能替代专业建议"类空话）

1. 不适用于多因果耦合的复杂系统：当问题涉及 3 个以上相互交互的子系统（如分布式系统级故障、供应链中断），5 Whys 的线性因果链会严重遗漏关键的交叉效应。NASA 的研究证实，在复杂近失事件中，单根因分析遗漏了 40% 以上的系统性贡献因素（来源：ResearchGate, "Multiple Systemic Contributors versus Root Cause: Learning from a NASA Near-Miss", 2016）

2. 分析结果高度依赖分析者的知识面，可重复性差：同一事件由不同人用 5 Whys 分析，可能得出完全不同的根因。Mark Galley 指出，这是 5 Whys 最大的方法论缺陷之一——它不是一个严谨的、可重复的分析工具，更像是一个启发式的思考框架（来源：Mark Galley, ThinkReliability）

3. "五个"的设定可能误导分析者提前停止：机械地数到五就停止，可能恰好停在症状层面而非根因层面。大野耐一的经典案例实际需要七层追问才能到达系统性根因（来源：Lean Blog, "Even Ohno's Classic 5 Whys Example Deserves Another Why", 2026）

4. 信息不足维度：关于 5 Whys 在教育、法律、公共政策等非工程/非商业领域的实证研究数据非常有限，本 Skill 的跨域证据主要集中在制造业、航空安全、互联网/软件、医疗安全和创业管理五个领域

调研来源（一手来源占比须 >50%）

#	来源	类型	一手/二手	权重
1	Taiichi Ohno, Toyota Production System: Beyond Large-Scale Production (1978)	著作	一手	高
2	Eric Ries, "The Five Whys for Start-ups", Harvard Business Review (2010)	文章	一手	高
3	Eric Ries, The Lean Startup (2011)	著作	一手	高
4	Brad Stone, The Everything Store (2013)	著作	一手	高
5	Google SRE Book, "Blameless Postmortem for System Resilience" (2016)	技术著作	一手	高
6	Mark Galley, ThinkReliability, "Top Criticisms of the 5-Why Approach"	专家文章	一手	中
7	Mark Galley, ThinkReliability, "5-Why is as Simple as a Shovel"	专家文章	一手	中
8	The Joint Commission, Framework for Conducting a Root Cause Analysis and Action Plan	官方框架	一手	中
9	AHRQ Patient Safety Network, Root Cause Analysis Primer	政府指南	一手	中
10	NASA, NPR 8621.1 NASA Procedural Requirements for Mishap Investigation, Appendix I	官方文件	一手	中
11	ResearchGate, "Multiple Systemic Contributors versus Root Cause: Learning from a NASA Near-Miss" (2016)	学术论文	一手	中
12	Lean Blog, "Even Ohno's Classic 5 Whys Example Deserves Another Why" (2026)	博客分析	二手	低
13	AWS Well-Architected Framework, Five Whys 文档	技术文档	二手	低

本 Skill 由 Forge Skill — 锻造思维工具 生成