需求四层拆解卡

一句话定位

把一条用户原话，逐层拆到表达、场景、处境、代价四层，找到真正该解决的问题。

何时触发

• 用户提出了一个需求，团队准备直接进入方案讨论
• 需要区分"用户说的"和"用户真正需要的"
• 需求评审时发现只有表达层，缺少深度

输入

用户的原始表达（一句话或一段话）。

示例输入：

"希望自动把消费分类做得更准"

输出

四层拆解结果 + 问题重定义 + 方案方向建议。

四层拆解

Layer 1: 表达层（用户原话是什么）

任务：原汁原味记录用户的表达，不加工、不翻译、不推断。

输出格式：

用户原话: "..."
表达方式: [direct/indirect/complaint/wish/compliment]
表达场景: [where/when/how this was expressed]

Layer 2: 场景层（问题发生在什么时候、哪一步、和谁有关）

任务：描绘问题发生的具体场景，包括时间、地点、角色、流程位置。

输出格式：

时间节点: [when it happens]
地点/界面: [where it happens]
涉及角色: [who is involved]
流程位置: [which step in the workflow]
频率: [how often]

Layer 3: 处境层（他为什么在这里被困住，谁在补位，谁在党底）

任务：探索用户被困住的深层原因，找出系统性缺失和隐性代价。

输出格式：

被困原因: [why the user is stuck]
系统缺失: [what the system fails to provide]
补位角色: [who is filling the gap]
党底角色: [who bears the cost]
隐性劳动: [unseen work being done]

Layer 4: 代价层（如果系统不接住，这个人会持续损失什么）

任务：量化用户因此承受的持续损失，包括可见和不可见的。

输出格式：

时间代价: [minutes/hours per occurrence]
金钱代价: [direct cost]
情绪代价: [frustration/anxiety/shame/etc]
机会代价: [what they miss out on]
长期损失: [churn/disengagement/etc]

综合输出格式

needs_decomposition:
  input: "用户原始表达"
  
  layer1_expression:
    verbatim: "用户原话"
    expression_type: "direct/indirect/complaint/wish/compliment"
    context: "表达场景"
  
  layer2_scenario:
    timing: "时间节点"
    location: "地点/界面"
    roles: ["涉及角色"]
    workflow_step: "流程位置"
    frequency: "频率"
  
  layer3_situation:
    stuck_reason: "被困原因"
    system_gap: "系统缺失"
    filler_role: "补位角色"
    bearer_role: "党底角色"
    hidden_labor: "隐性劳动"
  
  layer4_cost:
    time_cost: "时间代价"
    money_cost: "金钱代价"
    emotion_cost: "情绪代价"
    opportunity_cost: "机会代价"
    long_term_loss: "长期损失"
  
  reframed_problem:
    original: "用户表面上说的"
    actual: "真正该解决的"
    why_different: "为什么不同"
  
  solution_direction:
    dont_do: "不要做的（表达层方案）"
    should_do: "该做的（处境层方案）"
    key_metric: "怎么证明做对了"

快速使用法

1. 把一条需求写在白板/文档最上面
2. 要求团队逐层补全四层内容
3. 任何一层说不出来，先不要进入方案讨论

示例：完整走一遍

原始需求：

"希望自动把消费分类做得更准"

四层拆解：

层次	内容
表达层	用户说"不想每次都手动改分类"
场景层	通常发生在下班后、睡前或月底对账时，想快速看懂钱花去了哪里
处境层	他并不只是嫌麻烦，而是本来就对支出有点失控感；一旦分类不断出错，他还得重新回忆每笔钱为什么花，越改越想逃避
代价层	如果产品长期接不住，用户失去的不只是几次修正动作，而是对财务状况的掌握感，最后很可能直接放弃记账

重定义：

• 不要做：只是提高分类准确率
• 该做：帮助用户重新建立生活秩序感
• 关键指标：不是"分类准确率"，而是"月底对账时的焦虑程度下降"

常见误判

• 只有表达层：变成功能愿望清单
• 只有场景层：误把麻烦当成真问题
• 缺少处境层：无法区分"想要更快"和"真的困扰"
• 缺少代价层：无法判断优先级

一句判断

如果一条需求说不清处境和代价，它通常还不够成熟。

核心概念

概念一：表达不等于需求

很多需求错误不是团队没听到用户说什么，而是太容易把用户说的话直接当成需求本身。

用户说"我想要自动同步"，很容易放进 backlog。用户说"我想要更少的重复确认"，很容易理解为流程优化。但这些表达往往只是最容易说出的那一层——可能是动作层面的抱怨，可能是从环境中学来的产品语言，也可能是他们觉得系统更容易理解的请求。真正让他们疲惫的东西，往往没有被完全表达出来。

来源：《AI rebuild product needs》第18章第1节——为什么表达看起来这么像需求本身。

概念二：场景告诉你哪里出了问题，处境告诉你为什么沉重

场景（scenario）防止需求漂浮在抽象中——谁在用、什么时间、在流程的哪一步、周围有什么角色和上下文。但场景仍然不是终点。

场景能告诉你问题发生在哪里，但不能自动告诉你为什么这件事一直压在某一个人身上。这时候需要进入处境（situation）：

• 目标压力：这个人到底需要完成什么，完不成会怎样
• 约束条件：什么在限制他——时间、注意力、环境、资源、权限
• 风险暴露：如果失败、出错、被打断，主要后果是什么
• 补偿成本：产品没接住时，他必须额外付出什么动作、时间或心智负担
• 情绪负担：不只是不方便，还有焦虑、犹豫、羞耻、挫败或后悔

来源：《AI rebuild product needs》第18章第2节——场景和处境的区别。

概念三：处境的核心不是动作，而是代价

为什么有些问题一直被产品团队低估？因为表面上很多问题看起来是"小动作"，而沉重的部分藏在动作背后的代价里。

例如，一个人不断在系统外多发一条确认消息。表面动作很小——只是多几行文字。但深挖下去会发现：她在为不清的责任认领补位、在预防未来无人认领的问题、在用自己的额外注意力维持协作不崩塌。

产品真正需要处理的，不是"帮用户少发一条消息"，而是那条消息背后的整段隐性劳动。

来源：《AI rebuild product needs》第18章第3节——处境的核心是代价。

概念四：AI 特别容易停在表达层

模型天然擅长处理已经被表达、记录和整理过的东西。如果输入主要是表达层材料，模型就只能在表达层工作——这不是模型弱，而是输入本身已经把现实压平了。

AI 时代不是让模型做需求工作的理由，而是让团队更谨慎地决定模型处理什么材料、在流程中坐在哪个位置的理由。否则模型越强，就越快把表达变成看起来更像答案的东西。

来源：《AI rebuild product needs》第18章第4节——为什么 AI 特别容易停在表达层。

概念五：成熟的需求条目应该长什么样

如果"需求不是一句话而是一种处境"成立，那写需求条目的方式也必须重写。一个成熟的需求条目至少包含四部分：

1. 表达层：用户原话（保留原始措辞，不要过早翻译）
2. 场景层：问题在什么时间、什么空间、什么关系结构中发生
3. 处境层：这个人为什么被困在这里，多做了什么解释、确认、追踪或补位
4. 代价层：如果系统不处理，长期来看什么会持续累积

只有四层同时出现时，需求才开始像真正的问题定义，而不只是一句容易记录的话。

来源：《AI rebuild product needs》第18章第5节——成熟的需求条目应该长什么样。

分步执行

Step 1：记录表达层——原汁原味，不加工

输入：用户的原始表达（一句话或一段话）

处理：

1. 原汁原味记录用户的表达，不翻译、不推断、不"优化"
2. 标注表达方式：direct/indirect/complaint/wish/compliment
3. 标注表达场景：在哪里、什么时候、对谁说的
4. 如果有多条表达，分别记录，不要合并

输出：表达层记录（附表达方式和场景标注）

---

Step 2：描绘场景层——时间、空间、角色、流程位置

输入：Step 1 的表达层记录

处理：

1. 确定问题发生的时间节点：什么时候触发的？
2. 确定地点/界面：在哪里发生的？
3. 确定涉及角色：谁和谁有关？
4. 确定流程位置：在工作流的哪一步？
5. 确定频率：多久发生一次？

输出：场景层描述（时间/地点/角色/流程/频率）

---

Step 3：探索处境层——为什么被困住，谁在补位，谁在兜底

输入：Step 2 的场景层描述

处理：

1. 追问"为什么这个人在这里被困住？"
2. 找出系统缺失了什么
3. 找出补位角色：谁在填补这个缺口？
4. 找出兜底角色：谁在承担最终代价？
5. 识别隐性劳动：有哪些"看不见的工作"在被做？

关键追问句式：

• "他为什么不得不多做这一步？"
• "如果他不做这一步，会怎样？"
• "谁在为这个缺口买单？"

输出：处境层描述（被困原因/系统缺失/补位角色/兜底角色/隐性劳动）

---

Step 4：量化代价层——如果系统不接住，持续损失什么

输入：Step 3 的处境层描述

处理：

1. 估算时间代价：每次 X 分钟 × 频率
2. 识别金钱代价：是否有直接成本
3. 识别情绪代价：frustration/anxiety/shame/fatigue
4. 识别机会代价：因此错过了什么更重要的事
5. 评估长期损失：churn/disengagement/trust erosion

输出：代价层描述（时间/金钱/情绪/机会/长期损失）

---

Step 5：重定义问题——从"用户说的"到"真正该解决的"

输入：Step 1-4 的四层完整记录

处理：

1. 对比表达层和处境层：用户说的 vs 用户真正被困住的
2. 明确"不要做的"（表达层方案）
3. 明确"该做的"（处境层方案）
4. 设定关键指标：怎么证明做对了（不是功能指标，而是用户负担是否减轻）

输出：问题重定义 + 方向建议

---

示例 1

场景：在线问诊产品——"希望医生回复快一点"

原始需求：

"我希望医生能回复得快一点。"

表面上看，这是一个简单的需求——团队自然会想到供应排班、提醒机制和更好的轮值制度。

四层拆解：

层次	内容
表达层	用户说"希望医生回复快一点"
场景层	通常发生在深夜或周末，用户独自面对检查结果，不知道是否应该立刻去医院；或者在工作时间偷偷发了消息，不想让周围人知道此刻有多焦虑
处境层	用户反复追问不只是因为"等待烦人"。他们处于信息不对称、情绪高压、无法自行判断的状态。可能已经问过家人、搜了大量资料，但越看越害怕
代价层	如果产品长期接不住，用户损失的不只是等待时间，而是在最需要支持的时刻"没人先接住"的孤独感。长期来看，用户会放弃在线问诊，回归线下——或者更糟，在焦虑中做出错误判断

重定义：

• 不要做：只优化回复速度
• 该做：在等待期间提供风险分层、期望管理和临时支撑——让用户在等待时有"现在该做什么"的感觉
• 关键指标：不是"平均回复时间"，而是"等待期间用户的焦虑程度"

来源：《AI rebuild product needs》第18章第2节示例——在线问诊场景。

---

示例 2

场景：会后协作——"希望自动推送待办事项"

原始需求：

"希望会后自动推送待办事项。"

四层拆解：

层次	内容
表达层	用户说"希望会后自动推送待办事项"
场景层	通常发生在跨部门会议结束后，参会者各自回到工位，开始处理自己手头的事
处境层	对不同角色，这完全是不同的处境——普通参会者只是确认下一步该做什么；但如果没人再追一遍，项目负责人会担心事情悬空；新人即使没听懂也不敢问，只能回去按自己的理解做一个版本，等出错后再修
代价层	如果产品只做"平均推送"，能覆盖很多人，但很难真正接住任何一个具体的人。项目负责人持续损失的是"不敢放松"的安全感；新人持续损失的是"不怕犯错"的信任感

重定义：

• 不要做：只做统一的待办推送
• 该做：根据角色和处境差异，提供分层的信息暴露和确认机制
• 关键指标：不是"待办推送到达率"，而是"项目负责人是否还需要在系统外再追一遍"

来源：《AI rebuild product needs》第18章第2节示例——会后协作场景。

---

常见误判

• 只有表达层：变成功能愿望清单
• 只有场景层：误把麻烦当成真问题
• 缺少处境层：无法区分"想要更快"和"真的困扰"
• 缺少代价层：无法判断优先级
• 过早翻译：把用户原话"优化"成产品语言，丢失了原始信号