一份合格的 PRD 要包含哪些部分？

我的 PRD 结构：背景与目标——为什么做、衡量指标；用户与场景——谁在什么情况下用；需求范围——本版做什么不做什么；功能详述——流程图、字段定义、状态说明、异常分支；数据需求——埋点与报表；非功能——性能兼容安全；验收标准。我认为最关键的是『不做什么』和异常分支——多数扯皮发生在这里。

我讲演化：早期我的 PRD 被开发吐槽『看不懂要做什么』，因为只写了正常流程。之后我固化模板：每个功能必须配状态机图——所有状态与流转条件；每个输入框必须配字段表——类型、长度、校验、默认值；每个流程必须有异常分支表——网络失败、数据为空、权限不足、并发冲突。评审通过率显著提高，开发过程中的提问量降了七成。

资深视角：PRD 的本质是沟通契约与决策记录，写什么取决于读者风险——把开发、测试、设计最可能误解与遗漏的部分写透。三个进阶实践：可测试化——每条需求写 Given-When-Then 式验收，测试直接引用；决策留痕——关键取舍记录备选方案与放弃原因，半年后没人记得为什么这么做；活文档——与原型和数据字典联动，单一事实来源避免多文档漂移。

追问『PRD 写多细』：详略按变更成本——改代码贵的写细（接口契约、数据结构），表现层可留给设计走查；『敏捷还要 PRD 吗』：形式简化（用户故事加验收标准）但契约性质不变；『怎么防止文档过时』：版本化加评审机制，文档与需求变更绑定，不接受口头改需求。