PRD 结构
每份产品需求文档应包含的标准字段。
为什么
PRD 是产品想要什么和工程造什么之间的契约。没有共享结构，每个 PM 自创字段，工程师每次评审第一小时都在找验收标准藏哪了。固定结构——问题、用户、需求、成功指标、范围外——意味着读者 5 分钟扫完任何 PRD 就知道造什么、为什么。结构还迫使 PM 在工程开工前回答难题（什么不在范围内？）。
何时使用
任何 ≥1 个迭代的特性开工前。写好需 2-4 小时。修 bug 和琐碎调整可跳过。
如何做
1. 问题陈述——2-3 句：谁受苦、怎么受苦、不解决的代价 2. 目标用户——哪个细分，一行人设参考 3. 需求——编号列表，每条有明确的"完成长什么样" 4. 成功指标——怎么衡量这成了（如"注册转化 +2pp"） 5. 范围外——明确列出我们不造什么（这字段最有价值） 6. 待决问题——开工前需决策的未决项 7. 时间线——设计冻结、构建完成、上线的目标日期 8. 和工程+设计+QA 负责人评审；在文档里记录签字
示例
# PRD：从 git 提交一键生成发布说明 ## 问题 发布经理每次花 2 小时手写说明，30% 的发布漏掉安全修复。 ## 目标用户 10-100 人团队的平台工程师，用 GitHub + 约定式提交。 ## 需求 1. 给定标签范围，生成按提交类型分组的 markdown 摘要 - 完成 = 输出对 95% 的发布匹配团队现有模板 2. 自动检测安全相关提交并在"安全"区标记 ## 成功指标 - 200 提交范围生成 < 30 秒 - 上线 1 个月内 80% 团队采用 ## 范围外 - 多仓发布说明（v2） - Slack 集成（v2） ## 待决问题 - 要支持 gitlab 吗？（03-20 前需决策）
常见问题
- ⚠跳过范围外字段——没有它，范围蔓延不可避免，因为每个干系人都以为自己的要求在内。
- ⚠把需求写成能力（"系统应当…"）而非可测行为——工程师估不了不可测的东西。
最佳实践
- ✓PRD 控制在 2 页——更长说明特性太大，应拆成多份 PRD。
- ✓把 PRD 链到已验证想法文档和它依赖的 ADR，让想法→决策→规格全链可追溯。
- ✓每份 PRD 标日期和版本；构建中范围变化时建新版本而非静默改。