任务场景
你脑子里有一个功能想法（或者它埋在某个 Slack 频道里），下次产品评审之前你需要它变成一份 PRD。这份 PRD 要具体到工程能估时、设计能画稿、老板能在一堆事情里给它排优先级。没有 PRD 时，讨论会循环好几周；写得太虚时，团队会做出来错的东西。
哪些情况适合让 AI 来做，哪些情况不要
AI 很会把一段背景信息整理成 PRD 的”形状”——它会主动提醒你写非目标、成功指标、边界情况、待定问题，这些是你最容易忘的。但 AI 不擅长替你决定功能应该做什么。把 AI 的草稿当成”逼问清单”：每个被它填了占位符的位置，都是你还欠一个真答案的位置。涉及法律、定价、数据合规时，绝不要让 AI 凭空补内容。
需要给 AI 的输入信息
- 一句话功能想法（说人话）
- 用户问题，以及引用、工单、行为数据
- 业务背景（这件事挂哪个 OKR / 战略赌注）
- 硬约束（截止日期、人手、技术栈、合规）
- 明确不做什么——能划出去的范围越多，PRD 越好用
可直接复制的 Prompt
你正在给内部产品团队写一份 PRD。
想法：<一句话>
用户问题和证据：<引用、工单、数据>
业务背景 / OKR：<赌注>
硬约束：<截止、技术栈、合规>
不做的范围：<列表>
请按下面顺序输出 PRD：
1. 问题陈述（3-5 句，不要术语）
2. 目标（最多 3 个，每个可衡量）
3. 非目标（至少 3 个，明确不做的事）
4. 目标用户和主要场景
5. 功能需求（编号，每条可测）
6. 非功能需求（延迟、可达性、隐私）
7. 成功指标（先行 + 滞后，带目标数）
8. 待定问题（工程或设计还要拍板的事，带 owner）
9. 灰度方案（feature flag、放量节奏、kill switch）
没有证据的位置请写"TBD —— owner: <角色>"，不要瞎编。如果想要更狠的版本，可以再追加一轮：“现在帮我把上面这份 PRD 反着审一遍：哪些假设会让它翻车？哪个指标会被刷？“
建议让 AI 输出成什么样
一份 PRD 的理想形态：每节一个 H2、需求用 bullet、指标用表格（指标 / 定义 / 当前 / 目标），待定问题用列表写出 owner。工程师不用看完战略部分就能找到功能需求。
怎么判断 AI 写出来的草稿能不能用
- 每个目标都有数字、时间窗、衡量方式
- 非目标存在，且具体（不是”我们不做 CRM”这种废话）
- 每条功能需求都能用一句话写成测试用例
- TBD 都有 owner，不是孤零零一个问号
- “不做的范围”里的内容没在需求里悄悄出现
容易踩的坑
- 让 AI 凭空补”提升 25% 互动”这种没基线的指标
- PRD 没有非目标——任何缺非目标的 PRD 在落地时都会膨胀 40%
- 把功能需求和非功能需求混在一个 bullet list 里
- 把 AI 的草稿直接贴进 Notion 没删 TBD——干系人会把占位符当成已经定下来的范围
- 一个人闭门造车直接出。AI 用来起草可以，但落到估时前必须经过工程 / 设计 / 数据 review
FAQ
- PRD 要不要附 UI 稿？ 不用。PRD 描述行为，不描述像素。可以在”待定问题”里贴 Figma 链接，等设计交付。
- 一份好 PRD 多长合适？ 每节一屏 bullet 就够了。如果你的 PRD 有 12 页，那是战略文档，不是 PRD。
- AI 能估开发工作量吗？ 不能，也不要让它估。估时必须由真正改过这个代码库的人来做。
相关
- PRD 草稿 Prompt 集合 ——更多 Prompt 写法和章节模板
- 写用户故事 ——把 PRD 的需求拆成敏捷用户故事
- 功能优先级 ——PRD 写完后，再决定要不要现在做
- PRD 大纲 Prompt ——比完整 PRD 更轻量的大纲起点