| 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: 因果链的深度穿透——症状与根因之间存在多层因果关系
一句话定义：每一个可见的问题背后，都有一连串未被审视的因果链条，直到抵达系统性的根本原因。
跨域证据：
- 制造业（丰田）：大野耐一的经典案例——机器停机，表面原因是保险丝熔断，逐层追问后发现根因是油泵没有过滤网导致金属碎屑进入泵轴（来源：Ohno, Toyota Production System: Beyond Large-Scale Production, 1978）
- 航空安全：NASA 在事故调查政策 NPR 8621.1 中明确规定，根因分析必须追问"为什么"直至识别出所有系统性贡献因素，而非停留在直接原因（来源：NASA, NPR 8621.1 NASA Procedural Requirements for Mishap Investigation, Appendix I）
应用方式：面对任何故障或问题，不要在第一个答案处停下来，至少追问 3 层以上，直到触及"可以通过改变流程/系统来永久解决"的层面。
局限：因果链条并非总是线性的，复杂问题可能有多条因果分支交汇于不同节点。
原理 2: "五"是指导而非教条——追问深度取决于问题的复杂度
一句话定义：追问的次数不必须恰好五次，关键在于穿透到可采取系统性行动的层面。
跨域证据：
- 精益管理：大野耐一本人从未硬性规定"恰好五次"。Lean Blog 的分析指出，大野耐一经典案例中实际追问了七层才抵达真正的系统性根因（来源：Lean Blog, "Even Ohno's Classic 5 Whys Example Deserves Another Why", 2026）
- 软件工程：Google SRE 团队在故障复盘（Postmortem）中不限定追问次数，而是追问到"我们能改变什么系统来防止再次发生"为止（来源：Google SRE Book, Blameless Postmortem for System Resilience, 2016）
应用方式：以"是否已经到达一个可以设计系统性对策的原因"作为停止条件，而非机械地数到五。
局限：对于缺乏经验的执行者，"五次"作为硬性规则仍有其训练价值，避免追问过浅。
原理 3: 根因往往指向系统和流程，而非个人
一句话定义：连续追问会自然地将责任从"谁犯了错"转移到"什么系统允许这个错误发生"。
跨域证据：
- 互联网/电商：2004 年 Jeff Bezos 在亚马逊仓库亲自主持 5 Whys 分析，一名工人在传送带上夹伤手指，逐层追问后根因指向预算约束导致的编制不足和培训缺失，而非工人个人的疏忽（来源：Brad Stone, The Everything Store, 2013）
- 创业管理：Eric Ries 在《精益创业》中强调"每一个看似技术问题的根因都是一个人的问题"，5 Whys 应用于组织流程改进而非追责个人（来源：Eric Ries, The Lean Startup, 2011; Eric Ries, "The Five Whys for Start-ups", HBR, 2010）
应用方式：在每一层追问时，如果答案是"某人犯了错"，继续追问"为什么系统允许这个错误发生"，直到找出流程/制度/工具层面的改进点。
局限：在某些场景下（如蓄意破坏、严重渎职），个人责任确实是根因，强行转向系统可能掩盖真正的责任问题。
原理 4: 追问质量取决于提问者的领域知识
一句话定义：同样的问题，不同知识背景的人会构建出不同的因果链条，抵达不同的"根因"。
跨域证据：
- 可靠性工程：Mark Galley（ThinkReliability 创始人）指出 5 Whys 的最大弱点之一是"受限于调查者的知识面"——同一事件由不同人分析会得出不同的根因，缺乏可重复性（来源：Mark Galley, "Top Criticisms of the 5-Why Approach...and What the Critics Don't Understand", LinkedIn/ThinkReliability）
- 医疗安全：美国医疗机构评审联合委员会（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 假设问题存在一条从症状到根因的主因果链，但现实问题常由多条因果链交织而成。
跨域证据：
- 可靠性工程：Mark Galley 明确指出 5 Whys "基于线性的因果推理"，强制产生单一因果链，无法捕捉多因素并行作用和反馈回路，因此"不是一个完整的根因分析方法"（来源：Mark Galley, ThinkReliability Blog, "5-Why is as Simple as a Shovel"）
- 航空安全：NASA 的学术研究对比了传统 5 Whys 式的单根因分析与"多重系统性贡献因素"分析方法，发现在复杂近失事件中，单根因分析会遗漏关键的系统交互效应（来源：ResearchGate, "Multiple Systemic Contributors versus Root Cause: Learning from a NASA Near-Miss", 2016）
应用方式：如果问题可能涉及多条因果链，在每层追问时同时问"还有其他原因吗？"并画出分支，或将 5 Whys 与鱼骨图（Ishikawa Diagram）结合使用。
局限：对于高度耦合的复杂系统（如大型分布式系统故障、金融危机），仅靠 5 Whys 无法充分刻画因果网络。
原理 6: 根因分析的终点必须是可行动的对策
一句话定义：找到根因不是目的，基于根因设计出能防止问题再发的系统性对策才是。
跨域证据：
- 精益管理：丰田生产方式中 5 Whys 的每一层追问都要求对应"对策（Countermeasure）"，而非仅停留在"为什么"（来源：Ohno, Toyota Production System: Beyond Large-Scale Production, 1978）
- 医疗安全：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（因果链的深度穿透——需要明确的起点）
- 操作方式：问题陈述必须客观、可观测、不含归因。例如"2024年3月15日14:30，3号产线机器停机"而非"机器又坏了"
-
逐层因果追问：从起始事件出发，每一层问"为什么会发生上一个答案描述的事？"
- 来源原理：原理 1（因果链深度穿透）+ 原理 2（追问深度取决于复杂度）
- 操作方式：在每一层记录答案，并验证"这是直接原因还是更深层原因"。如果答案指向个人行为，触发原理 3 的追问——"什么系统允许了这个行为？"。当抵达"可以通过改变流程/工具/制度来防止"的层面时停止
-
分支验证：在每一层检查是否存在其他并行原因
- 来源原理：原理 5（线性简化的局限）+ 原理 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 分析 |
典型案例库
成功案例
-
丰田车间机器停机（制造业/1970年代）
- 问题：丰田车间一台机器突然停机
- 方法应用：大野耐一带领现场人员连续追问——Why 1: 保险丝熔断 → Why 2: 轴承润滑不足 → Why 3: 润滑油泵供油不足 → Why 4: 泵轴磨损振动 → Why 5: 油泵没有过滤网，金属碎屑进入泵轴
- 结果：根因不是"保险丝质量问题"，而是"油泵缺少过滤网"这一系统性设计缺陷，安装过滤网后问题永久解决
- 来源：Ohno, Toyota Production System: Beyond Large-Scale Production (1978)
-
Jeff Bezos 亚马逊仓库员工手指受伤（电商物流/2004）
- 问题：一名仓库工人在传送带上夹伤了手指
- 方法应用：Bezos 亲自主持 5 Whys——Why 1: 手指被传送带夹住 → Why 2: 工人在清理传送带卡堵 → Why 3: 没有专人负责维护和清理 → Why 4: 班次人手不足 → Why 5: 预算约束导致削减编制
- 结果：根因从"工人操作失误"追溯到"组织预算决策"，促使亚马逊重新审视仓库人员配置策略
- 来源：Brad Stone, The Everything Store (2013)
-
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)
失败案例
-
停在表面原因的 5 Whys（普遍误用）
- 问题：工厂产品次品率上升
- 误用方式：Why 1: 工人操作失误 → Why 2: 工人培训不足 → 停在这里，把原因归结为"工人素质差"，直接开除工人
- 教训：停止在"个人原因"层面违反了原理 3（根因指向系统而非个人），真正的根因可能在于"培训流程缺失"或"操作界面设计不合理"
- 来源：Eric Ries, "The Five Whys for Start-ups", HBR (2010)——Ries 明确警告不要用 5 Whys 追责个人
-
多人分析得出不同根因（可靠性工程/普遍）
- 问题：同一工业事故由不同工程师分别用 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 条具体局限，禁止"不能替代专业建议"类空话）
-
不适用于多因果耦合的复杂系统：当问题涉及 3 个以上相互交互的子系统（如分布式系统级故障、供应链中断），5 Whys 的线性因果链会严重遗漏关键的交叉效应。NASA 的研究证实，在复杂近失事件中，单根因分析遗漏了 40% 以上的系统性贡献因素（来源：ResearchGate, "Multiple Systemic Contributors versus Root Cause: Learning from a NASA Near-Miss", 2016）
-
分析结果高度依赖分析者的知识面，可重复性差：同一事件由不同人用 5 Whys 分析，可能得出完全不同的根因。Mark Galley 指出，这是 5 Whys 最大的方法论缺陷之一——它不是一个严谨的、可重复的分析工具，更像是一个启发式的思考框架（来源：Mark Galley, ThinkReliability）
-
"五个"的设定可能误导分析者提前停止：机械地数到五就停止，可能恰好停在症状层面而非根因层面。大野耐一的经典案例实际需要七层追问才能到达系统性根因（来源：Lean Blog, "Even Ohno's Classic 5 Whys Example Deserves Another Why", 2026）
-
信息不足维度：关于 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 — 锻造思维工具 生成
