更新时间： 2026年10月17日
AI生成的PRD适合整理资料和形成初稿，不能替代业务事实核验。评审时先把输入来源、假设和待确认项分开，再用墨刀AI或原型工具把关键流程落成页面和状态，产品、设计、研发共同确认后再进入开发。
一、四层评审顺序
| 层级 | 要问的问题 | 常见风险 |
|---|---|---|
| 事实 | 数据、角色、时间和来源真实吗？ | 把推测写成业务事实 |
| 任务 | 用户目标和成功结果是否明确？ | 页面很多但无法判断完成 |
| 规则 | 权限、状态、边界和异常是否完整？ | 只写主流程，遗漏失败路径 |
| 验收 | 什么结果算完成，如何验证？ | 指标空泛，研发无法测试 |
二、用“会员续费”做评审
先给AI一份经过脱敏的访谈摘要、现有规则和数据字典，要求它列出不确定项。评审时逐项核对：续费资格、价格、优惠叠加、支付失败、退款和到期提醒。任何数字都要回到来源；无法确认的内容标成“待业务确认”，不让AI自动补齐。
- 把每个核心规则改写成“条件—动作—结果”，例如“已过期且有未结订单时，不允许再次购买”。
- 在原型中补齐加载、失败、权限和空状态，检查规则是否能被用户理解。
- 让研发评估接口、数据和权限依赖，标注实现边界与替代方案。
- 把已确认规则转成验收用例，注明数据准备、预期结果和负责人。
三、删掉三类伪确定内容
- 没有来源的数字和效果承诺，例如“提升80%”“10秒完成”。
- 没有定义对象的词，例如“用户可以快速完成”“系统自动优化”。
- 把建议写成已上线能力的句子，尤其是权限、接口和第三方服务。
四、评审通过的交付包
一份合格的AI生成PRD应附输入来源、事实核对表、待确认清单、原型链接和验收用例。版本变更时保留差异和确认人；如果事实变化，先更新来源和规则，再重新生成相关段落，避免只修改表述而漏掉页面与测试。
五、把AI输出拆成事实、假设与决策
评审时给每段内容打标签：事实来自业务资料，假设需要验证，决策由负责人确认。比如“用户希望一键续费”可能只是访谈中的个别表达，应先标为假设；“退款金额按原支付方式退回”若来自财务规则，则可作为事实。标签能阻止AI生成的顺滑句子掩盖证据缺口。
把主流程和异常路径跑通后，再把本页的复现记录与交付结果放在同一份版本记录中，后续评审可以直接追踪。
案例：评审 AI 生成的会员权益 PRD
AI 生成的 PRD 常把“用户可以领取权益”写得很完整，却遗漏领取资格、次数限制和失败后的补偿。评审时不要从语句是否通顺开始，而要从一个真实任务反推规则：用户在会员中心领取一张限量券，领取失败后还能做什么。
- 把生成内容拆成目标、角色、前置条件、主流程、异常和验收指标六栏。
- 给每个规则补一个可验证例子，例如已领取、已过期、库存为零和网络超时。
- 检查原型是否有对应页面和状态；没有证据的规则标为待确认，不直接交给研发。
- 把争议项交给业务负责人确认，再将结论回写到 PRD 和评审记录。
- 用三条测试用例复核：符合资格成功、不符合资格被拒、重试不重复扣库存。
| 核对层 | 关键问题 | 可交付结果 |
|---|---|---|
| 事实 | 数字、角色和流程来源是什么？ | 来源链接或负责人 |
| 规则 | 边界、权限和异常是否明确？ | 规则表与示例 |
| 体验 | 页面是否能解释原因并恢复？ | 可点击原型 |
| 验收 | 如何判断实现完成？ | 用例和指标 |
四轮评审怎样落到一张可复用的表
AI生成PRD后不要先改措辞。先把每条结论拆成“事实、规则、体验、验收”四层，并给出来源或负责人。以会员续费为例，评审者可以直接复制下面的顺序。
| 轮次 | 检查问题 | 证据 | 不通过时怎么处理 |
|---|---|---|---|
| 事实 | 金额、角色、时间和流程来自哪里 | 原始资料、接口或负责人 | 标为待确认，不进入开发 |
| 规则 | 退款、权限、重复提交和边界是否写清 | 规则表与正反例 | 补条件和责任人 |
| 体验 | 页面是否能解释原因并恢复任务 | 可点击原型与状态 | 补空、错、加载和成功状态 |
| 验收 | 研发和测试如何判断完成 | 用例、接口字段和验收结果 | 把抽象描述改成可观察结果 |
可复制的评审操作
- 给每个事实加来源链接或负责人，无法核验的内容统一标为“待确认”。
- 从PRD抽出一个正常续费案例和三个边界案例：余额不足、重复提交、退款失败。
- 用墨刀AI整理页面初稿后，在墨刀原型中补页面连接、错误提示、按钮状态和权限差异。
- 邀请产品确认业务规则，设计确认信息层级，研发确认接口与实现边界。
- 发布评审结论时保留问题编号、责任人、截止时间和证据链接，下一版沿编号复查。
这样做的产物不是“AI写得像不像”，而是一份可以回到来源、复现任务、定位风险并交给研发的评审记录。
