RQ-03 · 需求来源回溯档案

① 场景引入

老板会上问「华正那个导出功能后来怎么样了」· 没有回溯档案的产品经理，每次提问都是一次翻聊天记录的考古

一、这件事现在是什么样

需求归集 · 真实业务触发

周一晨会，陈默突然问：「上上个月华正提的那个导出，当时为什么没排？」江晓的记忆是「好像说跟什么路线冲突」—— 但当时是谁提的、原话是什么、拒绝理由的完整版在哪，她翻了两小时聊天记录和邮件，找到的只有半句截图。这类突袭提问每个季度都有三五次，每次的代价是半天考古加一份不确定的答案。

二、痛点 · 每条都有来源

1突袭式提问是产品经理的高频噩梦：任何需求被问「谁提的、当时怎么说、为什么这么定」—— 没有回溯档案的团队每次都要现场考古依据 · 需求来源回溯的价值判例：蓝点案例的核心即「任何需求可回查谁提的、什么场景、当时原话」—— 老板突袭式提问（「王工那个导出功能后来怎么了」）是产品经理的真实高频场景2被拒需求因新商机复活是B 端常态，复活时不知道旧决策的存在 —— 同一个需求被拒两次、做两次的成本，比维护档案高一个量级依据 · 需求池的普遍欠账：「需求进来了没人清、历史需求没人敢删」—— 被拒需求因新商机复活是 B 端常态，但删一条历史需求有商业与政治双重风险3「需求确认书（In/Out of Scope）」是对外交付的护身符 —— 但中小企业的现实是：确认书没有、聊天记录散、决策靠记忆依据 · 发布管理的实操基线：《如期上线》复盘模板要求发布前核对影响范围、回滚预案与灰度计划；需求确认书（In/Out of Scope）是对外交付的护身符

三、换个做法之后

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

✕ 现在的做法

• 突袭式提问是产品经理的高频噩梦：任何需求被问「谁提的、当时怎么说、为什么这么定」—— 没有回溯档案的团队每次都要现场考古被拒需求因新商机复活是 B 端常态，复活时不知道旧决策的存在 —— 同一个需求被拒两次、做两次的成本，比维护档案高一个量级「需求确认书（In/Out of Scope）」是对外交付的护身符 —— 但中小企业的现实是：确认书没有、聊天记录散、决策靠记忆

✓ 交给 Agent 之后

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

四、场景闭环

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

1. 需求定位 · 顺藤摸瓜以需求条目为索引，把散在各处的相关记录全部挂上 —— 一条需求一页档案
2. 时间线重建 · 每个节点带原文首次提出→评估→决策→（拒绝/排期/变更）—— 每个节点配当时的原话引用
3. 决策还原 · 谁拍的、为什么决策人、决策场景、理由原文 —— 不美化不转述，原话就是原话
4. 关联挂接 · 上下游需求同一客户的相关需求、同一功能的旧版本 —— 回溯不止一条线
5. 突袭应答卡 · 30 秒版每个需求一张应答卡：谁提的/什么时候/结论/现状 —— 老板问起，一屏答完

要准备什么：与该需求相关的全部聊天记录销售群、客户群、内部群的原始导出相关邮件往来转发原始邮件 —— 带时间的才是证据评审纪要与会议速记当时的讨论与结论 —— 决策的原始现场需求池该条目的历史状态从入池到现在的每一次状态变更

为什么这个场景值得做

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

最大差异点：不要求先建档案制度。聊天记录、邮件、评审纪要扔进来 —— 需求级的回溯档案自动生成，随需求池条目挂接。

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

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

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

五、会产出什么

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

• 正式件本体：需求来源回溯档案.xlsx 时间线 + 决策还原 + 原文引用
• 可派发清单：突袭应答卡.xlsx 每需求一卡· 谁提/何时/结论/现状 · 一屏读完
• 可派发清单：断档标记清单.xlsx 记录缺失的节点 · 补档建议与责任人

这套东西不承诺什么：不做「自动生成决策」—— 回溯档案只记录已发生的事实（谁提的/原话/决策/理由），不改写历史。

② Live Demo（演示逐步）

老板会上问「华正那个导出功能后来怎么样了」· 没有回溯档案的产品经理，每次提问都是一次翻聊天记录的考古!

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

案例设定：驭数科技（虚构）考古日：周一晨会陈默突然问：「上上个月华正提的那个导出，当时为什么没排？」江晓的记忆是「好像说跟什么路线冲突」—— 但当时是谁提的、原话是什么、拒绝理由的完整版在哪，她翻了两小时聊天记录和邮件，找到的只有半句截图。

回溯对象1 条需求 · 10 个月跨度时间线节点9 个 · 1 处断档拒绝理由还原3 段 · 邮件原文应答卡30 秒版已备

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

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

• 01_需求池历史条目与状态日志.xlsx 该需求在池内的完整轨迹 —— 状态变更的官方记录禅道导出 · 2025-11 至今
• 02_拒绝决策邮件原文.txt 2025-11-14 沈知行拒绝理由的完整版 —— 三段全文邮件 · 2025-11-14
• 03_销售沟通记录（拒绝之后）.txt 郑海洋「客户没争取吗」的反证 —— 第 9 天的那次单独沟通微信记录考古 · 2025-11-23
• 04_2026年4月复议讨论（研发群）.txt 时间线上唯一的断档 —— 复议无结论的现场微信研发群 · 2026-04-16
• 05_API项目延期通知.txt 拒绝理由的前提变更 —— 复活讨论的支点项目周报摘录 · 2026-03-30

注意标橙色那一份 —— 02_拒绝决策邮件原文.txt。它邮件· 2025-11-14，平时压根不在核对范围里。这个场景的价值，很大一部分就来自把它读进来。

提示词就说这么几句

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

华正那个导出需求的来龙去脉帮我理一遍 —— 相关的聊天记录、邮件、还有去年评审的纪要都在这个文件夹。 当时谁提的、原话是什么、为什么拒的，每个节点都配上原始记录的引用； 时间线给我拉直，中间有断档的地方标出来，别糊； 跟这个需求相关的其他需求也挂上 —— 比如同一客户提过的别的； 最后给我一张 30 秒能答完的应答卡：老板周会问起来，我一屏讲清楚。

短是因为「时间线重建、决策还原、关联挂接、应答卡结构」都在能力包里。产品经理只要把原始记录扔进来。

触发晨会一问 vs 两小时考古的半句截图

「当时为什么没排」—— 没有档案的团队，每次回答都是重新破案

江晓把状态日志、拒绝邮件、销售沟通、复议讨论、延期通知全部扔进来 —— 回溯档案的骨架，五份原料里四份是聊天记录与邮件的考古。

第 1 步 · 时间线重建 · 九个节点一处断档

从 2025-11-03 登记到 2026-08-20 复活评估 —— 每个节点带原文

第 2 步 · 决策还原 · 拒绝理由的完整版

三段理由两个前提 —— 前提的现状逐条对

旧决策要点当时依据现状含义API 预计 Q2 上线开放平台立项排期延期至 Q4 评估第一支柱垮塌仅华正单家提出销售单渠道转述两家客户+17 家工单提及单客户判定失效Q2 后随 API 落地复议预留复议条件复议条件已成熟（4 月动议悬置）按旧决策也该复议了拒绝理由的三点，如今一点都没站住 —— 最妙的是第三点：按沈知行自己写的复议条件，这个需求本来就该复议了 —— 复活不是推翻决策，是执行决策里预留的那一条。

第 3 步 · 预警审计 · Q3 底线的九个月

客户给的期限一直在倒计时 —— 只是没人看得见

第 4 步 · 断档标记 · 2026-04 的复议悬案

无结论的讨论也是历史 —— 补档建议给到人

第 5 步 · 应答卡 · 30 秒版

下次晨会陈默再问 —— 一屏答完

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

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

老板会上问「华正那个导出功能后来怎么样了」· 没有回溯档案的产品经理，每次提问都是一次翻聊天记录的考古

1. Skill 能力包

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

需求来源回溯档案 · Skill

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

版本 v1.0

req-trace.zip

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

包内结构

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

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

2. 原始素材

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

📁RQ-03 · 演示素材

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

共 5 份

• 01_需求池历史条目与状态日志.xlsx 该需求在池内的完整轨迹 —— 状态变更的官方记录
• 02_拒绝决策邮件原文.txt 2025-11-14 沈知行拒绝理由的完整版 —— 三段全文
• 03_销售沟通记录（拒绝之后）.txt 郑海洋「客户没争取吗」的反证 —— 第 9 天的那次单独沟通
• 04_2026年4月复议讨论（研发群）.txt 时间线上唯一的断档—— 复议无结论的现场
• 05_API项目延期通知.txt 拒绝理由的前提变更 —— 复活讨论的支点

怎么用

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

3. 提示词卡片

华正那个导出需求的来龙去脉帮我理一遍 —— 相关的聊天记录、邮件、还有去年评审的纪要都在这个文件夹。 当时谁提的、原话是什么、为什么拒的，每个节点都配上原始记录的引用； 时间线给我拉直，中间有断档的地方标出来，别糊； 跟这个需求相关的其他需求也挂上 —— 比如同一客户提过的别的； 最后给我一张 30 秒能答完的应答卡：老板周会问起来，我一屏讲清楚。

为什么这么短就够了：短是因为「时间线重建、决策还原、关联挂接、应答卡结构」都在能力包里。产品经理只要把原始记录扔进来。

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

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

自己组织输入的三步法

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

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

4. 预期输出

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

📋正式交付物

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

共 3 份

• RQ-03_需求来源回溯档案.xlsx 正式件本体 · 时间线 + 决策还原 + 原文引用
• RQ-03_突袭应答卡.xlsx 每需求一卡 · 谁提/何时/结论/现状 · 一屏读完
• RQ-03_断档标记清单.xlsx 记录缺失的节点 · 补档建议与责任人

Skill 里固化了什么：从旧邮件里「想起」了拒绝理由的完整版该拦的地方拦住了排除性结论把技术动作翻译成钱

输入清单：与该需求相关的全部聊天记录销售群、客户群、内部群的原始导出相关邮件往来转发原始邮件 —— 带时间的才是证据评审纪要与会议速记当时的讨论与结论 —— 决策的原始现场需求池该条目的历史状态从入池到现在的每一次状态变更

人工边界：不做「自动生成决策」—— 回溯档案只记录已发生的事实（谁提的/原话/决策/理由），不改写历史。

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

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

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

• RQ-01 · 多渠道需求归集结构化 — 同一个「导出」需求，销售微信两条、客服工单两张、客户邮件一封、老板语音一段：六次转世，需求池里还是没有它RQ-02 · 需求池清淤体检 — 需求池 427 条，最近半年动过的不到三分之一 · 「进来了没人清、历史需求没人敢删」—— 每一条都是不敢碰的存量 查看 →

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

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