产品岗位 / 需求归集 / RQ-01
F旗舰T2+T3优先级 8.3微信截图转需求重复簇合并字段自动抽取六个来源一个需求

RQ-01 · 多渠道需求归集结构化

同一个「导出」需求，销售微信两条、客服工单两张、客户邮件一封、老板语音一段 —— 六次转世，需求池里还是没有它

一这件事现在是什么样

需求归集 · 真实业务触发

产品经理江晓的日常：销售总监郑海洋又发来一张微信截图 —— 华正重工的设备主管说「巡检数据想导出来给集团看」。她记得这话听过不止一次：客服工单里有、实施转发的邮件里有、上周老板陈默周日晚上那段 60 秒语音里好像也有。但需求池里搜「导出」只有 2025 年一条被拒的旧记录。六处来源、谁也没合并、谁也没结构化 —— 下周一的评审会，研发第一个问题一定是「这需求谁要的、几个人要」。

二痛点 · 每条都有来源

不是流程描述，是调研出来的真痛点 —— 每条可点开核对出处

1
销售带回的需求有结构性失真：客户随口一提、销售为拿下订单先一口答应 ——「销售的第一目标是签单，而不是做深度的需求调研」，研发照做就翻车的链路从入口就歪了依据 · 销售带回的需求为什么研发一做就翻车：客户传递给销售的需求不一定表达到位，销售收集的不一定全面 ——「销售的第一目标是签单，而不是做深度的需求调研」，客户随口一提、销售为拿下订单先一口答应
2
需求池的真实形态：「客户的操作问题、领导反馈的体验性改善问题、运维反馈的硬件问题全在里面」—— 没有分类、没有去重、没有优先级依据 · 用户反馈池的真实形态：「客户的操作问题、领导反馈的体验性改善问题、运维反馈的硬件问题全在里面」—— 没有分类、没有去重、没有优先级
3
重流程工具救不了：Jira 的 17 个必填字段让工程之外无人自愿使用，团队六个月后滑回 Excel —— 字段录入成本压在干活人身上，收益归管理层依据 · 重流程工具的失败机制：Jira 的「17 个必填字段」让工程之外无人自愿使用，团队六个月后滑回 Excel —— 字段录入成本全压在执行者身上、收益归管理层，影子表格是对它的理性反抗
4
需求池的价值在真不在多：有 PM 用 AI 两周生成 1000+ 功能点充需求池，前端被迫加班清洗「数字垃圾」—— 无来源的需求比没有需求更危险依据 · AI 扩写需求的灾难：PM 用 AI 两周生成 1000+ 功能点充需求池，前端被迫加班「糊弄」演示逻辑 —— 下游清洗成本全部转嫁研发
5
排序是政治决策：「被老板一句『和本季度核心指标关联度在哪』问死」—— AI 可以供证据，排序的拍板权在人在组织依据 · 需求排序的真实约束：「被老板一句『和本季度核心指标关联度在哪』问死」—— 中小企业的排序是政治决策，拍板权在人在组织

三换个做法之后

变化不在「快」，在「参与的角色」和「覆盖的范围」

✕ 现在的做法

  • 销售带回的需求有结构性失真：客户随口一提、销售为拿下订单先一口答应 ——「销售的第一目标是签单，而不是做深度的需求调研」，研发照做就翻车的链路从入口就歪了
  • 需求池的真实形态：「客户的操作问题、领导反馈的体验性改善问题、运维反馈的硬件问题全在里面」—— 没有分类、没有去重、没有优先级
  • 重流程工具救不了：Jira 的 17 个必填字段让工程之外无人自愿使用，团队六个月后滑回 Excel —— 字段录入成本压在干活人身上，收益归管理层
  • 需求池的价值在真不在多：有 PM 用 AI 两周生成 1000+ 功能点充需求池，前端被迫加班清洗「数字垃圾」—— 无来源的需求比没有需求更危险

✓ 交给 Agent 之后

  • 多来源文件一次读入，先做口径与完整性校验，再开始算
  • 每条结论绑定来源文件、字段或条号，可以被审
  • 产出是企业真会流转的正式件（带签批栏），不是一张展示用的表
  • 该拦的地方给出「现在还不能提交」，并给不用干等的替代方案

四场景闭环

5 步 · 每一步的产出都是下一步的输入

第 1 步
来源盘点 · 六个渠道各有各的方言销售截图、客服工单、实施邮件、老板语音、客户群、历史池 —— 每条记录标注渠道与时间
第 2 步
抽取结构化 · 字段从原文里长出来背景/提出人/场景/期望 —— 每个字段带原文引用，人一眼能核
第 3 步
语义查重 · 同一需求的多次转世合并「导出数据」「报表下载」「给集团交材料」聚成一个簇 —— 每簇给合并建议与差异说明
第 4 步
证据包生成 · 评审会的弹药每条需求带来源全景：几个客户、几个渠道、各说了什么原话 —— 研发问「谁要的」，一页答完
第 5 步
确认入池 · 人拍板合并建议逐条确认 —— AI 不入池、不生效，需求池的主权在人

要准备什么

销售/客户微信聊天记录（截图或导出）
原图扔进来 —— 不要求先转文字
客服工单导出（近 30-90 天）
Excel 原样 —— 全量不抽样
客户与实施顾问的邮件往来
转发原始邮件即可
需求池现状导出
Excel/飞书表格/禅道均可 —— 归集结果要与现状查重

为什么这个场景值得做

痛感 5 × AI 适配 5 ÷ 落地难度 3 = 8.3

最大差异点 · 不要求任何人改习惯：销售照样发截图、老板照样发语音、客服照样开工单 —— AI 从原始记录里把字段抽出来，人只做确认。

评分口径：痛感看「这事没做好谁会生气、生气到什么程度」； AI 适配看「输入是否非结构化、是否要跨部门取数、错了能不能当场看出来」； 落地难度是分母 —— 需要客户先做数据治理的场景，分数会被压得很低。

五会产出什么

判断标准只有一个：这份东西能不能直接进企业的流程

正式件本体
多渠道需求归集结果.xlsx
正式件本体 · 结构化条目 + 重复簇 + 证据包
可派发清单
待确认清单.xlsx
语义存疑的记录 · 每条给判断依据 · 人核实后归档
可派发清单
需求来源全景图.xlsx
单需求的六处来源对照 · 渠道/时间/原话

这套东西不承诺什么

不做「自动入池生效」—— 归集结果是人确认后才进需求池。也不做「自动补全编造字段」—— 每个字段要么来自原文、要么标明缺口等人补，绝不编。

想看具体怎么跑？

Live Demo 里有一个完整案例的每一步，包括 Agent 在哪一步拦住了

查看 Live Demo →