验收标准与完成定义（DoD）常被放在一起讨论，但它们回答的是两个不同层面的问题：验收标准针对单个需求，说明这个交付物做成什么样才算被接受；DoD针对团队共用的完成口径，说明一项工作从开始到可交付要满足哪些通用条件。本文按需求表示层面的口径梳理验收条件、验收标准与DoD的边界、放置位置和配合写法，帮助读者判断何时只需其一、何时需要两者并用。
要点总览（TL;DR）
- 验收标准针对单个需求或用户故事，回答“这个交付物做成什么样才算被接受”，写成可逐条判定的条件；完成定义（DoD）针对团队全部工作项，回答“一项工作达到哪些通用条件才算完成”。
- 验收条件与验收标准通常指同一类需求级判定条件，差异在表述习惯；真正需要区分层级的是需求级判定条件与团队级完成口径。
- 验收标准写在需求条目内，用于需求评审与验收；DoD写在团队工作协议或项目规范中，用于开发完成自检、提测与交付前评审。
- 两者叠加使用而非互相替代：DoD是进入验收的门槛，验收标准是验收本身的判据；把DoD条目抄进每条需求是常见误区。
- 需求差异大、验收口径不统一时优先补验收标准；交付质量波动、返工多时优先补DoD；多数持续交付团队最终两者并用，并分开维护责任。
验收标准与完成定义的核心区别
验收标准回答的是“这个需求做成什么样算被接受”。它依附于某一条具体的需求或用户故事，内容随需求变化：同一个系统里，登录功能的验收标准和报表导出功能的验收标准完全不同，因为业务预期不同。验收标准的写法通常是可以逐条判定的条件，例如给定某种输入时应得到某种结果，评审时能明确判为通过或不通过。
完成定义回答的是“一项工作达到什么通用条件才算完成”。它不针对某一条需求的内容，而是团队对“完成”这件事的统一约定，覆盖开发、测试、文档、评审等环节。比如代码已合并、单元测试通过、相关文档已更新、经过同行评审，这些条件对团队里的每个工作项都适用，不因需求内容不同而改写。
两者的作用对象和层级由此分开。验收标准的作用对象是单个需求条目，处在需求级；DoD的作用对象是团队的全部工作项，处在团队或项目级。这个层级差异决定了两者不能互相替代：DoD再完整，也无法说明某个具体需求的业务预期；验收标准再细致，也无法覆盖团队对所有交付物的通用质量要求。
理解这一区别的一个实用判断是看变更频率。需求内容调整时，验收标准随之修改；DoD相对稳定，通常在团队回顾中周期性修订，而不是每来一个需求就改一次。如果一份“验收标准”对所有需求都一字不差，它实际上已经是DoD；如果一份“DoD”只适用于某一条需求，它实际上是验收标准。
同口径差异对照：验收条件、验收标准与DoD
验收条件与验收标准在多数团队的实践中指向同一类需求级判定条件，只是表述习惯不同：有的团队习惯说“验收条件”，有的习惯说“验收标准”，也有团队把验收标准理解为条件集合的整体名称。本文按同一口径处理这两个词，不把它们当作两个独立概念。真正需要区分层级的是需求级判定条件与团队级完成口径，也就是验收标准（含验收条件）与DoD的关系。
下表用统一维度对照三个概念，便于在同一张表里看清各自的位置。
| 对照维度 | 验收条件 | 验收标准 | 完成定义（DoD） |
|---|---|---|---|
| 回答的问题 | 这条需求满足哪些条件才算被接受 | 这条需求做成什么样才算被接受 | 一项工作达到哪些通用条件才算完成 |
| 作用对象 | 单个需求或用户故事 | 单个需求或用户故事 | 团队全部工作项 |
| 编写者 | 需求提出方与需求分析人员共同确认 | 需求提出方与需求分析人员共同确认 | 团队共同约定，由团队负责人或质量角色维护 |
| 变更频率 | 随需求内容调整 | 随需求内容调整 | 相对稳定，按回顾周期修订 |
| 判定方式 | 逐条核对，通过或不通过 | 逐条核对，通过或不通过 | 逐项自检与评审，作为进入下一环节的门槛 |
| 文档位置 | 需求条目内 | 需求条目内 | 团队工作协议或项目规范中 |
从表中可以看出，验收条件与验收标准在六个维度上基本重合，差异主要在措辞习惯；DoD则在作用对象、编写者、变更频率和文档位置上全面不同。把三者放在同一口径下比较，能避免一种常见混淆：把团队级的通用条件误当成某条需求的验收标准，或者反过来，把某条需求的特殊判定条件上升为全团队的DoD。
各自用在什么位置：需求条目、团队规范与评审环节
验收标准写在需求或用户故事条目内，与需求描述放在一起。这样做的目的是让需求提出方、开发人员和测试人员在同一条目下看到业务预期，减少口头传递造成的信息丢失。条目内的验收标准应当能独立阅读，不依赖其他需求的上下文。
DoD写在团队工作协议或项目规范中，作为一份团队共用的清单存在。它不属于某一条需求，而是所有工作项在流转时共同参照的完成口径。团队新成员加入时，读这份协议就能知道“完成”在本团队意味着什么。
验收条件在需求评审与验收环节使用。需求评审时，评审者用验收条件检验需求是否表达清楚、是否可判定；验收环节，验收方逐条核对验收条件，决定这条需求是否被接受。验收条件在这里既是沟通工具，也是判定依据。
DoD在开发完成、提测、交付前的自检与评审中使用。开发人员提交前按DoD自检，评审者按DoD检查工作项是否达到可交付的通用门槛。DoD不判断业务预期是否满足，它判断的是这项工作在流程上是否已经完整。
把概念映射到文档位置与流程环节，可以用一张简表固定下来：
| 概念 | 文档位置 | 主要使用环节 |
|---|---|---|
| 验收标准（含验收条件） | 需求或用户故事条目内 | 需求评审、验收 |
| 完成定义（DoD） | 团队工作协议或项目规范 | 开发完成自检、提测、交付前评审 |
在工具承载上，需求条目通常需要独立的验收标准字段，工作项状态流转则需要能体现DoD检查的环节。以ONES为例，需求与工作项可以在同一处管理，验收标准作为需求条目的内容随需求一起评审，工作项状态流转到完成前可以设置检查环节，团队级的完成口径则以规范文档的形式沉淀下来。具体字段配置与状态设置方式，建议以团队实际使用的产品文档为准。
写法示例：同一条需求下的验收标准与DoD
下面用一个演示情景说明两者如何同时书写。情景为“用户可以通过手机号重置登录密码”，仅用于展示写法，不代表真实项目案例。
这条需求的验收标准可以写成可逐条判定的条件：
- 输入已注册手机号并提交后，系统在页面提示验证码已发送。
- 验证码有效期为5分钟，超时后提交提示验证码已失效。
- 连续3次输入错误验证码后，该手机号在10分钟内不可再次请求验证码。
- 验证码校验通过后，用户可设置新密码，新密码需满足既定的长度与字符要求。
- 新密码设置成功后，旧密码立即失效，用户可用新密码登录。
同一需求适用的DoD条目来自团队规范，与需求内容无关：
- 代码已合并到主干分支。
- 单元测试与相关集成测试通过。
- 接口文档与用户操作说明已更新。
- 经过至少一名同行评审。
- 测试环境验证通过，无阻断级缺陷。
两者叠加判定时，顺序上先过DoD再过验收标准更符合流程逻辑：DoD确认这项工作在流程上已经完整、具备被验收的条件；验收标准确认这条需求的业务预期是否满足。也可以反过来理解：DoD是进入验收的门槛，验收标准是验收本身的判据。任何一项不满足，工作项都不应标记为完成。
常见写法误区是把DoD条目抄进每条需求的验收标准。这样做会让每条需求都重复一遍通用条件，需求条目变得冗长，且一旦DoD修订，所有需求条目都要跟着改。正确的做法是让DoD在团队规范中维护一份，需求条目只写这条需求特有的判定条件。另一个误区是把某条需求的特殊条件写进DoD，导致DoD越来越长、失去通用性。
适配场景与选择建议
需求差异大、验收口径不统一时，优先补验收标准。典型表现是评审时对“做成什么样算完成”各说各话，验收阶段反复返工确认。此时把每条需求的判定条件写清楚，收益最直接。这个阶段DoD可以暂时保持简单，先解决需求级的表达问题。
交付质量波动、返工多时，优先补DoD。典型表现是工作项标记完成后仍被发现缺少测试、文档缺失或未经评审，问题出在通用完成口径没有约定或没有执行。此时先建立一份团队共用的DoD清单，并在状态流转中设置检查环节，比逐条补验收标准更能解决系统性问题。
两者并用的适用条件是：团队既有多个需求并行、业务预期差异明显，又希望统一交付质量门槛。多数持续交付的团队会落到这个状态。并用时要注意分工，验收标准由需求提出方与需求分析人员确认，DoD由团队共同约定并指定维护人，两份内容不互相复制。
落地顺序上，可以先建立一份最小可用的DoD，覆盖代码合并、测试通过、文档更新、评审这几项通用条件，再在需求条目中逐步补齐验收标准。维护责任建议分开：验收标准随需求变更由需求负责人更新，DoD按回顾周期由团队负责人或质量角色组织修订。这样两份内容各自演进，不会因为一方调整而牵连另一方。
常见问题
验收条件与验收标准是同一个东西吗？
在多数团队的实践中，两者指向同一类需求级判定条件，只是表述习惯不同：有的团队说“验收条件”，有的说“验收标准”，也有团队把验收标准理解为条件集合的整体名称。本文按同一口径处理，不把它们当作两个独立概念。真正需要区分层级的是需求级判定条件与团队级完成口径，也就是验收标准（含验收条件）与DoD的关系。
如果团队内部对这两个词有约定俗成的分工，建议在团队规范中写明，避免评审时因措辞产生歧义。
一条需求已经写了验收标准，还需要对照DoD检查吗？
需要。两者判定的是不同层面：验收标准确认这条需求的业务预期是否满足，DoD确认这项工作在流程上是否完整、是否具备被验收的条件。一条需求的验收标准全部通过，但代码未合并、文档未更新或未经同行评审，按DoD仍不应标记为完成。
实际操作中，先过DoD再过验收标准更符合流程逻辑：DoD是进入验收的门槛，验收标准是验收本身的判据。任何一项不满足，工作项都不应标记为完成。
小团队人少，能不能只保留DoD、不写验收标准？
可以按需求差异程度决定。如果团队需求数量少、内容相近，且需求提出方与开发人员能随时口头对齐业务预期，先建立一份最小可用的DoD、暂不逐条写验收标准是可行的过渡做法。
当需求开始并行、业务预期出现分歧，或验收阶段反复返工确认时，就应补上验收标准。判断信号是评审时对“做成什么样算完成”各说各话，这时需求级的判定条件比通用完成口径更能解决问题。
DoD应该由谁维护，多久修订一次？
DoD是团队共同约定，通常由团队负责人或质量角色负责维护，内容来自团队共识而非个人决定。修订节奏一般跟随团队回顾周期，在回顾中根据近期返工、缺陷和评审发现的问题调整条目，而不是每来一个需求就改一次。
维护责任建议与验收标准分开：验收标准随需求变更由需求负责人更新，DoD按回顾周期组织修订。两份内容各自演进，一方调整不会牵连另一方。
把DoD条目复制到每条需求的验收标准里，会有什么问题？
主要问题是重复和维护成本。每条需求都重复一遍通用条件，需求条目会变得冗长，阅读时难以快速找到这条需求特有的判定条件；一旦DoD修订，所有需求条目都要跟着改，容易出现遗漏和不一致。
更合适的做法是DoD在团队规范中维护一份，需求条目只写这条需求特有的判定条件。反向的误区同样要避免：把某条需求的特殊条件写进DoD，会让DoD越来越长、失去通用性。
