任务场景
PM 给你一段话的功能描述。工程要 user story + 验收准则才肯估点。你写过 50 次，明知道每次都要比想象中久。AI 可以拿这段描述和几条画像，先给你一份草稿，省去你对着白屏发呆。
哪些情况适合让 AI 来做
- 你每周要写 3+ 套 story，格式重复。
- 功能可识别（增删改查、通知、搜索、支付、设置）。
- 你想要”一份完整草稿用来修改”，不是从零脑暴。
- 多 squad 或多外包，要把 story 格式统一。
什么时候不要完全依赖 AI
- 全新的 UX——story 要在原型之后才能写。
- 受监管功能（医疗、金融），验收准则有法律含义，必须让领域专家逐行审。
- 技术债 / 平台类工作，“用户”是另一个工程师，story 格式套不进去。
需要先给 AI 的信息
- 3-5 句的功能描述。
- 1-3 个用户画像（身份、关心什么、当前在用什么工具）。
- 已知边界 case 和限制。
- “完成”的定义：你团队认为”上线了”是什么意思。
- 1-2 个写得好的过往 story 作为风格样例。
可直接复制的 Prompt
为这个功能写 user stories。
功能：{3-5 句描述}
画像：{列表 + 各自目标}
要覆盖的边界 case：{列表}
限制：{鉴权、权限、数据源等}
每个 story 的格式：
- 标题（短，动作导向）。
- "作为 [画像]，我想 [动作]，以便 [结果]。"
- Given/When/Then 验收：覆盖正常路径 + 至少 2 个边界 case。
- 不在范围（1 行）——本 story 不覆盖什么。
输出：
- 按优先级排好的 5-9 条 story。
- 末尾附一份"未覆盖清单"——你注意到但没写进去的事。建议让 AI 输出成什么样
干净的 story 集：5-9 条按价值排序，每条有紧凑标题、一句”作为/我想/以便”、3-6 条 Given/When/Then 验收、一行”不在范围”。最后那份”未覆盖清单”用于团队讨论缺口。
怎么判断 AI 的结果能不能用
- 每条验收读出声。能想象出点击流程吗？想不出就是太虚。
- story 是否独立可发？如果 story 4 必须等 story 7，合并或重排。
- AI 是否编了你没有的画像？删掉。
容易踩的坑
- 没验收的 story——规划会议会被退回。
- 一个大故事本应拆开。单条 story 估点不超过约 3 天。
- 跳过边界 case。Prompt 不列，AI 不会主动覆盖。
下一步怎么改得更好
每个 sprint 结束，记下哪几条 story 引发返工或 QA 漏测。把模式回喂：“这种 story 容易漏鉴权失败路径，请永远加一条未授权的 G/W/T。“你的 Prompt 每个 sprint 都会更准。
实操加深
做「用 AI 写 User Story：从功能想法到带验收的故事集」这类任务时，AI 输出质量主要取决于输入包是否完整。至少给它受众、原始材料、目标格式、你要做的决策，以及一好一坏两个参考。第一轮先要求保留事实，第二轮再优化结构、语气或表达，不要让模型一边猜事实一边润色。
拿到结果后单独做一次复核：有没有遗漏限制、编造细节、行动项不清、语气和真实场景不符。最终稿最好能马上使用，包含明确对象、下一步和判断标准，而不是还需要别人重新解释一遍。
FAQ
- AI 顺便写测试用例吗？能从验收准则出测试纲要——给 QA 搭脚手架可用，不能代替真测试。
- 一个功能多少 story？通常 5-9 条。超过 15 条就说明功能太大，拆。
- 能让 AI 估点吗？能猜，但别信；估点是团队校准的事。
相关阅读
标签: #工作流