简介这是一份可直接套用的产品需求文档PRD模板面向产品经理、需求分析师及软件开发团队用于在项目前期统一需求描述口径、减少沟通偏差。压缩包为单个docx文件大小仅463KB轻量易修改、易复用目前已有1464人学习下载。模板按标准PRD结构组织总体说明部分依次包含修订历史、项目概述、功能范围、用户范围、词汇表、非功能需求及其他说明既能记录文档变更轨迹也能帮助团队快速厘清项目边界与核心术语UC部分则细化为整体说明与用例正文每个用例都涵盖编号、名称、使用角色、优先级和操作描述并配以“用户可以在网上退票”这样的具体示例方便模仿撰写。无论编写新产品方案、功能迭代说明还是对外输出规范需求文档这份模板都能帮你节省格式整理时间把更多精力放在业务逻辑与用户场景的深入思考上适合各层级的PRD写作场景整体层次分明、可直接按需增删。1. PRD 模板不是排版问题先把用例写实产品需求文档PRD模板这套资源核心不在封面和目录而在 docx 里藏着的两套完整需求示例12306 中国铁路客户服务中心的功能描述以及一份系部事务管理系统的需求说明书。拿到它你会发现真正难的不是格式而是把用例写到开发、测试、前端都能照着执行的程度。文档的预期读者被限定为技术部门前端工程师和视觉设计师这意味着它是一份“实现导向”的 PRD不是写作文。它适合产品新人建立结构感适合前端和视觉反核对交互边界也适合老手用来检查自己漏掉了哪些字段。下面按“目录结构→用例写法→Word 落地→踩坑→自定义”这条路径拆开每个环节都给能直接抄的填法。2. 拆开模板目录总体说明到 UC五个必填字段群2.1 修订历史先行第一张表决定文档能活多久打开模板第一个字段组是“1.1 修订历史”。很多人写 PRD 时习惯跳过它但 12306 示例里填了一行真实记录日期 2015.10.08、版本 V0.11、说明“部分功能修改”、作者石进珍。这一行看着简单实际在告诉你一个规则——PRD 是活的改一次就必须留一条痕。我见过太多项目文档改了七八轮文件名从“最终版”变成“最终版2”再变成“打死也不改了版”但修订历史始终只有第一行。两周之后没人说得清当前基线是哪一版开发拿着旧文档开发测试拿着新文档验收两边对不上评审会变成扯皮会。模板把这个表放在第一节就是在逼你养成“先记录、后修改”的习惯。版本号不需要复杂V0.x 表示评审草稿V1.0 表示评审通过的基线V1.x 表示在基线上的修改。每次动内容之前先在这一行补上日期、版本、说明、作者再开始改正文。如果团队有需求编号体系我习惯在“说明”里加一列“关联需求编号”例如“部分功能修改关联 UC-1 退票流程”回溯的时候不用靠猜。2.2 功能范围与优先级用一张表圈住需求边界“1.3 功能范围”是模板里最值得反复看的部分。它由总体流程图和一张功能模块优先级表组成12306 那张表一共列了 7 项功能登录验证、管理员功能、普通用户功能、网站相关讯息介绍、列车时刻列表查询、票价查询、余票查询。其中 4 项标“高”、2 项标“中”、1 项标“低”。别小看这个高低分布。优先级的意义不是告诉开发“这个重要”而是告诉所有人“这个版本承诺做到什么程度”。一个评审基线里高优先级功能如果超过功能总数的一半这张表就等于白做了。真实项目里开发排期靠的是这张表视觉设计投入程度也参考这张表连测试用例优先级都从这张表派生。我一般会把模板里的“高/中/低”映射成四档来判断模板档位对应 MoSCoW判定口诀高Must必须有去掉它用户核心流程走不通中Should应该有不影响主流程但影响体验和完整度低Could可以有锦上添花这版不做也不算缺憾不承诺Wont这版不做明确写进“其他说明”防止后续被硬塞12306 示例里“登录验证”和“余票查询”标高是合理的去掉任何一个购票流程都断链“票价查询”标中合理因为它不阻塞下单“网站相关讯息介绍”标低也合理它属于内容运营而非核心流程。你对照自己的项目按这个口径重新过一遍功能范围表会发现至少三分之一的功能优先级要下调。还有一个细节值得注意模板里“管理员功能实现车票和车次管理”是一个合并项粒度太粗。开发认领任务时不知道要干什么。我建议把合并项再拆一层比如“车次增删改查”“余票同步”“票价维护”拆分后的功能点才能进排期和测试断言。2.3 用户范围与词汇表两个最容易留空的部分模板“1.4 用户范围”列了五类角色普通用户、游客、管理员、审核员、合作方。每个角色一行描述看似简单实际上直接决定了前端页面和权限设计——游客有浏览查询权限但没有购票权限意味着未登录状态下页面不能出现下单入口合作方是支付方式支持者意味着支付模块要预留对接外部支付渠道的接口审核员只在乘车人核验场景出现意味着需要单独的后台审核流程。角色权限边界对应前端/后台普通用户注册、登录、购票、退票、个人信息管理用户端全部核心页面游客浏览、查询车次和票价未登录首页、查询页管理员车次管理、车票管理、信息维护后台管理系统审核员审核乘客信息后台审核模块合作方支付方式支持支付网关、对账接口“1.5 词汇表”在模板里是空的只留了一句“术语与缩写的描述”。这个空恰恰是最常见的坑。拿 12306 场景举例“退票”“改签”“余票”“乘车人核验”这些词产品说“退票”指的是申请退款流程开发理解的是订单状态变更测试按“取消订单”来设计用例三方口径不一致评审会当场就吵起来。词汇表不用写满一页把功能范围表和用例里出现的名词扫一遍凡是开发和测试可能追问“你指的是哪个”的词都登记进去。每行至少三列术语、定义、备注。例如术语定义备注已完成订单已支付且未退票的订单不含已取消订单改签在可改范围内变更乘车日期或车次与退票互斥规则见 UC乘车人核验对乘车人身份信息的一致性与有效性校验审核员角色处理我从第 2 章往后每次写 PRD都会先填词汇表再写正文词汇表定的名后面所有用例都必须沿用这也是让模板不变成空壳的第一步。2.4 非功能需求把“滚动流畅”改写成可验收的指标模板“1.6 非功能需求”分了三块数据监控、性能、用户体验。12306 示例里性能一栏写了“滚动流畅、自动刷新数据、交易需要验证确保数据隐私安全”这句话方向没错但不可验收。“滚动流畅”怎么算流畅“自动刷新”刷新频率是多少“数据隐私安全”的边界在哪评审的时候开发和测试都会追着问。我的做法是把每一条非功能需求改写成可验证陈述。模板里的“展示相关车次信息及时”改成“余票查询接口在普通网络下 2 秒内返回结果”“交易需要验证确保数据隐私安全”改成“支付环节采用 HTTPS 加密提交订单需二次校验列表页敏感信息脱敏展示”“页面可任意缩放到合适比例适应人眼”改成“页面在 1280×720 至 1920×1080 分辨率下无破版浏览器缩放 200% 时关键操作可用”。数据监控这条也一样。“后台数据监测点监控数据”可以拆成至少四行记录用户查询日志、统计登录失败次数、监控支付成功率和失败率、跟踪异常退票请求。这样监控对象、监控指标都有了后端才能设计埋点和告警。模板“1.7 其他说明”一直被当成凑数项其实它是兜底的好地方。上线依赖、数据迁移计划、兼容性要求、法律合规说明都可以放在这里。比如 12306 场景就要写清楚“依赖国铁数据源数据同步延迟不超过 X 分钟”“支持 IE11 及以上浏览器”这些内容不影响用例设计但不写清楚临近上线才被发现就是事故。3. 把用例写成系统能读的状态流九个字段与一张规则表3.1 九个字段逐一拆编号、名称到规则描述模板的 UC 部分把单个用例拆成九个字段编号、名称、使用角色、优先级、描述、前置条件、后置条件、界面、规则描述。先看一张字段填法对照表字段模板示例值填法要点编号UC-1按模块分组如 UC-退款-001避免全局流水号名称用户可以在网上退票用“主语能力”句式不要用“退票功能”使用角色用户填角色不填人名角色名必须来自用户范围优先级高与功能范围表口径一致不重复标“中高”描述1.登录进入我的12306…动词串每一步完成一个动作前置条件用户有已完成订单写状态不写动作后置条件查看订单详情即可选择退票写系统保证的结果状态界面空放原型编号、页面截图链接规则描述空主流程之外的全部约束和异常分支编号规则建议在项目第一天定好。如果只有一个业务线“UC-1、UC-2”足够如果多模块并行用“UC-支付-001”这种带模块前缀的格式后续排期、测试引用不会撞车。名称统一用“用户可以在网上退票”这类句式而不是“退票功能”因为用例本质是“角色在系统内的某一次完整交互”名称要把角色和动作都带上。描述是九字段里最核心的。模板里 12306 退票用例的描述写了三步用户登录个人账号进入我的 12306点击已完成订单改/退选择要退的火车票点击退票最后确认即可成功退票。这三步是标准的动词串——每步都是“用户做了什么”没有形容词没有“系统应该友好地提示”这类废话。开发和测试可以直接从描述里摘出主流程路径生成测试用例。3.2 12306 退票用例复盘哪里是对的哪里是坑把模板里的退票用例完整还原一张表字段模板原值复盘结论编号UC-1合理单模块下可接受名称用户可以在网上退票规范句式可以直接用使用角色用户正确来源清晰优先级高退票属于核心闭环高优先级成立描述三步操作简洁能直接转为测试主线前置条件用户有已完成订单进入已完成订单界面“进入界面”是多余的动作应删掉后置条件查看订单详情即可选择退票这是界面操作不是系统状态界面空至少应给原型链接规则描述空最大的缺项见 3.4 节这份用例的优点在于描述缺点在于状态字段和规则字段。对比模板附录里系部事务管理系统的“请假审批”用例会发现后者成熟得多——它把基本活动步骤填写电子请假条、等待审批、销假和可选活动步骤分开写还写了业务规则“请假条提交后在申请时间到假期结束时间段内不允许第二次提出请假申请。如请假事由发生改变在假条未通过前可自行修改在假条已通过后可提出续假申请。”这就是一份能直接交付开发的用例。所以这套模板真正值钱的地方不是给你一个填空的格式而是给了你一个粗糙版和一个成熟版的对照。拿 12306 用例练手改成“允许二次退票驳回再申请”的规则再把请假审批的写法套回去两个示例互相对照着写一轮用例能力就立住了。3.3 前置条件与后置条件写状态不写动作模板里退票用例的后置条件写的是“查看订单详情即可选择退票”这是很典型的新手写法——把后置条件写成了界面说明。开发看到这句话不知道系统在用例结束之后到底要保证什么。真正的后置条件应该是订单状态置为已退票票款按规则退回原支付渠道已退票额重新释放。这是系统在用例走完后必然处于的状态开发照着实现测试照着断言验收标准自然成形。前置条件同理。模板写的是“用户有已完成订单进入已完成订单界面”后半句“进入界面”应该删掉因为这不是进入用例前的状态约束而是描述里的动作。正确的前置条件只需要三类内容身份用户已登录且有权限、数据状态存在已完成且未退票的订单、时间窗口当前时间在退票时限内。我常用一个口诀来区分前置条件回答“什么状态下才可以进来”后置条件回答“做完之后系统必然处于什么状态”描述是两者之间发生的动作序列。三段连起来要能完整走通。比如一个奖品发放用例前置“用户已领取但未发放”描述“点击发放系统向账户写入奖品”后置“奖品状态置为已发放且不可重复发放”三个字段闭环。如果后置写成“用户看到发放成功提示”开发就会纠结提示算不算发放成功数据到底落没落3.4 规则描述一张表把主流程之外的例外全部收进来12306 退票用例的规则描述是空的这其实是最危险的留白。退票业务天然有一堆边界条件发车前多久可以退、退票手续费按什么比例收、已改签的订单能不能直接退、退款多久到账、退票失败提示什么文案。这些不写清楚开发只能按自己的理解实现测试也没法设计异常分支。我给退票场景补一张规则表先当示范规则项规则内容备注退票时限距发车前 30 分钟以上可退超过时限进入“已发车不可退票”状态时限数值以实际业务为准手续费按距发车时间分档收取开车前 8 天以上免费24 小时以上按票价 5%24 小时内按票价 20%具体比例由业务方确认改签互斥已改签且新票已出票的订单需先取消改签再退票与改签用例联动退款渠道原支付渠道退回原渠道不可用时转人工退款流程需对接支付网关异常提示规则不满足时前端展示具体原因禁止笼统报错“退票失败”提示文案引用文案规范文档规则描述为什么要单列而不是塞进描述步骤里因为主流程保持线性开发才能快速提取正常路径异常分支聚合在规则表里开发和测试才能逐条对答案。写的时候注意模板里已经提示过“界面细节引用界面规范文档交互细节引用交互规范文档文案细节引用文案规范文档”所以规则表里只写业务逻辑不要把“弹出红色提示框字体 14px”这种内容写进来那是视觉规范的事。提示写完规则描述后把这张表直接发给测试工程师测试用例的异常分支基本可以照着列。4. 从 docx 到评审基线Word 样式、自动目录和修订模式4.1 套样式取代手敲编号自动目录才能一键更新这份资源是 docx 格式很多人在 Word 里写 PRD最常犯的错是手动敲标题编号——第 2.2 节后面插入一个新用例后面所有编号全要手改改到一半就乱了。正确做法是先把模板里只有 1、2、1.1 样式的标题重新应用 Word 样式把“2.2.1 UC_用户可以在网上退票”这类标题设为“标题 3”把“1.1 修订历史”设为“标题 2”把“第 1 章”设为“标题 1”然后光标放到需要生成目录的空白页点“引用 → 目录 → 自动目录 1”。目录生成后如果后续新增了章节按 CtrlA 全选再按 F9。弹窗选择“更新整个目录”编号和页码会自动刷新。提示目录更新依赖的是“标题”样式不是正文样式。如果目录里缺某节先检查那一节的标题样式是不是“标题 2/3”而不是手动加粗的文字。好处不只是目录能自动更新。套了样式之后文档结构从视觉样式变成可解析的层级生成 PDF 时书签自动带出来多人合作时每个人只要遵守样式规范合并文档不会出现格式错乱。模板里的目录页、正文页码分开设置也是因为用了“分节符”而不是回车键。4.2 导航窗格评审人按标题跳转不用滚动找写完 PRD 后打开“视图 → 导航窗格”左侧会出现按标题层级组织的目录树。评审会上产品经理说“看 2.2.7 那个用例”前端工程师在导航窗格里点一下就跳过去不用在 30 页文档里滚轮找。这一步对多用例的 PRD 特别重要。模板第 2 章“UC 部分”下面挂着十几个用例如果每个用例的编号和名称都出现在标题里例如“2.2.1 UC-1 用户可以在网上退票”而不是“2.2.1 UC_用例名称”导航窗格本身就是一个用例清单评审时扫一眼就能发现谁没写、谁编号断了。我在发布模板给团队时还会要求每个人提交前先开导航窗格自查一遍有没有只有编号没有名称的标题有没有该是标题样式却用了正文字体的段落。这个动作花两分钟但能避免发出一份结构混乱的文档。4.3 用“修订”和“批注”收评审最后一步接受所有更改多人评审 PRD 时最常见的翻车场景是评审人各自在自己的副本上改改完发回来五份内容互相冲突的文件。正确流程是走 Word 的“审阅 → 修订”模式。流程很简单发布评审版时明确要求所有人在原文档上开启修订模式。对争议内容用批注挂在具体字段旁边例如在后置条件字段上批注“这里应改为订单状态描述”而不是新开一段写“你这里有问题”。收齐反馈后先过一遍“审阅窗格”确认没有未解决的批注。点“审阅 → 接受所有更改”然后“另存为”一份新文件名这版才成为基线。最后一步“接受所有更改”至关重要。我见过有团队评审完了直接忽略修订痕迹发出基线合作方打开文档满屏删除线和颜色标记根本分不清哪些是确定内容愣是多花两天去对齐。接受所有更改之后再另存文件名带上版本号才算评审闭环。4.4 文件名、附录与一个保存报错的坑版本管理在 Word 里最便宜的手段就是文件名。模板场景下我建议这样命名文件名示例用途PRD_12306网站_V0.11_20151008.docx评审前草稿PRD_12306网站_V1.0_20151020.docx评审通过基线PRD_12306网站_V1.1_20151102.docx基线后的小幅度修改文件名里的版本号必须和正文“修订历史”表一致两者对不上就失去了版本管理的意义。每次改完“另存为”新文件时顺手在修订历史表里加一行这个习惯能避免“文档内容和文件名不符”的尴尬。模板末尾挂了一个附录系部事物管理系统需求说明书这种做法很实用。一个主体产品可以带多个附属系统的需求说明但每个附录要独立成节。用“布局 → 分隔符 → 分页符”开始新一页再写附录标题目录会自动收录如果用手动回车去凑整页一旦上面改了一行整个版面就歪了。最后提一个 Word 高频报错和 PRD 模板无关但总在改文档时碰到“word 无法将更改后的内容保存到共用模板中”。现象是每次保存都弹保存失败原因通常是 Word 的全局模板文件 Normal.dotm 被占用或权限受限。解决方法是关掉所有 Word 窗口备份用户路径下的 Normal.dotm删除后重新打开 Word 会自动重建。顺手处理这个小坑能避免写文档写到一半突然保存失败的翻车。5. 避坑指南优先级、前置条件和版本控制的四个现场5.1 优先级八项里四项“高”这表等于没排现象功能范围表或用例清单里优先级一栏清一色写着“高”或者出现“中高”“较高”这种模糊档。12306 模板的 7 项功能里 4 项“高”如果不在评审时重新定义开发问“这轮先做哪个”你答不上来。原因写 PRD 的人把“业务上很重要”等同于“这一版必须做”。登录重要退票重要余票查询重要连网站公告也重要结果就是没有优先级。解决给每一档优先级下定义并且加占比约束。一个评审版本里Must 档高的功能不超过总数的 20%—30%。判定方法是去掉这个功能用户核心流程能不能走通登录、余票查询、下单支付这类的确走不通标高公告展示去掉不影响购票最多标低。评审时让产品、开发、测试各对功能范围表独立标一次优先级再合并冲突。这个动作能暴露出团队对“本版本承诺什么”的真实分歧。5.2 前置条件出现“点击”后置条件出现“查看”现象前置条件写“用户打开我的 12306 页面”“用户进入已完成订单界面”后置条件写“查看订单详情即可选择退票”。开发看后仍然不知道系统状态该变成什么。原因把操作流程和状态约束混在一起写。前置条件描述的是“用例开始前系统必须满足的状态”不是用户的某个点击动作。解决前置条件只保留三类内容——身份用户已登录且有权限、数据状态存在已完成且未退票的订单、时间窗口当前时间在退票时限内后置条件只写系统保证的结果——订单标记为已退票、票款退回原渠道、票额释放。检查技巧把“前置条件”和“描述”连起来读如果前置条件里出现“点击”“进入”这类动词就把它挪到描述里如果后置条件里出现“查看”“点击”说明你写的是界面功能而不是系统状态。5.3 界面细节全堆进 UCPRD 变成操作手册现象拿到前端页面后每个用例里贴大段界面描述按钮颜色、字体大小、点击位置全写进去文档膨胀到上百页前端和视觉反而不看这份文档了。原因模板的“对单个 UC 的说明”里明明写了“视觉层面的描述通常直接通过 Demo 表达”“界面细节引用界面规范文档”写的人没遵守把 UC 正文当成了操作手册来写。解决UC 的“界面”字段只放原型页面编号或截图链接交互异常和提示文案放进“规则描述”颜色、字体、对齐方式全部交还给视觉规范文档。我的习惯是给每个 UC 配一个原型页面链接池用例里写“界面见原型 xx 页状态支付中/已支付”至于那个确认框长什么样不属于 PRD 的职责。PRD 是需求的翻译不是 UI 的复读机。5.4 七个版本不换名基线最终靠“猜”现象文档文件名一直是“PRD_最终版.docx”改到第五轮后另存为“最终版2”正文修订历史还停在第一行。两周后再打开没人说得清当前版本包含哪些修改。原因版本管理习惯缺失只改内容不记版本文件名和时间戳没有同步。解决评审通过即定基线 V1.0之后任何内容变动都升级为 V1.1、V1.2文件名、修订历史表、文档内部的版本号三处必须一致。每次评审会结束的顺序是先“接受所有更改”再在修订历史表加一行最后“另存为”新文件名。三步顺序不能反——如果先另存再接受更改基线文件里还带着修订痕迹发出去又是一场事故。6. 让模板变成团队的活工具从 12306 示例反推自定义字段6.1 按项目类型剪裁字段12306 这套模板是交易类系统的骨架功能范围、用户范围、UC 字段都是围绕“用户—订单—支付—退票”设计的。换到别的项目不能只填空要按项目类型增删字段。做支付网关设计文档时我会在用例后面强制加三个字段对账逻辑、掉单补偿、差错处理——这三个是所有资金类系统的命门模板里没有必须自己长出来。做 B 端后台管理时“使用角色”要重写运营、客服、超管这些角色的权限边界比 C 端用户复杂得多我一般会把权限矩阵单独拆成一张表而不是塞在 UC 字段里。模板的价值在于结构可扩展而不是格式固定。每接一个新项目先对照 12306 示例过一遍字段哪些字段在这个项目里是必填哪些是默认值哪些要换掉。这个“剪裁动作”花半小时但能让模板适配团队的不同业务场景而不是为了填而填。6.2 页面先行时用关键帧反推用例现在很多需求是“前端页面已经做好了再补 PRD”甚至有人问“如何让智能体根据前端工程的展示信息和交互来写 PRD”。这种情况下模板依然能用只是方向反过来。我的做法是按主流程把页面截成几帧关键帧搜索页、车次列表页、订单确认页、支付结果页。对每一帧写三行用户在这个页面能做什么动作、系统要保证什么状态、异常时会出现什么提示。把这三行分别映射到 UC 的描述、后置条件、规则描述三个字段。用 AI 生成初稿时我会把关键帧标注一起喂进去然后自己只补两个字段——前置条件和规则描述。因为 AI 生成的内容主流程通常写得很顺但例外分支最薄弱而前置条件和规则描述恰恰是开发测试最依赖的部分。页面先行补 PRD 的场景里这两栏就是人工审核的重点。从那以后我每次拿到任何一份 PRD 模板第一件事都不是填内容而是先检查修订历史和词汇表有没有更新、优先级有没有分档、规则描述有没有留空。这套动作看着慢实际上能在评审会前把至少一半的争论掐掉。希望帮到你。本文还有配套的精品资源点击获取