29

Five Whys Analysis

⏱️ 8 min

Five Whys Analysis

What Are the Five Whys?

The Five Whys is a root cause analysis technique. You keep asking "why" until you reach the fundamental cause, instead of stopping at surface symptoms.

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

  1. Why? → The application runs out of memory
  2. Why? → It loads entire file into memory at once
  3. Why? → The file parser wasn't designed for streaming
  4. Why? → Initial requirements only specified small files
  5. 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

  1. Why? → Database query is slow
  2. Why? → No index on the queried column
  3. Why? → Schema migration didn't include index
  4. Why? → No performance review in migration process
  5. 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 - don't blame individuals
  • Look for systemic issues - find structural problems
  • Document the analysis - record the full reasoning chain
  • Involve relevant stakeholders - get the right people in the room
  • Test solutions address root cause - verify your fix actually works

Applying Five Whys in Vibe Coding

When AI-generated code has issues, Five Whys can pinpoint what went wrong:

Problem: AI generated code doesn't compile

  1. Why? → Using wrong syntax for the framework version
  2. Why? → AI assumed older framework version
  3. Why? → Prompt didn't specify framework version
  4. Why? → No project context provided
  5. 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]

Next Steps

Check out Mermaid Diagram Generation to visualize your analysis results.

📚 相关资源

❓ 常见问题

关于本章主题最常被搜索的问题,点击展开答案

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 这类多因素方法。