PRD 翻车，多半是只列特性不给上下文——没说”为什么这个”、“为什么现在”、“不做什么”。工程各自脑补，scope 第二周开始膨胀，发布指标到上线那天还没人定。下面这些 Prompt 强制 PRD 必备的 4 件事：带具体用户的问题、可衡量的目标、明确的”不做”清单、暴露所有 open question。要先搭骨架，配合 PRD 大纲 Prompt 一起用。
这套 Prompt 适合用在哪
- 新特性 scope
- MVP 定义
- 跨团队对齐
- Vendor / agency brief
- 集成与平台工作
- 下线 / 迁移
1. 特性 PRD（1 页）
特性：{1 句摘要}。
受众：{persona——角色、场景、当前替代方案}。
要解决的问题：{pain——附 1 句用户原话或数据}。
请出 1 页 PRD，含：
- 问题（带证据）
- 用户与场景
- 目标与成功指标（可衡量）
- scope：含 / 不含（各至少 3 条）
- 5 步 happy path
- edge case（≥5）
- 依赖与假设
- open question
每节 ≤80 字。任何一节都不许写 "TBD"。2. Epic PRD（2 页）
Epic：{名}。
时间窗：{季度}。
对应的战略目标：{公司级目标}。
请出 2 页 PRD：
- 市场背景（什么变了、为什么现在）
- 用户洞察（这一 Epic 押在的那条信念）
- 成功指标 + 一条 tripwire 指标
- 假设写成 "若发 X，则 Y，因为 Z"
- 里程碑与大致日期
- 风险按优先级排
- 跨团队依赖与点名 owner
- 3 件明确不在这一 Epic 范围内的事3. MVP PRD
产品想法：{1 段}。
若证伪就停项目的那条信念：{信念}。
请出 MVP PRD：
- 能交付用户价值并验证那条信念的最薄切片
- 砍掉的、后续版本要的（列 5 条）
- MVP 能学到什么，以及"继续往下做"的指标 / 阈值
- 成功标准拆成"发出去 / 有人用 / 真喜欢"
- 估算工期：人周（区间）
- 杀项目条件：什么情况下停4. 从原型出 PRD
下面是原型 / 线框描述。
请转 PRD：
- 5 步用户流（含进入与退出点）
- 字段与数据（名、类型、校验、是否必填）
- 校验规则（白话）
- 错误态（≥4）
- 空态（≥3）
- 加载 / 异步状态
- 原型里没体现的 edge case
原型留下的歧义动作，统一列在末尾。
{粘贴原型描述}5. Vendor brief
我要请 {vendor / agency 类型} 做 {scope}。
预算区间：{}. 截止：{日期}.
请写 vendor brief：
- 要什么（带例子）
- 明确不要什么（带例子）
- 交付物与文件格式
- 里程碑 + 对应付款触发
- 验收标准（客观、可测）
- IP 条款（白话）
- 沟通节奏
- 一段"什么情况下我们会终止合作"6. 含明确”不做什么”的 PRD
为 {feature} 写一份 PRD，30% 篇幅放"明确不做"。
列 5-7 个被默认会含但其实不在 scope 的：
- 哪个 stakeholder 会默认包含
- 不做的原因（成本 / 依赖 / scope 纪律）
- 什么时候会重新评估（版本号或触发条件）
然后是常规 PRD（问题、用户、目标、scope-in、UX、指标、风险）。
输出顺序：先放"不做"清单，让 reviewer 第一眼看到。7. 含风险登记的 PRD
为 {feature} 写 PRD，含真正的风险登记。
风险登记格式：
- 至少 5 条
- 每条：描述、类别（技术 / 市场 / 组织 / 法务）、概率（低 / 中 / 高）、影响（低 / 中 / 高）、缓解、owner
- 按 概率 × 影响 排序
- 1 条明确标"我们接受这个风险"
外加常规 PRD 节，从简。8. 集成 / 平台 PRD
集成：{我们的产品} ↔ {对方产品 / API}。
方向：{单向拉 / 单向推 / 双向}。
请出 PRD 覆盖：
- 用户结果与触发
- 数据模型：什么字段流向哪里（含 PII）
- 鉴权模型与 token 生命周期
- Rate limit 与 backoff 策略
- 失败模式与给用户的错误提示
- 版本：对方 API 变了怎么办
- 隐私与合规备注
- 监控与 on-call 告警9. 下线 / 迁移 PRD
我们要下线 {feature}，迁移到 {新路径}。
受影响用户：{细分 + 量级}。
硬截止日：{日期 or "待定"}。
请出下线 PRD：
- 为什么要砍
- 谁受影响、怎么影响
- 迁移路径（手动 / 自动 / 混合）
- 沟通时间表：T-90、T-30、T-7、当天、之后
- 迁移失败的回滚方案
- 成功指标（如 Y 日前老路径 < X% 用户）
- 我们承诺迁移中不会破坏什么10. A/B 实验 PRD
实验：{要测的} vs {对照}。
请出实验 PRD：
- 假设："若改 X，则主指标移动 Y，因为 Z"
- 主指标与测量方式
- 护栏指标（≥2），不许回退
- 样本量与预计时长（标假设）
- 受众与排除条件
- 各 variant 的具体差异
- 决策规则：发布 / 砍 / 迭代
- 预先声明的"这次实验上不做的决定"11. PRD review——对抗式批评
下面是我的 PRD 草稿。
请以挑剔 reviewer 的身份批评：
- 问题是否清晰，是不是个真问题（而不是"找解决方案"找出来的）？
- 成功指标是否可衡量，是不是对的指标（不是虚荣代理）？
- 给定时间，scope 是否现实？
- open question 是否暴露，还是藏在假设里？
- 缺什么会让工程第 1 天就卡住？
- scope 里哪些不配占位？
输出：5 个亮点、5 个修复、分享前必须回答的 1 个问题。
{粘贴 PRD}12. 从用户访谈出 PRD
下面是 {N} 次用户访谈的笔记，主题 {topic}。
请综合成一份 PRD 前置 brief：
- 反复出现的 pain（附原话证据）
- 用户已经自创的 workaround，以及它哪里不够
- "如果你能挥魔杖"的请求，聚成 3 类主题
- 能放在 PRD 开头的那 1 句原话
- 反信号：哪些人没这个问题、为什么
- 建议的成功指标，要用上访谈里出现过的措辞
末尾：写 PRD 前还想再访谈一次确认的 2 件事。
{粘贴笔记}容易踩的坑
- 没有成功指标，或指标只是”把功能发出去”
- 没有”不做什么”——scope 必膨胀
- 把假设伪装成事实（“用户会……”）
- edge case 写 “TBD”——工程会替你定，且你不会喜欢答案
- 一份 PRD 同时承担愿景文档、规格、上线计划