先交代一下背景。做产品这行，写得最多的不是PPT，而是需求文档。刚入行那会儿，我最怕看到的就是这一串缩写：BRD、MRD、PRD、DRD、FRD，每个都叫"需求文档"，每个又都不一样。后来带团队、做评审、给新人做培训，发现绝大多数人卡住的不是"会不会写模板"，而是根本不清楚这几份文档分别在替谁说话、解决什么问题。所以这篇东西，我不想给你一套"万能模板"，而是想把这几类文档的前因后果、编写逻辑、常见坑，一次性讲透。
全文会用一个贯穿的例子来讲：某本地生活平台要做"会员成长体系"。这个项目不大不小，正好能把这五类文档的差异全部照出来。你跟着走一遍，基本就知道在真实的项目节奏里，什么阶段该动哪份文档，里面写什么、不写什么。
1. 别急着找模板，先搞清楚五类文档在为谁说话
很多新人拿到这些文档名称，第一反应是搜模板。搜完更晕：同一个PRD，A公司写成功能清单，B公司写成原型加说明，C公司干脆就是一个在线白板链接。模板之所以不通用，是因为每家公司对文档的定位不同。但放在行业通用的视角里，这五类文档其实有相对明确的"服务对象"和"要回答的问题"。
先说结论：
- BRD回答的是"要不要做"，读者是决策层，关注商业回报和风险。
- MRD回答的是"做的东西市场认不认"，读者是管理层和产品委员会，关注用户、市场、竞争。
- PRD回答的是"具体做成什么样"，读者是设计、研发、测试，关注功能、流程、规则。
- DRD回答的是"数据从哪来、到哪去、怎么算"，读者是后端工程师和数据工程师，关注接口、字段、口径。
- FRD回答的是"每一个操作细节到底怎么表现"，读者是前端工程师和测试工程师，关注交互、状态、边界。
这五份文档不是五选一，而是同一个项目在不同阶段的"视图"。BRD和MRD在项目还没立项时写，用来论证和排优先级；PRD在项目启动后写，用来统领研发；DRD和FRD在交互方案和技术方案并行推进时写，用来做细节对齐。你甚至可以理解为：BRD是给钱的人看的，MRD是给方向的人看的，PRD是给干活的人看的，DRD和FRD是给较真的人看的。
我见过最典型的问题，是把所有内容塞进一份PRD里：开头写市场分析，中间写商业模式，后面堆功能清单，最后再挂一份接口文档。结果这份PRD又长又乱，研发不知道哪段该自己看，领导翻两页就关了，最后谁都没获得有效信息。文档的价值不在厚，在于在正确的时间、用正确的粒度、给正确的人看。
下面用一个贯穿的例子来说明：某本地生活平台的会员成长体系。这个项目要做一个用户等级、成长值、会员权益的闭环，涉及运营策略、App前端改动、后端数据处理，够复杂，也够典型。
2. BRD与MRD：给决策层算账，给方向层指路
2.1 BRD：一页纸说清"值不值得做"
BRD的全称是商业需求文档，Business Requirements Document。它最大的特征是"短"。我见过好的BRD只有三四页，甚至有的是两页纸加一页附录。因为决策层的时间很少，他们要看的不是细节，而是三件事：机会有多大、要投多少、回报靠什么。
以会员成长体系为例。BRD里应该写清楚：
- 背景与机会：平台现有用户复购率连续两个季度下滑，而调研显示高活跃用户的消费频次是普通用户的3倍以上。通过成长体系锁定高价值用户，可能带来整体GMV提升。
- 商业目标：用可量化的口径写。比如"项目上线后12个月内，会员用户的月均消费频次提升15%""高等级用户占比达到20%"。不要写"提升用户粘性"这种没法验收的话。
- 投入估算：研发侧需要多少人力、周期多长；运营侧需要多少预算做权益采买；市场侧需要多少资源做推广。粗算即可，不需要精确到人天，但要让决策层知道盘子有多大。
- 风险与对策：比如"高等级权益可能被恶意刷取"，对策是风控规则前置；"低等级用户感知弱导致流失"的对策是新手快速升级机制。
写BRD最容易犯的错，是把PRD里的功能列表抄进来。比如"等级分为V1到V5""V5享受专属客服"——这些是PRD的活。BRD里只需要说"通过设置明确的用户等级阶梯和差异化的权益激励，拉动复购"，至于阶梯怎么分、权益怎么配，不在这一层讨论。
还有一点，BRD一定要给一个明确的结论和建议。比如"建议投入XX资源、在Q2启动该项目"。不要只罗列数据让老板自己拍板——数据是支撑你建议的依据，决策的成本应该由你来降低。
2.2 MRD：用户需求不等于产品功能
MRD，市场需求文档，Market Requirements Document。它在BRD之后、PRD之前。BRD论证了"值不值得做"，MRD要回答"做的东西到底对不对路"。换句话说，MRD是把商业目标翻译成需求语言的关键一环。
还是会员成长体系。BRD说我们要拉复购、提频次，MRD就要进一步说清楚：
- 目标用户是谁：不能只说"所有用户"。要细分成新用户、沉默用户、活跃用户、高价值用户。不同用户对成长体系的诉求完全不一样：新用户想快速拿实惠，老用户想要身份感和专属权益，沉默用户需要一张"召回券"。
- 使用场景是什么："周末打开App点外卖前刷一下会员进度条，看到再下两单就升级，果断凑了一单"——这才是场景。MRD里写场景，不是写故事，而是写触发条件、用户行为、心理预期。
- 市场机会有多大：参考同类产品的会员渗透率、用户调研数据、竞品分析。这里不是学术论文，给两个维度的足够数据就行：一是市场规模，二是用户侧验证结果（比如问卷调研中78%的用户表示愿意为成长值体系改变消费习惯）。
- 核心竞争力：同样的会员体系，别人也在做，我们靠什么赢？是平台已有的数据能力、还是供应链权益优势？
MRD常见的坑有两个。一是把用户需求直接等同于产品功能。用户在问卷里说"我想要更多优惠券"，不代表产品要做一堆优惠券，可能是需要更聪明的推荐机制让用户觉得"券刚好能用上"。MRD要写的是需求背后的动机和场景，而不是急着给方案。二是只堆数据和报告，没有决策。MRD结尾必须输出明确的结论，比如"目标市场确认，建议按A方案进入PRD阶段"，让项目真的往前走一步。
BRD和MRD的产出物经常是PPT或者在线文档，因为要反复给不同的人讲。我建议保持一个习惯：这两份文档永远用"结论先行"的叙事——先说是做什么、定不定，再给依据。决策层耐心有限，越早看到你的判断，他们对你的信任建立得越快。
3. PRD：从"方向对"到"做得对"的那道关键转换
3.1 PRD不该写成"功能说明书"
PRD，产品需求文档，Product Requirements Document。它是整个文档体系里最重要、也最容易写烂的一份。好多团队把PRD写成"功能说明书"：照着原型图，把每个按钮、每个弹窗用文字描述一遍。这其实是FRD的活。PRD的灵魂不在于"描述界面"，而在于解释"为什么做这个功能"以及"这个功能在什么条件下成立"。
拿会员成长体系来说，PRD开篇应该有一段需求背景：为什么要做成长值、这个项目的成功指标是什么（和BRD里的商业目标对应）、目标用户是谁（和MRD里的用户群对应）。这看起来像凑字数，实际上非常重要——它让每一个参与的研发和测试都知道自己在解决什么问题，而不是单纯执行一个"成长值规则"。
PRD的主体是需求列表。我会用这样的结构：
- 用户故事：作为高活跃用户，我希望每次消费都获得成长值，以便更快升级到更高等级、解锁更多权益。
- 功能清单：成长值获取规则、成长值查询、等级展示、权益说明页、升级提示弹窗、等级有效期规则。
- 每个功能下的详细规则：这才是PRD的工作量所在。成长值怎么算？是消费金额的10%，还是按单固定给？是否有上限？退款时成长值怎么处理？这部分我放到下一节讲。
3.2 业务规则与异常流：PRD的价值洼地
有一次评审会上，前端工程师直接问我："用户用积分兑换了权益，但订单在支付回调时失败了，积分已经扣了，页面显示什么？"我当时愣住了——因为我PRD里只写了"兑换成功""失败重试"两个分支，完全没考虑支付结果不确定的中间态。这是PRD最容易被抠出问题的区域：业务规则和异常流。
写PRD时，每个功能都必须回答以下问题：
- 正常路径是什么：用户下单 → 订单完成 → 成长值入账 → 等级提升 → 展示升级弹窗。
- 分支规则是什么：成长值按实付金额计算，实付金额含优惠券抵扣部分，不含运费；退款时按比例扣减对应成长值；如果扣减后等级下降，已解锁的权益如何处理。
- 异常路径是什么：支付成功了但回调延迟、成长值到账失败（需要补偿机制）、用户注销后成长值是否保留。
- 边界条件是什么：单日获取上限、单笔订单上限、成长值有效期、等级每月保级规则。
这些规则不是产品经理拍脑袋想出来的，而是要拉上运营、财务、法务一起过一遍。尤其是涉及钱、积分、权益的规则，每一条都要有口径。我习惯的做法是画一张"规则决策表"放在PRD里，列清楚条件组合和对应行为。比如：
| 场景 | 条件 | 系统行为 |
|---|---|---|
| 正常入账 | 订单状态变为已完成 | 按实付金额×10%计入成长值 |
| 退款 | 订单退款成功 | 按退款金额对应比例扣减成长值 |
| 退款后等级下降 | 扣减后总分低于当前等级阈值 | 等级同步下降，未使用权益保留30天 |
| 回调失败 | 支付成功但回调超时 | 系统按订单查询补偿，用户侧显示"成长值处理中" |
把这张表写透，研发几乎不需要再回来找你确认。这也是PRD和"功能说明书"最大的分水岭：功能说明书告诉别人"有什么"，PRD告诉别人"在各种情况下它会发生什么"。
4. DRD与FRD：决定交付质量的"最后一公里"
4.1 DRD：研发真正照着写代码的那张图
DRD有两种常见解释：一种是Data Requirements Document（数据需求文档），一种是Design Requirements Document（设计需求文档）。在多数互联网公司的实践中，DRD实际承载的职责是接口与数据契约，它和FRD一起，把PRD的"业务逻辑"翻译成"技术逻辑"。
为什么要单独写DRD？因为PRD里的业务规则，到研发手里会面临一个残酷的现实：系统里没有"成长值"这个字段。DRD要做的就是告诉后端工程师：数据从哪个表来、要新增哪些字段、接口怎么定义、返回什么结构、错误码怎么定。
以会员成长体系为例，DRD至少包含三块内容：
- 数据需求定义：新增"成长值流水表"，包含用户ID、变动类型（获取/扣减/过期）、变动数值、关联订单号、发生时间、过期时间。"会员等级表"包含用户ID、当前等级、当前成长值、升级时间、保级状态。数据字段要写清楚类型、长度、是否可空、默认值。
- 接口需求定义：比如"查询用户成长值"接口，入参是userId，出参是totalGrowthValue、currentLevel、nextLevelThreshold、expireGrowthValue。再比如"成长值变动通知"接口，用于第三方权益系统对接。接口文档尽量沿用团队的现有规范，字段命名要和PRD里的业务名词一一对应。
- 计算逻辑与边界：成长值的计算是实时的还是T+1批处理？如果用户一天内消费10笔，是一笔一笔算，还是累计到晚上统一算？这些必须写死。
写DRD最忌讳的是产品经理不懂技术但装懂。你不用写SQL，但要听得懂研发说的"这个字段要不要索引""这个接口要不要加分布式锁"是什么意思。DRD不是替研发做技术方案，而是把业务规则以数据流转的方式复述一遍，确保双方对齐。
这里我特别想提醒一点：DRD里的字段口径必须和PRD完全一致。比如PRD里写"实付金额"，DRD里就必须明确"实付金额 = 原始订单金额 - 优惠券分摊 - 平台补贴，不含配送费"。口径不一致，后面测试阶段一定打架。
4.2 FRD：把"应该怎么样"变成"就是怎么样"
FRD，Functional Requirements Document，功能需求文档。有些团队把它叫交互说明文档，或者界面需求文档。FRD的核心是把PRD里的功能点，细化到每一个界面状态、每一次交互反馈。如果说PRD是"灵魂"，FRD就是"皮囊和筋骨"。
回到会员成长体系。成长值页面上有：成长值数字、进度条、等级图标、获取攻略、权益列表。FRD要写的不是这些元素的名字，而是它们在不同状态下的表现：
- 成长值进度条，达到50%时是否有动画？是否显示"离下一级还差XX值"？
- 用户成长值刚够升级，进入页面时是从V3变成V4，顶部是否有升级动效？弹窗还是半屏浮层？用户关掉之后从哪个入口再能看到？
- 权益过期了，页面展示"已过期"标签还是直接置灰？点击置灰权益是否弹Toast说明原因？
- 登录态失效、接口超时、网络断网，各是什么状态？空数据页面长什么样？
- 等级有效期剩余天数，是用倒计时显示还是日期显示？最后一天是否要额外提醒？
这些东西PRD不会写、也没必要写，但研发一旦开始做页面就会来问你。如果FRD里提前写清楚，前端工程师可以独立完成开发，测试工程师可以直接对照FRD写用例，产品经理也省得被反复打扰。
写FRD有个实用的技巧：用"状态 + 行为"的表格来组织。一个页面拆成N个状态，每个状态对应一组行为。比如"成长值明细列表"：
| 状态 | 前端表现 | 交互行为 |
|---|---|---|
| 正常加载 | 显示成长值流水列表，每条包含变动原因和变动值 | 下拉可刷新，点击单条弹出详情 |
| 加载中 | 显示骨架屏，不少于3个占位块 | 不可点击，超过5秒显示超时重试按钮 |
| 空数据 | 显示空状态插画和"暂无成长记录"文案 | 按钮引导去"成长任务中心"消费赚成长值 |
| 加载失败 | 显示"加载失败"和"重试"按钮 | 点击重试重新请求接口 |
FRD的篇幅通常很长，但读起来应该很轻松——每一页都是"是什么状态 → 显示什么 → 能点什么 → 点了之后怎样"。写完FRD后，我永远会做一件事：让一个没参与过PRD讨论的人通读一遍，如果他能靠这份文档还原出页面，说明写到位了。
5. 这五类文档最容易死掉的方式，以及我的避坑方法
5.1 文档死在"没人看"和"不更新"
写了多年需求文档，我总结出文档最常见的死法：不是写得不好，而是没人看 + 不更新。
BRD和MRD通常只出现在立项评审会上，评审通过后就被丢进网盘落灰。这问题不大，因为它们本来就是"一次性"的决策文档。真正要命的是PRD、DRD、FRD的版本更新。产品经理最常见的操作是：评审会提了一堆修改意见，当场改了PRD里两段文字，但FRD没同步、DRD没同步，研发拿着旧文档做了两周，最后做出来个四不像。
我的习惯是：每次评审会开完，必须有一个人专门负责"同步文档状态"。要么在文档开头挂一个"变更记录"表格，列清楚谁在什么时候改了什么；要么建一个项目共享目录，所有文档放在一起，以"PRD_v2.3"的方式管理版本。最关键的是，不允许出现"口头同步"——你说"我上会说了，研发知道",但等文档落到新人手里，信息就断了。
5.2 评审机制：把文档变成会议的地基
文档的价值，一半在写，一半在"过"。没有评审会的文档，写完了基本等于白写。我观察到一个很普遍的现象：不少团队把PRD评审开成了"原型宣讲会"，产品经理对着图讲一遍"这里是按钮，那里是列表"，大家点头散会，然后研发回去发现一堆细节没定。
评审会正确的打开方式应该是：参会者提前看过文档，会上只聊分歧和缺陷。为了做到这一点，我在发出评审邀请时，会附带一份"评审要点清单"，明确告诉与会者"请大家重点看第三节的成长值获取规则，这里的异常流我拿不准"。会上讨论的话题，永远是一个个具体的决策点，而不是从头到尾把文档读一遍。
DRD和FRD评审也一样，甚至更需要。因为一份DRD里可能有几十个字段定义，现场让后端一行行看，效率极低。我会把DRD拆成"数据字典"和"接口定义"两个部分，提前发给后端和数据仓库的同事，让他们把意见直接批注在文档上，然后开会只过批注。
5.3 文档过细与过粗：两头都是坑
文档写太粗，研发没法干活；写太细，文档就成了研发的"茧房"——他们照着文档做，完全丧失判断力。我见过最极端的例子：某项目的FRD详细到"按钮在屏幕左上方12像素处"，结果设计稿一更新，整份文档立刻作废，产品经理每天的工作变成改坐标。
我的判断标准很简单：PRD管"业务规则"，DRD管"数据口径"，FRD管"交互行为"，三者各管一摊，不要越界。PRD里不要写"按钮放左边还是右边"；FRD里不要写"成长值按10%计算"；DRD里不要写"页面加载失败后显示一个重试按钮"。一旦越界，文档之间的同步成本就会指数级上涨。
再补一条：文档的粒度要和团队的专业度匹配。如果前端团队经验丰富，FRD可以只写状态和交互规则，不写具体视觉表现；如果团队里新人多，FRD就要把边界情况写得细一点。不要为了"显得专业"而把文档写到三百页，重点是每一页都得有人用。
6. 几句实在话：好的文档体系是产品经理的"第二大脑"
讲了这么多，最后还是想聊聊文档这件事的本质。
我做过无数个需求，从立项到上线，最深的体会是：写文档的过程，本质上是在逼自己把问题想清楚。有人说"产品经理的时间应该花在思考上，不要花在写文档上"，这话我不同意。思考不落到纸面上，永远会漏掉细节。你觉得自己想清楚了，但当你必须把"退款后等级下降、权益怎么办、30天内怎么提示"写明白的时候，才会发现原来还有一半场景没想过。
五类文档组合在一起，其实就是产品经理在项目推进过程中的"第二大脑"：BRD和MRD帮你回答"值不值"，PRD帮你回答"对不对"，DRD帮你回答"通不通"，FRD帮你回答"细不细"。它们相互印证、层层细化，最终变成一套可追溯的逻辑链。任何一环缺失，项目都会在某个阶段付出额外的沟通成本。
最后分享几个我一直在用的实操习惯：
- 先搭骨架再填肉。写PRD前，先把用户故事、功能清单、规则表、异常流的标题框架列出来，再逐节填充。不要从第一个字开始顺序写，那样很容易陷入细节出不来。
- 一次只写一类文档。不要一边写PRD一边改FRD，更不要同时写BRD和PRD。思维切换的成本远大于书写成本。
- 尽早让研发和设计参与评审。文档不要自己闷头写完再给所有人"惊喜"。PRD写了三分之一就拉研发看一眼，"成长值这个字段你打算怎么接"，这个动作能帮你提前避掉大量返工。
- 文档要有"可搜索性"。关键名词在同一份文档里全文统一，不要这次叫"成长值"、下次叫"经验值"。给关键字段设置锚点链接，方便别人跳转。
说了这么多，核心就一句话：文档不是流程的摆设，它决定了项目里信息的传递效率，也决定了产品经理自己的思考深度。希望这篇东西能帮你在写BRD、MRD、PRD、DRD、FRD的时候，少走点弯路。
