简介：一份经典的产品需求文档（PRD）模板，面向产品经理、需求分析人员及需要规范需求输出的项目团队，用于解决PRD结构不统一、修改记录难追溯、需求沟通缺依据等问题。模板以单份doc文件交付，压缩包约73KB，包含文档基本信息、接收人签字、修改记录，以及概要介绍、项目概述、产品环境、产品需求、用例和场景、优先级与发布计划、风险评估、参考资料等章节，目录层级清晰，便于按模块填写与评审。其价值在于把需求背景、市场与技术问题、目标客户、约束与假设、功能及非功能需求串联起来，并保留版本、修改原因、日期与责任人等追踪信息，适合直接套用或按团队规范微调。已有3199人学习，可作为产品需求文档撰写、评审与团队协作的参考底稿。

1. 需求散在群聊里，开发做到一半才发现对不上

某团队做过一个内部工具，需求靠口头和群消息传递，联调阶段才发现同一个字段两个人理解的口径不一样，返工两周。这类翻车往往不是写得不够细，而是缺一份所有人都按同一位置找信息的文档。这份经典 PRD 模板干的就是这件事：用固定骨架把“为什么做、给谁做、在什么条件下做、做成什么样、依据是什么”钉在纸面上，再用 PR ID 和修改记录让每条需求可追溯。它适合产品经理、项目经理，以及需要接手别人需求的开发，也适合想把“产品需求模板通用”这套结构沉淀成团队规范的小团队。

2. 五段式骨架：先定结构再填内容，顺序不能颠倒

2.1 先定骨架的理由：五个章节其实是一条因果链

很多人拿到模板先填“产品需求”那章，因为那章看起来最像干活的地方，结果写到一半发现目标客户没定义清楚，功能需求里全是“用户可以看到……”这种没法验收的句子。这份模板的顺序是有讲究的：概要介绍回答“为什么值得做”，项目概述回答“做给谁”，产品环境回答“在什么条件下做”，产品需求回答“做成什么样”，支持信息回答“依据是什么、和现有体系怎么衔接”。

按这个顺序推进，每一章的输出都是下一章的输入。举个具体例子，1.3 产品问题里写“现有方案在批量导入时没有失败重试”，4.2 功能需求里就能落一条“导入任务失败后支持按批次重试，最多三次”，PR ID 记为 IMP-003。反过来，如果先写功能需求，很容易写成功能清单，评审时没人能判断这条需求该不该进这一期。

我在实际项目里一般会强制自己按目录顺序走一遍，哪怕某一章只写三行，也不留空。留空的章节在评审时最容易被追问，而追问往往发生在会议现场，来不及补材料。还有一个隐性好处：五章结构本身就是一次自检清单，写完 1.2 市场问题你会发现有些假设根本没有数据支撑，这时候回头补调研比开发阶段返工便宜得多。

这份模板的五个一级章节不是随便凑的，它对应的是需求从模糊到可执行的一条收敛路径。理解这一点，后面填表才知道每张表在拦什么问题。

2.2 概要介绍：1.1 到 1.5 每节只回答一个问题

概要介绍下面有五个小节，很多人把它们写成一段话拆成五段，读起来全是重复。正确的用法是每节锁定一个问题，答完就停。

1.1 文档摘要写给没时间的人看。三到五句话说清三件事：产品是什么、解决谁的什么问题、这一期明确不做什么。“不做什么”这半句最容易被省略，但它是后面砍需求时最有力的依据。我习惯把摘要控制在两百字以内，超过就说明还没想清楚。

1.2 市场问题写外部证据，不写感受。数据来源、调研时间、样本量这三样至少要有两样，否则评审时一句“这个结论哪来的”就能把整章问穿。模板里这一节只有一行标题，很多人就随手写“市场前景广阔”，这种句子在文档里等于没写。

1.3 产品问题写现有方案的缺口。注意是缺口，不是竞品功能罗列。合格的写法是“现有工具在处理 X 场景时，用户需要手动做 Y，平均耗时 Z”，有场景、有动作、有量级。

1.4 技术问题写风险，不写方案。这一节的作用是让技术负责人提前看到坑，比如依赖的外部接口有调用频率限制、历史数据存在格式不一致。技术选型放到 4.13 方案技术概述里去写，两处混在一起，评审时容易被拉进架构讨论，把需求评审开成技术评审。

1.5 产品概念用一句话说清价值主张，句式可以是“给谁，在什么场景下，提供什么，相比现有方案省掉什么”。这句话后面会反复被引用，值得多改几遍。

提示：概要介绍整章建议控制在一页到两页。超过两页通常意味着把项目概述的内容提前写了，后面会重复。

2.3 项目概述与产品环境：把目标客户和边界条件写死

2.2 目标市场描述和 2.3 目标客户描述这两节，最常见的失败写法是人群画像式的描述，比如“25 到 40 岁的职场人士”。这种描述没法指导任何设计决策，因为范围太宽。可验证的写法是“场景 + 行为 + 现有替代方案”：用户在什么情况下会打开这个产品，打开前他通常在用什么东西凑合，凑合的成本是什么。

我一般会要求至少写清两类客户：主要客户和次要客户，并说明这一期优先满足哪一类。只写一类也可以，但要写明为什么排除另一类，否则评审时一定会有人问“那小 B 客户不管了吗”。

2.4 产品环境这一章只有两节，但含金量很高。约束条件列的是硬边界：预算上限、上线时间窗、必须遵守的行业规范、必须对接的既有系统。这些条件写进文档以后，后面任何一条需求如果突破约束，就有了明确的讨论依据。假设条件列的是“如果它不成立，方案就失效”的前提，比如“假设存量数据可以在两周内完成清洗”“假设第三方接口在下半年不调整返回结构”。

假设条件容易被写成愿望清单，区别在于：假设必须配一句“不成立时的应对”。模板里没有强制这一栏，我通常会在每条假设后面手动补一句，写不下就另起一行。没有应对措施的假设，本质上是一个没被记录的风险。

2.4 支持信息：别把参考资料写成摆设

第 5 章支持信息包含文档假设、参考资料、产品体系三节。参考资料这一节很多人只贴几个链接，过两个月自己都点不开。比较实用的做法是给每条参考资料标注三样东西：文件名称、获取位置、与本 PRD 的关联章节。关联章节这一列是关键，它让后来接手的人知道该去哪一节对照。

产品体系这一节写的是这个产品在整体产品矩阵里的位置，和哪些系统有上下游关系。这一节写清楚，能省掉大量“这个功能为什么不做在我们系统里”的重复解释。文档假设则记录本文档编写时的前提，比如“本文档不包含运营后台的详细设计，另行成文”。

3. 需求条目化：PR ID、MR ID 与优先级表怎么落

3.1 功能需求表：PR ID 与 MR ID 是两条不同的线

4.2 功能需求这一节，模板给的字段是需求描述、PR ID、实现目标、约束条件、MR ID。五个字段看着简单，填错的人不少。

需求描述要写成可验收的句子，包含触发条件、动作、预期结果。比如“当用户上传的文件超过 50MB 时，系统拒绝上传并提示单文件上限”，这句话里有条件、有动作、有结果，测试可以直接照着写用例。反过来，“支持大文件上传”就不是需求，是愿望。

PR ID 是需求编号，建议按模块前缀加三位序号，例如订单模块用 ORD-001、ORD-002，导入模块用 IMP-001。前缀控制在三到五个字母，全团队统一一张前缀表，避免两个人分别用 ORDER 和 ORD。编号一旦分配就不要回收，需求作废也保留编号并标注状态，这样历史讨论记录才有锚点。

MR ID 是这条需求对应的研发任务或里程碑编号，作用是把需求文档和研发侧的任务系统对上。这两条线分开以后，一个 PR 可能拆成多个 MR，一个 MR 也可能覆盖几条小需求。实际项目中经常出现多对多，如果只保留一个编号字段，后面统计覆盖率就会很痛苦。

实现目标这一列最容易被敷衍。它和需求描述的区别是：需求描述说“做什么”，实现目标说“做完以后哪个指标会变”。哪怕写不出量化指标，也要写出可观察的变化，比如“客服关于导入失败的问询量下降”。这一列在需求优先级打架的时候是唯一的裁判依据。

约束条件这一列不要轻易写“无”。写“无”意味着这条需求不受任何限制，评审时反而会被重点关照。确实没有特殊约束时，写“沿用 3.2 全局约束”也能表明你考虑过。

3.2 非功能需求：十条线里哪几条最容易被糊弄

4.3 到 4.11 这一串小节覆盖开发需求、兼容性需求、性能需求、国际性需求、文档需求、外观需求、发布需求、支持和培训需求、其它需求。数量多，实际写起来每一节两三行就够，但有三节不能糊弄。

性能需求必须可度量。合格的写法带三个参数：操作、指标、负载条件。例如“列表页在 10 万条数据量级下，95 分位响应时间不超过 800 毫秒”。只写“响应要快”等于没写，测试也没法判定通过与否。如果暂时给不出精确值，至少给出量级和测量方法，后续再校准。

兼容性需求要写明具体的环境清单，包括浏览器及最低版本、操作系统、屏幕分辨率的支持范围。这一节写含糊，上线后收到的兼容性缺陷会成倍增加。我的习惯是直接列一张支持矩阵，明确写“不支持”的范围，比只写支持范围更省事。

发布需求经常被忽略，但它决定了上线当天顺不顺。这一节至少要写清发布方式、灰度范围、回滚条件。回滚条件尤其重要，比如“核心接口错误率连续五分钟超过 1% 即触发回滚”，有了这句话，上线当晚值班的人不用临时开会决策。

国际性需求如果这一期不做，也要明确写“本期仅支持简体中文，文案不进入多语言资源文件”，避免开发按国际化标准做了一套用不上的东西，或者反过来把中文硬编码进代码后面改不动。

3.3 需求概要表：类别与优先级怎么定

4.14 产品需求概要表是整份文档的索引，字段是 PR ID、实现目标、约束条件、MR ID、类别、优先级。它和 4.2 的功能需求表信息有重叠，区别在于概要表是横向汇总，方便评审时一屏看完所有需求。

类别这一列建议固定几个枚举值，比如功能、性能、合规、体验。枚举值不统一，后面按类别统计工作量就没法做。我在项目里一般会要求类别和 4.x 的章节对应，功能类对应 4.2，性能类对应 4.5，这样从概要表能直接跳回详细描述。

优先级不要只用高中低，建议用 P0 到 P3 并给出定义：

优先级定义写进文档的好处是，评审时讨论的是“这条算 P1 还是 P2”，而不是“这条重不重要”。前者有判断标准，后者只能靠嗓门。

概要表填完以后做一次交叉检查：P0 需求的数量如果超过总需求的三成，说明优先级普遍虚高，需要压缩；如果某条 P0 没有对应的 MR ID，说明研发侧还没排期，上线风险要提前暴露。

4. 修改记录与版本追溯：让文档能被人接手

4.1 修改记录表：六列缺一列就追溯不了

文档开头的修改记录，模板给的基础列是日期、修订版本、修改人、核定人，而这份模板在说明里补了另外三列：编号、章节、修改原因。合起来六列，少一列追溯链条就断。

编号是修改的流水号，只表示这是第几次修改，不承载版本含义。章节写这次改的是哪个功能模块，方便阅读的人直接跳到对应位置。修改原因写为什么要改，这一列是六列里最容易被写成“优化”“调整”的，也是最有价值的一列。合格的写法是“因第三方支付接口调整回调字段，同步修改支付结果通知逻辑”，读的人一眼知道改动的来龙去脉。

日期和修改人保证责任可查，核定人是确认这次修改被审阅过的人。核定人和修改人分离，是这套记录能起作用的前提。如果同一个人既改又核，记录就退化成流水账。

注意：修改原因这一列如果连续多条都是“按评审意见修改”，说明评审意见没有被拆解记录。三个月后回看，没人知道当时具体改了什么、为什么改。

4.2 编号与版本号：两个概念别混着用

这两个词在很多文档里被当成同义词，实际作用完全不同。编号记录的是“第几次修改”，是流水号，一次修改对应一个编号。版本号描述的是“当前文档处于哪个状态”，是状态标识。

实用的版本规则是两段式：0.x 表示内部草稿和评审中，1.x 表示已发布或被正式确认。每次修改版本号不一定进位，比如连续三次文字修订都停在 0.3，等到功能范围变化才升到 0.4。这样看版本号就知道文档稳不稳定。

有人喜欢用日期当版本号，比如 20240601。这种写法在单文档场景下能用，一旦一份 PRD 拆成多个子文档，就没法判断谁先谁后。编号加版本号的双轨制虽然多一列，但回溯时省事得多。

4.3 签字与评审：把“已读”变成可查的记录

模板开头的文档接收人签字栏，包含签字、部门、职位、邮箱、电话。这一栏经常被当成形式，文档发出去没人签，开发照样开工，等到出问题才发现没人确认过需求范围。

签字的作用不是追责，是确认信息传递到位。我一般会要求接收人签字前做一件事：在文档里标出自己负责的章节，并在旁边写一句理解。这一步花不了十分钟，但能提前暴露理解偏差。曾经有个项目，测试负责人签字时在性能需求旁边写了“按这个指标，压测环境需要提前两周申请”，直接把一个被忽略的资源问题提前摆上了台面。

评审流程建议和修改记录绑定：每次评审结束，把评审意见拆成具体条目，能当场改的当场改并记录，不能当场定的挂到待定项并指定负责人和截止时间。评审纪要单独存档，和 PRD 的修改记录互相引用。这样文档的每一次变化都有出处，接手的人顺着修改记录能一路倒推回最初的讨论。

5. 避坑：这份模板用错的五个典型场景

5.1 需求描述只有一句话，开发照着做跑偏

现象：开发按需求做完，演示时产品经理说“不是这个意思”，双方各执一词。

原因：需求描述写成了功能名，比如“支持批量操作”。这句话没有说清批量操作的边界，是全选还是勾选、上限多少、失败怎么处理，全靠开发自己补。

解决：每条需求强制补齐三个要素，触发条件、动作、预期结果。写不出来就说明需求还没想清楚，先别进开发排期。评审时随机抽三条需求，让开发复述一遍自己的理解，复述不一致的直接打回重写。

5.2 PR ID 被复用，改一处崩一片

现象：改了一条需求，测试翻出三个月前的用例说这条之前不是这么定的，两边对不上。

原因：需求作废后编号被回收，分配给了新需求。旧文档、旧用例、旧缺陷单里还留着这个编号，指向的却是另一条需求。

解决：编号只增不回收，作废需求保留编号并标注“已作废”和作废原因。团队维护一张编号前缀表，新增前缀要先登记。发现编号冲突时，以修改记录里的时间为准倒查，而不是靠记忆判断。

5.3 约束条件只存在于会议纪要

现象：开发做到一半发现依赖的系统接口下个月才上线，整个排期往后推。

原因：约束条件在需求讨论会上提过，但只记在会议纪要里，没写进 PRD 的 3.2 约束条件，新加入项目的开发看不到。

解决：任何影响排期的约束，当天同步进 3.2 并更新修改记录。会议纪要只做索引，不做唯一载体。评审前花五分钟扫一遍 3.2，确认没有新增约束漏记。

5.4 版本号拍脑袋，回溯时对不上

现象：线上出问题需要确认当时的需求口径，翻出三个文件名带“最终版”的文档，内容各不相同。

原因：版本号没有规则，靠文件名区分，比如“需求文档-最终版-修改.doc”。文件一多，谁也不知道哪个是最新。

解决：版本号写进文档内部，不写进文件名。文件名保持稳定，版本信息只出现在文档头的修改记录里。对外发送时在邮件或消息里注明版本号，不靠文件名传递状态。

5.5 签字栏空着就开工

现象：上线后出现范围争议，接收方说“当时没确认过这条”，需求方说“文档发你了”。

原因：文档发出去了，但接收人没有确认动作，签字栏一直空着。

解决：把签字拆成可执行的动作，接收人在自己负责的章节旁标注理解并回复确认，确认记录附在评审纪要里。没有确认记录的章节，视为未评审，不进入开发。这条规则一开始会觉得麻烦，跑两三个迭代以后就顺了。

6. 进阶用法：把概要表变成验收对照表

需求概要表填完以后，大多数人就把它当索引用，翻一翻就过去了。我后来发现它还有一个更实用的用法：直接改造成验收对照表，让测试和产品在同一个表上对齐。

具体做法是在概要表右侧加三列：验收方式、用例编号、验收结论。验收方式写这条需求靠什么手段验证，是功能测试、性能压测还是人工走查。用例编号挂测试侧的实际用例，一条需求至少对应一条用例。验收结论只在验收阶段填，取值是“通过”“不通过”“部分通过”。

这张表跑起来以后，验收会上不用再逐条念需求，直接看“部分通过”和“待测”两列。P0 需求出现“不通过”就卡住发布，P2 以下可以带条件放行，但要在表里写清放行理由和补测时间。

还有一个细节值得说：验收结论和需求描述的口径必须一致。曾经有个项目，需求写的是“支持按批次重试”，验收时测的是“整体重试”，两边都觉得自己对。后来我们加了一条规矩，验收前先由产品经理把需求描述逐条读一遍，测试负责人当场确认理解一致，再开始测。这个动作只多花半小时，省掉的扯皮时间远不止半小时。

这套模板我自己用了几年，最大的教训不是哪一栏填错了，而是有段时间图快，跳过修改记录直接改正文，结果一个月后连自己都说不清某条需求是什么时候加的、为什么加。从那以后我每次动 PRD 都强制先写一行修改记录，哪怕只是改一个错别字，也把编号、章节、原因补齐再动正文。这个习惯看起来笨，但它是我用过最便宜的后悔药。希望帮到你。

本文还有配套的精品资源，点击获取