五个为什么分析法
五个为什么分析法
什么是 Five Whys?
"五个为什么"是一种根因分析技术,通过连续追问"为什么"来找到问题的根本原因,而不是只停留在表面症状。
Process
1. Define the Problem
Clearly state the issue or symptom
2. Ask "Why?" Five Times
- Why did this problem occur? → Answer 1
- Why did Answer 1 happen? → Answer 2
- Why did Answer 2 happen? → Answer 3
- Why did Answer 3 happen? → Answer 4
- Why did Answer 4 happen? → Answer 5 (Root Cause)
3. Validate Root Cause
- Verify the logical chain
- Check if addressing root cause prevents recurrence
- Consider multiple root causes if applicable
4. Develop Solutions
- Address the root cause, not just symptoms
- Create preventive measures
- Consider systemic improvements
Example: Application Crash
Problem: Application crashes when processing large files
- Why? → The application runs out of memory
- Why? → It loads entire file into memory at once
- Why? → The file parser wasn't designed for streaming
- Why? → Initial requirements only specified small files
- Why? → Requirements gathering didn't consider future growth
Root Cause: Incomplete requirements gathering process
Solution: Implement streaming parser and improve requirements process
Example: API Response Slow
Problem: API endpoint taking 10+ seconds to respond
- Why? → Database query is slow
- Why? → No index on the queried column
- Why? → Schema migration didn't include index
- Why? → No performance review in migration process
- Why? → Migration checklist is incomplete
Root Cause: Incomplete migration checklist
Solution: Add performance review step to migration process
Best Practices
- Focus on process, not people - 避免指责个人
- Look for systemic issues - 寻找系统性问题
- Document the analysis - 记录分析过程
- Involve relevant stakeholders - 让相关人员参与
- Test solutions address root cause - 验证解决方案
在 Vibe Coding 中的应用
当 AI 生成的代码出现问题时,可以使用 Five Whys 来分析:
Problem: AI generated code doesn't compile
- Why? → Using wrong syntax for the framework version
- Why? → AI assumed older framework version
- Why? → Prompt didn't specify framework version
- Why? → No project context provided
- Why? → Missing CLAUDE.md or context-prime step
Root Cause: Missing project context
Solution: Always run /context-prime before complex tasks
Five Whys Template
## Problem Statement
[Clear description of the issue]
## Analysis
### Why #1
Q: Why did this happen?
A: [Answer]
### Why #2
Q: Why did [Answer #1] happen?
A: [Answer]
### Why #3
Q: Why did [Answer #2] happen?
A: [Answer]
### Why #4
Q: Why did [Answer #3] happen?
A: [Answer]
### Why #5
Q: Why did [Answer #4] happen?
A: [Answer - Root Cause]
## Root Cause
[Summary of the fundamental issue]
## Proposed Solutions
1. [Solution 1]
2. [Solution 2]
## Preventive Measures
- [Measure 1]
- [Measure 2]
下一步
学习 Mermaid 图表生成 来可视化你的分析结果。
📚 相关资源
❓ 常见问题
关于本章主题最常被搜索的问题,点击展开答案
Five Whys 真的要问够 5 次吗?少问或多问可以吗?
5 是经验值不是规定。Toyota 当年统计大部分根因在 4-5 层挖到,问到第 3 层还在表面("代码有 bug" → "逻辑写错了")就明显不够,问到第 7-8 层开始扯哲学("为什么人会犯错")就过头了。判断是否到根因的标准:解决它能不能阻止同类问题再发生。
AI 生成的代码出 bug,怎么用 Five Whys 查?
本章给的实战例子:(1) 代码不能编译 → (2) 用了错误的 framework version 语法 → (3) AI 假定的是旧版本 → (4) Prompt 没指定版本 → (5) 没跑 `/context-prime` 没给项目上下文。根因是 missing project context,解决方案不是改 prompt 而是把上下文沉淀到 CLAUDE.md。
Five Whys 容易掉进的坑是什么?
三个高频坑:(1) 指向人不指向流程 — "为什么 bug 上线了?因为 reviewer 看漏了",把分析变成追责,本章原则是 Focus on process, not people;(2) 单线追因 — 一个根因可能有 2-3 条独立链路,需要并行追;(3) 答案靠猜不验证 — 每一层都要有日志/数据/可复现的 evidence,不能 "我觉得是这样"。
API 慢的例子里,根因为什么不是"DB 没建索引"?
因为修了这次的 index 还会再发生 — 下次 schema migration 又会忘。本章的链路:API 慢 → query 慢 → 没 index → migration 没加 index → migration 流程没有 performance review 这一步。根因是 migration checklist 不完整,解决方案是补 checklist 的 review 环节,而不是手动建 index。
Five Whys 适合什么场景?什么场景不适合?
适合:单点问题、有清晰因果链(线上 bug、性能下降、流程失败)—— 5 步内能挖到 actionable 根因。不适合:复杂系统涌现性问题(分布式 race condition、多 service 协同失败)—— 这类问题没有单一根因,需要 fishbone diagram 或 fault tree analysis 这类多因素方法。