5个为什么
**5个为什么：**连续问"为什么会发生这种情况？"五次，从症状深入到根本原因。第一个答案通常是症状；第五个通常是你能实际修复的可操作原因。用于制造、软件事后分析和管理回顾，以防止复发而非仅仅对症状做出反应。
什么是5个为什么？
5个为什么由丰田工业创始人丰田佐吉开发，在1970年代成为丰田生产系统（TPS）的基石。TPS的架构师大野耐一将其描述为丰田科学方法的基础："通过重复五次为什么，问题的本质及其解决方案变得清晰。"
该技术看似简单：当问题发生时，问"为什么？"并记录答案。然后对那个答案再问"为什么？"。重复直到找到一个可以实际修复的原因——通常在第五次迭代左右。目标不一定是正好五个问题（有时三个就够，有时需要七个），而是持续追问直到达到可操作的根本原因，而非停留在症状性答案上。
该方法的力量在于抵抗显而易见之事的拉力。我们的认知系统天生会对近因采取行动——问题的直接触发因素。机器停止工作；我们重启它。客户投诉；我们道歉。截止日期错过；我们增加更多时间。这些反应解决症状。5个为什么强迫越过症状，到达如果解决就能防止问题复发的结构性或系统性原因。
工作原理
步骤1：精确定义问题
——写一个清晰、具体的问题陈述
——"生产线停止了"而非"出了问题"
步骤2：问"为什么会发生这种情况？"
——记录第一个因果答案
——保持事实性，而非解释性
步骤3：对前一个答案再问"为什么？"
——深入原因，而非症状
步骤4：重复直到达到根本原因
——根本原因：可解决的系统性故障
——你已深入到足够程度的迹象：答案是流程/系统故障
步骤5：验证因果链
——向上阅读："因为X→导致Y→导致Z→"
——因果链应该逻辑清晰
步骤6：在根本原因层面设计对策
——不要只修复症状；解决根本原因
三个现实案例
丰田生产线停止：经典丰田案例：生产机器人意外停止。为什么机器停止了？——超负荷；保险丝烧断了。为什么超负荷？——轴承润滑不足。为什么润滑不足？——润滑泵没有正常循环油。为什么泵没有正常工作？——泵入口被金属屑堵塞了。为什么入口被堵塞？——没有安装过滤器；维护程序中没有指定。修复不是"更换保险丝"。而是"安装过滤器并更新维护程序"。更换保险丝解决症状；对策解决根本原因。没有5个为什么，同样的故障会在几周内再次发生。
软件部署失败：关键API服务在凌晨2点宕机。为什么服务宕机了？——主服务器内存不足错误。为什么内存不足？——当天发布的新功能有内存泄漏。为什么内存泄漏到达生产环境？——代码审查或测试中没有发现。为什么测试中没有发现？——预发布环境不模拟持续的生产负载。为什么预发布环境不模拟生产负载？——我们从未定义部署前进行负载测试的政策。修复：为所有内存密集型功能在生产部署前实施负载测试政策。不是：责怪工程师。
创业公司错过销售目标：B2B SaaS公司Q3收入目标错过40%。为什么错过了收入目标？——管道转化率从22%降到11%。为什么转化率下降？——竞争对手在7月推出了更便宜的替代品。为什么我们输给更便宜的替代品？——我们在销售电话中无法清晰表达差异化。为什么销售无法表达差异化？——我们没有竞争战斗卡；销售代表在即兴发挥。为什么没有战斗卡？——产品营销被分配到一个重要会议，而不是竞争情报。修复：创建竞争战斗卡流程和资源分配政策。不是：解雇销售团队。
何时使用
✅ 5个为什么很适合
- 运营故障事后分析（停机、缺陷、交付失败）
- 重复出现的问题——"为什么这种情况一直发生？"
- 敏捷开发中的团队回顾
- 任何"修复显而易见的事情"没有效果的问题
❌ 需要谨慎的情况
- 问题有多个原因（使用鱼骨图代替）
- 需要在诊断前恢复服务（先修复，后分析）
- 原因确实是随机的或外部的
| 配合使用 | 效果 |
|---|---|
| 鱼骨图 | 鱼骨图映射多个因果线程；5个为什么深入一个线程 |
| 根因分析 | 5个什么是根因方法论的最简单实现 |
| 事前验尸 | 事前验尸预判5个为什么式的因果链 |
| 科学方法 | 5个为什么生成假设；科学方法验证它们 |
常见误用和局限
**停在第一个"足够好"的答案。**最常见的失败：识别出一个合理的原因就停止。"服务器内存不足"是原因；它不是根本原因。越过舒适区，到达系统性故障。
把人当作根本原因。"因为约翰没有检查服务器日志"不是根本原因。约翰是系统中的一个节点——问系统为什么没有支持约翰。是缺少政策？没有警报？他超负荷了？人通常是近因；系统通常是根本原因。
**为多原因问题创建单一因果链。**5个为什么产生线性因果链；许多问题有分支原因。如果多个第二层原因看起来同样相关，使用鱼骨图代替。
**因果链中的确认偏差。**两个不同的分析师可以为同一个问题构建非常不同的因果链。因果链反映了带入调查的假设。通过反向阅读因果链并检查每个因果链接来验证。
相关模型
| 模型 | 关系 |
|---|---|
| 根因分析 | 5个什么是更广泛RCA框架中的特定技术 |
| 鱼骨图 | 鱼骨图探索多个因果分支；5个为什么深入一个分支 |
| 问题树 | 问题树结构化复杂问题；5个为什么诊断特定故障 |
| 黑匣子思维 | 黑匣子思维激励5个为什么分析的文化实践 |
常见问题
是否必须正好是五个"为什么"？ 不是。"5"是启发式，不是规则。有些问题三个就解决了；复杂的可能需要七个。停止标准是达到一个原因，该原因：(a)可以通过特定对策解决，(b)如果解决，将防止问题再次发生。当你达到那个层面时，就停止——无论三个还是八个。
近因和根本原因有什么区别？ 近因是直接触发因素："服务器崩溃是因为内存溢出"。根本原因是深层可解决的系统性原因："服务器崩溃是因为我们没有负载测试政策"。近因描述发生了什么；根本原因解释系统为什么允许它发生。根本原因通常是流程、政策或设计故障——可以改变以防止再次发生的事情。
如何防止5个为什么变成指责游戏？ 将调查框架为系统审计，而非绩效评估。使用"我们的流程中什么允许X发生？"而非"为什么人Y做了X？"当人出现在因果链中时，问系统应该提供什么来防止一个合理的人犯那个错误。丰田的做法是在个人失败之前假设系统失败。
延伸阅读
- Ohno, T. (1988). Toyota Production System: Beyond Large-Scale Production — 原始来源
- Liker, J.K. (2004). The Toyota Way — TPS的全面介绍，包括5个为什么
- Dekker, S. (2006). The Field Guide to Understanding 'Human Error' — 故障分析的系统思维方法
用AI应用
本页面是MindMax思维模型知识库的一部分。