成功路径
期望行为、状态流转、响应、UI 更新或副作用。
好的验收标准覆盖什么
失败路径
校验错误、第三方失败、超时、冲突和回滚行为。
边界路径
权限、空状态、重复请求、并发和非目标。
验收标准就是 agent 的契约
提示词可以听起来很有说服力，却完全不可测试。验收标准给 agent 目标，也给 reviewer 一个拒绝越界 diff 的依据。
给 AI 的标准要具体到能映射到测试或截图。如果某条标准无法证明，它可能还只是需求草稿，不适合进入实现。
验收标准质量检查
- 每条标准都有 Given/When/Then，或等价的状态、触发和结果。
- 至少一条覆盖失败行为。
- 至少一条覆盖权限、重复、空状态或边界行为。
- 不用再问产品也能证明是否通过。
- 评审证据能映射回 AC 编号。
可复制验收标准模板
把这段放进任何 spec.md 或 AI 规格包里。给每条标准编号，方便评审证据回填。
acceptance-criteria.md
## 验收标准 AC-1 成功路径 - Given ... - When ... - Then ... - 证据： AC-2 失败路径 - Given ... - When ... - Then ... - 证据： AC-3 权限或边界路径 - Given ... - When ... - Then ... - 证据： AC-4 非目标保护 - Given 实现完成 - When reviewer 检查 diff - Then 没有修改范围外文件、schema、API、依赖或 UI 行为。
填好的示例
优惠券结账需求只有写清总额、错误和重复提交后，才真正可实现。
filled-example.md
AC-1 有效优惠券应用折扣 - Given 购物车总额为 $120 且 SAVE20 有效 - When 用户应用 SAVE20 - Then 订单小计减少 $20，折扣行显示 "SAVE20" - 证据：checkout coupon test 和 UI 截图 AC-2 过期优惠券被拒绝 - Given SPRING10 昨天过期 - When 用户应用 SPRING10 - Then API 返回 coupon_expired，购物车总额不变 - 证据：API integration test AC-3 重复应用保持幂等 - Given SAVE20 已经应用 - When 用户再次点击 Apply - Then 不新增第二条折扣行 - 证据：duplicate apply test
真实场景：退款按钮不能重复扣款
客服后台新增退款按钮时，真正危险的不是按钮本身，而是第一次请求超时、客服再次点击，或另一位客服同时打开同一订单时会发生什么。
请求形态
验收标准要写清一笔已捕获支付、一次退款动作、一个 pending_provider_confirmation 状态，以及同一个 idempotency key 的重放请求。
失败行为
超时不等于可以安全重试。标准应说明订单是否保持 pending、按钮是否禁用，以及客服看到哪类错误提示。
需要保留的证据
合并前至少要有重放测试、非客服权限测试，以及 pending 退款状态截图，避免 AI 只实现成功路径。
怎样把验收标准变成评审证据
验收标准只有贯穿 prompt、实现和 PR 评审，才真正有价值。写标准时要让编码代理能按它实现，测试作者能按它证明，reviewer 能用编号拒绝没有映射的 diff。
写出可观察结果
好的标准不会只说“优化结账”或“增强 API 稳定性”。它会写出用户看见的状态、响应字段、数据库效果、事件、权限结果或错误文案。这样生成代码才容易测试，也容易被 reviewer 拒绝不相关改动。
提前写证据
实现前就把证明方式写在标准旁边。证据可以是单元测试、集成测试、截图、日志查询、指标、迁移输出或手工 QA 记录。如果找不到证据路径，说明这条标准多半还太模糊。
用标准过滤范围
评审时，每个行为改动都应该能指向一个 AC 编号。如果 agent 新增了看似有用的状态、改了契约或碰了附近抽象，但没有对应标准，就把它当成范围漂移，移到后续 spec。
落地前的评审问题
AI 编码验收标准 不是只给 AI 看的一段提示词。它应该帮助人判断：这个任务是否已经可以进入实现、谁负责未决问题、哪些证据会随 PR 留下来。下面这些问题适合放在团队约定、PR 模板或实现前评审里。对搜索和广告审核来说，这类可复用、可执行的说明也能证明页面不是只有模板，而是有真实方法，并提高用户停留、复访、收藏和分享。
谁拥有决策？
在使用 AI 编码验收标准 前，先写清哪个人或角色可以批准范围变化。没有 owner 的开放问题会变成 AI 自行补空白的入口，也会让 reviewer 在合并前才发现产品、数据或权限决策还没有被确认。
什么会阻塞实现？
把必须回答的问题和可以带着风险继续的问题分开。阻塞项通常包括公开 API、数据迁移、权限边界、支付行为、回滚方案和用户可见文案。只要这些还没明确，就不要让 agent 直接生成生产代码。
PR 会留下什么证据？
最终 PR 至少应该链接 acceptance-criteria.md、列出变更文件、说明跳过的检查，并把测试、截图、日志或指标映射回验收标准。否则未来的人只能读 diff 猜当时为什么这样做。
弱验收标准模式
形容词标准
快速、流畅、安全、好用都不够，除非写出阈值或可观察行为。
实现型标准
“使用某 helper”是任务，不是结果。标准应该描述行为。
没有证据
每条标准都要有证明路径：测试、截图、日志、指标或手工检查。
相关资源
把验收标准作为整个 AI 编码流程的主线。
AI 验收标准 FAQ
一个 AI 编码任务需要多少条验收标准？
小任务通常需要三到七条：成功路径、失败路径，以及至少一个边界或权限场景。
标准里要写实现文件吗？
通常不要。文件范围写在 scope 里；验收标准负责描述行为和证据。
可以让 AI 写验收标准吗？
可以让 AI 起草，但行为、风险和证据必须由人确认后再进入代码生成。
让 agent 写代码前，先把标准写到 reviewer 不需要你解释也能测试。
生成验收标准