AC 翻车几乎都从”用户可以登录”这种话开始——成功长什么样、失败长什么样、慢网、会话过期一概没写，QA 自己脑补覆盖、工程少写一半边界，bug 单一路涨。下面这些 Prompt 强制每条都可测，把 happy / 负向 / 非功能拆清，写出来的 AC 能扛得住 sprint planning 上挑刺。上游用户故事本身的范围问题，先用 MVP 范围 Prompt 处理掉，免得给不该做的功能写 AC。
这套 Prompt 适合用在哪
- PRD 与 user story
- Sprint planning
- QA 测试计划
- 跨团队契约
- Bug 工单
1. Given/When/Then 写法
为 user story {粘贴} 写 AC，用 Given/When/Then。覆盖：1 个 happy path、2 个边界、1 个负向、1 个非功能（性能 / 可访问性 / 安全）。每条独立可测。2. 边界生成
下面是功能描述。请列 AC 应覆盖的 10 个边界：极端输入、空状态、超大输入、并发用户、慢网络、权限拒绝、会话过期、竞态。
{粘贴}3. 负向 AC
为 {粘贴} 功能生成 8 条负向 AC：输入非法、未授权、服务端失败、限流、校验失败、支付失败、依赖服务挂、数据缺失。4. 非功能 AC
为 {粘贴} 功能写 5 条非功能 AC：性能预算、可访问性等级、安全 / 权限规则、错误日志、可观测（失败时记什么）。5. 复杂表单的 AC
为表单 {粘贴字段} 写 AC：必填校验、格式校验、异步校验、错误态、成功态、部分保存、自动保存、纯键盘提交。6. 集成的 AC
为与 {三方 API} 的集成写 AC：happy、限流处理、鉴权失败、不完整响应、重试、幂等、失败可观测。7. AC 模糊度压力测试
下面是我的 AC 草稿。逐条问：QA 能不能直接写出测试？不能就重写为可测。标出所有"应当 / 可能 / 如有必要"。
{粘贴}8. 可访问性 AC
为 {粘贴} 功能写 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 在功能做完才补——这是事后描述不是事前约束
- 多个故事套同一个模板，没针对该流程实际的失败模式做裁剪