AC 翻车几乎都从”用户可以登录”这种话开始：成功长什么样、失败长什么样、慢网、会话过期一概没写，QA 自己脑补覆盖、工程少写一半边界，bug 单一路涨。下面这 12 个 Prompt 强制每条都可测，把 happy / 负向 / 非功能拆清，写出来的 AC 能扛得住 sprint planning 上挑刺。上游用户故事本身的范围问题，先用 MVP 范围 Prompt 处理掉，免得给不该做的功能写 AC。
一句话总结： 把故事粘进 1 号拿到 Given/When/Then 初稿，再用 2 到 4 号补齐边界、负向、非功能覆盖，最后用 7 号逐条压测”QA 能不能直接照这条写出测试”。每个故事控制在 1 到 3 条 AC；要写到四条以上，说明故事太大、该拆。
这套 Prompt 适合用在哪
- PRD 与 user story
- Sprint planning 与 backlog 梳理
- QA 测试计划与 AC↔用例映射
- 跨团队契约
- Bug 工单
两种写法，分别什么时候用
下笔之前先定一种写法，别让模型在同一条故事里混着写：
- 场景式（Given/When/Then）： 适合行为依赖状态和用户动作的场景——登录、结账、多步流程。每个场景自成一体，和一条测试用例一一对应。
- 规则式（条目列表）： 适合 UI/UX 约束、校验规则、配置项这类套不进行为场景的内容——“密码至少 12 位”、“列表默认按日期倒序”。
敏捷测试里有条好用的纪律：每条都写到让测试人员不用揣摩就能判 Pass / Fail；并且尽量别用否定句（“系统不允许 X”），否定条件验证起来又慢又含糊，改写成一句正向的预期行为更好。
怎么跑这些 Prompt
这些 Prompt 不挑模型。截至 2026 年 6 月，做产品类的话 GPT-5.5（Thinking）、Claude Sonnet 4.6、Gemini 3.1 Pro 都能输出干净的 Given/When/Then。务必粘真实的故事和字段——输入模糊，再强的模型也只能给你模糊的 AC。遇到棘手的多团队契约（11 号），用 GPT-5.5 Pro 或 Claude Opus 4.7 多花点延迟也值。把所有 [方括号] 占位替换成你的实际内容。
1. Given/When/Then 写法
为 user story [粘贴] 写 AC，用 Given/When/Then。覆盖：1 个 happy path、2 个边界、1 个负向、1 个非功能（性能 / 可访问性 / 安全）。每条独立可测。如果这个故事需要超过 3 条 AC，告诉我它该拆，并给出拆分方案。2. 边界生成
下面是功能描述。请列 AC 应覆盖的 10 个边界：极端输入、空状态、超大输入、并发用户、慢网络、权限拒绝、会话过期、竞态。
[粘贴]3. 负向 AC
为 [粘贴] 功能生成 8 条负向 AC：输入非法、未授权、服务端失败、限流、校验失败、支付失败、依赖服务挂、数据缺失。4. 非功能 AC
为 [粘贴] 功能写 5 条非功能 AC：性能预算（给具体数字，如 p95 < 300ms）、可访问性等级（如 WCAG 2.2 AA）、安全 / 权限规则、错误日志、可观测（失败时记什么）。5. 复杂表单的 AC
为表单 [粘贴字段] 写 AC：必填校验、格式校验、异步校验、错误态、成功态、部分保存、自动保存、纯键盘提交。6. 集成的 AC
为与 [三方 API] 的集成写 AC：happy、限流处理、鉴权失败、不完整响应、重试、幂等、失败可观测。7. AC 模糊度压力测试
下面是我的 AC 草稿。逐条问：QA 能不能直接照这条写出测试，能或不能？不能就重写为可测。标出所有"应当 / 可能 / 如有必要 / 视情况"，并标出可以改写成正向说法的否定句。
[粘贴 AC]8. 可访问性 AC
为 [粘贴] 功能按 WCAG 2.2 AA 写 6 条 a11y AC：键盘导航、屏幕阅读宣告、焦点管理、对比度、ARIA role、错误宣告。9. 多步骤流程的 AC
为多步骤流程 [粘贴] 写 AC：每步状态、返回按钮行为、部分完成保存、每步校验、放弃后恢复。10. AC 到测试用例映射
下面是 AC + 现有测试用例。请映射。标出未覆盖的 AC 与无 AC 对应的测试。给缺口补建议。
[粘贴两者]11. 跨团队 AC 契约
我们团队和 [另一团队] 共享一个功能。请以契约方式写 AC：每条 owner、交接信号、一方未达成会发生什么。12. Bug 工单的 AC
为 bug [粘贴] 写修复需满足的 AC：原 bug 不再复现、相关流没回归、有测试覆盖、失败模式被记录。容易踩的坑
- “用户能登录”这种不可测——QA 没法直接落到一个确定的用例。
- 只写 happy path：没负向、没边界、没并发、没过期会话。
- 把非功能 AC（性能、a11y、日志）拖到来不及塞。
- 两条 AC 互相冲突（如”非法时禁用提交”和”提交时显示行内错误”同时存在）。
- AC 在功能做完才补——这是事后描述不是事前约束。
- 一个故事硬塞 6 条以上 AC 而不拆，结果每条都不再独立可测。
- 多个故事套同一个模板，没针对该流程实际的失败模式做裁剪。
常见问题
一个用户故事应该写几条验收标准？ 目标是 1 到 3 条。大小合适的故事基本都落在这个区间；一旦发现要写四条以上，多半说明故事太大，应该拆成更小、能独立交付的故事。
验收标准该用 Given/When/Then 还是条目列表？ 行为依赖状态和用户动作时（登录、结账、多步向导）用 Given/When/Then；校验规则、UI 约束、套不进行为场景的配置项用规则式条目列表。同一条 AC 里别两种写法混着用。
验收标准该谁写、什么时候写？ 开发前协作写——产品、工程、QA 在 backlog 梳理或 sprint planning 一起定。代码写完才补的 AC 描述的是已经做出来的东西，不是该做的东西，返工就是这么来的。
能不能直接信任 AI 写出来的验收标准？ 把模型输出当作快速初稿，不是最终契约。它确实擅长补上你容易漏的覆盖（并发、会话过期、限流），但也会编出听着合理、实际和你系统对不上的条目。务必用 7 号压测可测性，再由一个人类 owner 签字确认，才让故事进 sprint。
验收标准和测试用例有什么区别？ 验收标准定义一个故事”做完”要满足的条件；测试用例是验证每条标准的具体步骤。一条标准通常展开成多条测试用例。10 号 Prompt 负责映射两者，并标出没有测试的 AC、没有 AC 对应的测试。
相关阅读
- PRD 起稿 Prompt
- 用户故事 Prompt
- 特性优先级 Prompt
- MVP 范围 Prompt
- 测试生成 Prompt
- 定价假设 Prompt：免费 / Freemium / 阶梯模板
- 帮助中心 FAQ Prompt：产品支持模板