研发评审用的PRD，核心是让评审者能据此判断“做不做、怎么做、做到什么程度”。一份可评审的PRD通常包含背景与目标、范围与不做清单、用户与场景、功能需求与流程、验收标准、非功能要求、依赖与风险、里程碑与发布计划、待决问题。下面给出一套可直接复制填写的表格模板，并说明字段口径、必填门槛和填写示例。
要点总览（TL;DR）
- 研发评审用的PRD围绕“做不做、怎么做、做到什么程度”组织，核心信息块包括背景与目标、范围与不做清单、用户与场景、需求条目、验收标准、非功能要求、依赖与风险、里程碑、待决问题。
- 模板以表格为主体：文档信息、背景与目标、范围与不做清单、需求条目主表、非功能要求、依赖与风险、里程碑与发布计划、待决问题共八张表，复制表头即可填写。
- 评审前必须补齐的是文档信息、背景与目标、范围与不做清单、需求条目主表、依赖与风险、待决问题；验收标准、非功能要求、里程碑在初评可先给关键项，终评需逐条落实。
- 每条需求写清输入、操作、输出，并配一条可观察的验收标准，测试能据此设计用例，研发能据此判断实现范围。
- 模板按项目类型裁剪行和列，保留必填信息块；每次评审后回收“被反复追问”和“长期空置”的字段，按季度更新模板版本。
可复制空白PRD评审模板
模板以表格为主体，按信息块拆成六张表。复制到文档工具后，保留表头，逐行填写即可。文档信息表和需求条目主表是评审的基础，其余表格按项目实际情况增删行。
表1 文档信息
| 字段 | 填写内容 |
|---|---|
| 文档名称 | |
| 文档编号 | |
| 版本号 | |
| 作者 | |
| 评审日期 | |
| 评审类型 | 初评 / 终评 |
| 参与角色 | 产品、研发、测试、设计、运营等，注明各角色负责人 |
| 变更记录 | 版本号、变更内容、变更人、日期 |
表2 背景与目标
| 字段 | 填写内容 |
|---|---|
| 业务背景 | |
| 要解决的问题 | |
| 目标与衡量指标 | |
| 目标用户 | |
| 核心使用场景 |
表3 范围与不做清单
| 类型 | 内容 | 说明 |
|---|---|---|
| 本期范围 | ||
| 本期不做 | 说明原因或计划排期 | |
| 后续版本考虑 |
表4 需求条目主表
| 编号 | 模块 | 需求描述 | 优先级 | 验收标准 | 责任人 | 状态 |
|---|---|---|---|---|---|---|
| R-001 | P0/P1/P2 | 待评审/已确认/开发中/已完成 | ||||
| R-002 |
表5 非功能要求
| 类别 | 要求 | 验证方式 |
|---|---|---|
| 性能 | ||
| 安全与权限 | ||
| 兼容性 | ||
| 可用性与容错 | ||
| 数据与合规 |
表6 依赖与风险
| 编号 | 类型 | 描述 | 影响 | 应对措施 | 负责人 |
|---|---|---|---|---|---|
| D-001 | 依赖/风险 |
表7 里程碑与发布计划
| 阶段 | 交付物 | 计划时间 | 负责人 |
|---|---|---|---|
| 需求评审 | |||
| 开发完成 | |||
| 测试验收 | |||
| 发布上线 |
表8 待决问题
| 编号 | 问题描述 | 提出人 | 需谁决策 | 截止时间 | 状态 |
|---|---|---|---|---|---|
| Q-001 | 开放/已关闭 |
模板字段说明：每个字段回答评审中的什么问题
字段的价值在于对应评审者的一个判断动作。填写时先想清楚“谁会看这个字段、他要据此做什么决定”，再决定写多细。
| 字段 | 回答的评审问题 | 填写口径 |
|---|---|---|
| 业务背景与目标 | 为什么现在要做这件事 | 写清现状问题、触发原因和期望结果，目标尽量带可衡量指标，避免只写“提升体验” |
| 目标用户与场景 | 为谁解决什么问题 | 写明角色、使用时机和当前做法，场景数量控制在能覆盖主要路径的范围 |
| 范围与不做清单 | 这次做到哪里为止 | “不做”要写具体条目和原因，防止评审中反复讨论边界 |
| 需求描述 | 具体要做什么 | 一条需求只描述一个可独立验收的能力，写清输入、操作和输出 |
| 验收标准 | 怎么算做完、做好 | 与需求描述一一对应，用可观察的结果表述，能被测试转化为用例 |
| 优先级 | 资源不够时先保什么 | 按业务价值、紧急程度和实现成本综合判断，P0项需说明不做的后果 |
| 责任人 | 谁来推进和答复 | 每条需求指定一名负责人，负责澄清和跟进状态 |
| 非功能要求 | 质量底线在哪里 | 性能、安全、兼容等要求写具体数值或可验证条件，并注明验证方式 |
| 依赖与风险 | 什么可能卡住进度 | 外部系统、其他团队、技术不确定性都要记录，附应对措施和负责人 |
| 待决问题 | 哪些事还没定 | 每个问题写明需谁决策和截止时间，评审会上逐条确认或指派 |
需求描述与验收标准要成对出现。描述回答“做什么”，验收标准回答“做到什么程度算完成”。两者脱节时，研发和测试对同一需求的理解容易分叉，评审应重点检查这一对字段是否匹配。
必填与选填：评审前必须补齐的信息
评审准入的判断标准是：评审者能否在不追问的情况下做出“做不做、怎么做、做到什么程度”的判断。达不到这个标准的信息属于必填项，评审前必须补齐。
| 信息块 | 初评 | 终评 | 说明 |
|---|---|---|---|
| 文档信息（版本、作者、评审日期、参与角色） | 必填 | 必填 | 缺参与角色无法组织评审 |
| 背景与目标 | 必填 | 必填 | 初评可接受目标指标待细化，但问题描述必须清楚 |
| 范围与不做清单 | 必填 | 必填 | 边界不清会导致评审发散 |
| 需求条目主表（编号、描述、优先级、责任人） | 必填 | 必填 | 初评允许部分条目描述较粗，但需标注待细化 |
| 验收标准 | 选填 | 必填 | 初评可只写关键需求的验收口径，终评需逐条对应 |
| 非功能要求 | 选填 | 必填 | 涉及性能、安全、合规的需求在初评即应提出 |
| 依赖与风险 | 必填 | 必填 | 已知的外部依赖和重大风险不能留到开发阶段暴露 |
| 里程碑与发布计划 | 选填 | 必填 | 初评可给大致节奏，终评需有可排期的节点 |
| 待决问题 | 必填 | 必填 | 没有待决问题也要写明“无”，避免遗漏 |
缺失必填项时，建议在评审通知中列出缺口，由作者补齐后再排期，或降级为预沟通会，只讨论方向、不出结论。把“先开会再补材料”作为例外处理，并记录补交时间，能减少评审反复。
初评与终评的深度差异体现在颗粒度上：初评关注方向、范围和优先级是否成立，需求描述可以按模块汇总；终评关注每条需求能否直接进入开发和测试，验收标准、非功能要求和依赖需要逐条落实。
填写示例：一条需求从描述到验收的完整写法
以下为演示情景，用于说明字段如何配合，不代表真实项目数据。
背景与目标：运营团队每月需手工汇总各渠道的订单数据，平均耗时两天，且口径不一致。本期目标是提供订单数据导出功能，将月度汇总时间缩短到半天以内，导出结果与财务口径一致。
需求条目主表填写：
| 编号 | 模块 | 需求描述 | 优先级 | 验收标准 | 责任人 | 状态 |
|---|---|---|---|---|---|---|
| R-003 | 订单管理 | 支持按时间范围、渠道、订单状态筛选订单，并导出为表格文件；导出字段包含订单号、下单时间、渠道、金额、状态 | P1 | 1. 筛选条件组合生效，结果与列表页一致；2. 导出文件字段顺序与模板一致；3. 单次导出1万条以内数据在30秒内完成；4. 无数据时导出空表并提示 | 产品负责人A | 待评审 |
验收标准写法要点：每条标准对应一个可观察的结果，覆盖正常路径、边界情况和异常提示。测试人员可以据此直接设计用例，研发可以据此判断实现范围。
依赖与待决问题填写：
| 编号 | 类型 | 描述 | 影响 | 应对措施 | 负责人 |
|---|---|---|---|---|---|
| D-002 | 依赖 | 导出字段口径需与财务系统对齐 | 口径不一致会导致返工 | 评审前与财务确认字段定义 | 产品负责人A |
| Q-002 | 待决 | 导出文件是否需要保留历史记录 | 影响存储设计 | 终评前由业务负责人决策 | 业务负责人B |
这条示例体现了模板的配合关系：背景说明为什么做，需求描述界定做什么，验收标准界定做到什么程度，依赖和待决问题把未定事项显性化，评审者可以据此直接给出结论或指派决策人。
模板的调整与维护方法
模板需要随团队和项目类型调整，但调整应有规则，避免每次评审各写各的。以下维护规则可作为起点。
- 按项目类型裁剪字段：后台工具类项目可强化权限和数据口径字段；面向用户的功能可强化场景和交互说明；涉及外部系统的项目必须保留依赖表。裁剪只删减行和列，不删除必填信息块。
- 版本与变更记录：模板本身维护版本号，每次调整记录变更内容、原因和生效日期，旧版本归档，便于追溯历史文档的填写口径。
- 评审后回收意见：每次评审结束记录“哪些字段被反复追问”“哪些字段无人使用”，按季度汇总，把高频缺口补进必填项，把长期空置的字段降为选填或删除。
- 与需求状态衔接：需求条目状态从“待评审”到“已确认”的流转，以必填项补齐为条件；状态变更时同步更新文档版本，保证评审结论和文档内容对应。
当需求条目较多、评审轮次频繁时，可以把模板中的需求主表和待决问题表放到需求管理工具中维护。以ONES为例，需求可以作为工作项逐条记录编号、优先级、责任人和状态，PRD文档与工作项关联，评审结论和待决问题的关闭情况随状态流转留痕，减少文档与执行脱节。是否引入工具取决于团队规模和评审频率，小团队用文档表格配合固定评审节奏同样可行。
常见问题
初评时需求描述还比较粗，能先开会再补吗？
可以，但要把这种处理方式限定为例外。初评关注方向、范围和优先级是否成立，需求描述允许按模块汇总，但文档信息、背景与目标、范围与不做清单、依赖与风险、待决问题这几项仍需在会前具备。若这些必填项缺失，建议改为预沟通会，只讨论方向、不出结论，并在会议记录中写明补交内容和时间，避免评审反复。
验收标准写到什么颗粒度才算够？
判断标准是测试人员能否直接据此设计用例。一条验收标准对应一个可观察的结果，覆盖正常路径、边界情况和异常提示，涉及数值的写明数值和适用范围。例如“导出1万条以内数据在30秒内完成”比“导出要快”更可评审。终评前每条需求都应有对应的验收标准，初评可以只写关键需求的验收口径。
待决问题在评审会上应该怎么处理？
待决问题表要写明问题描述、提出人、需谁决策和截止时间。评审会上逐条确认：能当场定的给出结论并关闭；不能当场定的指派决策人和截止时间，状态保持开放。没有待决问题也要写“无”，避免遗漏。终评前仍未关闭的问题，需要评估是否影响排期，再决定是否带入开发。
小团队也需要用这么完整的表格模板吗？
可以裁剪。裁剪的原则是只删减行和列，不删除必填信息块。小团队可以合并文档信息与背景目标、精简非功能要求表的类别，但范围与不做清单、需求条目主表、验收标准、待决问题建议保留，这几项直接决定评审能否得出结论。团队规模小、评审频率低时，用文档表格配合固定评审节奏即可；需求条目多、评审轮次频繁时，再考虑把需求主表和待决问题表放到需求管理工具中维护。
模板更新后，历史PRD的填写口径怎么处理？
模板本身维护版本号和变更记录，每次调整记录变更内容、原因和生效日期，旧版本归档。历史PRD按当时版本的口径理解，不要求回溯改写；新发起的评审使用当前版本。需求条目状态从“待评审”流转到“已确认”时，同步更新文档版本，保证评审结论与文档内容对应。
