标准场景审查核验岗位 · 产品

DC-02 · PRD 一致性终审

痛点　「本期不做」写在范围声明里，正文却详细描述了它的交互 · 研发按正文实现，范围争议回到产品头上

① 场景引入

一、这件事现在是什么样

文档与评审 · 真实业务触发

找茬预演（DC-01）改完的 PRD 提交前，江晓还有最后一道担心：改过六轮的文档，前后还一致吗？她记得自己在第二轮把「批量导出」挪进了「本期不做」，但第四轮改权限章节时好像又引用了批量导出的交互。研发的习惯是按正文写代码、不读范围声明 —— 一旦矛盾，实现的就是「做了说不做的」。这类问题她自己读三遍都未必能挑出来，因为作者永远看不出自己的笔误。

二、痛点 · 每条都有来源

改过多轮的文档没有一致性终审：前后矛盾、「本期不做」与正文冲突、验收标准与用户故事脱节 —— 这三类问题作者自己读不出来
依据：找茬预演的实测口径：让 AI 扮演挑剔工程师提前找茬（「模拟杠精」），PRD 评审通过率从 60% 左右提升到 90%；全程单对话窗口防前后矛盾，能省一半返工
「AI 消化 AI，链条里没人用大脑」的教训：文档的可靠性是下游一切协作的前提 —— 研发按正文实现、测试按验收标准验，两头对不上就是返工
依据：「越快越慢」的机制：AI 把没想清楚的部分填成看似完整的八千字，看似提速、实则把推敲成本后置给研发；15 页 AI PRD 没人读、研发喂给自己的 AI 做总结 ——「AI 消化 AI，链条里没人用大脑」
研发估算偏差超 50% 的一个根源就是 PRD缺验收标准或验收与故事脱节 —— 终审恰好卡在这个断点上
依据：需求评审的真实痛点：评审会变成产品经理单方面汇报、其他角色沉默或事后才提异议，导致开发阶段频繁返工；许多 PRD 缺少验收标准与非功能性要求，致使研发估算偏差超 50%

三、换个做法之后

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

✕ 现在的做法

改过多轮的文档没有一致性终审：前后矛盾、「本期不做」与正文冲突、验收标准与用户故事脱节 ——这三类问题作者自己读不出来「AI 消化 AI，链条里没人用大脑」的教训：文档的可靠性是下游一切协作的前提 ——研发按正文实现、测试按验收标准验，两头对不上就是返工研发估算偏差超 50% 的一个根源就是 PRD 缺验收标准或验收与故事脱节 —— 终审恰好卡在这个断点上

✓ 交给 Agent 之后

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

四、场景闭环

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

范围声明 × 正文对照「本期不做」的每一项，检查正文是否还有残留描述 —— 逆向检查
前后术语一致性同一概念多种叫法（导出/下载/出报表）—— 统一术语表自动生成
用户故事 × 验收标准配对每个故事是否有对应验收标准、标准是否可验证 —— 脱节的逐条标出
数字与状态机一致性文档里的数字（权限级数/条数上限/时限）前后是否一致 —— 状态机的每个状态是否有出口
终审报告 · 三类矛盾分级范围冲突（高危）/术语漂移（中危）/配对缺失（低危）—— 每处带两侧定位

要准备什么：PRD 全文（最终稿）改过多少轮都行 —— 终审看的是终稿的整体范围声明（In/Out of Scope）「本期不做」的清单 —— 与正文对照的主轴变更历史（如有）改过几轮、每轮改了什么 —— 矛盾的高发区相关旧版 PRD（如有）版本间的漂移也是矛盾源

为什么这个场景值得做

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

最大差异点：不要求文档格式规范。任何格式的 PRD 扔进来 —— 矛盾点逐处定位（章节+段落），三分钟看完一份终审报告。

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

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

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

五、会产出什么

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

正式件本体：PRD 一致性终审报告.xlsx 三类矛盾分级 + 两侧定位
可派发清单：术语表.xlsx 统一叫法对照 ·含各处出现的章节定位
可派发清单：配对缺失清单.xlsx 故事与验收标准脱节的条目 · 补写建议

这套东西不承诺什么：不做「自动改写文档」—— 终审只标矛盾与位置，怎么改、改哪头，是产品经理的判断（改声明还是改正文，往往涉及范围决策）。

② Live Demo（演示逐步）

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

案例设定：驭数科技（虚构）提交前夜：找茬预演（DC-01）改完的 PRD 提交前，江晓还有最后一道担心 —— 改过六轮的文档，前后还一致吗？她记得第二轮把「批量导出」挪进了「本期不做」，但第四轮改权限章节时好像又引用了批量导出的交互。作者永远看不出自己的笔误。

终审对象42 页 · 改过 6 轮矛盾检出14 处 · 三类高危（范围冲突）3 处 · 必改术语归一5 组 · 统一表已生成

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

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

01_PRD终稿（六轮修改版）.txt 终审的主对象 —— 找茬预演后的第六轮飞书文档导出 · 2026-08-21
02_变更修改记录.txt 六轮修改的痕迹 —— 矛盾是改出来的证据文档修订历史 · 2026-08-15 至 08-2103_范围声明（In-Out of Scope）.xlsx「本期不做」的官方清单 —— 逆向检查的基准PRD 附录 A · v1.0
04_术语出现位置索引.xlsx 同一概念多种叫法的全谱 ——漂移的证据全文扫描输出 · 2026-08-21
05_用户故事与验收标准对照表.xlsx 故事与验收的配对检查 —— 脱节的逐条暴露PRD 章节对照 · v1.0

注意标橙色那一份 —— 02_变更修改记录.txt。它文档修订历史 · 2026-08-15 至 08-21，平时压根不在核对范围里。这个场景的价值，很大一部分就来自把它读进来。

提示词就说这么几句

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

PRD 终稿在这，改了六轮，范围声明也在最后，帮我做提交前的一致性终审。「本期不做」的每一项，帮我反查正文还有没有残留 —— 我记得批量导出挪出去了，但不确定哪里还引用着；同一件事的多种叫法帮我统一一下，术语表也给我一份；每个用户故事和验收标准配对核一遍，脱节的挑出来；数字和状态的前后一致性也过一遍；最后分级：哪些矛盾必须改完才能提交、哪些可以带批注先发。

短是因为「范围逆向检查、术语聚类、故事验收配对、状态机遍历」都在能力包里。产品经理只要把终稿扔进来。触发六轮修改之后 · 作者的盲区

「我记得挪出去了」—— 记忆是修改记录的敌人

江晓把终稿、修改记录、范围声明、术语索引、配对对照表全部扔进来 —— 终审的证据一半在文档里，一半在文档自己的修改历史里。

第 1 步 · 范围声明 × 正文 · 逆向检查

「不做」的每一项，正文都要能证明清白

演示数据（表格原文）范围外项正文残留位置残留性质处理批量导出3.4 模板说明（多设备批量导出）功能描述级残留改声明或改正文，二选一批量导出3.2 权限承接描述交叉引用级残留随上条联动CSV 格式3.4「兼容 CSV」措辞级残留删除或移入范围三处残留两种性质：3.4 的「多设备批量导出」是完整的功能描述 —— 范围声明说不做、正文教怎么写，研发按正文实现就是「做了说不做的」—— 这类矛盾流出去，范围声明就成了废纸。

第 2 步 · 术语归一 · 五组漂移一张表

名称型漂移伤可读性，数字型漂移要人命

演示数据（表格原文）漂移组风险等级统一方案保留 72 小时 / 存储 3 天数字型 · 高全文统一「保留 72 小时」导出任务/生成任务/下载任务中统一「导出任务」部门级/事业部级中（私有化语境）统一+括注模板三叫法中统一「导出模板（普通/集团 EHS）」站内信/消息通知低统一「站内信」「72 小时 vs 3 天」的数字型漂移单独立了案：如果「3 天」出现在与存储策略相关的段落而被按自然日实现 —— 周四晚生成的文件，72 小时口径周日下线、自然日口径周四24 点下线 —— 边界行为差出来的 24 小时，就是用户「文件怎么没了」的工单。

第 3 步 · 故事 × 验收配对 · 三条裸奔的故事

没有验收标准的故事，完成与否全凭研发良心

演示数据（表格原文）脱节故事影响补写建议巡检员导出数据（华正核心场景）测试无从验起按筛选项 × 结果行数 × 格式三要素补（另 2条）同同框架补8 条故事 3 条裸奔 —— 而裸奔的恰好包含华正的核心场景。验收标准不是文档的装饰，是「研发说做完了」的裁判 —— 没有裁判的完成，测试环节就会用 VA-01 的用例现编标准。

第 4 步 · 矛盾成因分析 · 改出来的病

修改记录指认了每处矛盾的来源轮次

演示数据（表格原文）矛盾引入轮次成因批量导出两处残留v0.3 复制未改 / v1.0 交叉引用复制旧段落没对照范围声明CSV 措辞残留v0.4 新增段落顺手写入新增内容没过范围过滤数字型术语漂移v0.1 初稿两处原样初稿就没统一，六轮没人发现矛盾的成因全部指向「增量修改缺乏全局对照」—— 终审的存在意义就在这：改的人永远只看着改动的那几段，总得有一个「只看全局不改动」的角色。

第 5 步 · 终审分级 · 门禁怎么设

高危卡住、低危放行 —— 一刀切终审会被绕过

演示数据（表格原文）级别数量处理要求高危 · 范围冲突3改完才能提交（半小时内可完成）中危 · 数字漂移1改完才能提交（10 分钟）低危 · 名称漂移与配对缺失10带批注提交，v1.1 清理分级的逻辑：高危会直接产生错误实现，中危产生边界 bug，低危伤可读性 —— 门禁的厚度跟着后果走，全卡死的话下次就没人走这道门了。PRD 还不能提交 —— 3 处高危范围冲突 + 1 处数字漂移未清「批量导出」的范围冲突是最危险的一类：范围声明、3.4、3.2 三处的表述互相矛盾 —— 研发按哪处实现都有依据，出问题时追责却无据可依。数字漂移（72 小时 vs 3 天）会在存储策略上产生 24 小时的行为分叉。这四处的修改涉及一个范围决策：模板机制到底承接不承接批量导出 ——这不是编辑问题，是江晓和沈知行要拍的事。给出的不是干等：方案 A（拍板后修改·推荐）：先花 10 分钟和沈知行对齐「批量导出」的范围口径（建议：3.4 的模板批量机制保留、5.1 的「批量导出」改为「跨模板批量导出不做」——精确化而非删除），然后 40 分钟完成全部高危修改，今晚提交；方案 B（带批注提交）：四处高危带修改建议的批注直接提交，评审会上作为「已知问题」过 —— 省两小时，但把矛盾摆上评审桌，谭锐大概率会揪着 3.4 与 5.1 的矛盾问十分钟 —— 省下的时间又赔回去。两案差 1 小时与评审会的十混乱 —— 门禁的意义就是「别把内部矛盾带到会上当众爆炸」。之后这一次跑完，公司多了什么

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

演示数据（表格原文）✓「做了说不做的」在提交前拦下 —— 研发按正文实现、测试按声明验收的断层被缝合✓多轮修改引入的矛盾有了系统检法 —— 改出来的问题用整体检查抓✓「文档质量差」的帽子被数据摘掉 —— 缺的是改完之后的一道门禁，不是重写✓半小时对冲 6 人日的门禁账 —— 终审从个人习惯变成迭代流程追问现场可能被问到的答不上来的问题，比答得漂亮的问题更能决定这场演示的结果终审和找茬预演有什么区别？找茬在会前、管「想没想清楚」（逻辑边界）；终审在提交前、管「改没改矛盾」（文档内部一致性）。一个对人、一个对文，两道门都要有。小改动也要终审吗？改过两轮以上的文档建议跑 —— 矛盾是改出来的，单轮成稿反而少。终审三分钟，习惯成本极低。术语表谁维护？终审自动生成，人工确认后成为下一份PRD 的基线 —— 术语的统一是攒出来的，不是规定出来的。

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

1. Skill 能力包

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

PRD 一致性终审 · Skill

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

版本 v1.0

prd-consistency.zip

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

包内结构

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

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

2. 原始素材

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

📁DC-02 · 演示素材

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

共 5 份

01_PRD终稿（六轮修改版）.txt 终审的主对象 —— 找茬预演后的第六轮
02_变更修改记录.txt 六轮修改的痕迹 —— 矛盾是改出来的证据
03_范围声明（In-Out of Scope）.xlsx 「本期不做」的官方清单 —— 逆向检查的基准
04_术语出现位置索引.xlsx 同一概念多种叫法的全谱 —— 漂移的证据
05_用户故事与验收标准对照表.xlsx 故事与验收的配对检查 —— 脱节的逐条暴露

怎么用

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

3. 提示词卡片

PRD 终稿在这，改了六轮，范围声明也在最后，帮我做提交前的一致性终审。「本期不做」的每一项，帮我反查正文还有没有残留 —— 我记得批量导出挪出去了，但不确定哪里还引用着；同一件事的多种叫法帮我统一一下，术语表也给我一份；每个用户故事和验收标准配对核一遍，脱节的挑出来；数字和状态的前后一致性也过一遍；最后分级：哪些矛盾必须改完才能提交、哪些可以带批注先发。

为什么这么短就够了：短是因为「范围逆向检查、术语聚类、故事验收配对、状态机遍历」都在能力包里。产品经理只要把终稿扔进来。

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

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

自己组织输入的三步法

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

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

4. 预期输出

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

📋正式交付物

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

共 3 份

DC-02_PRD 一致性终审报告.xlsx 正式件本体 · 三类矛盾分级 + 两侧定位
DC-02_术语表.xlsx 统一叫法对照 · 含各处出现的章节定位
DC-02_配对缺失清单.xlsx 故事与验收标准脱节的条目 · 补写建议

Skill 里固化了什么：从变更历史里「想起」了矛盾的成因该拦的地方拦住了排除性结论把技术动作翻译成钱

输入清单：PRD 全文（最终稿）改过多少轮都行 —— 终审看的是终稿的整体范围声明（In/Out of Scope）「本期不做」的清单 —— 与正文对照的主轴变更历史（如有）改过几轮、每轮改了什么 —— 矛盾的高发区相关旧版 PRD（如有）版本间的漂移也是矛盾源

人工边界：不做「自动改写文档」—— 终审只标矛盾与位置，怎么改、改哪头，是产品经理的判断（改声明还是改正文，往往涉及范围决策）。

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

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

文档与评审 · 产出即下一步输入

DC-01 · PRD 评审前找茬预演 — 评审会上研发问「两个状态同时触发怎么办」· 这种问题最好的出现时机是评审前一天，不是评审会上查看 →DC-03 · 评审材料自动凑齐 — 评审会前一小时还在找「这个需求哪个客户提的」· 证据没带齐的评审，每个问题都是一次减分查看 →

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

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

其他行业的同类场景 · 审查核验

想把这个场景在你们企业跑通？

顾问会先看你们的数据和流程够不够，再决定从哪一步开始。

看产品其他场景