PRD 结构
背景与目标：为什么做这个功能？解决什么问题？成功的标准是什么？
用户故事：作为 [角色]，我想要 [功能]，以便 [价值]。一句话说清楚需求的本质。
功能描述：详细的功能逻辑、交互规则、边界条件、异常处理。这是 PRD 的核心。
非功能需求：性能指标、兼容性要求、安全约束、数据埋点方案。
排期与里程碑：开发周期、上线计划、灰度策略。
写作原则
无歧义：每个描述只能有一种理解。大概、可能、尽量是 PRD 的天敌。
可测试：每个功能点都能被 QA 验收。如果你写不出测试用例，说明需求还没想清楚。
图文并茂：一图胜千言。交互原型比文字描述更直观。
版本管理：每次修改记录变更原因、修改人、修改日期。历史版本要可追溯。
常见问题
- PRD 变成了设计稿——描述怎么做而不是做什么，限制了研发的实现空间
- 过度设计——试图在文档里解决所有问题，忽略了沟通的价值
- 缺乏优先级——所有需求都是 P0，就等于没有 P0
- 写完就扔——PRD 是活文档，应该随项目推进持续更新