PRD写清三件事：业务目标回答“为什么做、做到什么算成功”，用可观察的业务结果和衡量口径表述；功能范围回答“这次做什么、不做什么”，用范围清单加边界说明界定；验收条件回答“怎么判定做完且做对”，按场景写成可验证的判定项，并标明验证方式与责任人。三部分共用同一套编号与术语，形成目标—范围—验收的对应关系。下文按这三部分的写作方法展开，并给出角色分工、完整示例与交付前自检清单。
要点总览（TL;DR）
- 业务目标写到能被一个版本范围覆盖、能被一条验收条件判定的颗粒度，包含业务问题、目标对象、期望结果、衡量口径四要素，多目标时标明优先级。
- 功能范围用“角色＋对象＋动作＋结果”的范围条目表达，每条标注对应目标编号，并列出不做清单及排除原因与后续计划。
- 验收条件按“前提—操作或输入—预期结果—判定标准”四段写，功能验收引用范围编号，业务目标验收引用目标编号，并写明验证方式与责任人。
- 目标、范围、验收共用一套编号与术语，形成追溯链；变更时记录条目、原因、影响范围与版本号，便于定位受影响内容。
- 交付前用自检清单逐项核对目标可衡量、范围有边界、验收可验证、编号一致、变更留痕，全部通过再提交评审。
业务目标怎么写：从业务问题到可衡量的成功口径
业务目标写到“能被一个版本的范围覆盖、能被一条验收条件判定”的颗粒度即可，不必细到功能按钮。判断标准很直接：读完这段目标，研发能判断哪些需求该进这个版本，测试能据此设计一条验证目标是否达成的检查项。达不到这个程度，说明目标还停留在口号层面。
一段可用的业务目标建议包含四个要素，缺一项都会给后续环节留下解释空间：
| 要素 | 要回答的问题 | 填写要求 |
|---|---|---|
| 业务问题 | 当前存在什么痛点或机会 | 描述现状与期望之间的差距，说明为什么现在要处理 |
| 目标对象 | 影响哪类用户或哪条业务线 | 写明角色或业务范围，避免“全体用户”这类无法验证的表述 |
| 期望结果 | 希望发生什么可观察的变化 | 落到具体业务动作或状态变化，而非抽象感受 |
| 衡量口径 | 用什么指标、什么周期、什么数据来源判断 | 指标、统计周期、数据来源三项齐全，口径写死 |
把“提升效率”落到具体动作，是业务目标写作中最常见的难点。改写方向是补全“谁、在哪个环节、从什么状态到什么状态、用什么数据观察”。例如“提升审批效率”可以改写为“门店店长提交的补货申请，从提交到区域经理审批完成的平均时长由2个工作日缩短至1个工作日，统计口径为审批系统内提交时间至审批通过时间，按自然月统计”。改写后的表述指向明确的角色、环节和可采集的数据，后续范围与验收都能引用。
目标与版本范围的关系需要说清：目标决定取舍，本身不承担功能清单的职责。一个版本可以对应一个或多个目标，但目标之间要有优先级，标明哪个是必须达成、哪个是尽力达成。多个目标并列且无优先级时，范围评审阶段一旦资源紧张就无法决策。常见写法问题集中在三类：目标与功能混写，把“上线某某页面”当成目标；口径缺失，只写方向不写指标与来源；多目标平铺，没有主次。写作时逐条对照四要素表，能消除大部分问题。
可直接套用的段落结构如下：
- 【目标编号】G1
- 业务问题：现状描述＋差距说明。
- 目标对象：角色或业务线。
- 期望结果：可观察的业务变化。
- 衡量口径：指标名称、统计周期、数据来源。
- 优先级：必须达成／尽力达成。
功能范围如何界定：范围清单、边界与不做清单
功能范围用可核对的范围条目表达，每条写清对象、动作、结果、所属角色，并标注它服务于哪个目标编号。这样评审时能逐条判断“这条是否支撑目标”，变更时也能顺着编号找到受影响的目标与验收项。
范围条目的推荐写法是“角色＋对象＋动作＋结果”一句话，例如“区域经理在审批列表中批量通过补货申请，通过后申请状态变为已审批并通知店长”。避免只写“补货审批功能”这类名词短语，它无法说明做到什么程度算完成。条目数量以覆盖目标所需为限，同一目标下的条目按业务流程顺序排列，便于阅读。
“本次做”与“本次不做”要并列呈现，不做清单同样需要理由。只写做哪些，评审时边界靠口头解释，容易在开发中途产生分歧。不做清单的每条建议注明排除原因与后续计划，例如“本次不做跨区域调拨审批，原因是涉及多仓库存口径统一，计划在下一版本随库存模块一并处理”。这样既划清边界，也保留了后续衔接的线索。
范围与目标的对应关系用编号维系：每条范围条目引用一个目标编号，一个目标可以对应多条范围。评审时反向检查一遍——每个目标是否至少有一条范围支撑，每条范围是否都能指回某个目标。出现无目标支撑的范围条目，要么补目标，要么从本版本移出。
范围变更时，在文档中记录变更条目、变更原因、影响的目标编号与验收条目，并更新版本号。变更记录与范围清单放在同一文档内，避免范围改了而验收条件未同步。功能范围清单模板如下：
| 范围编号 | 范围条目（角色＋对象＋动作＋结果） | 对应目标 | 是否本次做 | 排除原因／后续计划 |
|---|---|---|---|---|
| S1 | 示例条目 | G1 | 是 | — |
| S2 | 示例条目 | G1 | 否 | 写明原因与计划版本 |
验收条件如何编写：场景化判定项与验证方式
验收条件按“前提—操作或输入—预期结果—判定标准”四段写，每条独立可验证。四段齐全的条目，测试人员不需要再向产品确认就能执行；缺任何一段，判定就会依赖个人理解。
功能验收与业务目标验收要分开列。功能验收判定“功能是否按规格工作”，例如某状态下按钮可用、提交后状态正确流转；业务目标验收判定“目标口径是否达成”，例如上线后一个统计周期内审批平均时长是否达到目标值。两类条目分别编号，业务目标验收条目引用目标编号，功能验收条目引用范围编号，形成目标—范围—验收的追溯链。
验证方式与证据要写进条目：谁验、在什么数据或场景下验、留下什么证据。功能验收通常由测试在指定场景下执行并留存结果记录；业务目标验收通常由业务方在约定统计周期后依据数据报表确认。责任人写角色而非姓名，人员变动时条目仍然有效。
不可验证的表述需要改写。常见对照如下：
| 原始表述 | 问题 | 改写方向 |
|---|---|---|
| 页面响应快 | 无判定标准 | 指定场景与数据量下的结果状态，或由谁在什么条件下确认 |
| 体验流畅 | 主观感受 | 拆成具体操作路径上的结果判定项 |
| 审批效率提升 | 缺口径 | 引用目标编号中的指标、周期与数据来源 |
| 兼容主流浏览器 | 范围不明 | 列出具体浏览器与版本，写明验证场景 |
确实无法量化的主观项，明确由谁依据什么材料判定，例如“由业务方依据试用反馈表在验收会上确认”，把判定主体和依据固定下来，同样构成可执行的验收条件。验收条件条目模板：
- 【验收编号】A1，引用范围编号S1或目标编号G1
- 前提：系统状态、数据准备、角色权限。
- 操作或输入：执行的具体步骤或输入数据。
- 预期结果：可观察的状态或输出。
- 判定标准：通过／不通过的判断依据。
- 验证方式与责任人：谁验、用什么数据或场景、留什么证据。
角色分工与交付物：谁写、谁评审、谁确认
三部分内容的责任可以按组织实际调整，但每个环节要有明确的输入与输出，避免评审会上才第一次看到内容。下表给出一种常见分工，供参照后按团队情况修改。
| 角色 | 主要职责 | 交付物 | 确认节点 |
|---|---|---|---|
| 产品负责人 | 主笔业务目标与功能范围，维护编号与术语 | 目标段落、范围清单与不做清单 | 范围评审前定稿 |
| 业务方 | 确认目标对象与衡量口径，提供数据来源 | 目标口径确认意见 | 目标评审 |
| 研发 | 参与范围可行性评审，反馈技术约束 | 范围可行性意见 | 范围评审 |
| 测试 | 参与验收条件评审，确认可验证性 | 验收条件评审意见 | 验收条件评审 |
评审节点建议按目标、范围、验收条件分三次或合并为两次进行，每次评审有明确的通过标志：目标评审通过标志是四要素齐全且口径经业务方确认；范围评审通过标志是每条范围有目标编号、不做清单有理由；验收条件评审通过标志是每条可独立执行且责任人明确。确认方式写入文档头部，例如“目标口径由业务方在评审记录中签字确认”。
版本与变更记录的归属跟随主笔角色：产品负责人维护文档版本号与变更记录，变更涉及目标口径时由业务方重新确认，涉及验收条件时由测试重新评审。跨角色对齐的输入输出要固定下来——业务方输入目标口径与数据来源，研发输入技术约束，测试输入可验证性意见，产品负责人汇总后更新文档并通知相关角色。
当PRD需要在多人之间流转并保留每次变更的痕迹时，可以把目标、范围与验收条目作为需求工作项承载，在ONES中按条目记录状态与变更历史，使编号之间的引用关系随版本可查。这样评审意见、确认记录与条目本身放在一起，追溯时不必在多个文档间比对。
完整示例：一个版本的PRD目标、范围与验收
以下示例为演示情景，用于展示三部分如何互相引用，不代表任何真实项目数据。
业务目标段落
- 【G1】业务问题：门店补货申请在区域经理处积压，平均审批时长2个工作日，影响补货及时性。
- 目标对象：门店店长与区域经理。
- 期望结果：补货申请从提交到审批完成的平均时长缩短。
- 衡量口径：审批系统内提交时间至审批通过时间，按自然月统计，数据来源为审批系统报表。
- 优先级：必须达成。
功能范围清单
| 范围编号 | 范围条目 | 对应目标 | 是否本次做 |
|---|---|---|---|
| S1 | 区域经理在审批列表中批量通过补货申请，通过后状态变为已审批并通知店长 | G1 | 是 |
| S2 | 店长在申请列表中查看审批状态与审批时间 | G1 | 是 |
| S3 | 跨区域调拨审批 | G1 | 否，涉及多仓库存口径统一，计划下一版本处理 |
验收条件条目
- 【A1｜引用S1】前提：区域经理账号下存在3条待审批申请。操作：在列表中勾选3条并执行批量通过。预期结果：3条状态均变为已审批，店长收到通知。判定标准：状态与通知均正确。验证方式：测试在测试环境执行并留存结果记录。
- 【A2｜引用S2】前提：存在已审批与待审批申请各1条。操作：店长打开申请列表。预期结果：两条申请的审批状态与审批时间正确显示。判定标准：显示内容与审批记录一致。验证方式：测试核对审批记录。
- 【A3｜引用G1】前提：功能上线满一个自然月。操作：业务方导出审批系统报表。预期结果：平均审批时长达到目标口径要求。判定标准：按G1口径计算的结果达标。验证方式：业务方依据报表在月度复盘中确认。
三部分的引用关系是：G1被S1、S2支撑，S1、S2分别被A1、A2验证，G1本身由A3验证。变更S1时，可顺着编号定位到A1与G1，判断是否需要同步调整。
完成检查：PRD交付前的自检清单
交付前逐项核对以下检查项，每项给出通过判断，全部通过再提交评审。
| 检查项 | 通过判断 |
|---|---|
| 业务目标是否可衡量 | 每个目标四要素齐全，指标、周期、数据来源写明 |
| 目标是否有优先级 | 多目标时标明必须达成与尽力达成 |
| 目标与范围是否对应 | 每个目标至少有一条范围支撑，每条范围能指回目标 |
| 范围条目是否可核对 | 每条含角色、对象、动作、结果，无纯名词短语 |
| 是否含不做清单 | 不做条目有排除原因与后续计划 |
| 验收条件是否可验证 | 每条四段齐全，可独立执行，无主观表述 |
| 验收是否覆盖目标 | 每个目标有对应的业务目标验收条目 |
| 术语与编号是否一致 | 目标、范围、验收编号互相引用且全文统一 |
| 变更是否留痕 | 变更记录含条目、原因、影响范围与版本号 |
清单中任何一项无法通过，回到对应章节补齐内容，而不是在评审会上口头补充。三部分内容完整且相互一致，PRD才具备被评审和逐条验证的基础。
常见问题
业务目标的衡量口径暂时拿不到数据来源，PRD还能往下写吗？
可以继续写，但要把口径缺口显式标注出来，避免它被当成已确认内容。建议在目标段落中保留指标与统计周期，数据来源一栏写明“待确认”，并注明由业务方在目标评审前补齐。范围与验收可以先行推进，涉及该口径的业务目标验收条目暂不写死判定值，等数据来源确认后再补。若到范围评审时口径仍未确认，应把该目标标为“尽力达成”或移出本版本，防止验收阶段无法判定。
一个版本里目标较多时，范围条目和验收条件怎么组织才不混乱？
先给目标排优先级，标明必须达成与尽力达成，再按目标分组组织范围条目。每条范围条目只引用一个主目标编号，跨目标的条目拆开写或注明主次。验收条件同样按目标分组：功能验收条目引用范围编号，业务目标验收条目引用目标编号。这样资源紧张时，可以按目标优先级整体裁剪范围及其验收条目，而不必逐条判断取舍。
验收条件里的主观项，比如界面观感，怎么写才算可执行？
把判定主体、判定依据和判定时点固定下来，主观项也能执行。例如写明“由业务方依据设计稿与试用反馈表，在验收会上逐项确认”，并列出需要确认的具体页面与状态。另一种做法是拆成可观察的判定项，如指定操作路径上的元素显示、状态变化与提示文案。关键是让不同人按同一条目执行能得到一致结论，避免只写“观感良好”这类无法复现的表述。
PRD评审通过后范围发生变更，目标与验收条件要同步改吗？
要顺着编号判断影响面。范围条目变更时，先看它引用的目标是否仍被其他范围支撑；若目标失去支撑，需调整目标或补充范围。再看引用该范围编号的验收条目，同步修改或作废。变更涉及目标口径时，由业务方重新确认；涉及验收条件时，由测试重新评审。变更记录写明条目、原因、影响的目标与验收编号以及版本号，与范围清单放在同一文档内。
小团队人手少，目标、范围、验收三部分能否合并评审？
可以合并为一次或两次评审，但通过标志仍要分开判断。合并评审时按目标、范围、验收的顺序逐段过，每段给出明确结论：目标四要素是否齐全且口径经业务方确认，每条范围是否有目标编号且不做清单有理由，每条验收是否可独立执行且责任人明确。合并评审的风险是验收条件被范围讨论挤占时间，建议提前把材料发给参会角色，会上只处理分歧项。
