企业官网建设流程全解析

写产品需求文档（PRD）这件事，我前几年一直觉得是走流程。业务方说要个功能，我在文档里把页面画一画、把字段列一列，丢给研发就算交差。真正让我改变看法的是某次版本上线后的复盘：一个看起来极简单的“收藏夹分组”需求，因为没写清楚删除分组之后里面的条目怎么办，研发按自己的理解做了级联删除，上线两小时，用户投诉把客服系统打爆。那天之后我才明白，PRD不是给研发看的说明书，它是产品经理把自己脑子里那套模糊的、跳跃的、自以为是的想法，翻译成一群人可以共同校验的契约。这份笔记想聊的就是这件事：一份能落地的产品需求文档（PRD）到底该长什么样，每个章节背后在防什么坑，以及从需求澄清到评审通过这中间有哪些真刀真枪的操作细节。适合刚接手独立需求的新人，也适合写了几年文档但总觉得“评审老是被问住”的同行，我会尽量把判断依据和推演过程都摊开讲，而不是只给一份漂亮的模板。

1. 先想明白PRD到底在防什么

1.1 PRD在整条链路里的真实位置

很多人把PRD当成研发的输入物，这个定位太窄了。一份PRD实际上同时服务四个对象：研发要知道做什么、测试要知道验什么、设计要知道边界在哪、业务方要知道自己提的东西被理解成了什么样。它卡在“需求已经谈拢、代码还没开始写”这个窗口期，是整条链路上唯一一次能用极低成本改动的机会。代码写完再改，成本是文档阶段的十倍以上；上线之后再改，成本可能是一次事故。

我更愿意把PRD理解成一份“共识存档”。口头沟通会衰减，群里聊过的话会被刷走，评审会上拍的板子没人记。文档的价值不在于写得多漂亮，而在于三个月后有人问“当初为什么这么定”时，你能翻出那一行字。所以判断一份PRD合不合格，我有个很土的标准：把它单独发给一个没参加过需求会的研发，他能不能不问人就把活干了。做不到，就是没写完。

1.2 一份PRD要解决的五个具体问题

拆开看，PRD要回答的问题其实很固定，我把它们列成一张表，写文档时对着自查，缺哪块补哪块：

这五个问题里，最容易糊弄的是第一个和最后一个。背景写成“提升用户体验”等于没写，验收写成“功能正常”等于没定标准。中间三个反而是熟手最容易做好的部分，因为看得见摸得着。所以我的经验是：写文档的时间分配，前两成花在背景和目标上，五成花在功能与状态上，剩下三成留给异常、非功能和验收。

1.3 什么规模的改动才值得写完整PRD

不是所有需求都要走完整流程，全写会把自己累死。我一般按改动量分三档处理，这个分档标准是我自己踩坑总结的，不绝对，但足够用：

• 轻量改动（一个页面内的文案、样式、排序规则调整）：不写独立PRD，在需求管理工具里写清“改什么、改成什么、影响范围”，附一张对比图即可。但必须有一句“回滚方案”。
• 中等改动（新增一个页面、一条完整流程、一个数据看板）：写精简版PRD，保留背景、流程、字段、异常四块，非功能需求按需写。
• 重改动（跨系统、涉及资金/权限/数据迁移、影响存量用户）：完整PRD，一个章节都不能少，且必须走正式评审。

判断标准不是“我觉得复杂不复杂”，而是三个客观信号：是否改动数据结构、是否影响存量数据、是否有跨团队依赖。三个里中一个，就该上升到完整PRD。因为这三类问题的返工成本最高，也最容易在口头沟通里被漏掉。

提示：分档不是为了偷懒，是为了把精力省下来投到真正重要的需求上。我见过团队所有需求都写三十页文档，结果每份都没人看完，反而不如把重需求写透。

1.4 写之前必须先做的那点功课

动笔前我固定做三件事，缺一件文档就会飘。第一件是把需求来源原话抄下来，包括业务方说的原句和当时的上下文，这段话后面会变成背景章节里的“问题证据”。第二件是找研发负责人聊二十分钟，问三个问题：现有架构里这块归谁管、有没有现成的能力可以复用、你觉得哪里会最难。这三个问题的答案会直接改变方案的形状。第三件是翻历史工单和客服记录，看这类需求过去被投诉过什么，这往往是异常路径的来源。

这三件事听起来像流程，实际作用是防止文档写成“我以为”。某次我做一个导出功能，自以为难在文件生成，跟研发聊完才知道生成很快，真正卡的是大文件在弱网下的断点续传和超时重试，那块不写清楚，功能上线就是一半用户失败。这种信息只在人脑子里，不在任何需求描述里。

2. 骨架与信息分层：先把目录立住再填肉

2.1 一份可以直接抄的PRD目录结构

我不太相信“一份模板打天下”，但结构上确实有一套稳定的骨架。下面这版是我现在在用的，章节顺序按阅读者的关注顺序排，不是按写作顺序：

1. 文档信息（版本、作者、更新时间、变更记录） 2. 名词解释（业务黑话翻译表） 3. 需求背景（问题、证据、影响面） 4. 目标与衡量指标（含不做什么） 5. 用户角色与场景（角色权限表、主路径、异常路径） 6. 功能需求详述（按模块拆，每个模块含：流程、界面说明、字段、状态、权限、边界） 7. 非功能需求（性能、兼容、埋点、数据、安全） 8. 依赖与影响范围（上下游系统、存量数据、灰度策略） 9. 验收标准（可执行的检查项清单） 10. 待定事项与风险（谁负责、什么时候给结论）

这个顺序有个小心机：把“名词解释”放在很前面。原因是评审会上浪费时间最多的就是名词歧义，业务方说的“会员”和系统里的“付费用户”可能完全是两拨人，先把词对齐，后面能省半小时。而“待定事项”放最后不是不重要，是要让它显眼——一份PRD里留几个待定很正常，但不能藏在正文中间让人漏看，必须集中列出来，写明谁在什么时候给答案。

2.2 信息分三层：哪些必须写死，哪些留白

把所有细节都写死，文档会变得又臭又长，而且研发会觉得你在教他写代码。我的做法是把信息分成三层，不同层用不同的书写方式：

新手最容易犯的错是把第三层写进去。比如规定“用Redis缓存分组列表”，这既越界又容易错，因为你不了解当前架构的缓存策略。反过来，把第一层写成“分组管理要合理”，那就是把活推给了研发，他只能猜。我给自己定的规矩是：凡是用户能感知到的规则，我必须写死；凡是用户感知不到的技术选择，我不碰。

2.3 名词表和背景章节：最容易被跳过的两块

名词表看似枯燥，实际是整份文档的“翻译层”。我的写法是三列：业务口径叫法、系统内定义、边界说明。举个例子，做收藏夹分组功能时，业务方习惯说“文件夹”，设计稿上叫“分组”，数据库里可能叫collection_group，如果不统一，评审时三个人说三套词，讨论必然跑偏。边界说明这一列尤其重要，比如“分组”要不要包含“默认分组”，默认分组能不能改名、能不能删，这类问题不写清楚，后面全是扯皮。

背景章节的正确写法是“问题—证据—影响”三段式，而不是“我们要做一个XX功能”。前者是描述现状，后者是描述方案，方案可以改，现状不能改。举个对比：

• 差的写法：为了提升用户体验，我们将新增收藏夹分组功能。
• 好的写法：近三个月客服工单中，与“收藏内容找不到”相关的占比约12%，共约XXX条；用户访谈中8位里有6位提到收藏超过50条后基本不再回看；当前收藏列表按时间倒序单一排列，无任何分类能力。结论是收藏功能的“可再利用价值”接近于零。

后一种写法有数据、有来源、有结论，研发看完不会问“为什么要做”，测试看完知道重点验什么。数据来源要说清楚是工单、访谈还是后台统计，别写“据调研”这种没头没尾的话，评审时被追问一句就露馅。

2.4 目标章节：把“做好”翻译成可验证的数字

目标写不好，整份文档就失去了验收的锚点。我的习惯是把目标拆成三层：结果指标、过程指标、护栏指标。结果指标是这件事最终要改变的，过程指标是中间环节的变化，护栏指标是“不能变差的”。

以收藏夹分组为例，我当时是这么写的：

护栏指标这条是我后来加上去的，吃过亏。有个版本为了加功能在收藏按钮上加了个二次弹窗，功能本身没问题，但主流程完成率掉了1.5个点，等于用大损失换小收益。从那以后我写任何涉及主流程改动的PRD，都必须带一条护栏指标。

目标章节还要写“明确不做什么”，这一条经常被省略，但价值极高。比如明确写“本期不做分组排序自定义、不做跨端同步冲突合并”，评审时就不会有人临时加需求，研发也不会自作主张顺手做了个半成品。

3. 核心章节逐段拆解与实操要点

3.1 用户角色与权限：先画清谁不能做什么

功能需求写崩，十有八九是角色和权限没理清。我的做法是先做一张角色权限矩阵，横轴是角色，纵轴是操作，格子里填“可/不可/有条件”。有条件的那种，必须在下面补一句条件是什么。

这张表看着简单，写的时候能逼出很多问题。比如“运营后台删除用户分组”这个操作，删了之后条目去哪、要不要通知用户、能不能恢复，全是必须回答的。权限矩阵写完，功能需求的骨架基本就有了，因为每个“可”背后都是一条流程。

注意：权限这块一定要写“不可”的情况怎么反馈。用户点了没权限的按钮，是隐藏、置灰还是弹提示？三种处理方式对应完全不同的实现，不写清楚研发会各做各的。

3.2 状态定义：把所有中间态都列出来

状态是PRD里技术含量最高、也最容易被跳过的一块。很多文档只写“用户可以删除分组”，但删除这个动作在系统里其实有多个中间态：删除中、删除成功、删除失败、部分成功。尤其是删分组涉及条目迁移时，“部分成功”这种状态最要命。

我的写法是画一张状态表，列出状态名、触发条件、用户可见表现、允许的后续操作：

写完这张表，我发现一个必须拍板的问题：迁移失败时，原分组到底留着还是删掉？留着的用户体验是“白点了一次”，删掉会导致数据丢失。我选了保留，因为数据丢失是不可逆的，多点一次只是烦。这类取舍PRD里要写一句理由，不是为了给谁看，是为了将来自证。

3.3 字段定义：别让研发猜长度和格式

字段表是研发最直接照着写代码的部分，必须细到能直接建表。我一般给这几列：字段名、类型、是否必填、长度或范围限制、默认值、校验规则、异常提示文案。

长度限制不能拍脑袋。20字符这个数我是这么定的：主流手机一屏能完整显示约12到14个中文字符的分组名，20字符能覆盖绝大多数用户习惯，再长就会被截断影响识别；同时从存储角度看，20字符在多数字符集下不超过80字节，索引开销可控。数量上限1000则是反过来算的：单分组1000条，按每条记录平均200字节估算，单分组数据量约200KB，20个分组满载约4MB，客户端做全量缓存也能接受，超过这个量级就得改成分页拉取，实现复杂度会跳一档。

3.4 异常路径：PRD的价值八成在这里

主路径谁都写得出来，异常路径才是分水岭。我总结了一份固定要过一遍的异常清单，每次写功能需求都对着扫：

• 空状态：没有分组、分组内没有条目、搜索无结果，三种空态文案和引导是否不同？
• 超限：数量到顶、字符超长、文件超大，是拦截还是降级？
• 重复操作：连续点击创建按钮、重复提交删除请求，服务端要不要做幂等？
• 并发冲突：两台设备同时改同一个分组名，以谁为准？
• 网络异常：请求超时、断网、弱网，本地要不要暂存，恢复后怎么同步？
• 权限变更：操作过程中权限被回收，怎么反馈？
• 数据被删除：正在看的条目被别处删了，页面怎么表现？

这七类里，最容易被忽略的是“重复操作”和“并发冲突”。我见过一个版本，创建按钮没做防抖，用户手快点了两下，直接建出两个同名分组，还都进了列表。修复很简单，加个请求中的禁用态，但如果不写进PRD，研发大概率不会主动想。并发冲突的处理方案通常是“最后写入生效”或“版本号比对”，这个选择影响用户体验，必须产品来定，不能默认交给研发。

3.5 非功能需求：性能指标要能算出来

非功能需求最容易被写成口号：“响应要快”“体验流畅”。这种话等于没写。正确做法是给出可测量的数字，并说明测量口径。我通常写这几项：

数字怎么来的？我一般做一次粗算。假设日活50万，收藏相关操作人均每天3次，其中分组操作约占三成，即45万次/天。操作集中在晚间4小时，峰值系数按3倍算，则峰值QPS约为 45万 ÷ (4×3600) × 3 ≈ 94。再留一倍余量，按200 QPS设计接口容量。这个数字会直接影响研发要不要加缓存、要不要拆接口，所以他们很在意，写出来比写“要高并发”有用一百倍。

埋点部分也要在PRD里定好，不能等上线前才补。我一般给一张埋点表：事件名、触发时机、关键参数、用途。比如“分组创建成功”事件，参数带分组序号（第几个分组，用来分析用户习惯）、入口位置（列表页还是详情页），这些参数决定了后面能不能做归因分析。埋点漏了，等于这个版本白做一半。

4. 一个完整需求的落地过程实录

4.1 从需求澄清到结构成型

拿前面反复提到的收藏夹分组做个完整推演。需求最初来自业务方的一句话：“用户收藏太多了，找东西很麻烦，能不能加个分类。”这句话不能直接用，我先做了三件事：拉后台数据看人均收藏条数分布，发现中位数只有12条但P90到180条，说明这是少数重度用户的问题；翻了三十条相关工单，主要是“找不到之前收藏的那篇”；找了几位重度用户聊，发现他们的真实行为是“收藏完就忘”，分类这件事他们自己也不会主动做。

这个发现改变了方案形状。原设想是做一个完整的分组管理功能，但重度用户连分类都懒得建，功能再全也没人用。所以最后定的是两条腿：一是系统自动按内容类型做默认归类，降低使用门槛；二是提供手动分组给愿意折腾的用户。这个判断如果不做前面的功课，PRD就会照着“功能齐全”的方向写，做出来大概率没人用。

结构搭好后我先写了一段“方案对比”，把自动归类和手动分组两条路线的成本、收益、风险列出来，说明为什么两条都要。这段内容研发和业务方都会看，能省掉评审时一半的质疑。

4.2 关键参数与状态机的推演过程

分组上限这个参数，我推了两轮。第一轮按用户调研，20个分组能覆盖P95用户的需求。第二轮按实现成本验算：如果上限设50，列表页要支持虚拟滚动，客户端渲染逻辑复杂度上升；如果设10，重度用户不够用。最后折中取20，同时把这个数做成可配置项，后台能调整，避免上线后发现不对再发版。

状态机这块我画了文字版流转，写进文档里是这样的：

创建分组 ├─ 名称重复 → 提示"已有同名分组"，停留在输入态 ├─ 数量已达上限 → 提示"最多创建20个分组"，引导去管理页 └─ 成功 → 进入分组详情页（空态，带引导文案） 删除分组（含条目） ├─ 用户选择"迁移到其他分组" │ ├─ 目标分组已满 → 提示失败，保留原分组 │ └─ 成功 → 原分组删除，条目迁入目标 ├─ 用户选择"一并删除条目" │ └─ 二次确认 → 删除，7日内可在回收站恢复 └─ 删除默认分组 → 按钮置灰，不可操作

这段伪代码在文档里比大段文字描述清楚得多，研发看完直接问“回收站要不要做软删除”，讨论立刻进入实现细节，效率高很多。

4.3 评审前的自检清单

评审会开成批斗会，多半是文档没自检。我提交前会过一遍这份清单，一共八条，每条都能救命：

1. 所有“等”“暂定”“后续优化”是否都已标注负责人和时间？
2. 每个按钮点击后有没有明确结果，包括失败？
3. 每个列表有没有空态、加载态、错误态？
4. 所有涉及删除的操作，是否说明了数据去向和恢复方式？
5. 权限矩阵里每个“不可”是否有对应的界面表现？
6. 跨端（如果有多个客户端）行为是否一致，不一致的地方有没有说明？
7. 埋点是否覆盖了目标和过程指标？
8. 有没有一条“本次不做什么”的明确边界？

这八条里，第4条我吃过最大的亏。第6条是很多团队的通病，某次一个功能在移动端做了长按删除，在网页端没做，用户投诉“为什么手机能删电脑不能”，最后只能补一个版本对齐。

5. 评审现场与落地阶段的那些坑

5.1 评审会被问住的十类问题

评审不是走过场，它是文档质量的实测。我把被问得最多的问题整理成一张表，写文档时提前答掉，评审就能从两小时压到四十分钟：

被问住不可怕，可怕的是当场硬编一个答案。我的原则是：不确定的就说“这个我需要跟XX确认，今天下班前回复”，然后在文档的待定事项里记一条。当场瞎答，后面研发按错的做，返工成本全是自己的。

5.2 开发和测试阶段的偏差处理

PRD交付不是结束。研发过程中一定会有“这个地方我按自己理解做了”的情况，处理方式决定返工量。我的做法是设两个固定检查点：一是研发提测前，对照PRD的验收清单逐条核；二是测试用例评审时旁听，看测试理解的和我写的是不是一回事。

有一次测试用例里出现了“分组名为空时自动命名为‘未命名分组’”，而我的PRD写的是“拦截并提示”。这就是典型的理解偏差，如果不旁听，上线后就是两套逻辑打架。发现偏差后不要在群里吵，直接改文档、标版本、通知相关人，把文档当成唯一事实源。口头确认过的东西，一律回写进文档，否则三天后谁都记不清。

注意：变更一定要留痕。我的习惯是在文档头部维护一张变更记录表，写清版本号、改了什么、谁提出的、影响哪些模块。这张表在出问题时是唯一的追溯依据。

5.3 上线后的复盘：PRD写得好不好，数据会说话

版本上线两周后我会做一次小复盘，只看三件事：目标指标有没有动、埋点数据够不够分析、有没有出现文档里没写到的情况。第三件事最有价值，因为它直接暴露了PRD的盲区。我有个本子专门记这类“漏写”，比如漏了“用户连续快速切换分组时的请求竞态”、漏了“后台下架内容后收藏条目的展示态”。这些漏项攒多了，会自然沉淀成下一份文档的检查清单。

6. 工具、模板与长期习惯

6.1 工具选型的取舍逻辑

工具这块我踩过不少坑，最后稳定在一个组合：文档用支持多人实时协作的在线文档（改动能即时同步，评审时能当场改），流程图用能导出图片的绘图工具（评审投屏清晰），原型用中等保真度的工具（不追求还原视觉，够说明交互就行），需求与缺陷跟进用同一套看板（避免文档和任务两张皮）。

选择逻辑很简单：文档工具的第一要求是“改起来快”，因为PRD是活的，评审当天改十次很正常；第二要求是“能评论定位到具体段落”，避免群里刷屏。原型工具的第一要求不是好看，是“改一版只要五分钟”，因为方案一定会变，做太精细反而是浪费。

6.2 模板沉淀：从抄模板到长出自己的模板

我建议新人都从抄模板开始，但三个月后必须开始删。模板不是越全越好，很多章节在你的业务里根本用不上，留着只会让文档变厚、让人不想读。我现在的模板比最初少了将近一半章节，砍掉的是“竞品分析”“市场背景”这类写一次就再也不看的部分，保留的全是会被反复查阅的：字段、状态、异常、埋点、验收。

沉淀模板的正确方式是“从漏项里长出来”。每发现一次漏写，就往模板里加一条检查项，一年下来这份模板就是你自己的，别人的模板抄不走。我现在那份自检清单，八条里有六条是踩坑踩出来的，比如“所有涉及删除的操作是否说明数据去向”这条，就是那次级联删除事故之后加的。

最后分享一个我坚持了很久的小习惯：每份PRD写完，我会隔一晚再看一遍，只看开头和结尾两段。开头看背景是不是说清了“为什么”，结尾看验收是不是能直接照着测。这两段如果自己读着都含糊，那这份文档基本还得改。文档写得好不好，跟写代码一样，最终骗不过的是自己。