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。