P0b real needs validator

真需求判断五问

一句话定位

在需求评审前，用这五个问题给团队装上刹车系统——三问答不扎实，先不要做方案。

何时触发

• 需求评审会之前
• 团队情绪高涨，觉得"这个功能一定火"
• 需要区分"高频表达"和"真实需求"

输入

一条具体需求描述（不要抽象，要有主语）。

示例输入：

"希望系统支持一键催办"

输出

五问检测结果 + 真/伪需求判断 + 建议方向。

五个问题

Q1: 它是不是长期存在？

检测方法：

• 这个问题是否在不同项目/不同团队/不同时期都出现？
• 是否已经持续了一段时间（而不是最近才被提出）？
• 如果没有 AI，这个问题是否仍然存在？

输出格式：

存续性: [long-term/medium-term/recent/fad]
跨场景验证: [yes/no/partial]
无 AI 时仍然存在: [yes/no]

Q2: 它让谁持续付出了什么代价？

检测方法：

• 具体是哪些角色在付代价？
• 代价是时间、金钱、精力、情绪，还是职业风险？
• 这个代价是否被量化过（每次 X 分钟，每月 Y 元）？

输出格式：

付出角色: [角色列表]
代价类型: [time/money/energy/emotion/career_risk]
量化估算: [具体数字或范围]

Q3: 用户有没有为它发展出补偿行为？

检测方法：

• 用户是否已经有固定的解决方式（即使很厘赞）？
• 这些补偿行为是否已经被视为"正常流程"？
• 是否有人专门负责处理这些补偿行为？

输出格式：

补偿行为: [列表]
已常态化: [yes/no]
专职处理人: [yes/no - 角色名]

Q4: 它背后是不是有结构，而不只是偏好？

检测方法：

• 这个需求是否连着更大的流程缺口？
• 是否涉及角色权责、信息流、决策权的结构性问题？
• 如果解决了这个，是否会带动其他问题的解决？

输出格式：

结构性: [structural/situational/preference]
流程缺口: [具体缺口描述]
连锁效应: [yes/no - 如果有，列出]

Q5: 即使没人讨论，它还会不会继续存在？

检测方法：

• 如果今天没人提出，这个问题是否明天仍然在？
• 是否是组织/行业/人性的常态，而不是某个人的一时想法？
• 如果不做任何处理，问题是会恶化、保持还是消失？

输出格式：

自然存续: [yes/no]
常态类型: [organizational/industry/human_nature/situational]
不处理的趋势: [worsen/stable/diminish]

综合输出格式

real_needs_validation:
  input: "原始需求描述"
  
  q1_longevity:
    duration: "long-term/medium-term/recent/fad"
    cross_scenario: "yes/no/partial"
    exists_without_ai: "yes/no"
  
  q2_cost:
    bearers: ["角色列表"]
    cost_type: "time/money/energy/emotion/career_risk"
    quantified: "具体数字"
  
  q3_compensation:
    behaviors: ["补偿行为列表"]
    normalized: "yes/no"
    dedicated_handler: "yes/no - 角色"
  
  q4_structure:
    structural: "structural/situational/preference"
    process_gap: "流程缺口描述"
    chain_effect: "yes/no"
  
  q5_persistence:
    natural_existence: "yes/no"
    nature_type: "organizational/industry/human_nature/situational"
    trend_if_ignored: "worsen/stable/diminish"
  
  verdict:
    is_real_need: true/false
    confidence: "high/medium/low"
    pass_count: "X/5"
    reasoning: "判断理由"
  
  recommendation:
    action: "建议动作"
    priority: "P0/P1/P2"
    if_fake: "如果是伪需求，真正的问题可能是什么"
    next_step: "下一步"

使用规则

• 三问不过先停：五问中如果有三问答不扎实，先不要做方案
• 分开记录：把"高频表达"和"五问结果"分开记录，避免讨论被热度带跑
• 定期复盘：已通过的需求，上线 30 天后再跑一次五问验证

常见误判

• 高频 ≠ 真实：被多次提出的需求可能只是某个人的偏好
• 整齐 ≠ 可靠：需求描述很清晰不代表问题真实存在
• 可做 ≠ 该做：技术上能做不代表产品上该做

一句判断

真需求靠现实反复支付，伪需求靠热度和顺滑感成立。

核心概念

概念一：AI 时代伪需求为什么更难分辨

AI 让伪需求获得了前所未有的生长条件：

1. 平台持续放大可见表达：一个问题一旦更容易被说出、转发、评论和整理，它就在团队视野中反复出现。重复自然制造"这一定很重要"的错觉。
2. AI 让表层信号更像结论：曾经散乱、模糊、有噪声的输入，经模型整理后变成逻辑清晰的"高频痛点"。整齐感让人提早放弃怀疑。
3. 解决方案越来越容易生成：过去一个问题是否值得做，至少还要过实现成本关。今天很多表达一旦进入流程，几乎可以立刻长成看起来像真的功能。

来源：《AI rebuild product needs》第21章第1节——为什么 AI 让伪需求更难分辨。

概念二：伪需求四大来源

来源	特征	检测方法
被平台放大的主流表达	高频、明确、容易传播，但未必最深	追问"这个需求是在哪个平台/会议上被放大的？"
被焦虑和比较驱动的即时欲望	"别人都在用""我是不是落后了"	追问"如果没人知道你用不用，你还会要吗？"
被技术兴奋推出来的假问题	"能不能做"悄悄变成"是不是该做"	追问"如果不用 AI，这个问题还存在吗？"
被整理得过于顺滑的表层反馈	整理只增加可读性，不自动增加真实性	追问"用户说的和做的是否一致？"

来源：《AI rebuild product needs》第21章第2节——伪需求四大来源。

概念三：真需求五个特征

1. 持续性：长期存在的现实摩擦，不是一次性情绪。
2. 代价性：持续消耗时间、注意力、判断力、情绪容量、信任或责任安全感。
3. 补偿性：用户已为它发展出变通做法——系统没接住，代价不会凭空消失。
4. 结构性：和角色关系、流程断点、信息缝隙、责任机制有关，不是某个人的特殊偏好。
5. 非表演性：即使不被高频讨论，也仍然存在，靠现实里的重复代价成立。

来源：《AI rebuild product needs》第21章第3节——真需求通常有什么共同点。

概念四：真伪判断的目标不是做更多，而是少犯错

在 AI 时代，最大的组织浪费不再是"动得太慢"，而是"把误读的问题做得很完整"。一旦伪需求被快速产品化，就会产生一连串后果：

• 团队围绕它投入更多资源
• 数据开始在错误框架内循环
• 内部共识变得更难逆转
• 连用户反馈也会被再次整理成新的表层陈述

错误不是被发现的，而是被逐渐制度化的。

来源：《AI rebuild product needs》第21章第5节——真伪判断的目标是少犯错。

概念五：五问法与伪需求信号检测的配合

五问法是正向验证（"这是不是真需求"），伪需求信号检测是反向筛查（"这有没有可能是假的"）。两者配合使用，比单独用任何一个都更可靠。

伪需求五信号：

信号	检测问题	风险等级
S1: 技术兴奋型	"如果不用 AI，这个问题还存在吗？"	🔴 高
S2: 可见性偏差型	"这个需求是在哪个平台/会议上被放大的？"	🟡 中
S3: 表达-行为断裂型	"用户说的和做的是否一致？"	🔴 高
S4: 代理偏差型	"这个需求是谁的声音？终端用户还是中间人？"	🟡 中
S5: 解决方案伪装型	"他们描述的是问题，还是已经混进了解决方案？"	🔴 高

命中 ≥2 个 🔴 信号 → 回到需求四层拆解重新收集行为证据。

来源：主 Skill skills/ai-native-product-needs/SKILL.md Step 4。

分步执行

Step 1：收集原始表达——原汁原味记录

输入：一条具体需求描述（不要抽象，要有主语）

处理：

1. 原汁原味记录用户的表达，不加工、不翻译、不推断
2. 标注表达方式：direct/indirect/complaint/wish/compliment
3. 标注表达场景：在什么情况下、通过什么渠道、对谁说的
4. 同步记录：这个需求是在哪个平台/会议上被放大的？放大了多少次？

输出：原始表达记录 + 表达场景标注

---

Step 2：五问正向验证——逐项评估真实性

输入：Step 1 产出的原始表达记录

处理： 对需求逐项过五问：

1. Q1：它是不是长期存在？（跨项目/跨团队/跨时期验证）
2. Q2：它让谁持续付出了什么代价？（必须能命名具体角色和具体代价）
3. Q3：用户有没有为它发展出补偿行为？（列出已有的 workaround）
4. Q4：它背后是不是有结构，而不只是偏好？（是否连着更大的流程缺口）
5. Q5：即使没人讨论，它还会不会继续存在？（自然存续性验证）

每问必须有具体证据，不能靠推断。

输出：五问评估结果（每项标注 pass/fail + 证据）

---

Step 3：信号反向筛查——检测伪需求风险

输入：Step 1 的原始表达 + Step 2 的五问结果

处理： 逐项过伪需求五信号：

1. S1：如果不用 AI，这个问题还存在吗？
2. S2：这个需求是在哪个平台/会议上被放大的？
3. S3：用户说的和做的是否一致？
4. S4：这个需求是谁的声音？终端用户还是中间人？
5. S5：他们描述的是问题，还是已经混进了解决方案？

输出：伪需求信号标记（命中了哪几个，风险等级）

---

Step 4：综合判断——做/不做/先停的决策

输入：Step 2 的五问结果 + Step 3 的信号标记

处理：

1. 五问中 ≥3 问答不扎实 → 标记为"高伪需求风险"，先不要做方案
2. 命中 ≥2 个 🔴 信号 → 回到需求四层拆解重新收集行为证据
3. 五问全部通过 + 无 🔴 信号 → 标记为"真需求"，可以进入方案阶段
4. 中间状态 → 标记为"待验证"，补充行为证据后再判断

输出：真/伪/待验证 判断结论 + 理由

---

Step 5：分开记录——避免讨论被热度带跑

输入：Step 4 的判断结论

处理：

1. 把"高频表达"和"五问结果"分成两列记录
2. 在需求评审时，先展示五问结果，再展示高频表达
3. 如果团队讨论被热度带跑，暂停讨论，回到五问结果
4. 已通过的需求，上线 30 天后再跑一次五问验证

输出：分列记录的需求文档 + 评审规则

---

示例 1

场景：B2B 协作产品中的"一键催办"

原始需求：

"希望系统支持一键催办。"

听起来非常清晰，团队可以立刻开始讨论方案：要不要做催办按钮、要不要支持批量催办、要不要自动给相关人发消息。

五问验证：

问题	回答	证据
Q1：长期存在？	✅ 是	不同项目、不同团队里，总有人长期在追同一类事情
Q2：谁在付代价？	✅ 是	项目 owner、运营负责人、客户成功——反复翻记录、补上下文、找责任人
Q3：有补偿行为？	✅ 是	群里再发一遍、私聊提醒、给自己设闹钟、纸上再记一句
Q4：有结构？	✅ 是	背后连着责任认领不清、信息同步不全、流程悬空
Q5：没人讨论也存在？	✅ 是	只要责任还会悬空，总有人还得继续追

五问得分 5/5 → 真需求

伪需求信号筛查：

信号	检测结果
S1：技术兴奋型	❌ 未命中——不用 AI 这个问题也存在
S2：可见性偏差型	❌ 未命中——不是平台放大的
S3：表达-行为断裂型	❌ 未命中——用户说的和做的一致
S4：代理偏差型	❌ 未命中——是终端用户的声音
S5：解决方案伪装型	⚠️ 部分命中——"一键催办"可能混入了解决方案

信号风险：低。但需注意 S5——"催办"可能是表层方案，真正的问题是责任确认机制。

判断结论：真需求，但需要从"一键催办"向下挖一层。

团队看到的就不再只是"要不要做催办按钮"，而会更接近问题本体：

• 这里真正缺的是提醒动作，还是责任确认机制？
• 产品要处理的是"催一下"，还是"为什么总有人不得不反复补位"？
• 这个需求到底应该进按钮设计，还是进协作结构设计？

---

示例 2

场景：消费相机产品中的"打开就能拍好"

原始需求：

"我希望相机一打开就能拍好，不想手动调那么多东西。"

表面上看，这是一个"更自动、更傻瓜"的需求。但如果团队只把它理解为"用户嫌复杂"，就很容易做错东西。

五问验证：

问题	回答	证据
Q1：长期存在？	✅ 是	旅行、演唱会、拍孩子、拍宠物——完全不同的场景，用户都在反复说"来不及调""一慌就拍糊了"
Q2：谁在付代价？	✅ 是	用户付出的不只是多点几下的操作成本，而是机会成本——合唱部分已经过去了、孩子的表情闪过就没了
Q3：有补偿行为？	✅ 是	锁死一个默认模式不敢切；重要时刻用系统相机避开复杂 App；从一开始就连拍——宁可保住"拍到"也不追求完美设置
Q4：有结构？	✅ 是	不能重复的瞬间 + 有限的注意力 + 复杂的环境 + 极短的窗口——这不是界面偏好问题，是真实生活塑造的使用压力问题
Q5：没人讨论也存在？	✅ 是	只要用户还在紧张、不可重复的时刻打开 App，问题就不会消失

五问得分 5/5 → 真需求

伪需求信号筛查：

信号	检测结果
S1：技术兴奋型	❌ 未命中
S2：可见性偏差型	❌ 未命中
S3：表达-行为断裂型	❌ 未命中——用户说"不想调"，行为上确实在回避复杂操作
S4：代理偏差型	❌ 未命中
S5：解决方案伪装型	⚠️ 部分命中——"打开就能拍好"可能混入了解决方案

判断结论：真需求。产品要解决的不是"更少的设置"，而是怎样让用户更快进入拍摄状态、在复杂环境中自动保障基础画质、优先保证"拍到"再让用户做决策链。