PM-01 · 需求池多源收口与语义去重

① 场景引入

一、这件事现在是什么样

产品管理 · 真实业务触发

季度需求评审前一周，产品经理要给评审会备料：客服工单 240 张、销售拜访纪要 17 份、客户访谈转写 6 篇、现有需求池存量 380 条——粗扫就知道「多币种结算」至少以四种说法散在不同渠道（工单「美元账单对不上」/销售「恒鲜问过外币」/访谈「越南采购要本地币」），而谁也说不清这条需求到底代表多少客户、多少 ARR。

二、痛点 · 每条都有来源

1需求天然来自六类来源，「大家都能提需求，但没人知道该提到哪里」——重复需求变多、优先级变乱，产品经理被「谁声音大就先做谁」牵着走依据 · 国内产品管理实践：需求来源天然包括客户反馈、销售建议、客服工单、老板临时想法、运营诉求、实施现场问题；入口一多就出现「大家都能提需求，但没人知道该提到哪里」——重复需求变多、优先级变乱，产品经理被「谁声音大就先做谁」牵着走2PM 每周 12+ 小时用于收集管理反馈；只有 1/10 的团队能从所有可用来源捕获客户反馈，74% 的 PM 把高质量反馈列为最大挑战依据 · UserVoice 调研（200 名产品从业者）：收集和管理反馈可占产品经理每天 25% 以上、每周 12+ 小时3同一个需求换个说法就是三条记录（「夜间太刺眼」「增加深色主题」「重点客户问过 Dark Mode」）；按关键词机械去重又会把场景不同的相似诉求错误合并依据 · 需求重复录入的典型形态：客户访谈说「夜间看起来太刺眼」、客服工单写「希望增加深色主题」、销售反馈「几个重点客户都问过 Dark Mode」——逐条录入就是三条记录；按关键词机械去重又会把场景不同的相似诉求错误合并4同一个feature request 散落在工单/CRM/群聊/邮件中互不关联——「三个信号、一个洞察、零连接」；只有 37% 的会议产生明确决策依据 · 反馈碎片化代价：同一个 feature request 散落在 Zendesk/Salesforce/Slack/邮件中互不关联——「三个信号、一个洞察、零连接」；只有 37% 的会议产生明确决策，44% 的行动项永远无人完成5需求池治理共识：只进不出、缺乏准入判断、没有分层处理——治理次序是先堵新增（入口收口），再梳分类，最后归档存量依据 · 需求池治理共识：需求池越堆越满的根因不是需求多，而是入口未治理——只进不出、缺乏准入判断、没有分层处理；治理次序是「先堵新增（入口收口）→ 再梳分类 → 最后归档存量」6反馈闭环差的公司浪费最多 35% 开发资源造客户不想要的功能；72% 的高绩效销售组织与产品有正式反馈闭环，绩效差的只有 28%依据 · Gartner：反馈闭环差的公司浪费最多 35% 的开发资源去造客户根本不想要的功能

三、换个做法之后

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

✕ 现在的做法

• 需求天然来自六类来源，「大家都能提需求，但没人知道该提到哪里」——重复需求变多、优先级变乱，产品经理被「谁声音大就先做谁」牵着走PM 每周 12+ 小时用于收集管理反馈；只有 1/10 的团队能从所有可用来源捕获客户反馈，74% 的 PM 把高质量反馈列为最大挑战同一个需求换个说法就是三条记录（「夜间太刺眼」「增加深色主题」「重点客户问过 Dark Mode」）；按关键词机械去重又会把场景不同的相似诉求错误合并同一个 feature request散落在工单/CRM/群聊/邮件中互不关联——「三个信号、一个洞察、零连接」；只有 37% 的会议产生明确决策

✓ 交给 Agent 之后

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

四、场景闭环

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

1. 多源原始料登记工单/纪要/转写按来源登记，原始表述原样保留——归一不改写证据
2. 语义相似度聚类同义不同表述归到同源组；「疑似同源但场景不同」单独标，不自动合并
3. 证据链聚合每条归一需求挂：原始表述N 条 / 来源渠道数 / 提出客户数 / 关联 ARR（销售口径）
4. 存量池对照380 条存量里已存在的同源项标出——新增还是并入，评审定
5. 评审材料包成稿按证据链厚度排序的需求摘要 + 建议优先级栏留空 + 待确认同源清单

要准备什么：客服工单导出（近一个月全量）240 张含口语化描述——需求密度最高的矿脉，「美元账单对不上」就在这里销售/售前拜访纪要（微信记录与会议纪要）ARR 证据的来源——哪家客户、什么体量、问过什么客户访谈转写未过滤的原始抱怨——需求真实形态，也是语义归一的校准语料现有需求池存量导出（380 条）只进不出的存量——收口前先看有没有已经进来的同源项

为什么这个场景值得做

优先级评分：痛感 4 × AI 适配 5 ÷ 落地难度 2 = 11.0

最大差异点：不是又一个「需求管理工具」：入口从「让人填表」改成「把散装原始料倒进来」——工单、拜访纪要、访谈转写原样丢入，语义去重在收口侧完成。每条归一需求保留完整证据链（几条原始表述、来自几个渠道、哪几家客户、关联多少 ARR），评审会看的是证据链的厚度，而不是谁嗓门大。

评分口径：痛感看「这事没做好谁会生气、生气到什么程度」；

AI 适配看「输入是否非结构化、是否要跨部门取数、错了能不能当场看出来」；

落地难度是分母 —— 需要客户先做数据治理的场景，分数会被压得很低。

五、会产出什么

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

• 正式件本体：需求归一与证据链汇总表.xlsx 正式件 · 归一需求 × 原始表述/渠道/客户/ARR 证据链 · 含评审签批栏
• 可派发清单：疑似同源待复核清单.xlsx 语义相近但场景可能不同的条目 · 逐条给分拆/合并建议 · 人判
• 可派发清单：存量池处置建议.xlsx 41 条已上线重复反馈 / 长期无人跟进项 · 转客户成功或归档

这套东西不承诺什么：只做归一与聚类，不做优先级决策——建议优先级栏一律留空给评审会；语义相似但场景不同的条目只标「疑似同源待确认」，不自动合并；带 ARR 的证据链只引用销售提供的合同金额，不估算、不外推。

② Live Demo（演示逐步）

演示模式 · 可视化预演 本页展示的是「应该怎么跑、每一步看什么、交付什么」，用的是真实业务格式的脱敏构造数据， 不宣称已接入客户生产系统，也不承诺任何效率提升百分比。

案例设定：明衡软件产品部。月末需求评审材料准备：本月工单 240 条、三路原始需求 126 条归一为 79 条；存量需求池 380 条本轮处置。多币种结算以 4 条同义表述跨 3 渠道 3 客户出现，ARR 合计 67 万——是上会名单的第一条。

输入文件4 份原始条目126 条 · 归一 79多币种证据链4 条表述 · ARR 67 万存量池380 条 · 本轮处置

输入软件公司手上能拿到的东西

不需要整理格式、不需要改文件名 · 直接拖进对话框

• 01_工单导出_本月240条.xlsx 客服工单系统本月导出——四类分布与需求类明细客服部系统导出 · 每月初
• 02_销售与客户成功拜访记录_本月41条.xlsx 销售与客户成功的拜访及复盘记录汇总——需求入口的第二路销售部 / 客户成功部 · 每周汇总
• 03_群消息与邮件捞取_本月27条.xlsx 项目群与邮箱里捞出的需求表述——第三路入口产品部捞取 · 每周两次
• 04_存量需求池_380条.xlsx 历史累积的存量需求池——只进不出的死水，本轮开始流动产品部维护 · 上月评审会开了 3 小时议程过半

注意标橙色那一份 —— 02_销售与客户成功拜访记录_本月41条.xlsx。它销售部 / 客户成功部 · 每周汇总，平时压根不在核对范围里。这个场景的价值，很大一部分就来自把它读进来。

提示词就说这么几句

没有模板、没有表单 · 专业规则由 Skill 兜底

季度评审要备料。这是近一个月的客服工单全量导出、17 份销售拜访纪要、6 篇客户访谈转写，还有现有需求池的 380条存量。 帮我做多源收口：

1. 语义上去重——同一个需求的不同说法归到一起，但像「导出慢」和「导出格式不对」这种像但不是的，分开并标出来给我复核。
2. 每条归一后的需求，把证据链给我凑齐：几条原始表述、几个渠道、哪几家客户、关联多少 ARR（ARR 只用销售给的合同数，别估）。
3. 存量池里已经有同源的，标出来是并入还是新增。
4. 已上线功能被重复反馈的，单独挑出来转客户成功。 评审材料按证据链厚度排序，建议优先级那栏留着，评审会上大家填。

语义归一规则、证据链格式、误合并复核标记在能力包里；现场只需把四路原始料丢进来——不许任何人为了「格式统一」先手工整理一遍。

触发月末评审材料 · 三路入口 126 条原始表述倒进来

工单 58 + 拜访 41 + 群邮件 27——没人需要填新表

需求入口六个渠道人人能提、没人知道该提到哪里。这个月起的规矩：原始料照倒、归一在收口侧完成——禁止任何人为了「格式统一」先手工整理一遍。

第 1 步 · 三路入口收口 · 126 条归一为 79 条，合并 47 条

归并在收口侧完成——入口的人一个都不用动

第 2 步 · 多币种结算的证据链 · 4 条表述、3 渠道、3 客户、67 万 ARR

同义合并不是去重——是把同一件事的证据摆到一起

第 3 步 · 疑似同源待复核 · 语义相近不等于同一件事

「导出慢」和「导出格式不对」不能被关键词去重搅成一个坑

第 4 步 · 存量池处置 · 217 条「已上线重复反馈」是最大的一块

功能上了客户还在提——问题不在需求池，在告知

不讲省了多久 · 讲少了几个隐患、沉淀了什么

③ 能力沉淀（Skill / 提示词 / 预期输出 / 人工边界）

1. Skill 能力包

导入之后，同类任务会自动按这套规则走 —— 提示词才能写得那么短

需求池多源收口与语义去重 —— 「深色主题」从三个渠道进来就是三条记录 · Skill

SKILL.md 主本 + references（输出骨架 / 判据 / 渲染脚本）· 符合 WorkBuddy Skill 规范

版本 v1.0

feedback-intake-and-semantic-dedup.zip

在 WorkBuddy 里直接上传这个 zip 即可导入

包内结构

• SKILL.md 主本 —— YAML 元信息 + 执行流程 + 硬规则 + 人工边界
• references/output_template.md 输出骨架（sheet 名 / 分区顺序 / 列头）+ 可直接运行的渲染脚本
• references/judgement_rules.md 判据与口径 —— 什么情况算异常、什么情况必须拦住

references 不会一次性全读进来 —— Agent 按需取用。所以 Skill 可以写得很细，不会拖慢每次对话。

2. 原始素材

这些就是软件公司手上真实能拿到的东西 —— 格式不统一是常态，不是问题

📁PM-01 · 演示素材

脱敏构造数据 · 真实业务格式 · 埋点可核验

共 4 份

• 01_工单导出_本月240条.xlsx 客服工单系统本月导出——四类分布与需求类明细
• 02_销售与客户成功拜访记录_本月41条.xlsx 销售与客户成功的拜访及复盘记录汇总——需求入口的第二路
• 03_群消息与邮件捞取_本月27条.xlsx 项目群与邮箱里捞出的需求表述——第三路入口
• 04_存量需求池_380条.xlsx 历史累积的存量需求池——只进不出的死水，本轮开始流动

怎么用

• 把素材全部拖进 WorkBuddy 对话框（不需要整理格式、不需要改文件名）
• 粘贴下方提示词发送
• 拿到正式件初稿 —— 签批栏留空，推荐意见留空，由你填

3. 提示词卡片

季度评审要备料。这是近一个月的客服工单全量导出、17 份销售拜访纪要、6 篇客户访谈转写，还有现有需求池的 380条存量。 帮我做多源收口：

1. 语义上去重——同一个需求的不同说法归到一起，但像「导出慢」和「导出格式不对」这种像但不是的，分开并标出来给我复核。
2. 每条归一后的需求，把证据链给我凑齐：几条原始表述、几个渠道、哪几家客户、关联多少 ARR（ARR 只用销售给的合同数，别估）。
3. 存量池里已经有同源的，标出来是并入还是新增。
4. 已上线功能被重复反馈的，单独挑出来转客户成功。 评审材料按证据链厚度排序，建议优先级那栏留着，评审会上大家填。

为什么这么短就够了：语义归一规则、证据链格式、误合并复核标记在能力包里；现场只需把四路原始料丢进来——不许任何人为了「格式统一」先手工整理一遍。

换成你自己的业务：把素材换成你手上的真实文件即可。导入 Skill 之后，

该走几步、什么口径、什么情况必须拦住，Agent 自己知道 —— 你只需要说清这是什么事。

自己组织输入的三步法

• 用自然语言说清核心需求 —— 就按平时跟同事交代活的方式说：什么事、什么文件、什么要求。不用讲究格式。
• 调用 Skill 补齐专业规则 —— 导入本页 Skill 后，流程、口径、硬规则 Agent 自己知道。
• 用「增强提示词」补全遗漏 —— 输入框旁边有增强按钮，把随口说的话补成更完整的表述。

分工：自然语言负责「这是什么事」，Skill 负责「该怎么做」，增强提示词负责「别漏了什么」。

4. 预期输出

不方便现场跑的时候可以直接拿这份给客户看 · 与实跑结果同结构

📋正式交付物

带签批栏 / 冻结首行 / 开筛选 —— 判断标准是「能不能直接进企业的流程」

共 3 份

XLSPM-01_需求归一与证据链汇总表.xlsx正式件 · 归一需求 × 原始表述/渠道/客户/ARR 证据链 · 含评审签批栏 XLSPM-01_疑似同源待复核清单.xlsx语义相近但场景可能不同的条目 · 逐条给分拆/合并建议 · 人判下载

• ↓XLSPM-01_存量池处置建议.xlsx 41 条已上线重复反馈 / 长期无人跟进项 · 转客户成功或归档

Skill 里固化了什么：「多币种结算」的四条记录合成了一条一次差点发生的误合并排除性结论把技术动作翻译成钱

输入清单：客服工单导出（近一个月全量）240 张含口语化描述——需求密度最高的矿脉，「美元账单对不上」就在这里销售/售前拜访纪要（微信记录与会议纪要）ARR 证据的来源——哪家客户、什么体量、问过什么客户访谈转写未过滤的原始抱怨——需求真实形态，也是语义归一的校准语料现有需求池存量导出（380 条）只进不出的存量——收口前先看有没有已经进来的同源项

人工边界：只做归一与聚类，不做优先级决策——建议优先级栏一律留空给评审会；语义相似但场景不同的条目只标「疑似同源待确认」，不自动合并；带 ARR 的证据链只引用销售提供的合同金额，不估算、不外推。

升为客户真实案例还缺什么：客户当前真实输入文件（不要整理过的）岗位现行 SOP 与审批链（金额分档、谁签字）至少一次真实出过问题的案例客户当前正在用的正式输出模板客户确认的阈值口径（多少天算临期、多少金额算大额）

5. 同一角色下的其他场景

产品管理 · 产出即下一步输入

• PM-02 · 基于自有需求库的 PRD 初稿：评审会 3 小时，八成时间耗在信息对齐

上下游串起来就是完整链路。每一步的产出都是下一步的输入，不用在不同工具之间来回复制粘贴。

场景内容基于 WorkBuddy 产品能力整理，演示中的企业、人物与数据均为虚构，不代表任何客户的实际成效；痛点引用的公开来源已做脱敏处理。网页版由原资料转换，部分演示表格以原文形式展示。