夜雨聆风
为什么你的需求文档总被开发吐槽?一个PRD的自检清单
一、开篇 Hook：那个被开发怼到自闭的下午
周三下午三点，会议室。
我信心满满地把 PRD 投到屏幕上，准备接受开发的「顶礼膜拜」。结果后端小哥看了三页，直接灵魂发问：
「这个字段为空的时候怎么办？」
「用户同时点两次提交，数据会不会重复？」
「这个接口超时了，前端怎么给用户反馈？」
我：……
那一刻，我悟了。PRD 不是写给自己看的，是写给开发看的。开发吐槽你，往往不是需求有问题，而是你没把边界讲清楚。
今天这份「PRD 自检清单」，来自我被怼了 100 次后的血泪总结。建议收藏，写 PRD 时逐条对照。
二、PRD 自检清单：10 个检查点
以下清单按「被吐槽频率」排序，越靠前越容易被怼。
|
|
|
|
|---|---|---|
| 1. 边界条件 |
|
|
| 2. 异常流程 |
|
|
| 3. 数据字典 |
|
|
| 4. 埋点设计 |
|
|
| 5. 权限控制 |
|
|
| 6. 并发处理 |
|
|
| 7. 状态流转 |
|
|
| 8. 性能指标 |
|
|
| 9. 兼容性 |
|
|
| 10. 兜底策略 |
|
|
三、实战案例：一个被怼的 PRD 长什么样
来看一个真实的「翻车现场」。
需求背景：做一个「用户提现」功能。
初版 PRD 描述：
「用户在钱包页面点击提现按钮，输入金额，确认后提交申请。」
开发看到后的反应：
❓ 最小提现金额是多少？最大呢？
❓ 用户一天能提几次？
❓ 余额不足时怎么提示？
❓ 提现申请提交后，用户还能取消吗？
❓ 银行接口超时了怎么办？
❓ 需要记录操作日志吗？
改进后的 PRD：
✅ 输入校验：最小 1 元，最大 50000 元，单日累计不超过 50000 元
✅ 次数限制：单日最多 3 次，超过后提示「今日提现次数已用完」
✅ 余额不足：前端实时校验，余额不足时按钮置灰，提示「余额不足」
✅ 状态流转：申请中 → 处理中 → 成功/失败，申请中可取消
✅ 异常处理：银行接口超时，标记为「处理中」，异步查询结果，超时 5 分钟未返回走人工审核流程
✅ 埋点：点击提现按钮、提交申请、申请成功/失败，均上报事件
看到差距了吗？好的 PRD 不是「描述功能」，而是「穷尽场景」。开发不是不愿意做，而是不知道怎么做。
四、问答环节：读者常见问题
Q1：PRD 写太细会不会限制开发的发挥？
A：不会。PRD 的「细」是指边界清晰，而不是实现细节。你可以不写「用 Redis 分布式锁」，但要写「防止重复提交」。技术选型交给开发，业务规则由产品定。
Q2： checklist 这么多，每个需求都要检查吗？
A：看需求复杂度。一个简单的「公告展示」功能，可能只需要检查边界条件和异常流程；但涉及到交易、状态流转、权限控制的需求，建议全部过一遍。
Q3：开发不看 PRD 怎么办？
A：这是另一个话题了。但首先确保你的 PRD 值得被看。如果开发发现每次看你的 PRD 都能快速找到答案，而不是来问你，他们就会养成先看文档的习惯。信任是双向的。
五、结尾升华：PRD 是产品的「代码」
写代码要编译、要测试、要 Code Review。PRD 也一样。
开发吐槽你，其实是在帮你 debug。那些让你尴尬的问题，如果不在 PRD 阶段暴露，就会在测试阶段、上线后、用户投诉时暴露。
所以，下次被怼的时候，别急着反驳。掏出这份 checklist，微笑着说：「你说得对，我补充一下。」
毕竟，能写出让开发无话可说的 PRD，才是产品经理的终极浪漫。
🎯 今日金句
「好的 PRD 不是让开发无话可说，而是让开发无需多问。」
—— 萧闹闹，在被怼了 100 次后
觉得有用？点个「在看」，下次写 PRD 时翻出来对照。你的开发会感谢你的。