验收条件与完成定义（DoD）解决的是两个不同层面的问题。验收条件绑定单条需求或用户故事，写在需求条目上，用来判断这一条需求交付后是否被接受；DoD是团队共享的完成门槛，作用于每个工作项从开始到可交付的通用环节。前者回答“这条需求对不对”，后者回答“这类工作项算不算完成”。本文按术语、对照、场景、组合规则、工具承载和选择建议逐层说明两者的使用位置，并在工具承载部分自然提及ONES的需求与工作项管理方向。
要点总览（TL;DR）
- 验收条件（含验收标准）绑定单条需求或用户故事，写在需求条目上，回答“这条需求交付后是否被接受”；DoD是团队级共享的完成门槛，回答“这类工作项算不算完成”。
- 承载位置不同：验收条件随需求走，由需求提出方与开发方共同确认，随需求变化；DoD随团队走，由团队共同约定，按迭代或季度回顾调整。
- 按环节看：需求评审时验收条件随需求一起评审，开发自检阶段由DoD约束通用动作，测试验收阶段逐条核对验收条件，迭代回顾阶段用DoD检查完成质量并调整。
- 叠加使用时按“通用动作放DoD、需求特有结果放验收条件”分工，重复条目上移或下沉，冲突时以更严格者为准并记录原因。
- 选择建议：需求差异大、验收争议多的团队优先写扎实验收条件；交付质量波动大的团队优先建立DoD；两者都需要时先立DoD保底，再为关键需求补验收条件。
验收条件、验收标准与DoD分别指什么
三个术语常被混用，根源在于它们分属两个层级：验收条件与验收标准属于需求条目级，DoD属于团队流程级。先把对象和层级分清，后面的对照和场景才有共同口径。
验收条件与验收标准：绑定单条需求
验收条件是针对某一条需求或用户故事，事先约定的、可验证的接受判据。它描述这条需求交付后，需求提出方与开发方共同认可“做对了”的具体表现。验收标准是验收条件的常见表述形式，通常写成若干条可核对的条目，例如“提交订单后30秒内生成订单号”“余额不足时给出明确提示且不生成订单”。两者在多数团队中指向同一件事：一条需求内部的、逐条可验证的结果约定。
验收条件的关键特征是“专属”：它只对当前这条需求有效，换一条需求就要重新写。它不描述团队所有工作项都要满足的通用动作，而是描述这条需求特有的业务结果和边界情况。
DoD：团队对“完成”的统一约定
完成定义（Definition of Done，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与验收条件对同一件事要求不一致时，例如DoD要求“部署到测试环境”，而某条需求的验收条件要求“部署到预发布环境并完成冒烟测试”，应以更严格的要求为准执行，并在需求或团队规范中记录这一差异的原因。记录的目的是避免后续回顾时误以为其中一方写错了。
两个常见反模式
一是把验收条件写成泛化清单，例如“功能正常、性能良好、无缺陷”，这类表述无法逐条核对，失去接受判据的作用。二是把DoD写成单条需求专属要求，例如把某个业务规则写进团队DoD，导致其他工作项被无关条件约束。保持“通用归DoD、专属归验收条件”的分工，可以同时避免这两种问题。
在需求管理工具中如何承载这两类内容
两类内容在工具中的承载位置不同，落到具体系统时，需要分别找到对应的字段、检查项和状态流转节点。以下按承载方式说明，具体能力以团队实际使用的工具为准。
验收条件：需求条目的结构化字段或子项
验收条件适合作为需求条目的结构化字段或子项存在，每条验收条件独立成行，便于逐条核对和标记通过状态。结构化承载的好处是：验收时不会遗漏条目，评审时可以直接在条目上讨论，需求变更时能清楚看到哪些验收条件随之调整。若工具支持子项或检查清单，把验收条件做成可勾选的条目，能让“逐条核对”这一动作留下记录。
DoD：团队级检查项或完成前必填校验
DoD适合作为团队级检查项存在，例如在工作项流转到“完成”状态前，弹出或展示一组通用检查项，要求逐项确认。部分工具支持状态流转的必填校验，可以把关键检查项设为完成前必须确认的条件。DoD作为团队规范，通常只需要维护一份，所有同类工作项引用同一份，避免逐条复制。
状态流转与评审记录：留下判定证据
验收条件的核对结果和DoD的检查结果，都应随工作项的状态流转留下记录。例如验收条件逐条标记通过后，工作项才进入验收通过状态；DoD检查项确认后，工作项才能流转到完成。评审记录中保留谁在什么时间确认了哪些条目，便于后续追溯和回顾。
ONES的承载方向
ONES在需求与工作项管理方向上，支持将需求作为工作项进行管理，并通过状态流转和字段记录承载需求信息与评审过程。团队可以在需求条目上维护验收相关的结构化内容，在工作项流转中保留确认记录。具体到验收条件字段的形态、DoD类完成前校验的配置方式，以及评审记录的留存细节，建议以团队实际使用版本的配置能力为准进行确认。
适配场景与选择建议
两类内容并非必须同时以同等力度建设。根据团队当前的主要问题选择侧重点，更容易落地。
优先写扎实验收条件的团队
需求差异大、接受标准需要逐条约定的团队，应优先把验收条件写扎实。典型情况是：业务规则复杂、需求之间差异明显、验收时经常出现“我以为你要的是……”的争议。这类团队的核心问题是单条需求的接受判据不清，把验收条件写到可逐条核对的程度，能直接减少验收争议。
优先建立并维护DoD的团队
交付质量波动大、通用环节常被遗漏的团队，应优先建立并维护DoD。典型情况是：代码评审时有时无、测试覆盖不稳定、文档经常滞后、上线后反复出现本可避免的问题。这类团队的核心问题不是单条需求写得不清，而是“完成”的标准不统一，先把DoD立起来，能让每个工作项的完成质量有保底。
两者都需要的团队：先立DoD保底，再补验收条件
多数团队最终两者都需要。建议的顺序是先立DoD保底，再为关键需求补验收条件。DoD覆盖所有工作项，建立成本相对低，先解决“完成”标准不统一的问题；验收条件逐条编写，成本随需求数量增加，优先为业务规则复杂、争议风险高的关键需求补齐，再逐步扩展。
小团队的起步方式
小团队可以从简化版DoD起步，例如先约定代码评审、基本测试、必要文档三项，随协作复杂度增加再细化。验收条件可以先在争议较多的需求上试用，形成团队自己的写法习惯后再推广。起步阶段的目标是让两类内容都有人用、有用，而不是一次写全。
无论侧重哪一方，判断标准是一致的：验收条件回答“这条需求对不对”，DoD回答“这类工作项算不算完成”。把通用动作放进DoD，把需求特有的可验证结果放进验收条件，两者叠加使用，需求从提出到交付的每个环节都有明确的判定依据。
常见问题
验收条件和验收标准是同一个东西吗，团队里两种叫法要不要统一？
多数团队中两者指向同一件事：一条需求内部的、逐条可验证的接受判据。验收标准常作为验收条件的具体表述形式，写成若干条可核对的条目。不同团队可能有细微用法差异，有的把验收标准当作验收条件的子集，有的混用两个词。
是否统一叫法取决于团队协作需要。只要团队内部对“这是单条需求的接受判据”达成一致，术语选择不影响实际使用；如果跨团队协作频繁、评审时经常因叫法产生歧义，可以在团队规范中明确一个主用词，并在需求模板中固定下来。
一条需求已经写了验收条件，还需要在DoD里重复写测试通过吗？
不需要重复。测试通过属于对所有同类工作项都成立的通用动作，应放在DoD中统一约束；验收条件只保留这条需求特有的可验证结果，例如具体的业务规则、边界情况和异常处理表现。
如果发现验收条件里写了“已通过单元测试”“代码已评审”这类通用动作，应把条目上移到DoD并从验收条件中删除。去重后，验收条件逐条核对时关注的是需求本身对不对，DoD则在流转到完成前统一把关通用环节，两者各管一段，核对时不会互相干扰。
DoD和某条需求的验收条件要求不一致时，按哪个执行？
以更严格的要求为准执行，并记录差异原因。例如DoD要求“部署到测试环境”，而某条需求的验收条件要求“部署到预发布环境并完成冒烟测试”，就按预发布环境加冒烟测试执行。
记录原因的目的是避免后续回顾时误以为其中一方写错了。如果这类更严格的要求反复出现，说明DoD可能需要上调门槛，可以在迭代回顾时讨论是否把该要求写入DoD；如果只是个别需求的特殊要求，保留在验收条件中并注明原因即可。
小团队人手少，能不能只写验收条件、先不建DoD？
可以按团队当前的主要问题决定侧重点。如果团队的核心困扰是单条需求的接受判据不清、验收时经常出现理解偏差，优先把验收条件写扎实是合理的；如果困扰是代码评审时有时无、文档经常滞后、上线后反复出现本可避免的问题，则说明“完成”的标准不统一，更适合先建立简化版DoD。
小团队从简化版DoD起步的成本不高，例如先约定代码评审、基本测试、必要文档三项，随协作复杂度增加再细化。验收条件可以先在争议较多的需求上试用，形成写法习惯后再推广。起步阶段的目标是两类内容都有人用、有用，不必一次写全。
在需求管理工具里，验收条件和DoD分别应该挂在哪里？
验收条件适合作为需求条目的结构化字段或子项存在，每条独立成行，便于逐条核对和标记通过状态；DoD适合作为团队级检查项存在，例如在工作项流转到“完成”状态前展示一组通用检查项，要求逐项确认。DoD通常只维护一份，所有同类工作项引用同一份，避免逐条复制。
两者的核对结果都应随状态流转留下记录，便于追溯和回顾。ONES在需求与工作项管理方向上支持将需求作为工作项管理，并通过状态流转和字段记录承载需求信息与评审过程；验收条件字段的具体形态、完成前校验的配置方式，建议以团队实际使用版本的配置能力为准确认。
