产品需求场景的提示词库
2026-10-19需求文档的提示词重点是边界
AI 写 PRD 最大的问题是"什么都写了，但没写边界"：异常怎么处理、什么情况下不做、谁有权限。这些恰恰是开发最需要、也最容易在需求里漏掉的部分。
所以这一组提示词的共同做法是：强制它输出"不做什么"和"边界条件"，而不是只描述正常流程。
1. 用户故事（带验收条件）
帮我把需求拆成用户故事。
【需求】（一句话说明要做什么）
【用户是谁】（具体角色，不同角色可能要拆不同故事）
【已知约束】（技术、时间、合规等）
每条故事按这个格式：
- 作为（角色），我想要（能力），以便（价值）
- 验收条件（3-5 条，每条都是可判定的，写成"当…时，应…"）
- 不包含（明确写出这条故事不处理什么）
- 依赖（需要哪个先做）
【必须额外输出】
1. 异常路径：列出这个功能可能失败的 5 种情况，以及各自的处理方式
2. 边界条件：数量、长度、并发、超时、权限的临界值
3. 待确认清单：开发一定会问但需求里没写清的问题
【禁止】
- 验收条件不写"用户体验良好"这类无法判定的表述
- 不把多个角色的需求混在一条故事里2. PRD 骨架（先骨架，再填充）
帮我搭一份 PRD 骨架。先只给目录和各节要点，不要写正文。
【功能】（做什么、给谁）
【背景】（为什么要做，现在怎么凑合解决的）
目录至少包含：
1. 背景与目标（含一个可衡量的成功指标）
2. 用户与场景
3. 功能范围（明确"本期做"与"本期不做"两栏）
4. 详细流程（主流程 + 异常流程）
5. 边界与约束（数量、权限、并发、兼容）
6. 数据与埋点（要记录什么，用来验证什么）
7. 上线与回滚方案
8. 风险与待确认
【要求】
- 每节给 2-4 条要点，让我确认后再展开
- 第 3 节"本期不做"必须写出理由，不能留空
- 第 7 节必须有回滚触发条件
【最后】
指出这份 PRD 里最容易在开发阶段返工的一节，为什么。3. 竞品拆解（看它做什么，也看它不做什么）
帮我拆解一个竞品的功能设计。
【竞品】（名称 + 我观察到的事实：截图、流程、收费方式）
【我要做的功能】（用于对比）
【输出】
1. 它解决的核心问题是什么（一句话）
2. 主要流程：用户从进入到完成的路径，逐步列出
3. 它主动放弃了什么：找不到某功能、某场景被简化、某类用户被排除——这是重点
4. 它的取舍意味着什么：它假设用户是谁、假设了什么约束
5. 与我的对比：相同点 / 差异点 / 我可以不做的部分
【要求】
- 只写我提供的事实，没有观察到的写"未观察到"，不要推测
- 不评价"好用/难用"，描述机制
- 差异点必须说明这个差异对用户意味着什么
【最后】
如果我只抄它最核心的一点，抄哪一点收益最大。4. 需求评审（当反方）
以"最可能反对这个需求的人"的身份评审。
【需求文档】（粘贴）
【反对者的立场】（如：开发负责人 / 运营 / 财务 / 合规，选一个）
【逐项质疑】
1. 价值：这件事真的解决了用户问题吗，证据是什么
2. 必要性：不做会怎样，有没有更小的替代方案
3. 成本：开发和维护成本被低估在哪
4. 边界：异常流程缺失在哪几条
5. 度量：上线后怎么判断成功或失败
6. 风险：最坏情况下会出什么事
【输出】
按"必须澄清 / 建议补强 / 可以接受"三档，每条引用文档原句。
不要给出"建议做得更好"这种笼统意见。
【最后】
用一句话说：如果只能问一个问题来决定要不要做，问什么。怎么用
- 用户故事一定要有"不包含"那一栏。这是控制范围蔓延最有效的一行字。
- 异常路径让它列 5 种。多数需求文档只写主流程，漏掉的异常是上线后 bug 的主要来源。
- PRD 先出骨架再展开。直接要正文会得到一份看起来完整但每节都很浅的文档。
- 竞品拆解重点看"它放弃了什么"。取舍比功能列表更能说明它的战略。
- 评审时指定一个具体反对者立场。让它"综合评审"会得到四平八稳的意见。
常见误区
- 只写主流程。异常与边界缺失是返工的头号原因。
- 验收条件写成形容词。"流畅""友好"无法判定是否达成。
- 竞品分析只列功能表。那不叫分析，叫清单。
- 让它给"综合评审意见"。没有立场的评审等于没有评审。