PRD要让研发、测试和业务方读完后能判断三件事：为什么做、这次做到哪里、怎样算做完。本文按业务目标、功能范围、验收条件三段给出可直接套用的写法，并用同一套编号把三段串成可追溯的链条，最后附角色分工与定稿检查清单。
要点总览（TL;DR）
- PRD用三段回答三个问题：业务目标写清为什么做与做到什么算成功，功能范围写清这次做什么与不做什么，验收条件写清怎么判定做完。
- 三段共用一套编号：目标条目G、功能项F、验收条目AC逐级挂接，每个功能项能回溯到目标，每条验收条件能回溯到功能项。
- 业务目标要落到目标对象、现状差距、可衡量结果与衡量口径，并写明前提假设和不覆盖的边界，避免方向性口号。
- 功能范围按本次、后续、不做三层划分，功能项写到可独立验收的粒度，优先级标注取舍依据，范围变更保留记录。
- 验收条件采用前置条件—操作—可观察结果—通过标准的句式，覆盖正常、异常与边界三类情形，定稿前按一致性清单核对。
先定PRD三段结构的核心写法
业务目标、功能范围、验收条件分别回答三个问题：为什么做且做到什么算成功、这次做什么和不做什么、怎么判定做完。三段写在同一份文档里，共用一套功能项编号，形成“目标—功能—验收”的追溯链：每个功能项能回溯到某条业务目标，每条验收条件能回溯到某个功能项。
三段的输入、动作与输出可以这样安排：
| 段落 | 回答的问题 | 输入 | 写作动作 | 输出 |
|---|---|---|---|---|
| 业务目标 | 为什么做、做到什么算成功 | 业务方诉求、现状数据、用户反馈 | 界定目标对象，描述现状差距，给出可衡量结果与边界 | 目标条目（G1、G2……）与衡量口径 |
| 功能范围 | 这次做什么、不做什么 | 目标条目、角色场景、资源与排期约束 | 拆功能项、标优先级、划本次/后续/不做三层 | 功能项清单（F1、F2……）并挂接目标编号 |
| 验收条件 | 怎么判定做完 | 功能项清单、业务流程、异常与边界情况 | 逐条写前置条件、操作、可观察结果与通过标准 | 验收条目（AC1、AC2……）并挂接功能项编号 |
编号对应是这套结构的关键。建议采用“目标编号—功能编号—验收编号”的挂接方式，例如功能项F3标注“支撑G1”，验收条件AC3-1、AC3-2标注“对应F3”。术语也要统一：同一个对象在目标段叫“待审核订单”，在功能段和验收段就沿用这个名称，避免出现“订单”“单据”“申请单”混用导致理解偏差。
常见写法错误集中在三处：目标段只写“提升用户体验”这类方向性表述，无法判断是否达成；范围段只列要做的功能，不写不做什么，评审时无法收敛；验收段写成“功能正常可用”，测试无法据此设计用例。这三类问题都会在定稿检查中被拦下。
业务目标怎么写：从现状差距到可衡量结果
业务目标段要写成可判断的描述，核心是把“想改善什么”落到目标对象、现状、期望结果和衡量口径四个要素上。先界定目标对象与业务场景，例如“面向运营人员的退款审核环节”，对象和场景越具体，后续功能范围和验收条件越容易对齐。
现状与差距用事实描述，不用形容词。可以写“当前退款审核平均耗时2个工作日，审核人员需在三个系统间切换核对”，这比“审核效率低”更能支撑后续取舍。期望结果要给出可衡量的指标和口径，写明统计范围与时间窗口，例如“退款审核平均耗时从2个工作日降至0.5个工作日，统计口径为提交审核到审核完成的自然时间，统计范围为上线后第一个完整月”。
目标边界与前提假设同样要写。边界说明本次目标不覆盖哪些对象或场景，前提假设说明目标成立依赖的条件，例如“假设退款申请量维持当前水平”。条件与结论相邻书写，避免读者把假设当成承诺。
下面是一组改写对照：
| 写法 | 示例 | 问题或改进点 |
|---|---|---|
| 原写法 | 提升退款审核效率，优化用户体验 | 无对象、无现状、无口径，无法判断是否达成 |
| 改写后 | G1：将运营退款审核的平均处理耗时从2个工作日降至0.5个工作日（口径：提交至审核完成的自然时间；范围：上线后首个完整月；前提：退款申请量维持当前水平）；本次不覆盖财务打款环节 | 对象、现状、结果、口径、前提与边界齐全，可被验证 |
功能范围怎么划：清单、角色场景与优先级
功能范围段用三层清单划清内外：本次范围、后续范围、不做范围。本次范围是本期交付并验收的功能项；后续范围是已识别但排到后续版本的内容，写明大致版本或触发条件；不做范围明确列出本次明确排除的事项及原因，这一层最容易被省略，却直接决定评审能否收敛。
每个功能项建议包含以下字段：
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 功能编号 | 唯一编号，全文引用 | F2 |
| 功能名称 | 动词加对象，术语与目标段一致 | 退款申请批量审核 |
| 支撑目标 | 挂接目标编号 | G1 |
| 角色与场景 | 谁在什么场景下使用 | 运营审核员在每日集中审核时使用 |
| 功能描述 | 写到可独立验收的粒度 | 支持勾选多条退款申请后一次性通过或驳回，驳回需填写原因 |
| 优先级 | 标注依据，如目标贡献度、依赖关系、合规要求 | 高：直接支撑G1的耗时目标 |
| 范围归属 | 本次/后续/不做 | 本次 |
粒度控制以“可独立验收”为标准：一个功能项应当能对应一组验收条件，并且能被单独判定完成或未完成。“退款审核模块”这种粒度太粗，无法验收；“批量审核”和“驳回原因填写”拆开则各自可验收。优先级标注要写依据，避免全部标为高优先级导致取舍失效。
范围变更要有记录方式。建议在PRD中保留变更记录表，记录变更日期、变更内容、涉及的功能编号、变更原因和确认人。范围调整后同步更新受影响的验收条件，防止文档内部出现新旧版本并存。
验收条件怎么写：可观察、可判定、可对应
验收条件的基本句式是“前置条件—操作—可观察结果—通过标准”。前置条件说明数据与状态，操作说明执行的动作，可观察结果说明界面上或系统里能看到什么，通过标准说明判定通过的依据。每条验收条件挂接功能项编号，一个功能项通常对应多条验收条件。
覆盖面上，每个功能项至少写正常流程、异常流程和边界条件三类。正常流程验证主路径；异常流程验证错误输入、权限不足、依赖服务失败等情况下的表现；边界条件验证数量上限、空值、超时、并发等临界情形。三类条件写全，测试才能据此设计用例，开发也能提前识别实现难点。
通过标准要写判定方式，例如“页面提示‘驳回成功’且列表状态更新为已驳回”，而不是“驳回功能正常”。下面是一组改写对照：
| 写法 | 示例 | 问题或改进点 |
|---|---|---|
| 原写法 | 批量审核功能正常，异常情况有提示 | 无前置条件、无可观察结果、无判定方式 |
| 改写后 | AC2-1（对应F2，正常流程）：审核员勾选3条待审核退款申请并点击“批量通过”，列表状态全部更新为“已通过”，页面提示“3条申请已通过”；AC2-2（异常流程）：勾选包含已处理申请的混合列表点击“批量通过”，已处理项被跳过并提示跳过数量，未处理项正常通过；AC2-3（边界条件）：单次勾选超过50条时提示上限并阻止提交 | 前置条件、操作、可观察结果与通过标准齐全，可逐条验证 |
验收条件与功能项编号的对应关系要在文档中显式写出，便于评审时检查覆盖是否完整：每个本次范围的功能项都应至少有一条验收条件，每条验收条件都应指向一个存在的功能项。出现孤立验收条件或没有验收条件的功能项，都属于需要修正的情况。
角色分工与交付物：谁写、谁评审、谁确认
PRD三段内容的编写与确认涉及产品、业务、研发、测试四类角色。分工不清时，目标由产品单方面拍定、验收条件由测试事后补充，都会造成返工。建议按下表明确职责与交付物：
| 角色 | 主要职责 | 输入 | 输出 | 确认段落 |
|---|---|---|---|---|
| 产品负责人 | 撰写PRD全文，组织评审，维护编号与版本 | 业务诉求、现状数据、排期约束 | 目标段、范围段初稿，验收条件初稿 | 三段整体 |
| 业务方 | 确认目标与优先级，提供现状数据 | 业务数据、用户反馈 | 目标与衡量口径的确认意见，优先级排序 | 业务目标、功能范围优先级 |
| 研发 | 参与范围可行性评审，识别技术约束 | 功能项清单 | 可行性意见、技术约束与拆分建议 | 功能范围 |
| 测试 | 参与验收条件评审，补充异常与边界情形 | 功能项清单、验收条件初稿 | 验收条件补充与可测性意见 | 验收条件 |
评审节点建议分两次：第一次评审目标与范围，确认做不做、做到哪里；第二次评审验收条件，确认怎么判定。两次评审的结论都要落到文档里，记录确认人和确认日期。确认方式可以是评审会结论加文档批注，关键是留下可追溯的记录，避免口头确认后无人对结论负责。
当PRD需要在团队内长期维护并与研发任务保持对应时，可以把文档承载在ONES Wiki中：页面组可关联项目，需求与文档互相对应，文档还能嵌入任务进度与报表，便于在评审时直接看到功能项对应的开发进展。页面模板库可用于沉淀统一的PRD模板，页面版本记录支持查看与回滚，范围变更后能追溯历史版本。这些能力承载的是文档与工作的对应关系，三段内容本身仍需按前述方法撰写。
完整示例：一份PRD的目标、范围与验收段落
以下示例为演示情景，用于展示三段如何写并相互对应。背景设定：某电商平台的运营团队处理退款审核，当前审核需在多个系统间切换核对，平均耗时2个工作日。
业务目标段落：
G1：将运营退款审核的平均处理耗时从2个工作日降至0.5个工作日。口径为提交审核至审核完成的自然时间，统计范围为上线后首个完整月，前提为退款申请量维持当前水平。本次目标不覆盖财务打款环节，打款时效由财务系统另行优化。
功能范围清单：
| 编号 | 功能项 | 支撑目标 | 角色与场景 | 优先级 | 范围归属 |
|---|---|---|---|---|---|
| F1 | 退款申请信息聚合展示 | G1 | 审核员集中审核时查看订单、支付、物流信息 | 高：消除跨系统切换 | 本次 |
| F2 | 退款申请批量审核 | G1 | 审核员每日集中处理时批量通过或驳回 | 高：直接压缩单条处理时间 | 本次 |
| F3 | 审核操作日志导出 | G1 | 主管复盘审核时效 | 中：支撑口径统计 | 后续版本 |
| F4 | 退款原因智能分类 | G1 | 审核员按原因分流处理 | 低：依赖分类模型 | 不做（本期） |
验收条件示例：
AC1-1（对应F1，正常流程）：审核员打开一条待审核退款申请，页面同屏展示订单信息、支付记录与物流状态，无需跳转其他系统。AC2-1（对应F2，正常流程）：勾选3条待审核申请点击“批量通过”，列表状态全部更新为“已通过”并提示“3条申请已通过”。AC2-2（对应F2，异常流程）：勾选含已处理申请的混合列表点击“批量通过”，已处理项被跳过并提示跳过数量。AC2-3（对应F2，边界条件）：单次勾选超过50条时提示上限并阻止提交。
三段编号的对应关系一目了然：G1向下挂接F1、F2，F1、F2向下挂接AC1-1、AC2-1至AC2-3；F3标注为后续版本，本期不写验收条件；F4标注为不做并说明原因。这套写法可迁移到多数业务系统需求，适用边界在于：当目标本身难以量化时，衡量口径可改为可观察的业务状态变化，但仍需写明判定方式，不能退回方向性表述。
完成检查：PRD定稿前的核对项
定稿前按下列清单逐项核对，每项给出通过标准。任一项不通过即视为阻断项，修正后方可进入开发。
| 检查类别 | 检查项 | 通过标准 |
|---|---|---|
| 业务目标 | 目标对象与场景是否明确 | 能指出具体角色与业务环节 |
| 业务目标 | 现状与差距是否有事实依据 | 有数据或可核实的事实描述 |
| 业务目标 | 结果指标与口径是否完整 | 写明指标、统计范围与时间窗口 |
| 业务目标 | 边界与前提是否写明 | 明确不覆盖的对象与成立条件 |
| 功能范围 | 三层划分是否齐全 | 本次、后续、不做三层均有内容 |
| 功能范围 | 功能项粒度是否可独立验收 | 每个功能项能对应一组验收条件 |
| 功能范围 | 优先级是否有依据 | 每项标注取舍理由 |
| 验收条件 | 句式要素是否齐全 | 前置条件、操作、可观察结果、通过标准齐备 |
| 验收条件 | 三类情形是否覆盖 | 正常、异常、边界均有对应条目 |
| 一致性 | 目标与功能项是否对应 | 每个本次功能项挂接至少一条目标 |
| 一致性 | 功能项与验收条件是否对应 | 无孤立验收条件，无缺验收的功能项 |
| 一致性 | 术语与编号是否统一 | 同一对象全文同名，编号无重复无断档 |
阻断项的判定标准是：缺少可衡量目标、本次范围未列不做事项、本次功能项缺少验收条件、编号对应断裂，这四类问题任一存在，PRD即不具备评审通过条件。其余检查项可作为改进项在评审中提出。全部通过后，由产品负责人汇总确认记录，业务方、研发、测试分别对各自确认段落签字或批注，PRD进入开发阶段。
常见问题
业务目标实在难以量化时，PRD里该怎么写才不算口号？
把衡量口径换成可观察的业务状态变化，并写明判定方式。例如目标改为“退款审核完成后，审核员无需再登录支付系统核对”，判定方式可以是上线后抽查审核记录，确认审核操作在同一页面完成。关键是保留目标对象、现状、期望状态和判定依据四个要素，让读者能判断达成与否。方向性表述如“提升体验”缺少判定依据，仍属于需要改写的情况。
功能范围里的“不做范围”要写到什么程度，写少了会怎样？
不做范围至少覆盖评审中被提出、但本期明确排除的事项，并写明排除原因，例如依赖外部系统改造、排期不足或目标本期不覆盖。写少了，评审时同一议题会被反复提出，范围无法收敛；开发过程中也容易出现临时加需求。不做范围与本次范围使用同一套功能项编号体系，后续版本启动时可直接引用。
验收条件由产品写还是测试写，两边怎么衔接？
常见做法是产品负责人写出验收条件初稿，测试在评审中补充异常流程与边界情形，并对可测性提出意见。产品负责保证每条验收条件挂接功能项编号，测试负责保证条件可转化为用例。衔接的关键是评审节点：验收条件评审通过后再进入开发，避免开发中期验收标准仍在变化。确认结论与确认人应记录在文档中。
范围中途变更后，已经写好的验收条件怎么处理？
范围变更时同步更新受影响的验收条件，并在变更记录中写明变更日期、涉及的功能编号、变更原因和确认人。新增功能项要补写对应验收条件；移出本次范围的功能项，其验收条件标注为后续版本或删除，避免文档中新旧内容并存。定稿检查时把“无孤立验收条件、无缺验收的功能项”作为一致性核对项，可以拦住大部分遗漏。
PRD放在文档工具里维护时，怎样让目标、范围与验收的对应关系不散掉？
把三段写在同一个页面或同一组页面中，功能项编号在全文唯一，验收条件直接引用功能项编号。若使用ONES Wiki，页面组可关联项目，需求与文档互相对应，文档还能嵌入任务进度与报表，评审时可直接看到功能项对应的开发进展；页面模板库可用于沉淀统一的PRD模板，页面版本记录支持查看与回滚，范围变更后能追溯历史版本。工具承载的是对应关系与版本，三段内容本身仍需按目标、范围、验收的写法逐段完成。
