这份PRD模板以表格承载需求背景、目标与衡量、用户与场景、功能范围、需求明细、验收标准、依赖与风险、发布与变更记录八类字段，可直接复制到文档工具中填写。先完成必填项形成能支撑一次需求评审的最小版本，再按项目复杂度补充选填内容，并用变更记录维护版本。下文依次给出空白表、字段填写口径、必填与选填划分、一份登录改造的完整片段，以及模板裁剪与长期维护规则。
要点总览（TL;DR）
- 模板由文档信息表与八类字段表组成：需求背景、目标与衡量、用户与场景、功能范围、需求明细、验收标准、依赖与风险、发布与变更记录，可整表复制填写。
- 最小可用PRD只需五类必填字段：背景、目标、范围、需求明细、验收标准；满足这些即可发起一次需求评审，其余字段随项目推进补齐。
- 需求明细按“触发条件—操作—结果”写，一条需求对应一个可验收的行为，验收标准写成验收人可直接判断的句子。
- 模板按项目类型裁剪：外部产品需求保留全部字段，内部工具可简化用户与场景，紧急修复先填四类核心字段、发布后一周补齐。
- 版本号分主次两级，实质变更升主版本、文字修正升次版本，每次修改在变更记录表追加一行并注明影响的需求编号。
可复制空白PRD模板
模板由两部分组成：文档信息区记录这份PRD的身份与状态，八类字段表承载需求内容。复制时保留表头，按行填写；字段名称与第二节的说明、第四节的示例保持完全一致，便于团队对照检查。
文档信息表
| 项目 | 填写内容 |
|---|---|
| 文档名称 | |
| 文档编号与版本 | |
| 产品/业务线 | |
| 负责人 | |
| 参与角色 | |
| 创建日期 | |
| 当前状态 | 草稿 / 评审中 / 已确认 / 已上线 |
| 关联需求或项目 |
八类字段表
| 字段类别 | 填写要点 | 内容 |
|---|---|---|
| 1. 需求背景 | 问题现状、触发原因、不做的后果 | |
| 2. 目标与衡量 | 业务目标、可量化指标、观察周期 | |
| 3. 用户与场景 | 目标用户、使用场景、当前替代做法 | |
| 4. 功能范围 | 本期做什么、明确不做什么 | |
| 5. 需求明细 | 逐条需求，见下方明细表 | |
| 6. 验收标准 | 每条需求的通过条件 | |
| 7. 依赖与风险 | 外部依赖、技术约束、风险与应对 | |
| 8. 发布与变更记录 | 发布计划、变更历史，见下方记录表 |
需求明细表
| 需求编号 | 需求名称 | 需求描述 | 优先级 | 验收标准 | 负责人 | 状态 |
|---|---|---|---|---|---|---|
发布与变更记录表
| 版本号 | 日期 | 变更人 | 变更内容 | 影响范围 | 评审结论 |
|---|---|---|---|---|---|
字段说明：每个字段填什么、写到什么颗粒度
字段说明解决“有这一栏但不知道怎么写”的问题。下表给出每个字段的含义、填写口径和示例片段，示例片段只示意写法，实际内容按项目替换。
| 字段 | 含义 | 填写口径 | 示例片段 |
|---|---|---|---|
| 需求背景 | 为什么现在要做这件事 | 写清现状问题、触发来源（数据、用户反馈、业务规划）以及不处理的后果，控制在三到五句 | 近三个月登录失败工单占比12%，集中在验证码环节 |
| 目标与衡量 | 做完之后要达成什么 | 一个业务目标配一到两个可量化指标，注明统计口径与观察周期 | 登录成功率从92%提升至97%，上线后观察四周 |
| 用户与场景 | 谁在什么情况下使用 | 列出主要用户角色与典型场景，写清当前替代做法 | 移动端用户在弱网环境下登录，目前只能反复重试 |
| 功能范围 | 本期边界 | 分“本期包含”和“本期不包含”两栏，不包含项写清后续安排 | 本期包含验证码改版；不包含第三方登录接入 |
| 需求明细 | 逐条可执行的需求 | 一条需求对应一个可验收的行为，描述写触发条件、操作与结果 | 用户连续输错三次验证码后，展示图形验证码 |
| 验收标准 | 需求通过的条件 | 写成可观察、可判断的陈述，避免“体验良好”这类主观表述 | 连续输错三次后出现图形验证码，第四次输错锁定60秒 |
| 依赖与风险 | 外部条件与不确定项 | 逐条列出依赖方、交付时间、风险等级与应对措施 | 依赖短信服务商接口升级，预计第2周交付 |
| 发布与变更记录 | 版本演进 | 每次修改追加一行，写清版本号、变更内容和影响范围 | v1.1 调整验证码触发次数，影响需求明细第2条 |
需求明细的写法要求
需求明细是整份PRD的核心，颗粒度直接决定评审效率。描述按“触发条件—操作—结果”组织，一条需求只描述一个可验收的行为；优先级使用统一档位（如P0必做、P1本期做、P2可延后），并在团队内约定每档的含义；验收标准与需求一一对应，写成测试人员或验收人可以直接判断的句子。需求名称用动宾短语，避免“优化登录”这类无法判断完成与否的表述。
必填与选填：最小可用PRD与完整版的分界
最小可用版本的判定标准是：能支撑一次需求评审，评审参与者据此可以判断做不做、做什么、怎么算做完。达到这个标准需要背景、目标、范围、需求明细和验收标准五类字段；其余字段可以随项目推进补充。
| 字段 | 必填/选填 | 理由与适用场景 |
|---|---|---|
| 需求背景 | 必填 | 评审首先要判断值不值得做，缺少背景无法决策 |
| 目标与衡量 | 必填 | 没有衡量指标，上线后无法判断是否达成 |
| 功能范围 | 必填 | 明确边界，防止评审中范围反复扩张 |
| 需求明细 | 必填 | 评审的主体内容 |
| 验收标准 | 必填 | 决定需求何时算完成，缺失会导致验收争议 |
| 用户与场景 | 选填 | 面向新用户群体或场景复杂时建议填写；内部工具类需求可简化 |
| 依赖与风险 | 选填 | 涉及外部团队、第三方服务或技术不确定性时必填，独立小需求可后补 |
| 发布与变更记录 | 选填（首次创建时） | 首次评审可只写发布计划；文档进入修改阶段后必须开始记录 |
最小版本清单可以概括为：文档信息表填完、背景与目标各一段、范围分两栏、需求明细至少一条且带验收标准。满足这些条件即可发起评审，其余字段在评审意见收敛后补齐。
填写示例：一份完整的登录改造PRD片段
以下片段演示各字段如何协同表达一条需求，字段顺序与空白模板一致。示例为演示情景，数据仅用于说明写法。
| 字段 | 填写内容 |
|---|---|
| 文档名称 | 移动端登录流程改造 PRD |
| 文档编号与版本 | PRD-LOGIN-001 v1.0 |
| 负责人 | 产品经理 A |
| 当前状态 | 评审中 |
| 需求背景 | 近三个月登录失败工单占客服工单的12%，其中验证码环节占七成；现有验证码在弱网下加载慢，用户反复重试后放弃登录。 |
| 目标与衡量 | 登录成功率从92%提升至97%；验证码相关工单下降一半；上线后观察四周，按周统计。 |
| 用户与场景 | 移动端用户在通勤弱网环境下登录；当前做法是反复点击重试，部分用户转向网页端。 |
| 功能范围 | 本期包含：验证码改版、错误提示优化。本期不包含：第三方登录接入，列入下季度规划。 |
| 依赖与风险 | 依赖短信服务商接口升级，预计第2周交付；风险为升级延期导致联调顺延，应对方案是先用测试环境模拟。 |
需求明细行
| 需求编号 | 需求名称 | 需求描述 | 优先级 | 验收标准 | 负责人 | 状态 |
|---|---|---|---|---|---|---|
| R-01 | 验证码触发规则调整 | 用户连续输错三次密码后，展示图形验证码；第四次输错锁定账号60秒 | P0 | 连续输错三次后出现图形验证码；第四次输错提示锁定并倒计时60秒；倒计时结束后可重新尝试 | 后端 B | 待开发 |
| R-02 | 错误提示文案优化 | 登录失败时按失败原因展示对应提示，替代统一提示语 | P1 | 密码错误、验证码错误、账号锁定三种情况分别展示不同文案，文案与需求文档附表一致 | 前端 C | 待开发 |
这份片段中，背景解释了R-01的必要性，目标给出了上线后的判断依据，验收标准与需求明细一一对应，依赖与风险说明了排期约束。评审时参与者可以沿着“问题—目标—需求—验收”这条线逐项确认。
调整与维护：按团队情况裁剪字段并管理版本
模板长期使用后容易出现两种问题：字段越加越多导致填写负担过重，或者长期不更新导致与实际评审流程脱节。裁剪和维护需要明确规则和责任人。
按项目类型裁剪字段
- 面向外部用户的产品需求：保留全部八类字段，用户与场景、依赖与风险通常需要展开。
- 内部工具或流程优化：可简化用户与场景，合并为一段说明；依赖与风险在无外部依赖时可只写一句“无外部依赖”。
- 紧急修复类需求：先填背景、范围、需求明细和验收标准四类，发布后一周内补齐其余字段。
- 探索性需求：目标与衡量可先写假设指标，评审时标注“待验证”，验证后再更新。
裁剪的原则是保留能支撑当前评审决策的字段，删减的字段在文档信息表中注明原因，便于后续追溯。
维护责任人与评审节奏
模板由产品团队指定一名维护人，负责收集填写中的问题并定期修订。建议每季度检查一次：统计哪些字段经常空置、哪些字段在评审中被反复追问，据此增删或改写填写口径。模板修订后同步更新字段说明和示例，避免三处不一致。跨团队使用时，维护人还需与研发、测试确认验收标准的写法是否满足他们的判断需要。
变更记录与版本号规则
版本号建议采用主次两级：需求范围、验收标准发生实质变化时升主版本号（如v1.0到v2.0）；文字修正、补充说明升次版本号（如v1.0到v1.1）。每次修改在变更记录表中追加一行，写清变更内容与影响的需求编号，评审结论栏记录当次评审的通过或退回意见。这样任何人拿到文档都能看到它经历了哪些调整。
PRD定稿进入评审和执行阶段后，需要与需求条目、评审记录放在一起管理。ONES Wiki 支持页面模板库，可将这份表格固化为制式模板重复使用；页面组可关联项目，使需求与文档互相对应；文档记录所有页面版本，支持随时查看与回滚，便于变更记录与实际内容保持一致。团队可按自身流程决定哪些文档进入该系统管理。
常见问题
团队规模小、需求数量少，还需要维护完整的八类字段吗？
可以先从最小可用版本起步，只填背景、目标、范围、需求明细和验收标准五类。需求数量少时，用户与场景、依赖与风险往往一两句话就能说清，直接写在对应字段里即可，不必为了填满表格而扩写。等需求开始涉及外部团队或第三方服务，再把依赖与风险展开成逐条清单。
需求评审时被要求补充内容，应该改原文档还是另起一份？
在原文档上修改并追加变更记录，不要另起新文档。评审意见收敛后，把调整写进对应字段，同时在变更记录表中新增一行，写明版本号、变更内容和影响的需求编号。这样评审参与者下次打开的还是同一份文档，能看到完整演进过程，避免多份文件并存导致版本混乱。
验收标准写到什么程度才算合格？
判断标准是验收人或测试人员不看其他说明也能直接判断通过与否。写成可观察的陈述，例如“连续输错三次后出现图形验证码，第四次输错锁定60秒”，避免“体验流畅”“提示友好”这类主观表述。如果一条验收标准需要再解释才能执行，说明还需要拆细。
PRD定稿后，文档和需求条目怎么保持对应？
常见做法是让文档与需求条目互相引用：文档信息区记录关联的需求或项目编号，需求条目中回链到PRD页面。使用 ONES Wiki 时，页面组可关联项目，使需求与文档互相对应；文档记录所有页面版本，支持随时查看与回滚，变更记录与实际内容更容易保持一致。具体采用哪种承载方式，按团队现有流程决定。
模板用了一段时间发现字段太多，怎么精简才不影响评审？
先统计近几次评审中哪些字段经常空置、哪些字段被反复追问，空置且不影响决策的字段可以合并或删除，被追问的字段则要改写填写口径而不是删掉。裁剪后在文档信息表中注明删减原因，并同步更新字段说明和示例，保持三处一致。建议每季度检查一次，由指定维护人牵头修订。
