with one click
p0b-real-needs-validator
// 真需求判断五问验车器。AI 时代最危险的不是没有需求,而是伪需求太容易长得像真需求。 基于《AI rebuild product needs》工具卡。
// 真需求判断五问验车器。AI 时代最危险的不是没有需求,而是伪需求太容易长得像真需求。 基于《AI rebuild product needs》工具卡。
[HINT] Download the complete skill directory including SKILL.md and all related files
| name | p0b-real-needs-validator |
| description | 真需求判断五问验车器。AI 时代最危险的不是没有需求,而是伪需求太容易长得像真需求。 基于《AI rebuild product needs》工具卡。 |
在需求评审前,用这五个问题给团队装上刹车系统——三问答不扎实,先不要做方案。
一条具体需求描述(不要抽象,要有主语)。
示例输入:
"希望系统支持一键催办"
五问检测结果 + 真/伪需求判断 + 建议方向。
检测方法:
输出格式:
存续性: [long-term/medium-term/recent/fad]
跨场景验证: [yes/no/partial]
无 AI 时仍然存在: [yes/no]
检测方法:
输出格式:
付出角色: [角色列表]
代价类型: [time/money/energy/emotion/career_risk]
量化估算: [具体数字或范围]
检测方法:
输出格式:
补偿行为: [列表]
已常态化: [yes/no]
专职处理人: [yes/no - 角色名]
检测方法:
输出格式:
结构性: [structural/situational/preference]
流程缺口: [具体缺口描述]
连锁效应: [yes/no - 如果有,列出]
检测方法:
输出格式:
自然存续: [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: "下一步"
真需求靠现实反复支付,伪需求靠热度和顺滑感成立。
AI 让伪需求获得了前所未有的生长条件:
来源:《AI rebuild product needs》第21章第1节——为什么 AI 让伪需求更难分辨。
| 来源 | 特征 | 检测方法 |
|---|---|---|
| 被平台放大的主流表达 | 高频、明确、容易传播,但未必最深 | 追问"这个需求是在哪个平台/会议上被放大的?" |
| 被焦虑和比较驱动的即时欲望 | "别人都在用""我是不是落后了" | 追问"如果没人知道你用不用,你还会要吗?" |
| 被技术兴奋推出来的假问题 | "能不能做"悄悄变成"是不是该做" | 追问"如果不用 AI,这个问题还存在吗?" |
| 被整理得过于顺滑的表层反馈 | 整理只增加可读性,不自动增加真实性 | 追问"用户说的和做的是否一致?" |
来源:《AI rebuild product needs》第21章第2节——伪需求四大来源。
来源:《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 产出的原始表达记录
处理: 对需求逐项过五问:
每问必须有具体证据,不能靠推断。
输出:五问评估结果(每项标注 pass/fail + 证据)
输入:Step 1 的原始表达 + Step 2 的五问结果
处理: 逐项过伪需求五信号:
输出:伪需求信号标记(命中了哪几个,风险等级)
输入:Step 2 的五问结果 + Step 3 的信号标记
处理:
输出:真/伪/待验证 判断结论 + 理由
输入:Step 4 的判断结论
处理:
输出:分列记录的需求文档 + 评审规则
原始需求:
"希望系统支持一键催办。"
听起来非常清晰,团队可以立刻开始讨论方案:要不要做催办按钮、要不要支持批量催办、要不要自动给相关人发消息。
五问验证:
| 问题 | 回答 | 证据 |
|---|---|---|
| Q1:长期存在? | ✅ 是 | 不同项目、不同团队里,总有人长期在追同一类事情 |
| Q2:谁在付代价? | ✅ 是 | 项目 owner、运营负责人、客户成功——反复翻记录、补上下文、找责任人 |
| Q3:有补偿行为? | ✅ 是 | 群里再发一遍、私聊提醒、给自己设闹钟、纸上再记一句 |
| Q4:有结构? | ✅ 是 | 背后连着责任认领不清、信息同步不全、流程悬空 |
| Q5:没人讨论也存在? | ✅ 是 | 只要责任还会悬空,总有人还得继续追 |
五问得分 5/5 → 真需求
伪需求信号筛查:
| 信号 | 检测结果 |
|---|---|
| S1:技术兴奋型 | ❌ 未命中——不用 AI 这个问题也存在 |
| S2:可见性偏差型 | ❌ 未命中——不是平台放大的 |
| S3:表达-行为断裂型 | ❌ 未命中——用户说的和做的一致 |
| S4:代理偏差型 | ❌ 未命中——是终端用户的声音 |
| S5:解决方案伪装型 | ⚠️ 部分命中——"一键催办"可能混入了解决方案 |
信号风险:低。但需注意 S5——"催办"可能是表层方案,真正的问题是责任确认机制。
判断结论:真需求,但需要从"一键催办"向下挖一层。
团队看到的就不再只是"要不要做催办按钮",而会更接近问题本体:
原始需求:
"我希望相机一打开就能拍好,不想手动调那么多东西。"
表面上看,这是一个"更自动、更傻瓜"的需求。但如果团队只把它理解为"用户嫌复杂",就很容易做错东西。
五问验证:
| 问题 | 回答 | 证据 |
|---|---|---|
| Q1:长期存在? | ✅ 是 | 旅行、演唱会、拍孩子、拍宠物——完全不同的场景,用户都在反复说"来不及调""一慌就拍糊了" |
| Q2:谁在付代价? | ✅ 是 | 用户付出的不只是多点几下的操作成本,而是机会成本——合唱部分已经过去了、孩子的表情闪过就没了 |
| Q3:有补偿行为? | ✅ 是 | 锁死一个默认模式不敢切;重要时刻用系统相机避开复杂 App;从一开始就连拍——宁可保住"拍到"也不追求完美设置 |
| Q4:有结构? | ✅ 是 | 不能重复的瞬间 + 有限的注意力 + 复杂的环境 + 极短的窗口——这不是界面偏好问题,是真实生活塑造的使用压力问题 |
| Q5:没人讨论也存在? | ✅ 是 | 只要用户还在紧张、不可重复的时刻打开 App,问题就不会消失 |
五问得分 5/5 → 真需求
伪需求信号筛查:
| 信号 | 检测结果 |
|---|---|
| S1:技术兴奋型 | ❌ 未命中 |
| S2:可见性偏差型 | ❌ 未命中 |
| S3:表达-行为断裂型 | ❌ 未命中——用户说"不想调",行为上确实在回避复杂操作 |
| S4:代理偏差型 | ❌ 未命中 |
| S5:解决方案伪装型 | ⚠️ 部分命中——"打开就能拍好"可能混入了解决方案 |
判断结论:真需求。产品要解决的不是"更少的设置",而是怎样让用户更快进入拍摄状态、在复杂环境中自动保障基础画质、优先保证"拍到"再让用户做决策链。