开发看完需求文档，回了一句：这个字段为空时显示什么？产品经理愣住，文档里只写了「展示用户昵称」。一份 PRD 卡在这种地方，评审会能开成猜谜会。

PRD 是产品需求文档，读者是开发、测试、设计和运营，不是给老板看的汇报材料。它要把做什么、给谁做、什么算做完讲清楚；篇幅不重要，能把歧义消掉才有用。十几页全是背景分析，关键规则藏在附件里，开发照样得追着问。

开头先写清目标和边界

一句话说明这次要解决什么问题，再列不做什么，比如「本次只做手机号登录，微信登录下期再说」，能省掉一半扯皮。目标别写成「提升用户体验」，改成「注册转化率从 40% 提到 50%」这种能验证的说法，后面复盘才有依据。范围写清楚，后面加需求时也好判断是本期做还是下期做。

流程和字段是重灾区

主流程画一张图，异常分支单独列：网络断了、重复提交、权限不够、数据为空，各显示什么；字段表至少包含名称、类型、长度、是否必填、默认值、校验规则、示例。手机号 11 位、验证码 6 位、昵称 2 到 12 个字，这些写清楚，开发和测试都不用猜。状态流转画成状态机，待支付、已支付、已发货、已取消，谁能改、改了能不能撤回，都要写明。

验收标准要能逐条打勾

每条需求配一到三条验收条件，用「当……时，系统应……」的句式。比如「当用户连续输错 5 次密码，账号锁定 15 分钟，并提示剩余时间」。埋点也顺手写上，事件名、触发时机、携带参数，不然上线后数据对不上，又得返工；验收条件尽量可观测，别写「体验流畅」这种测试没法判断的话。

版本和变更留痕

文档开头放版本号、修改人、日期，改动用批注或修订记录。口头确认的结论补进文档，别只留在聊天记录里。评审结束把待办列成清单，谁负责、什么时候给，比一句「大家再看下」有用得多。

PRD 不是越厚越专业，能让开发照着做、测试照着验、上线后能复盘，就够了。写之前先想清楚异常情况，比事后补十页说明都值。文档写完先让开发和测试各读一遍，他们提的问题就是下一版要补的洞。