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