填写PRD模板可以按一条固定顺序推进：先写需求背景与目标，再补用户与场景、功能范围、流程与规则，最后落到验收标准、优先级与依赖。本文提供一份可直接复制的空白模板、逐字段说明表、必填与选填清单，并用一个完整示例演示从空白到可评审成稿的填写过程，字段口径在模板、说明和示例中保持一致。
要点总览（TL;DR）
- 填写顺序固定：背景与目标→用户与场景→功能范围→流程与规则→验收标准→优先级与依赖，按此顺序推进可减少返工。
- 必填字段包括文档信息、问题描述与业务目标、目标用户与使用场景、本期与不在本期范围、功能点与主流程与业务规则、验收标准、优先级；缺失即构成评审阻断项。
- 暂不确定的内容统一写成“【待确认】+内容+责任人+确认时间”，避免使用没有责任人的“TBD”。
- 验收标准要逐条可执行、可观察，并与功能点、业务规则一一对应，评审时可直接据此设计测试用例。
- 模板按需求类型裁剪并做版本记录，评审中反复被追问的问题应回流到模板字段和填写说明中。
可直接复制的PRD空白模板
下面这份模板按需求文档的阅读顺序排列，复制到文档工具后，把方括号中的占位内容替换为实际信息即可。模板只给结构和占位符，各字段的写法在下一节展开。
# [需求名称] ## 一、文档信息 - 需求名称：[一句话概括要做的需求] - 文档版本：[V0.1 / V1.0] - 作者：[姓名] - 评审人：[产品、研发、测试、设计等角色姓名] - 更新日期：[YYYY-MM-DD] - 变更记录：[版本号 | 日期 | 修改人 | 修改内容] ## 二、背景与目标 - 问题描述：[当前存在什么问题，谁在什么情况下遇到] - 业务目标：[本次需求希望达成的业务结果] - 成功衡量：[上线后用哪个指标、在什么时间窗口内、达到什么水平算成功] ## 三、用户与场景 - 目标用户：[角色、规模或典型特征] - 使用场景：[用户在什么时机、为什么目的使用] - 现有做法：[当前如何解决，痛点在哪里] ## 四、功能范围 - 本期范围：[本次要交付的功能点清单] - 不在本期范围：[明确排除的内容及原因] ## 五、功能描述 - 功能点：[功能名称与一句话说明] - 主流程：[从入口到完成的步骤] - 业务规则：[判断条件、计算方式、状态变化] - 异常处理：[失败、超时、无权限、数据为空时如何处理] ## 六、验收标准 - [可验证的通过条件，逐条编号] ## 七、优先级与依赖 - 优先级：[P0 / P1 / P2，并说明依据] - 关联需求：[相关需求编号或名称] - 外部依赖：[依赖的系统、接口、数据或团队] - 风险：[可能影响交付的因素及应对方式]
这份模板覆盖了需求评审时最常被追问的七类信息。团队如果已有固定的文档头格式，可以把“文档信息”区替换为现有格式，其余部分保持字段不变，便于横向比较不同需求的完整度。
每个字段写什么：PRD字段说明表
字段说明解决的是“写到什么程度算填好”。下表按字段给出填写目的、颗粒度要求和常见错误，并标出与其他字段的对应关系，填写时可以对照检查。
| 字段 | 填写目的 | 颗粒度要求 | 常见错误 | 对应关系 |
|---|---|---|---|---|
| 需求名称 | 让人一眼知道这份文档讲什么 | 一句话，包含对象和动作，控制在20字左右 | 写成“优化需求”“系统改造”这类无法区分对象的名称 | 与功能范围的首个功能点一致 |
| 文档版本与变更记录 | 支撑评审和后续追溯 | 每次评审后递增版本号，记录修改人和修改内容 | 只改内容不记版本，评审意见无法回溯 | 与更新日期同步维护 |
| 问题描述 | 说明为什么值得做 | 写清谁、在什么场景、遇到什么具体问题，附数据或反馈来源 | 只写“用户体验不好”，没有对象和证据 | 与目标用户、现有做法互相印证 |
| 业务目标 | 对齐需求的价值判断 | 一条需求对应一到两个目标，避免罗列 | 目标写成功能描述，如“增加一个导出按钮” | 与成功衡量成对出现 |
| 成功衡量 | 让上线效果可判断 | 指标、口径、时间窗口三要素齐全 | 只写“提升转化率”，没有基线值和观察周期 | 与业务目标一一对应 |
| 目标用户 | 界定需求服务对象 | 角色加典型特征，必要时说明规模 | 写“所有用户”，导致场景无法收敛 | 与使用场景、权限规则关联 |
| 使用场景 | 还原真实使用过程 | 按“什么时机—做什么—期望结果”描述 | 把功能操作步骤当成场景 | 与主流程衔接 |
| 现有做法 | 说明替代方案和迁移成本 | 写清当前工具、流程和主要不便 | 省略不写，导致上线后无人迁移 | 与不在本期范围共同界定边界 |
| 本期范围与不在本期范围 | 控制交付边界 | 逐条列出功能点，排除项写明原因 | 只写本期范围，评审时反复确认边界 | 与功能点、优先级对应 |
| 功能点 | 拆解可开发、可测试的单元 | 每个功能点可独立验收，命名统一 | 一个功能点里混入多个不相关操作 | 与验收标准逐条对应 |
| 主流程 | 说明操作路径 | 按步骤编号，标出分支和结束状态 | 只写正常路径，遗漏分支 | 与业务规则、异常处理配套 |
| 业务规则 | 固定判断和计算逻辑 | 条件、取值、结果写全，边界值明确 | 用“合理处理”“视情况而定”代替规则 | 与异常处理共享同一套状态定义 |
| 异常处理 | 覆盖失败路径 | 列出触发条件、提示内容和后续动作 | 只写“给出提示”，不写提示后用户能做什么 | 与验收标准中的异常用例对应 |
| 验收标准 | 作为测试和验收依据 | 每条可执行、可观察，包含前置条件和预期结果 | 写成“功能正常”“体验流畅” | 与功能点、业务规则一一覆盖 |
| 优先级 | 支撑排期取舍 | 给出级别和判断依据，如影响用户范围或合规要求 | 全部标为最高优先级 | 与关联需求、依赖共同决定排期 |
| 关联需求与外部依赖 | 暴露协作界面 | 写明依赖对象、提供方和期望时间 | 依赖只写系统名，不写接口和时间 | 与风险条目对应 |
| 风险 | 提前暴露不确定性 | 写清风险描述、影响和应对措施 | 把已知未决问题藏在正文里 | 与待确认事项、依赖关联 |
填写时有一个通用判断标准：换一个没参与讨论的研发或测试来读，能否据此判断做什么、不做什么、怎么算做完。如果某段内容读完仍需要当面追问，说明颗粒度还不够。
必填与选填：哪些字段不能空
PRD模板中的字段并非同等重要。进入评审前，必填字段应当全部有内容；确实无法确定的，要写明待确认事项、责任人和确认时间，不能留空。
必填字段清单
- 需求名称、文档版本、作者、评审人、更新日期：评审和后续追溯的基础信息，缺失会导致文档无法定位责任人。
- 问题描述、业务目标：决定需求是否值得投入，缺失时评审无法判断价值。
- 目标用户、使用场景：缺失会导致方案无法验证是否覆盖真实使用过程。
- 本期范围与不在本期范围：两者同时填写才能界定交付边界，只写其一容易在评审中反复拉扯。
- 功能点、主流程、业务规则：研发和测试据此估算与设计用例，缺失会直接阻断排期。
- 验收标准：没有验收标准的需求无法判定完成，属于评审阻断项。
- 优先级：影响排期顺序，缺失时需求无法进入排期池。
选填字段的适用情形
成功衡量在探索型需求或内部工具类需求中可以简化，但仍建议给出一个可观察的判断依据。现有做法在全新场景、无存量用户时可以不写。异常处理在纯展示类、无状态变化的功能中可以精简，涉及数据写入、支付、权限的功能则应当补齐。关联需求与外部依赖在没有跨团队协作时可以标注“无”，风险在需求确定性高时可以只保留一条总体说明。
暂不确定字段的标注方式
统一使用“【待确认】+ 待确认内容 + 责任人 + 期望确认时间”的格式，例如“【待确认】导出文件上限，责任人：产品经理，确认时间：评审后两个工作日内”。这样评审时能快速识别未决项，也便于会后跟踪。避免使用“TBD”“待定”这类没有责任人和时间的写法。
评审前的完整性检查
- 必填字段逐项有内容，无空白项。
- 所有【待确认】项都有责任人和时间，且不影响本期核心流程。
- 功能点与验收标准数量对应，没有无验收标准的功能点。
- 不在本期范围有明确条目，排除原因可读。
- 版本号与变更记录一致，评审人名单完整。
完整填写示例：一个需求从空白到成稿
以下示例为演示情景，用于说明各字段的填写方式，不代表真实项目数据。需求场景是某协作工具为项目管理员增加“批量导出任务清单”能力。
背景与目标填写
问题描述填写为：“项目管理员在月度复盘时需要整理任务完成情况，目前只能逐页截图或手动复制，单个项目约200条任务，整理一次耗时约1小时，且容易遗漏。”业务目标填写为：“让管理员能一次性导出项目任务清单，减少月度复盘的数据整理时间。”成功衡量填写为：“上线后一个月内，使用导出功能的项目管理员占活跃管理员的比例达到30%以上，单次整理时间下降到10分钟以内。”
功能范围与业务规则填写
本期范围填写为：“任务列表页增加导出入口；支持按当前筛选条件导出；导出格式为表格文件；导出内容包含任务名称、负责人、状态、截止日期。”不在本期范围填写为：“不支持跨项目合并导出，原因是涉及权限校验范围扩大，另行评估。”业务规则填写为：“单次导出上限5000条，超出时提示缩小筛选范围；无导出权限的角色不显示入口；导出文件保留7天。”异常处理填写为：“导出超时给出重试提示；数据为空时提示调整筛选条件。”
验收标准写法
- 具备导出权限的管理员在任务列表页可见导出入口，无权限角色不可见。
- 按状态筛选后导出，文件中的任务与页面筛选结果一致。
- 导出任务数超过5000条时，页面提示缩小筛选范围，不生成文件。
- 导出完成后7天内可重复下载，超过7天提示文件已过期。
优先级、依赖与风险填写
优先级填写为“P1，依据是影响全部项目管理员的高频操作，但不阻塞核心业务流程”。关联需求填写为“任务列表筛选优化（已完成）”。外部依赖填写为“依赖文件存储服务的下载链接有效期配置，由平台团队提供，期望在本期开发第二周前确认”。风险填写为“大数据量导出可能影响服务性能，应对方式是限制单次导出条数并做异步生成”。
这份示例中，功能点、业务规则和验收标准逐条对应，评审时可以直接按验收标准设计测试用例。团队把这类文档沉淀为固定模板后，可以在文档工具中复用。ONES Wiki 提供页面模板库，可一键创建制式化文档模板；页面组可关联项目，使需求与文档互相对应；文档实时同步并记录页面版本，支持查看与回滚，便于评审后按版本维护。将模板中的功能点拆成需求条目进入排期时，ONES Assistant 可基于项目、工作项和 Wiki 页面等上下文，把 PRD 拆解为需求和任务，具体能力以实际开通的套餐与版本为准。
模板的调整与长期维护方法
模板的价值在于稳定口径，而非字段越多越好。团队可以按需求类型裁剪字段，并通过版本记录和评审反馈让模板逐步贴合实际业务。
按需求类型裁剪字段
可以先把需求分为三类：面向外部用户的功能需求、内部效率工具需求、合规或缺陷修复类需求。功能需求保留完整模板；内部工具需求可以精简成功衡量和现有做法；合规与缺陷修复类需求可以压缩功能描述，但问题描述、影响范围和验收标准必须保留。裁剪的原则是：删掉不影响判断价值和验收的字段，保留决定做不做、做多少、算不算做完的字段。
模板版本与变更记录
模板本身也应有版本号。每次调整字段时，在模板文件头部记录版本号、调整内容、生效日期和适用范围，例如“V1.2，新增外部依赖字段，适用于跨团队需求”。已进入开发的需求沿用其创建时的模板版本，避免评审中途字段口径变化。
评审反馈回流模板
评审中反复被追问的问题，往往说明模板缺少对应字段或字段说明不清。可以在每次评审后记录两类信息：被追问三次以上的问题、因字段缺失导致的返工。每月汇总一次，判断是补充字段、修改填写说明，还是调整必填清单。调整后在新需求中试用一到两个迭代，再决定是否全面推行。
与需求状态流转的衔接
模板填写应与需求状态对应：草稿阶段允许存在待确认项；进入评审时必填字段完整；评审通过后冻结版本并记录评审结论；开发过程中需求变更时递增版本并同步关联需求与依赖。这样模板不只是一份文档格式，而是需求从提出到交付过程中的检查依据。
常见问题
PRD模板里的“成功衡量”在什么情况下可以简化？
探索型需求或内部效率工具类需求，往往在上线前难以给出稳定的指标基线，这时可以简化成功衡量的写法，但仍建议保留一个可观察的判断依据，例如使用频次、覆盖的项目数量或人工整理时间的下降幅度。面向外部用户、涉及转化或收入的功能需求，则应写全指标、口径和时间窗口三要素。简化不等于留空，评审时需要能说清上线后用什么来判断这件事做成了。
评审时必填字段还没填完，应该先评审还是先补文档？
建议先补齐必填字段再进入评审。问题描述、业务目标、范围边界、功能点与验收标准这几类字段缺失时，评审很难判断需求价值和交付边界，容易变成讨论“要不要做”而不是“怎么做”。如果确实存在未决信息，可以带着标注清楚的【待确认】项进入评审，但前提是这些未决项不影响本期核心流程，且每项都有责任人和确认时间。评审通过后应冻结版本，后续变更递增版本号并同步记录。
同一个团队有功能需求、内部工具需求和缺陷修复，需要维护几套模板？
通常维护一套主模板加少量裁剪规则即可，不必为每类需求各建一套完整模板。主模板保留全部字段，再按类型说明哪些字段可以精简：功能需求使用完整模板；内部工具需求可精简成功衡量和现有做法；缺陷修复与合规类需求可压缩功能描述，但问题描述、影响范围和验收标准保留。裁剪规则写进模板说明并记录版本，新成员拿到模板时能直接判断自己这类需求该填哪些字段。
模板调整后，已经在开发中的需求要不要按新模板重写？
一般不需要。已进入开发的需求沿用其创建时的模板版本，避免评审中途字段口径变化导致前后内容对不上。新模板从下一个需求或下一个迭代开始适用，并在模板头部记录版本号、调整内容、生效日期和适用范围。如果新模板补充的字段对在研需求确实关键，例如新增了外部依赖或风险条目，可以单独补充这几项，其余部分保持原版本结构。
PRD写完后，怎么和需求条目、评审记录对应起来？
常见做法是让文档与需求条目保持可追溯的对应关系：文档中每个功能点对应一个需求条目，条目上记录优先级、负责人和排期，文档版本与评审结论一并留存。ONES Wiki 提供页面模板库，可一键创建制式化文档模板；页面组可关联项目，使需求与文档互相对应；文档实时同步并记录页面版本，支持查看与回滚，便于评审后按版本维护。将模板中的功能点拆成需求条目进入排期时，ONES Assistant 可基于项目、工作项和 Wiki 页面等上下文，把 PRD 拆解为需求和任务，具体能力以实际开通的套餐与版本为准。
