PRD模板是一份按固定结构组织需求背景、目标用户、功能范围、流程规则、验收标准与非功能约束的文档骨架。本文提供一份可直接复制填写的空白PRD模板，并配套字段说明、必填与选填划分、完整填写示例和模板维护方法，四部分内容与空白模板逐项对应，拿到即可开始填写。
要点总览（TL;DR）
- 空白PRD模板按文档信息、背景与问题、目标与衡量、用户与场景、功能范围、流程规则、验收标准、非功能约束、开放问题与变更记录九个章节组织，可直接复制填写。
- 必填字段的判断依据是缺少它研发无法估算、测试无法验收、评审无法决策；小需求可合并流程规则、简化非功能约束，但背景、目标、范围、验收四项必须保留。
- 字段填写要落到可判断、可验证的内容：目标带数值与统计口径，功能点带编号，验收标准可被测试直接转成用例，开放问题有负责人和关闭时间。
- 模板维护以版本记录、按需求类型拆分变体、回收评审反馈、季度抽查为手段，每次调整只动一到两个字段，避免字段只增不减导致模板失效。
- PRD在ONES中可作为需求工作项的关联文档承载，评审意见、状态流转与变更记录围绕同一工作项沉淀。
可复制空白PRD模板
以下骨架可直接复制到文档工具中，把方括号内的提示替换为实际内容。章节顺序按“先讲清问题，再讲清方案，最后讲清如何验收”排列，填写时保持顺序，便于评审人按同一路径阅读。
# [需求名称] PRD ## 1. 文档信息 - 文档版本：[v0.1] - 作者：[姓名] - 评审人：[产品、研发、测试、设计、业务方] - 文档状态：[草稿 / 评审中 / 已确认 / 已变更] - 最后更新日期：[YYYY-MM-DD] - 关联需求单/工作项：[编号或链接] ## 2. 背景与问题陈述 - 业务背景：[当前业务处于什么阶段，发生了什么变化] - 问题描述：[谁在什么场景下遇到什么问题，造成什么影响] - 现状与数据：[现有流程、现有数据或用户反馈，注明来源与时间] - 不解决的后果：[问题持续会带来什么损失或风险] ## 3. 目标与成功衡量 - 业务目标：[本次需求要达成的业务结果] - 用户目标：[用户完成什么任务、获得什么体验] - 成功指标：[指标名称、当前值、目标值、统计口径、观察周期] - 非目标：[本次明确不解决的问题] ## 4. 用户与使用场景 - 目标用户：[角色、规模、特征] - 核心场景：[场景描述、触发条件、用户期望结果] - 使用频率与关键路径：[高频路径与低频路径分别是什么] ## 5. 功能范围与优先级 - 功能清单： | 编号 | 功能点 | 优先级 | 说明 | |---|---|---|---| | F1 | [功能点] | [P0/P1/P2] | [一句话说明] | - 本期范围：[包含哪些功能点] - 本期不做：[明确排除的功能点及原因] - 依赖方：[依赖的系统、团队或外部条件] ## 6. 流程与业务规则 - 主流程：[步骤1 → 步骤2 → 步骤3，标注角色与系统动作] - 分支与异常流程：[条件A走哪条路径，条件B如何处理] - 业务规则：[规则编号、规则内容、生效条件] - 状态与流转：[状态列表、允许的流转方向、触发条件] ## 7. 验收标准 - 验收场景： | 编号 | 场景 | 前置条件 | 操作步骤 | 预期结果 | |---|---|---|---|---| | AC1 | [场景] | [条件] | [步骤] | [可观察结果] | - 验收方式：[演示验收 / 测试用例 / 数据核对] - 验收责任人：[角色] ## 8. 非功能约束与依赖 - 性能：[响应时间、并发量、数据量级] - 兼容性：[终端、浏览器、版本范围] - 安全与权限：[角色权限、数据可见范围] - 合规与审计：[需要留存的记录] - 外部依赖：[接口、第三方服务、上线时间窗口] ## 9. 开放问题与变更记录 - 开放问题： | 编号 | 问题 | 负责人 | 截止时间 | 状态 | |---|---|---|---|---| | Q1 | [待定问题] | [姓名] | [日期] | [待解决/已解决] | - 变更记录： | 版本 | 日期 | 变更内容 | 变更人 | 影响范围 | |---|---|---|---|---| | v0.1 | [日期] | [初稿] | [姓名] | [无] |
PRD模板字段说明
模板能否发挥作用，取决于每个字段是否被填成可判断、可验证的内容。下表逐字段说明填写目的、内容边界和判断标准，填写时可用“判断标准”一列自查。
| 字段 | 填写目的 | 内容要求 | 判断标准 |
|---|---|---|---|
| 文档信息 | 让读者知道这份文档处于什么阶段、由谁负责 | 版本号、作者、评审人、状态、更新日期、关联工作项 | 评审人覆盖研发、测试等主要协作角色；状态与实际评审进度一致 |
| 背景与问题陈述 | 回答“为什么现在要做这件事” | 业务背景、具体问题、现状数据、不解决的后果 | 问题能落到具体角色和场景；数据注明来源与统计时间 |
| 目标与成功衡量 | 回答“做完之后怎么算成功” | 业务目标、用户目标、指标及口径、非目标 | 指标有当前值、目标值和统计口径；非目标写明边界 |
| 用户与使用场景 | 回答“为谁解决、在什么情况下使用” | 目标用户、核心场景、触发条件、关键路径 | 场景可还原为具体操作序列，而非人群标签 |
| 功能范围与优先级 | 回答“这次做什么、先做什么” | 功能清单、优先级、本期范围、本期不做、依赖方 | 每个功能点有唯一编号；优先级有判断依据 |
| 流程与业务规则 | 回答“系统按什么逻辑运转” | 主流程、分支与异常、规则编号、状态流转 | 异常分支有处理方式；规则可被测试用例直接引用 |
| 验收标准 | 回答“怎样确认做对了” | 场景、前置条件、操作步骤、预期结果、验收方式 | 预期结果可观察、可判定；每条标准对应功能编号 |
| 非功能约束与依赖 | 回答“在什么条件下必须满足哪些底线要求” | 性能、兼容性、权限、合规、外部依赖 | 约束有具体数值或范围；依赖方有对接人和时间 |
| 开放问题与变更记录 | 回答“还有哪些没定、改过什么” | 问题、负责人、截止时间、状态；版本变更明细 | 开放问题都有负责人和关闭时间；变更记录可追溯到版本 |
字段之间存在依赖关系，填写顺序会影响质量。“目标与成功衡量”依赖“背景与问题陈述”中的数据，“验收标准”依赖“功能范围”和“流程与业务规则”的编号，“非功能约束”依赖“用户与使用场景”中的使用规模。填写时先完成上游字段，再写下游字段，能减少返工。
需要引用数据或证据的字段集中在三处：背景中的现状数据、目标中的指标口径、非功能约束中的性能与合规要求。这三处如果只写“提升体验”“性能良好”之类的表述，评审时无法判断，应替换为具体数值、来源或可核对的事实。常见填写偏差包括：把功能清单写成方案描述、把验收标准写成功能复述、把非目标留空、开放问题只列不跟进。逐项对照上表判断标准，可以提前发现这些问题。
必填与选填字段的划分
必填字段的判断依据是：缺少它，研发无法估算、测试无法验收、评审无法决策。按此标准，模板中大部分章节属于必填，选填部分主要服务于复杂需求或特定业务场景。
| 字段 | 划分 | 理由或适用条件 |
|---|---|---|
| 文档信息 | 必填 | 没有版本和状态，评审与变更无法追溯 |
| 背景与问题陈述 | 必填 | 决定需求是否值得做，是评审的第一判断依据 |
| 目标与成功衡量 | 必填 | 没有衡量口径，上线后无法判断效果 |
| 用户与使用场景 | 必填 | 场景决定流程与边界条件 |
| 功能范围与优先级 | 必填 | 范围与优先级是排期和裁剪的基础 |
| 流程与业务规则 | 必填（简单需求可合并到功能说明） | 规则缺失会导致实现分歧 |
| 验收标准 | 必填 | 测试与验收的直接依据 |
| 非功能约束与依赖 | 按需必填 | 涉及性能、权限、合规、外部系统时必须填写 |
| 开放问题与变更记录 | 开放问题必填，变更记录随版本累积 | 未决事项需要有人跟进；变更记录在首次修改后启用 |
| 非目标 | 选填 | 需求边界容易混淆时填写，用于防止范围蔓延 |
| 使用频率与关键路径 | 选填 | 高频功能或体验敏感型需求填写 |
| 分支与异常流程 | 选填 | 流程存在多条件分支时填写 |
| 状态与流转 | 选填 | 需求涉及多状态对象时填写 |
小需求可以裁剪，但裁剪有底线。一个只改文案或调整单个字段的需求，可以把“流程与业务规则”合并进功能说明，把“非功能约束”简化为一行结论，但背景、目标、范围、验收标准四项必须保留，否则评审无法判断价值，测试无法确认结果。复杂需求则相反，应在必填项基础上补充非目标、异常流程、状态流转和完整的非功能约束，并把验收标准拆到场景级。
裁剪后仍需保留的最低信息集可以概括为五句话：为什么做、为谁做、做什么和不做什么、按什么规则做、怎样算做完。这五句话分别对应背景、用户、范围、规则、验收五个字段，任何规模的需求文档都应能回答。
PRD模板填写示例
以下示例演示一份完整PRD的填写方式，字段与前述空白模板一一对应。示例为演示情景，数据仅用于说明写法。
文档信息：版本 v0.2，作者为产品经理，评审人包括研发负责人、测试负责人、客服主管，状态为评审中，关联需求单编号 REQ-1042。
背景与问题陈述：客服团队在处理退款申请时，需要人工在三个系统间核对订单与支付记录，平均每单耗时 6 分钟。近三个月退款工单量从每月 800 单增长到 1400 单，客服反馈高峰期积压明显。若不处理，退款平均处理时长将继续上升。
目标与成功衡量：业务目标是把退款平均处理时长从 6 分钟降到 3 分钟以内；用户目标是客服在一个页面内完成核对与提交。成功指标为“退款单平均处理时长”，当前值 6 分钟，目标值 3 分钟，统计口径为工单从受理到提交完成的时长，观察周期为上线后一个月。非目标为本次不改造支付渠道对接。
用户与使用场景：目标用户为一线客服，核心场景是收到退款申请后核对订单金额与支付流水，确认无误后提交退款。高频路径为“打开工单 → 查看核对结果 → 提交”。
功能范围与优先级：F1 退款核对信息聚合页（P0）；F2 核对结果异常提示（P0）；F3 批量提交（P2，本期不做）。本期范围为 F1 与 F2，依赖订单系统与支付系统的查询接口。
流程与业务规则：主流程为客服打开工单，系统自动拉取订单与支付记录并展示比对结果，客服确认后提交。规则 R1：订单金额与支付金额不一致时标记异常并阻止提交；规则 R2：超过 30 天未处理的工单进入待办提醒。异常流程为接口超时，此时展示重试入口并记录日志。
验收标准：AC1，前置条件为存在一笔金额一致的退款申请，操作打开工单，预期结果为 3 秒内展示比对结果且提交按钮可用；AC2，前置条件为金额不一致，预期结果为展示异常提示且提交按钮不可用；AC3，模拟接口超时，预期结果为展示重试入口。
非功能约束与依赖：核对页加载时间不超过 3 秒；仅客服角色可查看支付流水后四位；操作日志保留 180 天；依赖订单系统与支付系统接口，需在上线前完成联调。
开放问题与变更记录：Q1，异常工单是否需要通知主管，负责人为客服主管，截止时间为评审后三个工作日。变更记录：v0.1 初稿；v0.2 根据评审意见补充异常流程与 AC3，影响范围为测试用例设计。
这份示例体现了几个写法要点：目标带数值和口径，功能点带编号并被验收标准引用，规则可被测试直接转成用例，开放问题有负责人和关闭时间。评审通过后，文档状态需要从“评审中”推进到“已确认”，后续每次修改都在变更记录中留痕。在 ONES 中，PRD 可以作为需求工作项的关联文档承载，评审意见、状态流转与变更记录围绕同一工作项沉淀，研发与测试从工作项直接进入文档，减少文档与需求单脱节的情况。
模板的调整与维护方法
模板需要随团队实践迭代，但迭代本身要有规则，否则会出现多个版本并存、填写口径不一致的问题。维护工作可以按以下清单执行。
- 版本与变更记录：模板文件本身带版本号，每次调整记录变更内容、原因和生效日期；旧版本归档保留，新需求统一使用当前版本。
- 按需求类型拆分变体：当团队同时处理功能迭代、数据类需求、合规类需求时，可基于主模板拆出变体，变体只增删字段，不改变章节顺序，便于评审人形成固定阅读习惯。
- 评审反馈回收：每次评审后记录“哪个字段没写清导致追问”，按月汇总；同一字段连续多次引发追问，说明该字段的填写说明需要补充示例。
- 字段增删判断：新增字段需说明它解决了哪类反复出现的问题；删除字段需确认没有评审环节依赖它。字段数量以评审能在一轮内读完为限。
- 落地检查点：每季度抽查若干份已确认的PRD，检查必填字段完整率、验收标准与功能编号的对应率、开放问题的关闭率，用抽查结果决定下一轮模板调整方向。
模板维护的常见问题是只增不减。字段越加越多，填写成本上升，团队开始跳过字段，模板反而失效。建议每次调整只动一到两个字段，并在下一次评审中观察效果。模板的价值在于让不同作者写出的PRD具备可比较的结构，维护时应围绕这一目标做取舍，把反复出现的填写偏差转化为字段说明中的示例，而不是不断新增章节。
常见问题
PRD模板和需求规格说明书（SRS）有什么区别，能共用一份模板吗？
PRD侧重从业务和用户角度说明为什么做、为谁做、做什么，读者以产品、业务、研发、测试为主；需求规格说明书更侧重系统行为的精确描述，包括接口、数据、状态机等细节，常用于对外交付或强合规场景。两者可以共用同一份文档骨架，但PRD模板中的“背景与问题陈述”“目标与成功衡量”在规格说明书中通常简化为引用，而规格说明书需要补充更细的接口与数据定义。团队规模较小、需求以内部迭代为主时，用一份PRD模板覆盖即可；涉及外部验收或合规审计时，建议在PRD基础上单独维护规格说明。
需求很小，只改一个字段或一段文案，也要按完整模板填写吗？
不需要填满全部章节，但需要保留最低信息集：为什么做、为谁做、做什么和不做什么、按什么规则做、怎样算做完。对应到模板，就是背景、用户、范围、规则、验收五项。流程与业务规则可以合并进功能说明，非功能约束可以简化为一行结论，非目标、异常流程、状态流转等选填项可以省略。判断标准是：研发看完能估算工作量，测试看完能写出用例，评审人看完能判断是否值得做。三项都满足，裁剪就是合理的。
模板里的成功指标一定要有当前值和统计口径吗？暂时拿不到数据怎么办？
有当前值和统计口径，指标才能在上线后被验证，否则“提升体验”“提高效率”这类表述无法判断是否达成。如果暂时拿不到基线数据，可以在指标栏写明“基线待补”，同时注明补齐时间和负责人，并把补齐基线作为开放问题跟进。另一种做法是改用可观察的过程指标，例如某类工单的处理步骤数、页面跳转次数，这类指标在需求上线前就能统计。关键是把“无法衡量”的状态显式记录下来，而不是用模糊表述掩盖。
多个团队共用一份PRD模板，字段口径不一致怎么处理？
先确认差异来自需求类型还是填写习惯。功能迭代、数据类需求、合规类需求对字段的要求不同，可以基于主模板拆出变体，变体只增删字段、不改变章节顺序，评审人仍按同一路径阅读。如果差异来自填写习惯，例如有的团队把验收标准写成功能复述，应在字段说明中补充正反示例，而不是新增章节。主模板保留版本号和变更记录，各变体注明基于哪个主版本派生，主模板升级时同步评估变体是否需要跟进。
PRD写完后，评审意见和后续变更记录放在哪里比较合适？
评审意见可以就近记录在文档的开放问题表中，标明负责人和截止时间；变更记录按版本累积，写清变更内容、变更人和影响范围，便于测试判断哪些用例需要同步调整。如果团队使用需求管理工具，把PRD作为需求工作项的关联文档，评审意见、状态流转和变更记录围绕同一工作项沉淀，研发与测试从工作项直接进入文档，能减少文档与需求单脱节。在ONES中，PRD可以作为需求工作项的关联文档承载，评审与状态流转在同一工作项上完成。
