用户故事翻车基本就两个原因：一个 sprint 做不完，或者太模糊导致 QA 写不出测试。下面这套 Prompt 强制原子形态、可测的 Given/When/Then 验收（AC），并显式覆盖边界和反路径——这恰恰是 AI 草稿最爱跳过的部分。把一段特性、一个 bug 或一份访谈记录粘进去，直接拿到可进 backlog 的工单。
一句话总结
- 12 个 Prompt 对应真实的梳理场景：拆特性、挖 edge case、拆大故事、给 backlog 排序、生成 API 契约。
- 每个 Prompt 都要求明确 persona（绝不写”用户”）、验收用数字而不是形容词、该有回归测试的地方必须有。
- backlog 和访谈记录很长时，丢给 1M token 的模型——Claude Opus 4.7、Gemini 3.1 Pro 或 GPT-5.5（截至 2026 年 6 月均为 1M 上下文）。临时拆个把故事，免费档就够。
- 想看从想法到 backlog 的完整流程，参考用 AI 写 User Story；专门看验收那一层，参考验收标准 Prompt。
这套 Prompt 适合用在哪
- 敏捷团队（Scrum / Kanban）的 sprint 规划与梳理
- vendor / 外包交付，模糊就是真金白银的损失
- 快速写 Jira 或 Linear 工单
- 把 PRD 转成 backlog
- 把 bug 报告和访谈笔记反推成能力点
用哪个模型（2026 年 6 月）
三家前沿模型写故事都不差，差距在规模上才显出来。
| 模型 | 上下文 | 写故事时强在哪 | 备注 |
|---|---|---|---|
| Claude Opus 4.7 | 1M token | 长访谈、依赖推理、验收严谨度 | Pro 20 美元/月，Max 100/200 美元 |
| Gemini 3.1 Pro | 1M token | 一次性粘整份 Confluence PRD | Google AI Pro 19.99 美元/月 |
| GPT-5.5 | 应用内约 320 页（Plus）；200 美元 Pro 才给满 1M | 快速拆单条故事，排优先级时用 picker 的 Thinking 模式 | Plus 20 美元/月 |
如果你本来就泡在工单系统里，AI 已经内置了：Atlassian Rovo 在 Jira 里直接起草工单，Linear 能把一句话几秒内变成 spec（截至 2026 年 4 月，Linear AI 已并入其付费档，不另计 token 费）。Jira Standard 月付约每人每月 8 美元（年付更便宜）；Linear 免费档封顶 250 个 issue，再多就得升级付费档。不管你在哪起草，都用下面的 Prompt 把质量底线立住。
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 个故事。请按 影响 x 成本 用 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 输出。
[粘贴]怎么验收 AI 给你的东西
每条生成的故事过一遍 INVEST（Bill Wake 的清单）：Independent（独立）、Negotiable（可协商）、Valuable（有价值）、Estimable（可估）、Small（够小）、Testable（可测）。“够小”不过关就丢进 Prompt 11；“可测”不过关就丢进 Prompt 8。SPIDR（Mike Cohn）是配套的拆分法——一个健康的 sprint 大概装 6-10 条 INVEST 尺寸的故事，所以 AI 估出来超过 3 天的，都是要拆的候选。把模型当快速初稿手，而不是产品经理：它很乐意编 persona、堆验收，凡是没落到你真实用户身上的，统统删掉。
容易踩的坑
- 故事太大一个 sprint 出不完（用 SPIDR 拆，Prompt 11）
- 验收不可测——“页面应当流畅”不是验收；“4G 下首屏内容渲染在 1.5 秒内”才是
- 一个故事塞多个（一条 Given/When/Then 就一条故事）
- 反路径和 edge case 拖到 QA 在 staging 才发现
- 角色写”用户”——没 persona 就没真正可测的收益
- AI 输出不改就用；模型不懂你的数据模型，只能瞎猜
常见问题
哪个 AI 模型写用户故事最好？ 日常起草哪个都行。但规模一上来——30 分钟访谈记录或整份 PRD——就用 1M token 的模型：Claude Opus 4.7、Gemini 3.1 Pro 或 GPT-5.5（截至 2026 年 6 月均为 1M 上下文）。Opus 4.7 在验收严谨度和依赖推理上通常最强；如果你的文档本来就在 Google Workspace 里，Gemini 3.1 Pro 最顺手。
该用这套 Prompt 还是直接用 Jira 内置 AI？ 两个都用。Atlassian Rovo 和 Linear 的 AI 适合在你本来工作的地方起草工单，但它们套的是团队默认话术，不是 INVEST/SPIDR 那套纪律。把这套 Prompt 粘进去把底线拔高，再把整理好的故事搬进工单系统。
用户故事和验收标准有什么区别？ 故事说清楚谁、做什么、为什么（“作为 [persona]，我想 [动作]，从而 [收益]”）。验收是证明它做完了的可测条件，通常写成 Given/When/Then。一条故事一般有 3-5 条验收。要专门的验收 Prompt，参考验收标准 Prompt。
一条故事该多大？ 小到单个工程师 3 天内能出，小到一个 sprint 能装 6-10 条。再大就先用 SPIDR 拆了再估。
AI 能估故事点吗？ 它能给相对尺寸建议、标出离群值，但它看不到你的代码库和团队速率，所以它给的人日数字只当团队自己估算的起点，别当最终值。
相关阅读
标签: #Prompt #产品创业 #User Story