企业官网建设流程全解析

2. 核心细节解析：PRD 的“五脏六腑”怎么填

PRD 到底要写哪几块？业内没有 100% 统一的标准，但我建议你按“用户、场景、流程、规则、状态、边界”这六个维度去拆，基本上能把一个功能说透。

2.1 用户与场景：先想清楚“谁在用、在什么情况下用”

很多刚入行的产品经理，上来就写“用户点击按钮，系统返回列表”，这其实是把结果当需求。正确的姿势是先写清楚：谁会在什么场景下，因为什么动机，进到这个页面。

举个例子，你要做一个“发票抬头自动识别”的功能。如果你只写“用户上传发票照片，系统识别抬头”，那研发会问：照片模糊怎么办？识别错了怎么办？多张发票怎么办？

如果改成这样写，研发就很好评估：

用户：财务人员为主，偶尔有行政兼岗。
场景：每月报销高峰期，用户一次性拍摄 5-10 张发票，手机端上传。环境多为办公室自然光，部分为外出差旅途中（光线不稳定）。
动机：减少手工录入抬头和税号的时间，避免报销单填错被退回。

同样的功能，前面那种写法，研发只能“猜”着做；后面这种写法，研发能直接拍板：要不要做图片增强、要不要做批量识别、识别置信度低于多少需要人工确认。

还有一个我特别想强调的点：场景一定要写“频率”和“占比”。比如“识别错误”这个场景，如果你不写“预期错误率低于 5%”，研发可能做成 100% 人工兜底，虽然稳，但是繁琐；如果你写了“错误率高于 20% 时，自动进入人工审核队列”，研发就有明确的阈值可以去实现。场景描述不是文学创作，是给研发的“输入参数”。

2.2 业务流程与状态流转：把用户操作变成系统逻辑

在 PRD 里，业务流程我通常分为两种：用户操作流程和系统状态流转。前者描述人怎么操作，后者描述数据状态怎么变。很多人只写前者，忘了后者，结果开发做到一半来问：“订单被取消了，优惠券要不要退回？”“退款到一半，用户又确认收货了，怎么处理？”

这些都属于状态流转。我建议大家画一张简单的状态图（不用画得很复杂，能表达清楚即可），然后把每个状态之间的“触发条件”“前置条件”“后置动作”用文字列出来。

还是拿订单举例，一个典型的订单状态流转可以拆成：

这张表看着简单，但你把“取消订单时优惠券要不要退回”“发货后取消订单要不要扣运费”这些分支条件都填进去之后，研发基本不需要再来问你了。实测下来，一次把状态流转写清楚，整个开发周期里的沟通成本能少一半。

2.3 功能需求 vs 非功能需求：没写“多快多稳”，上线必踩坑

功能需求是“做什么”，非功能需求是“做多好”。这两者的差别，往往是项目上线前才发现问题的地方。

拿“订单列表”来说，功能需求是：支持按订单号、手机号、时间范围筛选。但非功能需求是：列表页首屏加载时间不超过 2 秒；支持并发 1000 人同时查询；数据量超过 10 万条时，分页加载不卡顿。

我见过最典型的翻车案例：一个后台管理系统的导出功能，功能需求写了“支持按条件导出 Excel”，但没写“最大导出行数”。结果运营真的导出了 80 万行数据，Excel 直接打不开，然后运营投诉，研发背锅。其实这就是 PRD 里没写上限导致的。

所以我的习惯是，在每个核心功能后面补一个小节，叫“性能与容量约束”，哪怕只写一句话：预估日活/月活、预估数据量级、峰值 QPS、允许的响应时间。研发看到这些，才会在技术选型的时候考虑缓存、分库分表、异步任务，而不是一头扎进去写个最简单的同步查询。

2.4 异常与边界：PRD 写得好不好，看异常条款就知道

我有一个很朴素的标准：PRD 里“异常处理”部分写得越多的，越可能是老鸟；一字不写的，一定是新人。

原因是，正常流程谁都会写，但异常流程里藏着系统真正的复杂度。我和研发对需求的时候，最怕听到“这个情况不可能发生”。实际上，在真实业务里，用户会传错格式的文件、会连点三次提交按钮、会在弱网环境里提交订单、会手机断电导致半途页面关闭。

下面这几种异常，是我在 PRD 里必写的：

• 网络异常：弱网、断网、超时分别怎么提示，点击提交后多久算超时，要不要支持重试。
• 重复提交：按钮置灰、请求幂等，后端收到两次相同请求怎么处理。
• 数据异常：依赖的外部接口返回空值、超长文本、特殊字符，前端怎么展示。
• 权限异常：用户没登录、登录过期、无操作权限，跳转到哪里。
• 部分成功：批量操作中 10 条成功、2 条失败，提示文案怎么写，失败的是不是要展示明细。

每一条看着都不难，但你不写，研发就会按照自己的理解去实现，最后 100 个研发有 100 种处理方式。等你做用户反馈分析的时候就会发现，投诉最多的往往不是主流程，而是这些边角异常。所以我的习惯是，每写一个功能，都会问自己一句：“用户最可能在哪个步骤犯错？系统在这个步骤怎么兜底？”然后把答案写进 PRD。