// 需求四层拆解卡。很多团队一听到用户表达，就直接拆功能。 这张卡强迫团队先把"用户说了什么"和"用户真正被什么困住"分开。 基于《AI rebuild
[HINT] Download the complete skill directory including SKILL.md and all related files
| name | p0c-needs-decomposer |
| description | 需求四层拆解卡。很多团队一听到用户表达，就直接拆功能。 这张卡强迫团队先把"用户说了什么"和"用户真正被什么困住"分开。 基于《AI rebuild |
把一条用户原话，逐层拆到表达、场景、处境、代价四层，找到真正该解决的问题。
用户的原始表达（一句话或一段话）。
示例输入：
"希望自动把消费分类做得更准"
四层拆解结果 + 问题重定义 + 方案方向建议。
任务：原汁原味记录用户的表达，不加工、不翻译、不推断。
输出格式：
用户原话: "..."
表达方式: [direct/indirect/complaint/wish/compliment]
表达场景: [where/when/how this was expressed]
任务：描绘问题发生的具体场景，包括时间、地点、角色、流程位置。
输出格式：
时间节点: [when it happens]
地点/界面: [where it happens]
涉及角色: [who is involved]
流程位置: [which step in the workflow]
频率: [how often]
任务：探索用户被困住的深层原因，找出系统性缺失和隐性代价。
输出格式：
被困原因: [why the user is stuck]
系统缺失: [what the system fails to provide]
补位角色: [who is filling the gap]
党底角色: [who bears the cost]
隐性劳动: [unseen work being done]
任务：量化用户因此承受的持续损失，包括可见和不可见的。
输出格式：
时间代价: [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: "怎么证明做对了"
原始需求：
"希望自动把消费分类做得更准"
四层拆解：
| 层次 | 内容 |
|---|---|
| 表达层 | 用户说"不想每次都手动改分类" |
| 场景层 | 通常发生在下班后、睡前或月底对账时，想快速看懂钱花去了哪里 |
| 处境层 | 他并不只是嫌麻烦，而是本来就对支出有点失控感；一旦分类不断出错，他还得重新回忆每笔钱为什么花，越改越想逃避 |
| 代价层 | 如果产品长期接不住，用户失去的不只是几次修正动作，而是对财务状况的掌握感，最后很可能直接放弃记账 |
重定义：
如果一条需求说不清处境和代价，它通常还不够成熟。
很多需求错误不是团队没听到用户说什么，而是太容易把用户说的话直接当成需求本身。
用户说"我想要自动同步"，很容易放进 backlog。用户说"我想要更少的重复确认"，很容易理解为流程优化。但这些表达往往只是最容易说出的那一层——可能是动作层面的抱怨，可能是从环境中学来的产品语言，也可能是他们觉得系统更容易理解的请求。真正让他们疲惫的东西，往往没有被完全表达出来。
来源：《AI rebuild product needs》第18章第1节——为什么表达看起来这么像需求本身。
场景（scenario）防止需求漂浮在抽象中——谁在用、什么时间、在流程的哪一步、周围有什么角色和上下文。但场景仍然不是终点。
场景能告诉你问题发生在哪里，但不能自动告诉你为什么这件事一直压在某一个人身上。这时候需要进入处境（situation）：
来源：《AI rebuild product needs》第18章第2节——场景和处境的区别。
为什么有些问题一直被产品团队低估？因为表面上很多问题看起来是"小动作"，而沉重的部分藏在动作背后的代价里。
例如，一个人不断在系统外多发一条确认消息。表面动作很小——只是多几行文字。但深挖下去会发现：她在为不清的责任认领补位、在预防未来无人认领的问题、在用自己的额外注意力维持协作不崩塌。
产品真正需要处理的，不是"帮用户少发一条消息"，而是那条消息背后的整段隐性劳动。
来源：《AI rebuild product needs》第18章第3节——处境的核心是代价。
模型天然擅长处理已经被表达、记录和整理过的东西。如果输入主要是表达层材料，模型就只能在表达层工作——这不是模型弱，而是输入本身已经把现实压平了。
AI 时代不是让模型做需求工作的理由，而是让团队更谨慎地决定模型处理什么材料、在流程中坐在哪个位置的理由。否则模型越强，就越快把表达变成看起来更像答案的东西。
来源：《AI rebuild product needs》第18章第4节——为什么 AI 特别容易停在表达层。
如果"需求不是一句话而是一种处境"成立，那写需求条目的方式也必须重写。一个成熟的需求条目至少包含四部分：
只有四层同时出现时，需求才开始像真正的问题定义，而不只是一句容易记录的话。
来源：《AI rebuild product needs》第18章第5节——成熟的需求条目应该长什么样。
输入：用户的原始表达（一句话或一段话）
处理：
输出：表达层记录（附表达方式和场景标注）
输入：Step 1 的表达层记录
处理：
输出：场景层描述（时间/地点/角色/流程/频率）
输入：Step 2 的场景层描述
处理：
关键追问句式：
输出：处境层描述（被困原因/系统缺失/补位角色/兜底角色/隐性劳动）
输入：Step 3 的处境层描述
处理：
输出：代价层描述（时间/金钱/情绪/机会/长期损失）
输入：Step 1-4 的四层完整记录
处理：
输出：问题重定义 + 方向建议
原始需求：
"我希望医生能回复得快一点。"
表面上看，这是一个简单的需求——团队自然会想到供应排班、提醒机制和更好的轮值制度。
四层拆解：
| 层次 | 内容 |
|---|---|
| 表达层 | 用户说"希望医生回复快一点" |
| 场景层 | 通常发生在深夜或周末，用户独自面对检查结果，不知道是否应该立刻去医院；或者在工作时间偷偷发了消息，不想让周围人知道此刻有多焦虑 |
| 处境层 | 用户反复追问不只是因为"等待烦人"。他们处于信息不对称、情绪高压、无法自行判断的状态。可能已经问过家人、搜了大量资料，但越看越害怕 |
| 代价层 | 如果产品长期接不住，用户损失的不只是等待时间，而是在最需要支持的时刻"没人先接住"的孤独感。长期来看，用户会放弃在线问诊，回归线下——或者更糟，在焦虑中做出错误判断 |
重定义：
来源：《AI rebuild product needs》第18章第2节示例——在线问诊场景。
原始需求：
"希望会后自动推送待办事项。"
四层拆解：
| 层次 | 内容 |
|---|---|
| 表达层 | 用户说"希望会后自动推送待办事项" |
| 场景层 | 通常发生在跨部门会议结束后，参会者各自回到工位，开始处理自己手头的事 |
| 处境层 | 对不同角色，这完全是不同的处境——普通参会者只是确认下一步该做什么；但如果没人再追一遍，项目负责人会担心事情悬空；新人即使没听懂也不敢问，只能回去按自己的理解做一个版本，等出错后再修 |
| 代价层 | 如果产品只做"平均推送"，能覆盖很多人，但很难真正接住任何一个具体的人。项目负责人持续损失的是"不敢放松"的安全感；新人持续损失的是"不怕犯错"的信任感 |
重定义：
来源：《AI rebuild product needs》第18章第2节示例——会后协作场景。