验收标准
Acceptance Criteria也常被叫作：AC完成的定义怎么算做完了
「他说做完了，可我不知道该看哪儿才算真的做完。」
验收标准 Acceptance Criteria
在开工之前就写下来的、能被第三方一条条勾掉的「做完了」的证据清单。
验收标准是开工前就写下来的、能被第三方一条条勾掉的「做完了」的证据清单。本质上是一句话的对赌：做完之前，我们就说清楚做完长什么样。
它必须满足两个条件才有意义。第一，可观察——不能是「体验流畅」「代码优雅」这种只能吵架的说法，得是「点保存后 1 秒内出现成功提示，刷新页面数据还在」。第二，事先写——事后补的验收标准只是给已经做出来的东西写说明书，永远都能通过。
说一个我们真付过学费的例子。我们发布长篇作品页有一份发布清单，其中 6 处是写死在页面里的版本号标签。有一次正文改了 16 处都改对了，清单里这 6 处标签却漏了——页面上了线，版本号还停在旧版，读者根本看不出更新过。正文 16 处全对、清单漏 1 项，结果就是那 1 项出事：验收清单漏掉的那一条，几乎必然出事。
和 AI 协作时，这份清单的价值被放大了十倍。因为 AI 几乎永远会说「已完成」：它对完成的判断是「我按你的话生成了内容」，你的判断是「用户能用」。中间的落差不靠信任解决，靠一份开工前就写好的清单解决。
一条好的验收标准通常长这样：在什么情况下，做什么操作，会看到什么结果。三段齐了，谁来都能验；缺一段，就会变成「我觉得可以了」对「我觉得不行」。清单要在开工前写，不是收工时补。
长什么样 真实可交互，不是截图
验收清单示例
注意右边那条为什么能验：它写了「什么情况 → 什么操作 → 什么结果」。也注意最后一项老实标了「未验证」——这比全部打勾可信得多。
拆开看，里面有这几块
-
1
前提条件 Given
在什么状态下开始。比如「已登录的用户」「购物车里有 3 件商品」。
-
2
操作 When
具体做什么。要具体到「点哪个按钮」，不是「使用这个功能」。
-
3
可观察结果 Then
会看到什么。数字、文字、页面变化、时间上限——能用眼睛确认的东西。
-
4
非目标 Out of scope
这次明确不做什么。少了这一段，范围会自己长大。
-
5
证据形式 Evidence
验收时要交什么：截图、命令输出、可访问的地址。写清楚就不用事后追问。
常见的有哪几种
最通用的写法，一条一个场景，包括失败场景。
用在：功能需求、交互流程
一串能勾选的短句，适合改动琐碎但要点多的任务。
用在：样式调整、文案批改
给出具体数字上限或下限，比如「首屏 2 秒内可交互」。
用在：性能、容量、成本
明确列出「不允许发生」的情况，比如「不能出现重复订单」。
用在：涉及钱、数据、权限时必写
容易搞混？这样区分
需求说要做什么，验收标准说怎么算做成了。「加一个搜索框」是需求；「输入关键词回车后 1 秒内出结果，无结果时显示明确空状态」是验收标准。
验收标准关心「这个功能对不对」；上线检查表关心「放出去安不安全」——备份、回滚、监控、灰度。两者都要，别互相顶替。
什么时候用得上
把验收标准写在需求最后一段。这一步花 3 分钟，能省掉后面半小时的来回。
不逐条讨论感受，只逐条对清单。没打勾的写「未验证」，不要模糊过去。
小改动也给一条：「我打开哪个地址、点哪一步，能看到这个变化」。一句话就够。
你可以这样跟 AI 说
直接复制下面这段，把【】里的换成你的情况。它比一句「帮我加个 X」多说清楚了：改哪里、不许动啥、做完交什么。
【任务】[在这里写你要做的事] 【范围】只改 [具体文件或页面] 【边界】不要动 [配色 / 布局 / 数据结构 / 其他页面]；不确定就先问我，不要猜 【验收标准】做完之后，下面每一条我都要能自己验证： 1. 在 [什么状态] 下，[做什么操作]，会看到 [什么结果] 2. 出错时（[具体错误情况]），会看到 [明确的提示]，且不会 [不允许发生的事] 3. 手机宽度下 [具体表现] 【交付格式】 - 改了哪些文件，分别改了什么 - 实际执行的命令 + 原始输出（贴出来，不要复述） - 我打开哪个地址、点哪一步能看到效果 - 上面三条验收标准里，哪几条你已亲自验证过，哪几条没有（没验证就写「未验证」，不要写「应该可以」）
最后那句「没验证就写未验证」是整段话里最值钱的一句。它给了 AI 一条诚实的退路，你才能拿到真实的完成度，而不是一份人人都通过的成绩单。
它说「做好了」，你怎么自己验
这是本站的重头戏。AI 最会的不是写代码，是说「已完成」。这一条，它通常最多做到「主路径」这层：真实用户的正常操作能走通，不靠特殊参数。
要亲眼看到这些，才算数
- 每一条验收标准都能由你本人在不看代码的情况下验证。做不到，说明它写得还不够具体。
- 清单里包含至少一条失败场景（输错了、网断了、没权限），不只有顺利路径。
- 涉及数据、钱、删除的任务，清单里有一条明确的「不允许发生」。
- 验收时逐条勾选，未验证的项目如实标出，而不是整体打一个「通过」。
- 验收标准是在开工之前写的（翻一下你自己的消息记录就知道）。
它常这么糊弄你
- 「已按验收标准全部完成」——但清单是他自己事后总结的。你要对的是你原来那份清单。
- 把「代码写完了」当成通过标准。代码存在不等于行为正确。
- 只验顺利路径。真实事故几乎都发生在错误分支上。
- 清单里出现「体验良好」「性能优秀」这类词——那不是标准，那是形容词。
验收标准本身停在「主路径」层就够用了：你能亲手走一遍即可。要推到「生产」层，还得加上线上地址、回滚方式和观测手段。
考考你 选一个你觉得对的
下面哪一条是可以验收的标准？
只有 A 写清了「什么情况 → 什么操作 → 什么可见结果」，任何人都能在 10 秒内验证。B、C 是形容词，只能吵架；D 是一个完成宣称，恰恰是需要被验收的东西，不能当作验收标准。