写PRD这事儿产品圈里吵了好多年。有人说一页纸就够写多了没人看有人说写不清楚就是埋雷上线后全是坑。我做了这么多年产品带过也审过不少PRD结论很朴素PRD不是用来证明你多勤奋的核心作用是让设计、研发、测试和你站在同一张作战地图上减少“我以为你知道”的沟通成本。如果你正在为PRD无从下手发愁或者写出来的文档总被开发追问“这块没看懂”这篇文章就是给你准备的。我会从一套能直接套用的通用模板开始再用一个结算页改版的例子逐条拆解给你看最后附上一份评审清单还会聊聊一个挺实用的进阶玩法——当前端页面已经有了怎么逆向把PRD补出来甚至让智能体帮你起草初稿。1. 先搞清楚PRD的本质不是交作业而是立规矩1.1 PRD到底给谁看、能解决什么问题很多新人以为PRD是写给领导看的“作业”于是把精力全花在排版和措辞上页面弄得花里胡哨核心逻辑却一塌糊涂。实际上PRD的第一读者从来不是领导而是研发、测试、设计和运营。它回答的是三个问题我们为什么要做这个功能这个功能具体长什么样、怎么工作怎么判断做完了、做对了想清楚这一点你就明白为什么PRD里最忌讳“优化体验”“提升效率”这种空话。开发看到“优化体验”只会挠头因为没法落地测试看到“用户能正常下单”也无从下手因为“正常”这个词每个人理解都不同。PRD的真正价值是把模糊的意图翻译成团队可以执行、可以验收的规则。它是一份契约不是一篇作文。1.2 为什么很多PRD写了等于没写我评审过上百份PRD问题高度集中在几个地方把“做什么”和“怎么做”搅在一起。产品经理上来就写“用Redis缓存”“调XX接口”技术方案写得比开发还细反而把业务规则一笔带过。只写主流程不写异常流。正常路径写得很爽用户断网怎么办、重复点击怎么办、优惠券过期怎么办全部空白。没有验收标准。需求描述是“点击按钮后跳转下一页”但按钮在什么条件下可点、跳转的下一页数据何时加载完成全是模糊地带。没有版本管理。文档改了七八版团队手里拿的却是第一版最后吵起来谁都不认账。这些问题不是文笔问题是写作习惯问题。解决问题的第一步是给自己定一个固定模板每次写PRD都按同样的骨架走不靠灵感靠结构。1.3 一页纸还是完整版先看场景我见过两种极端一种是把所有功能塞进一页PPT式说明开发要反复找你确认细节另一种是写一个100页的大全文档改了需求后连作者自己都不想维护。实际工作中PRD的详细程度应该跟着需求风险走。如果是内部工具的小优化、活动页面这类生命周期短、影响面小的需求一页纸加上几个关键备注完全够用。但凡是涉及用户主流程、多端联动、交易支付、权限体系的需求老老实实写完整版。判断标准很简单如果这次改动上线后出了问题能不能在几分钟内说清楚影响面说不清就需要完整版。一页纸和完整版的差别不在于字数而在于核心规则是否被覆盖。哪怕只写一页纸用户场景、核心逻辑、验收标准这三样也不能缺。2. 一套能直接抄的通用PRD模板2.1 模板整体框架九个模块按这个顺序写以下是我个人比较常用的PRD骨架不同项目可以删减但顺序建议不要乱。按这个顺序写读的人不会迷路。模块核心内容关键要求文档头项目名称、版本号、作者、更新日期、评审对象版本号必须带防止团队看错版本背景与目标业务背景、现存问题、量化目标目标可度量禁止“提升体验”这类空话用户与场景目标用户、使用场景、用户故事说明为什么用户需要而不是你觉得需要范围本期做、明确不做“不做”一定要写明这是挡需求的护城河功能需求信息架构、页面流程、功能详述、异常流按功能模块拆每条带优先级数据需求埋点事件、统计口径测试和数据分析师靠这个核数非功能需求性能、兼容性、安全合规涉及老系统改造时必须写需求清单拆给研发的子任务列表、排期方便研发排期和追踪附录参考文档、术语表、相关链接方便后来人快速了解上下文模板的价值不是让你填格子而是防止你漏项。我见过太多PRD只写了功能需求连背景目标都没有开发改到一半跑来问“这个需求到底为什么做”。有了固定模板至少这种低级事故不会发生。2.2 文档头与版本管理这块千万别偷懒文档头不写版本号的PRD在我这里直接打回。这不是强迫症是血泪教训。有一次一个后台系统的需求文档改了四版其中第三版和第四版的用户权限规则完全不一样结果开发手里拿的是第二版上线后权限全乱用户投诉炸了锅。查了半天发现是群里文件传输混乱根本没人在意版本。从那天起我要求所有PRD第一页必须有版本记录表每次更新必须写清变更人和变更摘要版本日期变更人变更内容摘要V1.02024-11-01陈X初稿核心流程V1V1.12024-11-03陈X增加优惠券失效逻辑调整REQ-002优先级V1.22024-11-06陈X补充埋点事件表做法很简单每次更新在文档头的“变更记录”里加一行同时在对应需求处用颜色或标注标出“V1.2新增”。团队管这个叫“留下痕迹”本质上是让所有人知道你改了哪里不用重读全篇。2.3 业务背景与目标怎么写才不是废话背景部分最常见的写法是“公司业务发展迅速为提升用户体验特增加XX功能”。这种开场白等于什么都没说。好的背景写法是“现状痛点影响”最好有数字支撑。比如写结算页改版的背景我会这样写“当前结算页在用户切换优惠券后应付金额不会实时更新需刷新页面才能看到最新价格。近三个月客服反馈累计120单与金额显示不一致有关结算页转化率低于行业均值约X%。”有了这个背景评审会上所有人瞬间明白为什么要做。目标部分同理。不要写“提升转化率”要写“结算转化率从X%提升至Y%”。目标不需要多一两个关键指标就够。目标的作用是让大家对齐方向也是项目上线后复盘的标准。注意一点目标数字一定要和业务方确认过别自己拍脑袋写一个评审时被业务方当场拆穿就很难看。2.4 用户故事与范围界定“做与不做”同样重要用户故事的标准句式是“作为XX角色我想要XX以便XX”。这种写法的好处是逼你从用户视角出发而不是从功能清单出发。举个例“作为首次下单的普通用户我想在结算页看到每一笔优惠的明细以便确认自己的钱没有被多扣。”这比“结算页展示优惠明细”多了一层判断设计评审时UI能不能说出这个信息的展示优先级依据就在用户故事里。范围界定是我反复强调的部分。“本期不做”往往比“本期做”更重要。开发最怕的不是需求多而是需求在评审会上不停长肉。在PRD里专门列一节“不做”把已经提出来但决定本期砍掉的写上比如“不做支付流程改造”“不做多币种展示”“不做订单详情页”。这样评审时有人说“顺便把XX也做了吧”你直接指给他看这块明确了不做理由是影响核心目标想加可以走下一次排期。2.5 功能需求详述信息架构、交互细节与异常流功能需求是整个PRD的躯干也是最见功夫的部分。我习惯把一个功能模块拆成以下小节来写功能说明用一段话说清楚这个功能解决什么问题。信息架构页面分哪几个区块每个区块展示哪些信息。交互流程主流程和分支流程用文字或简图描述注意不用流程图工具也行关键路径写清楚。交互细节按钮状态、跳转逻辑、加载态、空状态、文案提示能写多细就写多细。异常流与边界网络异常、接口超时、重复操作、无权限、数据为空每个都要给反馈。验收标准可量化、可测试的描述。这里提醒一点交互细节别全依赖原型图。原型图能表达80%的正常流程但异常态往往画不全。文字版本的交互细节和异常流是对原型图最重要的补充。很多开发提测时漏掉空状态和失败提示不是他们不想做是PRD里压根没写。各功能需求条目要带优先级。我通常用P0/P1/P2P0是核心主流程不做就不能上线P1是高优但可短时缺失P2是锦上添花可排到下期。优先级的作用是让开发在排期冲突时能自己做判断而不是反复来问你“这个要不要先做”。2.6 非功能需求与埋点数据需求非功能需求常常被新人忽略但它坑起人来毫不含糊。做后台系统要写权限边界涉及用户手机号要提醒脱敏老项目改造要写明兼容性要求。哪怕不是一个从零开始的系统只要改了底层数据结构就要考虑线上数据兼容。数据需求是另一个容易被忽视的部分。PRD里写清埋点事件和统计口径数据分析师才能帮你验证目标是否达成。我会附一张表格事件名称触发时机统计参数checkout_success用户点击提交订单且返回成功订单金额、支付方式、优惠券ID不要写“全埋点”三个字就完事。埋点也要有目标每个埋点都要对应一个你想验证的假设。不然上线两周后做复盘拿不出数据结论需求价值就没法验证。3. 示例拆解以“购物车结算页改版”为例3.1 从文档结构看一版完整的PRD该长什么样接下来用一个例子串起整个模板。假设我们现在要做“购物车结算页改版”。需求背景是用户切换优惠券后页面金额不刷新导致用户以为多扣钱而放弃支付同时结算页信息层级混乱优惠明细要展开才能看到信任感差。目标设定为结算转化率提升3个百分点金额展示类客诉降低50%。范围上本期只做结算页信息重构和优惠券交互优化不做支付渠道扩展和订单详情页改造。按模板展开后PRD的目录会是这样的文档头与版本记录背景与目标用户与场景首次下单用户、老用户、价格敏感型用户范围做结算页UI重构、优惠券切换交互优化不做支付流程、不做订单详情功能需求REQ-001 优惠金额实时刷新REQ-002 优惠券失效处理REQ-003 优惠明细展示数据需求结算页曝光、优惠券切换、提交订单事件非功能需求接口响应时间≤500ms兼容最低版本iOS12/Android83.2 核心需求条目逐条拆解实操拿最核心的REQ-001“优惠金额实时刷新”来说我会这样拆功能说明用户在结算页切换优惠券后商品优惠明细和应付金额在500ms内自动更新无需刷新页面。交互细节切换优惠券时按钮置为loading态防止用户重复点击。切换成功后应付金额区做一次短暂的高亮动画提醒用户价格已更新。如果接口返回新价格和页面展示价不一致页面以接口数据为准并Toast提示“价格已更新”。若用户选择不使用优惠券金额区域恢复正常展示优惠总金额归零。验收标准从点击优惠券到新金额渲染完成耗时≤500ms。同一优惠券连续快速点击接口只产生一次切换请求。无论用户如何切换应付金额商品总额-优惠金额运费误差为0。这样拆完开发拿到手基本不用再问你“这个按钮怎么处理”测试也可以直接照着验收标准写用例。写PRD写到这个颗粒度才是真的到位。3.3 为什么异常流和边界条件必须写全我再强调一次异常流。REQ-002就是专门为异常场景准备的进入结算页时检测所有可用优惠券对已过期或未达到门槛的券置灰展示并标明原因用户切换优惠券过程中接口报错恢复为原优惠券状态并用Toast提示“切换失败请重试”。很多产品经理会觉得写异常流很烦。但你反过来想主流程是开发根据常识就能实现的异常流才是真正需要需求方拍板的地方。比如接口失败了要不要自动重试重试几次失败后用户停留在哪个状态这些规则你不定开发就会自己定测试也不知道该按什么标准来测。最后的结果就是线上出现各种在你预料之外的“用户骚操作”然后客诉又落到产品头上。异常流是PRD里的“保险条款”花了时间写就是花钱买保险不写就是裸奔。3.4 纯文本PRD与原型图配套的配合方式有同学会问我有原型图了PRD还要写这么细吗我的答案是原型图管“形”PRD管“义”。原型图能直观展示页面长什么样但页面背后的规则——什么条件下文案变成“已售罄”、接口超时提示什么、权限不足怎么处理——原型图很难全覆盖。配合方式很简单原型图展示正常流程PRD用文字补全状态、异常和规则原型图上标注对应需求编号比如“本区块对应REQ-001”PRD里引用原型图截图两边双向跳转。这个习惯养成了评审效率会明显提高。开发一边看原型图拿布局一边看PRD拿规则不用反复在群里追问“这个状态什么时候出现”。4. 评审清单从“自我感动”到“评审稳过”4.1 评审前自查先把自己的文档当别人的来挑毛病每次评审前我都会按下面的清单过一遍自己的PRD。这份清单是我的血泪集结建议你直接抄走。背景和目标是否可度量目标数字有没有和业务方确认“不做”清单里有几项能不能挡住评审时的“顺便加一个”每条需求是否都有优先级开发排期冲突时能不能自行判断异常流是否覆盖了空数据、加载失败、网络超时、重复操作、无权限、部分失败验收标准是否每条都可测试测试拿到后能不能直接写用例数据埋点事件是否和核心指标逐一对齐涉及老系统时是否说明了兼容性和数据迁移方案文档版本号是否正确变更记录是否更新是否给研发留了足够时间做技术预研特别是涉及新方案的需求。上一条“技术预研”是我特别加的。评审会让研发当场拍板方案压力很大容易拍出事后发现做不了的方案。正确做法是在PRD发出后、正式评审前先和研发负责人私下过一遍技术可行性把风险在会前解决掉。评审会上重点过业务逻辑技术细节会前沟通效率会高很多。4.2 评审会上最常见的五个质疑和接招方式评审会上被质疑很正常关键是别慌也别硬刚。我把最常见的五个问题和我的应对思路列在下面“这个需求到底有什么价值”——把背景里的数据亮出来用客诉量、转化率、用户流失数据说话不要讲“我觉得用户需要”。“为什么不做XX”——先确认XX是否在“不做”清单里如果在说明理由如果不在就说“可以评估但建议不塞进本期避免影响核心目标达成”。永远不要当场答应加需求记下来会后评估就好。“这个交互做起来成本太高能不能砍”——这是开发在和你谈判优先级。先确认这个交互是不是P0主流程的一部分如果是就讨论简化版方案如果不是可以考虑砍掉核心方案砍不动也要保证体验兜底。“验收标准定得这么死测试很难通过。”——告诉他验收标准是防止歧义不是刁难开发。如果标准确实设得过高可以协商调整数值比如响应时间从500ms调整到800ms但条件不能去掉。“你写这么多开发根本没时间看。”——承认文档确实不短但解释清楚结构是分模块的开发只需要看自己负责的部分再说出了问题追查起来文档写清楚对大家都好。4.3 评审后跟进纪要、变更与闭环评审不是需求尘埃落定的终点恰恰是执行力较量的开始。评审会后当天出纪要哪怕只是一页纸也要写清楚哪些结论已定、哪些问题待确认、哪些需求改了、负责人和截止时间分别是什么。没有纪要的评审等于白开几天后各自分工就会走样。同时PRD要做相应修改并升版本号在变更记录里写“V1.2根据评审意见调整REQ-002优先级”然后同步到项目群。这一步很多人懒得做总觉得“群里说过大家都知道”。等踩过一次“开发按旧文档做了三天”的坑你就再也不会省这一步了。5. 进阶玩法前端页面已经有了怎么逆向写PRD5.1 什么情况下需要从前端反推PRD先说说这个场景怎么来的。我实际遇到的常见情况有三类一是竞品做得比我们好要参考对方的页面写自己的方案但没有任何需求文档二是接手老系统页面上线了、代码在跑但历史PRD早就找不到了现在要加功能却没人说得清规则三是敏捷团队先做了交互Demo或前端页面 PM反而要在“页面已存在”的情况下补一份正式PRD。这几类情况说到底都一样结果已经有了但推导过程和规则没沉淀。前端页面就是你最好的“需求标本”——它记录了产品最终长什么样、交互怎么走、文案怎么写的。逆推PRD的本质是从“结果”还原“规则”。5.2 手工逆向一套从页面到PRD的还原方法我提炼了一套手工逆向的方法整个过程不需要任何黑科技用浏览器加Excel就能完成第一步梳理页面清单。打开前端工程的路由配置文件把页面路径、页面标题、所属导航列一张表。这相当于产品的目录。第二步画出信息架构。逐个页面看区块记录每块展示的信息元素比如“价格区域包括原价、优惠价、优惠标签”这就是功能模块的雏形。第三步走通主流程。以目标用户视角从进入到离开完整点一遍记录每一步的入口、操作、跳转目标。第四步记录交互细节。每个可点击元素、按钮状态、文案提示、空状态都记下来。重点看浏览器控制台里报了什么错异常提示怎么展示的。第五步反推业务规则。页面上的展示逻辑不等于规则要做一层“假设验证”为什么这里显示“满199减30”推测是满减规则为什么这个按钮置灰推测有前置条件。把这些推测统一标记为“待确认”。第六步整理成PRD。按前面那套九段式模板填充所有“待确认”项标注颜色约业务方逐条确认。这套流程看起来很朴素但它比闷头写文档快得多。因为页面已经把逻辑约束好了你需要做的只是把一个“实物”翻译成“规则”。5.3 让智能体根据前端工程写PRD提示词思路与效果实测前端页面有了能不能让智能体来辅助生成PRD我试过答案是能但前提是你要用对方法。最忌讳的是直接把一堆HTML源码甩给大模型让它“写PRD”——HTML是表现层代码智能体很难从中推断出业务规则只会输出一堆正确的废话。正确的做法是先让前端工程“结构化”然后喂给智能体。我实际操作时会让前端同学生成一份“页面组件-交互事件-接口调用”清单或者我自己从代码里提取路由、组件、事件绑定和API调用整理成结构化文本。拿结算页举例我喂给智能体的信息是类似这样的页面路径/checkout 页面标题结算页 组件列表 - 收货地址卡片可点击事件 address_select调接口 GET /api/address/list - 商品清单只读展示 - 优惠券面板可展开事件 coupon_toggle优惠券项可选中事件 coupon_choose调接口 POST /api/coupon/check - 应付金额区域展示 total_amount - 提交订单按钮事件 submit_order调接口 POST /api/order/create 交互限制优惠券切换请求中按钮置为 loading防止重复提交。 文案提示按钮上方提示文字为“已为你自动选择最优优惠券”。然后把这段信息作为输入用下面的提示词框架让它生成PRD初稿你是资深产品经理。我会提供一份前端页面结构信息包含页面路径、组件列表、交互事件、接口调用和文案。请基于这些信息生成PRD初稿要求 1. 按以下结构输出背景目标、用户故事、功能需求、异常流、验收标准、数据埋点。 2. 对于前端信息无法推断出的业务规则标记“待确认”不要编造。 3. 每条需求给出P0/P1/P2优先级。 4. 异常流至少覆盖空状态、加载失败、重复操作、接口超时。实测下来智能体能很好地完成“把页面结构翻译成需求条目”这项工作尤其是信息架构、交互细节、异常流的罗列效率确实高。它生成的初稿大致是下面这种质量功能需求“点击优惠券面板可展开当前可用优惠券列表用户可选择任意一张券选中后调接口并刷新应付金额。”异常流“若获取优惠券列表失败展示默认空状态并提供重试按钮。”验收标准“点击优惠券后页面在3秒内展示最新金额。”初稿的优势是框架完整、表达规范省掉了我从零开始憋字的时间。但要注意它也会暴露出明显问题。5.4 智能体生成PRD的局限与人工修正清单智能体生成PRD最大的风险有三个一是会编造业务规则。页面显示了一个满减标签它会自动脑补门槛和规则但这些可能只是静态文案真实规则要问业务二是不知道产品背景和业务指标。页面摆在那里但为什么这么设计、目标指标是多少只有产品经理知道三是对复杂状态流转覆盖不足。多个分支条件叠加时初稿常常会漏掉部分组合场景。所以我给智能体生成PRD定了一条铁律它出初稿我做终审。具体需要人工修正的点我用下面这份清单逐一排查“待确认”项是否都找到了对的业务方确认后是否写回PRD。页面上的文案和真实接口返回的文案是否一致有时前端是写死的。权限控制是否覆盖登录态、会员等级、内部白名单。优先级P0/P1/P2是否合理智能体对“哪个是核心流程”判断力有限。数据埋点是否覆盖了核心转化漏斗的每一层。5.5 一个可直接复用的智能体提示词模板最后送你一个可以拿去直接用、略作修改就能适配多数场景的完整提示词框架。我现在让智能体辅助写PRD初稿时基本就是套这个模板你是一名有10年经验的产品经理。我会给你一份前端页面的结构化信息请你基于它写出一份PRD初稿。 结构化信息如下 [在此粘贴整理后的页面路径、组件列表、交互事件、接口调用、文案提示等内容] 请按以下9个章节输出 1. 文档头信息项目名称栏位留空版本V1.0作者AI助手 2. 背景与目标背景写“基于前端页面逆向补全需求文档”目标项列出3个可度量的候选指标 3. 用户与场景列出2-3个可能的用户身份和场景标注“待确认” 4. 范围把页面中已体现的功能列入“做”推测可能被砍的功能列入“不做”并标注原因 5. 功能需求每条包含需求描述、交互细节、优先级信息不足处标“待确认” 6. 异常流至少覆盖空数据、加载失败、重复操作、接口超时 7. 数据需求列出3-5个建议埋点事件及触发时机 8. 非功能需求列出性能、兼容性、安全性3类默认建议 9. 验收标准每条功能需求对应1条验收标准 硬性要求不得编造业务规则。所有来自前端信息无法确认的内容必须标注“待确认”并在文末汇总成一个待确认问题清单。用这个模板生成的初稿通常能在一分钟内给你一份有模有样、可直接在此基础上修改的文档。但请记住我前面说的AI帮你省掉的是整理和罗列的体力活业务判断、指标确认、方案取舍这些核心工作永远要产品经理自己来把关。说到最后我还是想分享一个个人体会。PRD写得多了你就会发现它真正的价值不在于“写得多完整”而在于“团队能不能基于同一份文档达成共识”。模板能帮你降低写作负担智能体能帮你提升起草速度但最花心思、也最值钱的部分永远是业务规则的澄清。如果你也要在项目里尝试“从前端页面逆推PRD”或者“用智能体辅助写PRD”我的建议是从小项目练手先用一版真实需求的PRD去对比AI生成的初稿哪些地方能直接用、哪些地方容易被编造试一次你就有体感了。