p0b-real-needs-validator

---
name: p0b-real-needs-validator
version: 1.0.0
description: 真需求判断五问验车器。AI 时代最危险的不是没有需求，而是伪需求太容易长得像真需求。 基于《AI rebuild product needs》工具卡。
author: Max
tags: p0, 需求发现, 真需求验证
- book-skill
- needs-discovery
- validation
- fake-needs
- ai-product
requires: []
homepage: https://github.com/gmaxxxie/ai-native-product-agent-skills/tree/main/skills/p0b-real-needs-validator
stage: p0b
source_book: AI rebuild product needs
source_chapter: 第2章 真需求验证

---


# 真需求判断五问

## 一句话定位

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

## 何时触发

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

## 输入

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

**示例输入**：
```
"希望系统支持一键催办"
```

## 输出

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

## 五个问题

### 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]
```

## 综合输出格式

```yaml
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：解决方案伪装型 | ⚠️ 部分命中——"打开就能拍好"可能混入了解决方案 |

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