验收标准（acceptance criteria）是一个功能要被算作「完成」必须满足的条件——「完成」的可测试定义，它把一个含糊的故事变成 QA、工程和 PM 都能认同「满足了或没满足」的东西。这页讲它是什么、真正会被用起来的两种写法（Given/When/Then 和清单）、示例和一份模板。然后是诚实的那部分：标准是对着一份 spec 写的，spec 会动，而被复制进工单的标准，会和它出处的 spec 悄悄对不上。
验收标准是一个 用户故事 或需求被接受为完成所依据的、具体而可测试的条件。它把「做搜索」变成可核对的东西：什么算可用、边界是什么、失败时怎样。它的任务是在写代码之前消除歧义，让「做完了吗」有一个事先达成共识的答案，而不是评审时的一场争论。
它和「完成的定义」（definition of done，那是适用于每个故事的团队级标准——测试通过、文档更新）不同，也和需求本身不同（需求说做什么，标准说你怎么知道做对了）。好的标准在开发前写好、可测试、聚焦结果而非实现。
多数验收标准取这两种形状之一。按行为是有条件的（场景）还是一组扁平的必备项（清单）来选。
Given [上下文]，When [动作]，Then [结果]。例：「Given 一个有 3 张卡片的 thread，When 我导出为 PDF，Then 3 张卡片按顺序都出现。」当行为依赖状态时最佳——它逼你点名上下文，而 bug 正藏在那里。这是 BDD 写法。
一串必须全为真的条件：「搜索在 500ms 内返回结果」「空查询显示提示」「结果按 20 条分页」。当是一组互相独立的必备项、没有条件流程要建模时最佳。
人人都忘的那些条件：空状态、失败、权限、上限。只覆盖顺路径的标准是半份 spec——缺的那半，正是会生成 bug 报告的部分。点名出错时会怎样。
一份好的标准：3–7 条，每条可独立测试，覆盖顺路径和明显的失败。多于此，通常意味着故事太大了。
验收标准是在某一刻对着一份 spec 写的。spec 随后变了——一个决策反转、一条需求被重切——而被复制进工单的标准，仍在检验旧版本。Draftlize 把标准连到它出处的 spec。
在 Draftlize 里，一条标准不是粘进工单的文字——它绑在它所验证的 spec 卡片上。「完成于」引用需求而不是复述它，于是两者不会悄悄分叉成「工单说一套、spec 说另一套」。
重切了需求，检验旧需求的标准自动标记 stale——于是 QA 不再是你发现「验收测试已和 spec 不符」的地方。错位在 spec 移动时浮现，而不是 sprint 进行到第三天。
当 Claude Code 或 Cursor 经 MCP 实现或写测试，它把标准和相连的 spec 一起读——于是它构建并据以检验的，是当前的「完成定义」，而不是两个决策前就石化了的某条 Given/When/Then。
验收标准只和它复制自的那份 spec 一样靠谱。麻烦在于 spec 不会在自己变了时告诉那份复制件。留着 Given/When/Then，把标准链接到 spec，而不是复制它。
验收标准针对单个故事——让那个具体功能算完成的条件；完成的定义是适用于每个故事的团队级清单（写了测试、代码评审、文档更新）。标准说「这个功能对不对」，完成的定义说「任何故事可不可上线」。
一种把标准写成场景的方式：Given 某上下文，When 某动作发生，Then 期望某结果。它来自行为驱动开发（BDD），在行为依赖状态时最强，因为它逼你点名行为发生的上下文。
通常由产品经理或产品负责人起草，在开发开始前与工程和 QA 一起打磨。和将要构建、测试这个功能的人一起写，能趁边界情况还便宜时早早抓住它们。
通常三到七条，每条可独立测试，覆盖顺路径和明显的失败与边界。如果你需要远多于此，故事多半太大、该拆分了。
用上面的格式写标准，或在 Draftlize 里把它们写成连着所验证 spec 的卡片——这样 spec 一动，验收测试就标 stale，而不是对着一份已不成立的「完成定义」照样通过。
$5 免费开始