用户故事翻车原因就两个：一个 sprint 做不完，或者 QA 写不出测试。下面这套 Prompt 强制原子形态、可测验收、显式覆盖边界和反路径。想看从特性想法到带验收的完整故事集，参考用 AI 写 User Story。
这套 Prompt 适合用在哪
- 敏捷团队（Scrum / Kanban）
- Sprint 规划与梳理
- vendor / 外包交付
- JIRA / Linear 工单
- PRD → backlog 转化
1. 从特性拆故事
特性：{描述}。请拆成原子用户故事。每条要求：
- 用"作为 {角色}，我想 {动作}，从而 {收益}"格式
- 单工程师 ≤3 天可出货
- 3-5 条 Given/When/Then 验收
- 角色写出明确 persona，不要"用户"
按 markdown 表格输出：故事 | 角色 | 验收数 | 估时（天）。2. edge case 故事
主流（happy path）：{描述}。请写 5 个必须处理的 edge case 故事：
1. 错误态（如 API 挂了）
2. 空态（还没数据）
3. 最大态（边界 / 溢出）
4. 并发态（两个用户同时操作）
5. 慢网态（降级性能）
每条完整验收。标 MVP 和 P2。3. 反路径故事
为 {feature} 写 4 个反路径故事。每条含：
- 用户不应能做的动作
- 系统必须阻止的（权限、校验、限流）
- 阻止如何告知（报错文案、UI 禁用、静默失败）
- 回归测试断言
按完整故事 + 验收格式写。4. 故事优先级
下面 12 个故事。请按 影响×成本 用 2x2 排。每条：
- 影响 1-5 分，一行说明并挂到指标
- 成本按人日
- 象限归位（速胜 / 大赌 / 凑数 / 时间黑洞）
标 MVP 必备和延到 v1.1 的。
{粘贴}5. 故事 → 任务
为下面的故事拆 5-8 个实现任务。每个：
- 工作量 ≤1 天
- 归一个角色（设计、后端、前端、QA、devops）
- 有明确"完成"定义
- 标依赖顺序
测试任务和开发任务分开。
{粘贴}6. 故事依赖图
下面是故事。请识别依赖（故事 A 阻塞故事 B）。输出：
- 文本格式 DAG（标出边）
- 关键路径（最长链）
- 按 sprint 分组的建议出货顺序
- 无依赖故事（任何时候可出）
{粘贴}7. 模糊故事改写
下面 5 个模糊故事。请改写至：
- 角色是具体 persona，不要"用户"
- 动作是系统要支持的动词，不是结果描述
- 收益可测可量，不要"体验更好"
- 验收无歧义（不要"应当很快"——给数字）
新旧对照展示。
{粘贴}8. 验收检查
下面是故事 + 验收。请审计并标出：
- 不可测的验收（含"流畅"、"直觉"这种主观词）
- 缺反路径验收（只覆盖了 happy path）
- 隐藏多个故事的验收（一条 Given/When/Then 应只对应一个故事）
- 重复 UI 设计而非行为描述
对每条标记给出改写建议。
{粘贴}9. 从 bug 反推故事
Bug 报告：{粘贴}。底层是某能力缺失。请反推成 1-2 条用户故事——如果当时出货了，这类 bug 就不会发生。验收必须包含这个具体 bug 的回归测试。10. 从用户访谈出故事
下面是 30 分钟用户访谈记录。请提取 4-6 条受访者隐含（不是字面要求）的用户故事。每条含：
- 支撑它的原话引用
- 从上下文推断的 persona
- 基于他描述的工作流的验收
标出"看起来像故事其实只是吐槽"的，不该做。
{粘贴记录}11. 拆大故事
下面是一个 sprint 装不下的大故事。请按 SPIDR（Spike、Path、Interface、Data、Rule）拆分。输出：
- 用了哪种技术
- 每个子故事 ≤3 天
- 哪个子故事是"最薄但有价值的切片"（先出）
- 哪些延后、为何延后安全
{粘贴}12. 故事 → API 契约
为下面故事起草满足验收所需的 API 契约：
- 端点、方法、路径
- 请求 schema + 示例
- 响应 schema：成功 + 每种错误情况都给示例
- 状态码映射到验收条目
- 幂等 / 鉴权要求
按 OpenAPI 风格 YAML 输出。
{粘贴}容易踩的坑
- 故事太大一个 sprint 出不完（用 SPIDR 拆）
- 验收不可测——“页面应当流畅”不是验收
- 一个故事塞多个（一条 Given/When/Then 就一条故事）
- 反路径和 edge case 拖到 QA 在 staging 才发现
- 角色写”用户”——没 persona 就没真收益
相关阅读
标签: #Prompt #产品创业 #User Story