RQ-01
F旗舰
8.3
多渠道需求归集结构化
同一个「导出」需求，销售微信两条、客服工单两张、客户邮件一封、老板语音一段 —— 六次转世，需求池里还是没有它
中小企业的产品经理不是一个岗位，是同一个人戴着的五张面具：需求管理员、产品设计师、项目经理、测试验收员、客户接口人 —— 大厂的「产品/策略/数据」分工在这里不存在。而真正让产品经理背锅的从来不是文档写得慢，是需求池半年没洗、用户反馈从来没聚类过、需求变更从没留过档、定制占比从没算过账 —— 四个「从没」，每一个都对应一次真实的返工或事故。所以这套场景库不按大厂职能表切，按「五张面具各自背的锅」切。
全部场景来自一份逐条打过分的候选清单 —— 打分口径是痛感强度 × AI 适配度 ÷ 落地难度，只保留得分站得住且没命中排除法则的。被砍掉的伪需求也一并列出来，因为主动说清不做什么，比被客户问出来强得多。 被砍掉的 12 个伪需求也一并列出来了。
产品岗是「AI 写文档」故事的重灾区，但翻车判例最密集的恰恰是这里：AI 一键生成 PRD 引发返工两周、项目延期三个月；AI 编造的细节让研发照做、上线即翻车；PM 用 AI 两周生成一千多个功能点、前端被迫加班清洗「数字垃圾」。虚假精确比没有文档更害人。AI 的可行区在证据层：归集、查重、回溯、找茬、留痕、算账 —— 判断与拍板永远是人。所以每个场景在收进来之前都要过三道排除法则：是不是一段脚本更快更准（法则一）、是不是需要判断取舍或对外担责（法则二）、真实瓶颈是不是根本不在这一步（法则三）。现场选场景时可以直接用一句话帮客户剔掉伪需求：「这份 PRD 里的每句话，你敢为它导致的返工签字吗？」
归集（3） + 评审（3） + 变更（3） + 验收（3） + 客户（3） = 15 个场景， 每个配齐场景引入 / Live Demo 两份内容。