企业官网建设流程全解析

写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.2新增”。团队管这个叫“留下痕迹”，本质上是让所有人知道你改了哪里，不用重读全篇。

2.3 业务背景与目标：怎么写才不是废话

背景部分最常见的写法是“公司业务发展迅速，为提升用户体验，特增加XX功能”。这种开场白等于什么都没说。好的背景写法是“现状+痛点+影响”，最好有数字支撑。

比如写结算页改版的背景，我会这样写：“当前结算页在用户切换优惠券后，应付金额不会实时更新，需刷新页面才能看到最新价格。近三个月客服反馈累计120+单与金额显示不一致有关，结算页转化率低于行业均值约X%。”有了这个背景，评审会上所有人瞬间明白为什么要做。

目标部分同理。不要写“提升转化率”，要写“结算转化率从X%提升至Y%”。目标不需要多，一两个关键指标就够。目标的作用是让大家对齐方向，也是项目上线后复盘的标准。注意一点：目标数字一定要和业务方确认过，别自己拍脑袋写一个，评审时被业务方当场拆穿就很难看。

2.4 用户故事与范围界定：“做与不做”同样重要

用户故事的标准句式是“作为XX角色，我想要XX，以便XX”。这种写法的好处是逼你从用户视角出发，而不是从功能清单出发。举个例：“作为首次下单的普通用户，我想在结算页看到每一笔优惠的明细，以便确认自己的钱没有被多扣。”这比“结算页展示优惠明细”多了一层判断：设计评审时，UI能不能说出这个信息的展示优先级，依据就在用户故事里。

范围界定是我反复强调的部分。“本期不做”往往比“本期做”更重要。开发最怕的不是需求多，而是需求在评审会上不停长肉。在PRD里专门列一节“不做”，把已经提出来但决定本期砍掉的写上，比如“不做支付流程改造”“不做多币种展示”“不做订单详情页”。这样评审时有人说“顺便把XX也做了吧”，你直接指给他看：这块明确了不做，理由是影响核心目标，想加可以走下一次排期。

2.5 功能需求详述：信息架构、交互细节与异常流

功能需求是整个PRD的躯干，也是最见功夫的部分。我习惯把一个功能模块拆成以下小节来写：

• 功能说明：用一段话说清楚这个功能解决什么问题。
• 信息架构：页面分哪几个区块，每个区块展示哪些信息。
• 交互流程：主流程和分支流程，用文字或简图描述，注意不用流程图工具也行，关键路径写清楚。
• 交互细节：按钮状态、跳转逻辑、加载态、空状态、文案提示，能写多细就写多细。
• 异常流与边界：网络异常、接口超时、重复操作、无权限、数据为空，每个都要给反馈。
• 验收标准：可量化、可测试的描述。

这里提醒一点：交互细节别全依赖原型图。原型图能表达80%的正常流程，但异常态往往画不全。文字版本的交互细节和异常流，是对原型图最重要的补充。很多开发提测时漏掉空状态和失败提示，不是他们不想做，是PRD里压根没写。

各功能需求条目要带优先级。我通常用P0/P1/P2：P0是核心主流程，不做就不能上线；P1是高优但可短时缺失；P2是锦上添花，可排到下期。优先级的作用是让开发在排期冲突时能自己做判断，而不是反复来问你“这个要不要先做”。

2.6 非功能需求与埋点数据需求

非功能需求常常被新人忽略，但它坑起人来毫不含糊。做后台系统要写权限边界，涉及用户手机号要提醒脱敏，老项目改造要写明兼容性要求。哪怕不是一个从零开始的系统，只要改了底层数据结构，就要考虑线上数据兼容。

数据需求是另一个容易被忽视的部分。PRD里写清埋点事件和统计口径，数据分析师才能帮你验证目标是否达成。我会附一张表格：

不要写“全埋点”三个字就完事。埋点也要有目标，每个埋点都要对应一个你想验证的假设。不然上线两周后做复盘，拿不出数据结论，需求价值就没法验证。

3. 示例拆解：以“购物车结算页改版”为例

3.1 从文档结构看一版完整的PRD该长什么样

接下来用一个例子串起整个模板。假设我们现在要做“购物车结算页改版”。需求背景是：用户切换优惠券后页面金额不刷新，导致用户以为多扣钱而放弃支付；同时结算页信息层级混乱，优惠明细要展开才能看到，信任感差。目标设定为：结算转化率提升3个百分点，金额展示类客诉降低50%。范围上，本期只做结算页信息重构和优惠券交互优化，不做支付渠道扩展和订单详情页改造。

按模板展开后，PRD的目录会是这样的：

• 文档头与版本记录
• 背景与目标
• 用户与场景：首次下单用户、老用户、价格敏感型用户
• 范围：做结算页UI重构、优惠券切换交互优化；不做支付流程、不做订单详情
• 功能需求：REQ-001 优惠金额实时刷新；REQ-002 优惠券失效处理；REQ-003 优惠明细展示
• 数据需求：结算页曝光、优惠券切换、提交订单事件
• 非功能需求：接口响应时间≤500ms，兼容最低版本iOS12/Android8

3.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. 进阶玩法：前端页面已经有了，怎么逆向写PRD

5.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生成的初稿，哪些地方能直接用、哪些地方容易被编造，试一次你就有体感了。