“做一个类似某某APP的产品”不是可执行需求。参考产品只能说明大致方向，不能解释你的用户是谁、业务规则有什么不同、哪些功能首版不做。
一份好PRD应让团队在开发前暴露分歧，而不是上线后通过Bug和返工再理解需求。
01 第一部分先写为什么做
说明业务背景、目标用户、当前问题、阶段目标和成功指标。目标应能指导取舍，例如“让新用户在五分钟内完成首次预约”，而不是“打造领先平台”。
同时写清不在本期范围的内容，避免所有想法被默认包含。
02 用角色与场景组织需求
列出用户、运营、客服、管理员、合作方等角色，以及各自目标、权限和关键任务。不要只写一张统一功能列表。
每个核心场景描述触发条件、前置条件、主要步骤、异常和完成结果。
APP PRD建议结构
| 章节 | 必须回答的问题 | 主要交付 |
|---|---|---|
| 背景与目标 | 为什么做、衡量什么 | 目标、指标、非目标 |
| 用户与角色 | 谁使用、权限为何不同 | 画像、角色权限表 |
| 范围与优先级 | 首版做什么、不做什么 | 功能清单、MVP |
| 流程与规则 | 任务怎么走、如何分支 | 用户流程、业务规则 |
| 页面与状态 | 用户看到什么 | 页面清单、状态矩阵 |
| 数据与接口 | 字段、来源、同步方式 | 数据字典、接口依赖 |
| 非功能要求 | 性能、安全、兼容、可访问性 | 质量标准 |
| 验收与上线 | 怎样算完成 | 验收用例、发布计划 |
03 业务规则要写成可判断条件
“符合条件可以申请”应进一步写清条件、数据来源、优先级、边界值和失败提示。规则若只存在于某个业务人员脑中，开发无法稳定实现。
复杂规则可用决策表、状态机和示例数据，通常比长段落更清楚。
04 页面清单必须带状态
除了正常页面，还要覆盖空、加载、错误、无网络、无权限、审核中、被拒绝和数据冲突。
页面数量不是简单把功能数相加。一个关键页面可能因为角色和状态产生大量差异。
05 非功能要求不能放到最后一句
性能、并发、日志、安全、隐私、兼容、备份、监控和可访问性会影响架构与成本。若开发后期才提出，通常代价更高。
不确定的指标可以标记为待验证，但不能完全省略。
06 让设计、开发和测试共同评审
设计关注用户路径和信息，开发关注规则、依赖与边界，测试关注可验证性。三方评审能提前发现大量问题。
需求变更后更新版本与变更记录，避免群聊中的新决定没有进入正式文档。
常见问题
PRD需要写到每个按钮吗？
核心行为、状态和规则需要明确；纯视觉细节可在设计规范中说明，避免文档重复。
没有产品经理可以写PRD吗？
可以由业务负责人、设计或项目经理协作完成，关键是有人对范围和决策负责。
原型能不能代替PRD？
不能完全代替。原型展示交互，复杂规则、数据、权限和非功能要求仍需文字或表格。
需求还不确定时怎么写？
标注假设、待验证项和决策截止时间，先通过研究或原型降低不确定性。
PRD写完后还能改吗？
可以，但要记录原因、影响、版本和确认人，并重新评估周期与成本。
链接复制成功
