五个为什么
从表面诉求追到根因，再决定要不要照着做。
用户给的是他能想到的解决办法。连着问几次为什么，你才会摸到那个让他产生这个想法的原因。这套追问法最早来自丰田的生产现场，后来被产品行业拿来挖需求，核心始终是同一件事：别停在他提出的方案上。five-whys-wiki
你会遇到的现象：
- 照着需求做了功能，用户还是绕着走
- 同一个模块反复被提需求，补了一个又来一个
- 功能列表越来越长，但没有一个从根上解决问题
「五个」是个约数，不是必须问满五次。多数情况下问到第三层就见底了。真正的规则是：一直问到答案不再是「因为系统不支持」，而是变成一个业务事实为止。
怎么追
每往下一层，问的对象要从「方案」转向「处境」：
| 层 | 这一层在问什么 | 问出来的东西属于 |
|---|---|---|
| 第 0 层 | 他要什么 | 方案。多半是他见过的某个界面 |
| 第 1 层 | 他拿这个方案去干什么 | 任务。开始有场景了 |
| 第 2 层 | 为什么必须自己干这件事 | 缺口。系统在哪一步断了 |
| 第 3 层 | 为什么会有这个缺口 | 结构问题。通常是当初的信息架构没设计对 |
| 第 4 层 | 为什么当初这么设计 | 业务事实或历史包袱。到这一层可以停了 |
越往下，能解决的问题越根本，但改动成本也越高。所以追到底之后，还要往回走一步，选一个成本合适的层次下手。这张图解释了为什么「追到底」本身不是目的——最底层往往是组织和流程的事，产品动不了，真正的收获是中间那一两层。
什么时候停
| 可以停了 | 还没到底 |
|---|---|
| 答案变成了一个业务事实 | 答案还是「因为系统不支持」 |
| 答案指向了组织或流程，产品改不动 | 答案还是另一个功能名 |
| 再往下问，答案开始重复 | 答案是「大家都这么做」 |
| 已经能推出一个跟原诉求不同的方案 | 你还说不出他那天到底卡在哪一步 |
右边第一条最常见。「因为系统不支持」等于什么都没说，它只是把问题换了个说法，再问一次就能往下走。
三个常见误用
还有一个经常踩的坑：把五个为什么当成访谈的全部。它只适合追单个诉求，不适合做整体调研。访谈里留出时间问「你最近一次做这件事是什么时候，那天发生了什么」，比从头到尾只问为什么有效得多。
- **对着人问，不是对着事问。**连问五次为什么很容易变成质问，对方会开始防守。改成一起复盘那天发生了什么，用「那一步是怎么回事」代替「你为什么这么做」。
- **只有一条链。**真实问题往往有几个并行原因。追到第二层时如果出现两个原因，就分叉，别硬挑一条走到底。
- **追到底就直接做最底下那个。**根因往往是架构问题，改起来要几个月。正确做法是拿到根因之后，回头挑一个成本能接受的层次先解决。
给 AI 的话
让 AI 帮你追问，比你自己追更容易保持中立——它不会替你的方案辩护。
下面是一条用户提出的需求，以及我了解到的背景：
需求原话：[用户说的话]
背景：[你知道的场景、这个人是谁、他在做什么]
请扮演一个中立的产品顾问，帮我做根因分析：
1. 逐层往下追问，每一层给出你的推测和理由，最多五层。
2. 每一层标注：这是方案、任务、缺口、结构问题，还是业务事实。
3. 如果某一层可能有多个并行原因，请分叉列出，不要只选一条。
4. 最后给出三个不同层次的解决方向，各自标注改动成本
（小时级 / 天级 / 周级以上）。
5. 明确列出你在推测时用到的假设，哪些需要我去跟用户确认。
不要给代码，也不要给界面方案。
第五点是关键。它会把「这一步是我猜的」和「这一步是你告诉我的」分开，你就知道下次访谈该去问什么。