一句话总结
PM 丢给你一段话。工程要 user story + 验收准则才肯估点。把这段话加上 1-3 个画像，喂给 Claude Opus 4.7 或 GPT-5.5，套用下面这套 Prompt，一分钟内就能拿到 5-9 条带 Given/When/Then 的草稿。然后你做模型做不了的事：逐条对照 INVEST、删掉它编造的画像、把超过约 3 天的故事拆开。模型帮你省掉对着白屏发呆的成本，判断仍然在你手里。
真正费时的是那张白屏
给 CRUD 界面写第 30 套 story 不难，只是烦。一烦就拖延动笔、边界 case 也只是扫一眼。这恰好是当下 LLM 擅长的活：格式可识别、结构清晰、你要的是一份用来挑刺的草稿，而不是从零想点子。
适合让 AI 来做的情况：
- 你每周要写 3+ 套 story，格式重复。
- 功能是常见套路（增删改查、通知、搜索、支付、设置、引导流程）。
- 你想要”一份完整草稿用来批改”，不是从零脑暴。
- 多 squad 或多外包，要把 story 格式统一。
不要依赖 AI、或只拿它当草稿纸的情况：
- 全新的 UX，story 要在原型之后才写得出来。先做原型，再写 story。
- 受监管功能（医疗、金融），验收准则有法律含义，必须让领域专家逐行审。
- “用户”是另一个工程师（平台、技术债）。画像式 story 格式套不进去，硬套只会产生噪音。
好故事长什么样：INVEST 与 Given/When/Then
在评判任何草稿之前，先用团队本来就在用的两把尺子去量。
INVEST 是一条能挺过规划会的 story 的检查清单：
| 字母 | 检验 | 快速失败信号 |
|---|---|---|
| Independent 独立 | 不用等兄弟 story 就能发 | ”story 4 得先做完 story 7” |
| Negotiable 可协商 | 描述需求，不锁死方案 | 标题里写满实现细节 |
| Valuable 有价值 | 真实用户能得到东西 | ”作为系统，我想……” |
| Estimable 可估 | 团队能估点 | 太虚，估不出 |
| Small 够小 | 一个 sprint 内，最好 ≤ 3 天 | 一个大故事 |
| Testable 可测 | 有明确的通过/失败标准 | 根本没有验收准则 |
Given/When/Then（来自 Cucumber/Gherkin 的 BDD 写法）是让 story 可测的方式。每条 story 建议 3-5 条验收：
Given 我是已登录、在账单页的订阅用户，
When 我点击"暂停订阅"并确认，
Then 我的状态变为"已暂停"，
And 我在当前周期结束前仍可使用，
And 我收到一封含重新激活步骤的确认邮件。如果你想象不出某条验收的点击流程，那它就太虚，不能上线。
需要先给模型什么
输入是垃圾，输出就泛泛。草稿有多具体，取决于你给的输入包：
- 3-5 句的功能描述。
- 1-3 个真实画像：身份、关心什么、当前在用什么工具。
- 已知边界 case 和限制（鉴权、权限、数据源、限流）。
- 你的”完成”定义：你团队认为”上线了”是什么意思。
- 1-2 个你自己过往写好的 story 作为风格样例，让输出贴合团队格式。
最后这一条最关键。贴一条你团队真写过的 story，模型对你的语气、颗粒度、验收写法的模仿，会远好过任何文字描述。
Prompt
在 Claude Opus 4.7 和 GPT-5.5 上实测过（2026 年 6 月）。把每个 [方括号] 换成你的具体内容。
你是一位资深产品经理，要写出工程团队能估点的 user story。
使用 INVEST 与 Given/When/Then。
功能：[3-5 句描述]
画像：[列表，每个附其目标]
要覆盖的边界 case：[列表]
限制：[鉴权、权限、数据源等]
我们的房屋风格（请对齐）：[贴 1 条真实的过往 story]
每条 story 输出：
- 标题：短，动作导向。
- "作为 [画像]，我想 [动作]，以便 [结果]。"
- 3-5 条 Given/When/Then 验收。覆盖正常路径，外加至少
2 个边界 case（如空状态、权限拒绝）。
- 不在范围：一行写本 story 不覆盖什么。
然后输出：
- 按用户价值排序的 5-9 条 story，每条独立可发。
- 末尾一份"未覆盖"清单：你注意到但没写进去的事，
让团队决定要不要补。
不要编造我没给你的画像或功能。若缺某个细节，
请放到"待澄清问题"里，而不是猜。最后一段是承重墙。没有明确的”不要编造、要问”这条指令，模型会用看似合理的虚构去填补缺失的上下文，你的复核时间就全花在删除不存在的画像上。
该用哪个模型
| 任务 | 最合适（2026 年 6 月） | 原因 |
|---|---|---|
| 结构化 story 草稿、严格格式 | Claude Opus 4.7 或 Sonnet 4.6 | 把”恰好 5 条验收、不提价格”当成硬约束执行；1M token 上下文能吞下整份 PRD |
| 在 Jira 里、调用你的 Confluence 规则 | Atlassian Rovo / Intelligence | 直接基于你已写好的文档起 story、扩验收；随 Jira Premium 附带（约 $13.53/人/月，年付） |
| 随手起一份再贴到别处 | GPT-5.5（ChatGPT） | 快、通用起草强；Plus $20/月 |
如果是纯文档生成、需要把长 PRD 装进上下文又要严格守格式，Claude 更稳；Sonnet 4.6 更便宜，每 1M token 进/出为 $3/$15，而 Opus 4.7 为 $5/$25，写 story 草稿通常 Sonnet 就够。如果你的 story 就住在 Jira 里，让 Rovo 直接对着你的 Confluence 业务规则写，能省一趟复制粘贴。
故事太大怎么拆
这里 AI 最常见的翻车，就是把本该拆成三条的写成了一个大故事。当一条草稿 story 装不进约 3 天，用 SPIDR（Mike Cohn）拆：
- Spike 探针 —— 团队还不知道怎么做时，先切出一个调研任务。
- Paths 路径 —— 功能的不同走法（刷卡 vs PayPal vs 余额支付）。
- Interface 界面 —— 一次只做一个平台或输入方式（先 Web，再移动端）。
- Data 数据 —— 先支持一部分数据（先国内地址，国际之后）。
- Rules 规则 —— v1 先放宽某条业务规则（先跳过批量折扣逻辑，之后再加）。
直接让模型做：“story 3 大于 3 天，请用 SPIDR 拆成纵向切片，每片独立可发。“纵向切片（从 UI 一路到数据）能交付价值；横向切片（“先搭 API 层”）不能。
五分钟怎么验草稿
- 每条验收读出声。 想不出点击路径？就是太虚。
- 逐条跑 INVEST，用上面那张表。最常挂的两项：Independent 和 Small。
- 抓编造的画像或功能。 不在你输入里的，删。
- 看”未覆盖”和”待澄清问题”两份清单。 真正的规划讨论就藏在这里。
- 确认每条 story 都有 3-5 条验收，且至少一条非正常路径。
容易踩的坑
- 没验收的 story，规划会议会被退回。在 Prompt 里把 G/W/T 写成不可省。
- 一个超大故事。封顶约 3 天，用 SPIDR 拆。
- 跳过边界 case。模型只覆盖你点名的那些，所以空状态、权限拒绝、超时路径都要明确列出。
- 信 AI 估的点。它只是在猜；估点是团队的速度与校准，模型拿不到。
让 Prompt 越用越准
每个 sprint 结束，记下哪几条 story 引发返工或 QA 漏测，再把模式回喂：“这种 story 老是漏鉴权失败路径，请永远加一条未授权访问的 Given/When/Then。“几个 sprint 下来，你的 Prompt 就把团队踩出来的教训沉淀进去，草稿需要动的刀也越来越少。
FAQ
AI 顺便写测试吗？ 能把验收准则变成测试纲要或 Gherkin 场景，是有用的 QA 脚手架，但不能代替工程师亲手写、亲手跑的测试。
一个功能多少 story？ 通常 5-9 条。如果出到 15 条，说明这是个 epic，估点前先拆。
能让 AI 估点吗？ 能猜，但别信。点数反映的是团队速度与校准，模型完全接触不到。
写这个用 Claude 还是 ChatGPT？ 论严格格式、长上下文的 story 起草（2026 年 6 月），Claude Opus 4.7 或 Sonnet 4.6 守约束更稳。如果你的 story 本来就在 Jira 里，让 Atlassian Rovo 基于 Confluence 规则起草最省步骤。
工程师会信 AI 起的 story 吗？ 只有你改过才会。直接甩一份原始草稿，信任很快就掉。把输出当成由你署名负责的第一版草稿，而不是成品。
相关阅读
标签: #工作流