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（演示逐步）

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

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

案例设定：驭数科技（虚构）归集日：郑海洋又发来华正重工的微信截图 —— 设备主管刘科长说「巡检数据想导出来给集团看」。江晓记得这话听过不止一次：客服工单里有、实施转发的邮件里有、上周老板陈默周日晚上那段 60 秒语音里好像也有。但需求池里搜「导出」只有 2025 年一条被拒的旧记录。

输入来源6 处 · 4 类渠道有效合并5 处 · 1 条需求存疑待核1 处 · 民康工单旧案撞上2025-11 被拒记录

输入产品手上能拿到的东西

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

• 01_销售微信记录（华正相关）.txt 两条微信截图的原始现场 —— 需求的第一来源微信记录 · 2026-06-14 与 07-02
• 02_客服工单导出（导出相关）.xlsx 近 60 天工单里与「导出」相关的全量 —— 第二来源客服工单系统导出 · 2026-08-20
• 03_实施邮件（华正信息化科长）.txt 书面来源 —— 证据等级最高的那条邮件转发 · 2026-07-21
• 04_老板语音转写.txt 陈默周日晚上那段 60 秒 —— 第六来源微信语音 · 2026-08-17 21:47
• 05_需求池现状导出（导出相关）.xlsx 查重的对照面 —— 旧记录在等着这次归集禅道需求池导出 · 2026-08-20

注意标橙色那一份 —— 03_实施邮件（华正信息化科长）.txt。它邮件转发 · 2026-07-21，平时压根不在核对范围里。这个场景的价值，很大一部分就来自把它读进来。

提示词就说这么几句

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

最近两个月销售微信截图、客服工单导出、实施转发的客户邮件、还有老板上周那段语音都在这，帮我归集一遍。每个渠道的需求都抽出来，字段填齐，但每个字段要能对回原文，编的不行； 「导出」这个词在好几个地方出现过，帮我查一下是不是同一个需求，该合并的合并、拿不准的单独标出来； 跟需求池里的旧记录也查个重，有没有以前被拒过的； 最后给我一份能带上评审会的证据包：这需求谁提的、几个客户、各说了什么原话。

短是因为「渠道方言识别、语义查重、字段抽取规则、证据包结构」都在能力包里。产品经理只要把原始记录扔进来。

触发第六次听见「导出」vs 需求池里那条 2025 年的旧记录

六处来源、四种形态 —— 没有归集的合力，每一处都只是孤声

江晓把微信记录、工单导出、实施邮件、语音转写、需求池现状全部扔进来 —— 归集的价值在「合并后的证据包」，不在任何单一来源。

第 1 步 · 来源盘点 · 六处四种形态

微信/工单/邮件/语音 —— 每处的证据等级不一样

第 2 步 · 语义查重 · 同一需求的多次转世

「导出数据」「报表下载」「给集团交材料」—— 聚成一个簇

第 3 步 · 字段抽取 · 每个字段对回原文

背景/提出人/场景/期望 —— 编的一个不要

第 4 步 · 旧案对照 · 2025 年的那次拒绝

复活与否的讨论基准 —— 旧决策的完整理由在 RQ-03

第 5 步 · 证据包成册 · 评审会的第一页

谁要的、几个客户、各说了什么 —— 一页答完

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

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

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

1. Skill 能力包

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

多渠道需求归集结构化 · Skill

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

版本 v1.0

req-intake.zip

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

包内结构

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

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

2. 原始素材

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

📁RQ-01 · 演示素材

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

共 5 份

• 01_销售微信记录（华正相关）.txt 两条微信截图的原始现场 —— 需求的第一来源
• 02_客服工单导出（导出相关）.xlsx 近 60 天工单里与「导出」相关的全量 —— 第二来源
• 03_实施邮件（华正信息化科长）.txt 书面来源 —— 证据等级最高的那条
• 04_老板语音转写.txt 陈默周日晚上那段 60 秒 —— 第六来源
• 05_需求池现状导出（导出相关）.xlsx 查重的对照面 —— 旧记录在等着这次归集

怎么用

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

3. 提示词卡片

最近两个月销售微信截图、客服工单导出、实施转发的客户邮件、还有老板上周那段语音都在这，帮我归集一遍。每个渠道的需求都抽出来，字段填齐，但每个字段要能对回原文，编的不行； 「导出」这个词在好几个地方出现过，帮我查一下是不是同一个需求，该合并的合并、拿不准的单独标出来； 跟需求池里的旧记录也查个重，有没有以前被拒过的； 最后给我一份能带上评审会的证据包：这需求谁提的、几个客户、各说了什么原话。

为什么这么短就够了：短是因为「渠道方言识别、语义查重、字段抽取规则、证据包结构」都在能力包里。产品经理只要把原始记录扔进来。

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

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

自己组织输入的三步法

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

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

4. 预期输出

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

📋正式交付物

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

共 3 份

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

Skill 里固化了什么：从历史池里「想起」了这条需求的旧案该拦的地方拦住了排除性结论把技术动作翻译成钱

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

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

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

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

需求归集 · 产出即下一步输入

RQ-02 · 需求池清淤体检 — 需求池 427 条，最近半年动过的不到三分之一 · 「进来了没人清、历史需求没人敢删」—— 每一条都是不敢碰的存量 查看 →RQ-03 · 需求来源回溯档案 — 老板会上问「华正那个导出功能后来怎么样了」· 没有回溯档案的产品经理，每次提问都是一次翻聊天记录的考古 查看 →

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

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