旗舰场景 审查核验 岗位 · 产品

DC-01 · PRD 评审前找茬预演

痛点 评审会上研发问「两个状态同时触发怎么办」· 这种问题最好的出现时机是评审前一天,不是评审会上

① 场景引入

一、这件事现在是什么样

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

v3.4 迭代的「导出功能」PRD 初稿写完了,周四评审。江晓对这份文档心里没底:导出权限的边界、大数据量导出的超时、私有化客户与标准版的差异 —— 这三处她自己都知道没写透。上一次评审会,研发组长谭锐当着沈知行的面问了七个问题,她当场只答上来四个。沈知行会后的评价是「文档质量决定你在研发面前的信用额度」。

二、痛点 · 每条都有来源

1评审会形式化是结构病:变成产品经理单方面汇报、其他角色沉默或事后才提异议 —— 开发阶段频繁返工;PRD 缺验收标准时研发估算偏差超 50%依据 · 需求评审的真实痛点:评审会变成产品经理单方面汇报、其他角色沉默或事后才提异议,导致开发阶段频繁返工;许多 PRD 缺少验收标准与非功能性要求,致使研发估算偏差超 50%2AI 找茬预演有实测口径:让 AI 扮演挑剔工程师提前找茬(「模拟杠精」),PRD 评审通过率从六成左右提升到九成 —— 找茬是「检查型」任务,恰是 AI 的强区依据 · 找茬预演的实测口径:让 AI 扮演挑剔工程师提前找茬(「模拟杠精」),PRD 评审通过率从 60% 左右提升到 90%;全程单对话窗口防前后矛盾,能省一半返工3返工的代价有判例:AI 把没推敲的假设填成详细规则、研发照做,返工两周、项目延期一个月 —— 越早抓出假设级漏洞,返工成本越低(入口拦截1 倍成本 vs 生产环境放大的修复成本)依据 · AI 写 PRD 的翻车判例:审批提醒 PRD 因 AI 把没被推敲的假设填成详细规则(「每小时触发提醒」),研发照做,返工两周、项目延期一个月;另有「编造细节」致延期三个月与 SQL 注入漏洞返工

三、换个做法之后

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

✕ 现在的做法

  • 评审会形式化是结构病:变成产品经理单方面汇报、其他角色沉默或事后才提异议 —— 开发阶段频繁返工;PRD 缺验收标准时研发估算偏差超 50%AI 找茬预演有实测口径:让 AI 扮演挑剔工程师提前找茬(「模拟杠

精」),PRD 评审通过率从六成左右提升到九成 —— 找茬是「检查型」任务,恰是 AI 的强区返工的代价有判例:AI把没推敲的假设填成详细规则、研发照做,返工两周、项目延期一个月 —— 越早抓出假设级漏洞,返工成本越低(入口拦截 1 倍成本 vs 生产环境放大的修复成本)

✓ 交给 Agent 之后

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

四、场景闭环

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

  1. 三视角轮番提问 · 研发/测试/客户研发问逻辑与边界、测试问验收与异常、客户问场景与易用性 —— 三个视角各自的盲区不一样
  2. 假设级漏洞定位 · 「写满了但没想清楚」看似详细实则未推敲的规则(上一次返工两周的那类)—— 逐条定位到段落
  3. 边界与异常清单 · 没写的才是雷并发/超时/权限/数据量/空态 —— PRD 里没提的边界逐项追问
  4. 验收标准核对 · 能测才算数每个用户故事配可验证的验收标准 —— 缺的地方标出来(估算偏差的根源)
  5. 会前修改建议 · 按风险排序高/中/低三档问题 + 每条的修改建议 —— 优先改会当场被问的

要准备什么:PRD 草稿(任何格式)飞书文档/Word/Markdown —— 写到哪一步都行该需求的相关记录RQ-01 的证据包—— 找茬的对照基准历史评审纪要上次被喷的点 —— 同样的坑不踩第二次技术约束说明(如有)研发给过的边界

—— 私有化差异、性能红线

为什么这个场景值得做

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

最大差异点:不要求换文档工具。PRD 草稿任何格式扔进来 —— AI 用研发、QA、客户三个视角轮番提问,问题清单会前给到。

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

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

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

五、会产出什么

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

  • 正式件本体:PRD 找茬报告.xlsx 7 高/9 中/5 低问题 + 定位 + 修改建议
  • 可派发清单:边界与异常清单.xlsx 文档未覆盖的边界逐项追问 · 按模块分组
  • 可派发清单:会前修改优先级表.xlsx 必须改/可解释两档 · 每条预估工作量

这套东西不承诺什么:不做「AI 替你改 PRD」—— 找茬报告给定位与建议,改不改、怎么改是产品经理的判断。也不做「保证评审通过」—— 预演覆盖的是文档质量,业务拍板仍在评审会。

② Live Demo(演示逐步)

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

案例设定:驭数科技(虚构)评审前夜:v3.4「设备数据导出」PRD 初稿写完,周四评审。江晓心里没底的三处:导出权限的边界、大数据量导出的超时、私有化客户与标准版的差异 —— 她自己都知道没写透。上次评审谭锐当着沈知行的面问了七个问题,她当场只答上来四个。

预演问题21 个 · 三视角高危问题7 个 · 会前必改上次评审同类3 个 · 不踩第二次结论延期一天 · 权限模型有结构缺口

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

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

  • 01_导出功能PRD初稿.txt 找茬的主对象 —— 江晓写了三天的 42 页飞书文档导出 · 2026-08-19
  • 02_上次评审纪要.txt 谭锐那七个问题的原始记录 —— 同类坑的对照表评审纪要 · v3.3 · 2026-05
  • 03_技术约束说明.txt 研发给过的边界 —— 找茬的对照基准之一谭锐在研发群的说明 · 2026-08-12
  • 04_RQ-01证据包(导出需求).xlsx 需求的原始诉求 —— 场景完整性的对照RQ-01 归集产出 · 2026-08-20
  • 05_私有化组织架构说明.xlsx 权限模型的结构性矛盾原料 —— 三级架构长什么样实施交付组提供 · 2026-08

注意标橙色那一份 —— 02_上次评审纪要.txt。它评审纪要 · v3.3 · 2026-05,平时压根不在核对范围里。这个场景的价值,很大一部分就来自把它读进来。

提示词就说这么几句

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

「导出功能」的 PRD 初稿在这,周四要评审,上次的评审纪要也附上了,帮我先找一轮茬。 分别用研发、测试、客户三个人的视角把这份文档问一遍,问题越刁越好; 写得很满但没想清楚的地方帮我挑出来 —— 上次那种「看起来详细、一追问就露馅」的; 边界和异常状态帮我过一遍:并发、超时、大数据量、权限,文档里没提的都列出来; 每个用户故事的验收标准核一遍,缺的标出来; 最后按风险排个序,哪些必须改完才能上会、哪些可以会上解释。

短是因为「三视角提问框架、假设级漏洞特征、边界检查清单」都在能力包里。产品经理只要把草稿扔进来。

触发42 页初稿 vs 上次只答上来四个的七问

评审会的信用额度是攒出来的 —— 找茬预演是存钱

江晓把 PRD 初稿、上次纪要、技术约束、证据包、架构说明全部扔进来 —— 找茬的火力和上次被喷的位置直接挂钩。

第 1 步 · 三视角轮番提问 · 各抓各的

研发问逻辑、测试问异常、客户问场景 —— 三个盲区不重叠

演示数据(表格原文)视角问题数典型问题命中章节研发(谭锐视角)8任务完成时权限被收窄,文件还通知吗?3.2 × 4.2 交叉测试(QA 视角)75 万行上限的临界值测过吗(49999/50001)?3.3客户(刘科长视角)6「批量」是书面要求,本期不做谁去解释?5.1 × 证据包合计21 个三视角各管一段—研发视角的 8 问里最狠的一条:「任务完成时权限被收窄,文件还通知吗」—— 3.2 与 4.2 两章各自都对、拼起来是漏洞。跨章节的交叉矛盾作者自己永远看不出 —— 这正是找茬预演相对自读的增量。

第 2 步 · 假设级漏洞 · 写满了但没想清楚

上次返工两周的那类问题 —— 本次抓出 4 个

演示数据(表格原文)假设级漏洞位置风险「导出权限跟随报表权限」—— 两套权限的粒度不同3.2结构性缺口「文件保留 72 小时」—— 私有化本地存储的保留策略未定义4.2环境差异遗漏「上限 5 万行」—— 依据是什么?华正月均巡检数据量级未核对3.3数字拍脑袋「站内信通知」—— 陈默要的「给集团看」场景里,通知是发给谁?4.2场景错位四个假设级漏洞里,第一个(权限粒度)是结构性缺口 —— 标准版两级、私有化三级,PRD 的权限描述在私有化不可实现。这不是措辞问题,是设计缺口 —— 会上被问出来就是事故现场。3上次七问的同类对照

三个「两个东西打架」类问题 —— 这次提前找到了

上次的问题本次同类会前状态两个动作同时触发听谁的?导出进行中用户删除巡检记录 → 任务结果算谁的已补进 4.3权限不足的人什么体验?三级架构下「部门级范围」指哪层未解决 · 结构缺口移动端与 PC 一致吗?移动端只通知不出文件 —— 用户在哪下载?已补一半上次的三类问题这次提前找到了同类 —— 其中权限那条仍是缺口:同一个坑摔两次,信用额度直接见底 —— 这条被列为第一优先级,改不完不上会。

第 4 步 · 边界与异常清单 · 没写的都是雷

并发/超时/空态/降级 —— 文档沉默的地方就是开发自由发挥的地方

演示数据(表格原文)边界PRD 是否覆盖建议120 秒网关限制 vs 大文件生成未覆盖超 90 秒转离线任务(需补 4.2)导出中数据被变更4.3 已补快照语义写明空结果导出未覆盖空文件 or 友好提示,二选一写死移动端文件获取路径补一半扫码传 PC 的方案写明技术边界(120 秒网关)早就给了 —— PRD 没接住。边界清单的价值是把研发群里的口头约束翻译成文档语言 —— 不翻译,约束就不存在。

第 5 步 · 修改优先级 · 会前的作战序

必改/可解释/可带伤 —— 三档排完才敢上会

演示数据(表格原文)档位问题数预估投入判断必改(会前)7约 1 人日(权限模型 0.5 + 其余 0.5)改不完不上会可解释(会上口头)9—备好口径即可可带伤(下版修)5—PRD 标注「已知限制」三档的分界标准:会不会被当场问倒。必改 7 个里权限模型占0.5 人日 —— 「延期一天的文档,好过当场返工的评审」—— 这句写在报告第一行,给沈知行的延期申请当理由。PRD 周四还不能上评审会 —— 权限模型的结构缺口改不完私有化三级架构下的权限模型是设计缺口而非措辞问题—— 补齐需要 0.5 人日(含双版本架构说明),加上其余 6 个必改项,总投入约 1 人日。带着这个缺口上会,谭锐的第一个问题就会打在 3.2 节 —— 而这正是上次七问里「答不上」的同类题。给出的不是干等:方案 A(延期一天·推荐):评审改到周五 —— 明天全天补权限模型(双版本对照说明 + 三级继承规则)与其余 6 个必改项,找茬报告的 21问全部闭环或备好口径。成本:迭代周期内消化 1 天,缓冲(剩 3.5 人日)足够;方案 B(周四照开·权限单列):评审照常,但议程里把「导出权限」单独列为「方案讨论项」而不是「评审通过项」—— 会上和谭锐现场对齐三级架构的规则(他手里有架构说明)。风险:方案讨论在评审会上是最容易跑题又最难收口的环节 —— 上次这样的会开了三小时。两案差一天与一场失控风险 —— 找茬实测口径(通过率六成抬到九成)的前提是「必改项清零」,方案 B 不满足这个前提。之后这一次跑完,公司多了什么

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

演示数据(表格原文)✓评审会从「被当场问倒的事故现场」变成「问题已提前答完的通过现场」—— 实测口径六成抬到九成✓权限模型的结构性缺口在会前一天暴露 —— 延期一天好过开发中期重做✓「写得简略」被排除 —— 病根是规则间冲突没被交叉检查,修改方向省一半工作量✓上次被喷的同类问题自动对号 —— 同一个坑不摔第二次,信用额度守住了追问现场可能被问到的答不上来的问题,比答得漂亮的问题更能决定这场演示的结果找茬报告能保证评审通过吗?不能 —— 业务拍板仍在会上。预演覆盖的是文档质量:逻辑、边界、验收标准这些「不该在会上翻车」的部分。每次评审前都跑吗?高优先级需求必跑,小改动抽查 —— 找茬的成本是半小时预读的置换,换的是会上不翻车。AI 找的问题靠谱吗?三视角的框架来自实测复盘(通过率口径在来源登记册)—— 但最终判断是您的:报告里每条都标了定位与理由,您逐条看比逐条改快。

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

1. Skill 能力包

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

PRD 评审前找茬预演 · Skill

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

版本 v1.0

prd-challenge.zip

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

包内结构

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

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

2. 原始素材

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

📁DC-01 · 演示素材

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

共 5 份

  • 01_导出功能PRD初稿.txt 找茬的主对象 —— 江晓写了三天的 42 页
  • 02_上次评审纪要.txt 谭锐那七个问题的原始记录 —— 同类坑的对照表
  • 03_技术约束说明.txt 研发给过的边界 —— 找茬的对照基准之一下载
  • ↓XLS04_RQ-01证据包(导出需求).xlsx 需求的原始诉求 —— 场景完整性的对照
  • 05_私有化组织架构说
  • 明.xlsx 权限模型的结构性矛盾原料 —— 三级架构长什么样

怎么用

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

3. 提示词卡片

「导出功能」的 PRD 初稿在这,周四要评审,上次的评审纪要也附上了,帮我先找一轮茬。 分别用研发、测试、客户三个人的视角把这份文档问一遍,问题越刁越好; 写得很满但没想清楚的地方帮我挑出来 —— 上次那种「看起来详细、一追问就露馅」的; 边界和异常状态帮我过一遍:并发、超时、大数据量、权限,文档里没提的都列出来; 每个用户故事的验收标准核一遍,缺的标出来; 最后按风险排个序,哪些必须改完才能上会、哪些可以会上解释。

为什么这么短就够了:短是因为「三视角提问框架、假设级漏洞特征、边界检查清单」都在能力包里。产品经理只要把草稿扔进来。

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

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

自己组织输入的三步法

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

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

4. 预期输出

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

📋正式交付物

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

共 3 份

  • DC-01_PRD 找茬报告.xlsx 正式件本体 · 7 高/9 中/5 低问题 + 定位 + 修改建议
  • DC-01_边界与异常清单.xlsx 文档未覆盖的边界逐项追问 · 按模块分组
  • DC-01_会前修改优先级表.xlsx 必须改/可解释两档 · 每条预估工作量

Skill 里固化了什么:从上次评审纪要里「想起」了谭锐的七个问题该拦的地方拦住了排除性结论把技术动作翻译成钱

输入清单:PRD 草稿(任何格式)飞书文档/Word/Markdown —— 写到哪一步都行该需求的相关记录RQ-01 的证据包—— 找茬的对照基准历史评审纪要上次被喷的点 —— 同样的坑不踩第二次技术约束说明(如有)研发给过的边界

—— 私有化差异、性能红线

人工边界:不做「AI 替你改 PRD」—— 找茬报告给定位与建议,改不改、怎么改是产品经理的判断。也不做「保证评审通过」—— 预演覆盖的是文档质量,业务拍板仍在评审会。

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

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

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

DC-02 · PRD 一致性终审 — 「本期不做」写在范围声明里,正文却详细描述了它的交互 · 研发按正文实现,范围争议回到产品头上 查看 →DC-03 · 评审材料自动凑齐 — 评审会前一小时还在找「这个需求哪个客户提的」· 证据没带齐的评审,每个问题都是一次减分 查看 →

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

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

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

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

看产品其他场景