验收条件、验收标准和完成定义常被当成同一件事写进需求文档，结果验收时说不清、开发与测试互相等待。三者处在不同层级：完成定义管团队工作项的流程出口，验收条件管单条需求的出口，验收标准为每条验收条件提供可判定的口径。本文按统一维度对照三者，说明它们在需求流程中的位置、常见混用后果，并给出一条需求的配套写法示例。
要点总览（TL;DR）
- 验收条件回答“这条需求怎样算通过”，针对单条需求，通常拆成若干条可验证的结果描述。
- 验收标准回答“按什么口径判定通过”，附着在验收条件上，规定判定方法、阈值或观察方式。
- 完成定义（DoD）回答“工作项何时可以标记完成”，是团队级统一约定，覆盖评审、测试、文档等共同环节。
- 位置关系：DoD 管团队工作项的流程出口，验收条件管单条需求的出口，验收标准为每条条件提供可判定依据。
- 补齐顺序按团队痛点定：验收争议多的先补验收条件与标准，交付环节不统一的先统一 DoD，小团队可先合并维护再拆分。
三者分别回答什么问题
把三个词放在一起时，最容易出现的错误是拿其中一个替代另外两个。它们各自回答一个不同的问题，回答对象也不同。
验收条件回答“这条需求怎样算通过”。它针对单条需求，把需求拆成若干条可验证的结果描述，例如“用户提交订单后能看到订单号”“重复提交同一订单只生成一条记录”。验收条件的数量取决于需求复杂度，一条需求通常对应若干条。
验收标准回答“按什么口径判定通过”。它附着在验收条件上，规定判定方法、阈值或观察方式，例如“订单号在提交成功后 3 秒内展示”“并发提交 10 次仅产生 1 条订单记录”。验收标准让验收条件从一句期望变成可以执行的判定。
完成定义（DoD）回答“工作项何时可以标记完成”。它是团队级约定，覆盖代码评审、单元测试、文档更新、上线检查等共同环节，对团队内所有工作项生效，与某条需求的具体内容无关。
三者的层级关系可以这样理解：DoD 是团队层面的流程出口，对所有工作项生效；验收条件是单条需求的出口，只对这条需求生效；验收标准是验收条件内部的判定依据，让每条条件可以被核对。DoD 不描述某条需求做成什么样，验收条件也不规定团队共同的完成环节，两者作用范围不同，不能互相替代。
同口径差异对照：对象、粒度、归属与失效后果
把三者放在同一组维度上对照，差异更容易核对。下表按作用对象、粒度、归属与维护者、变更频率、失效后果五个维度展开。
| 维度 | 验收条件 | 验收标准 | 完成定义（DoD） |
|---|---|---|---|
| 作用对象 | 单条需求 | 每条验收条件的判定口径 | 团队内所有工作项 |
| 粒度与数量 | 每条需求若干条，随需求拆分 | 每条验收条件对应一组判定方法或阈值 | 团队级一份统一约定，条目相对稳定 |
| 归属与维护者 | 需求提出方与验收方共同确认 | 需求方与测试共同确认判定方法 | 团队或工程规范维护，团队共同遵守 |
| 变更频率 | 随需求澄清和变更调整 | 随判定手段和阈值调整，变更较少 | 随团队工程实践演进，按周期评审更新 |
| 失效后果 | 验收范围不清，交付内容与预期错位 | 条件无法判定，验收变成主观判断 | 完成口径不一，工作项提前关闭或反复返工 |
这张表里最容易被忽略的是变更频率一列。验收条件跟着需求走，需求一变就要重写；验收标准相对稳定，改的是判定方法和阈值；DoD 变化最慢，通常按季度或按工程实践调整。三者变更节奏不同，混写在同一段落里，任何一方调整都会牵连另外两方，维护成本随之上升。
在需求流程中各放在什么位置
三个概念在需求从提出到关闭的过程中出现时点不同，交接对象也不同。按流程顺序看，它们的位置大致如下。
| 流程环节 | 出现的内容 | 主要参与角色 | 交接对象 |
|---|---|---|---|
| 需求澄清 | 形成验收条件，明确这条需求要达成哪些可观察结果 | 需求提出方、产品、开发、测试 | 评审材料与需求文档 |
| 需求评审 | 为每条验收条件补充验收标准的判定方法与阈值 | 产品、测试、开发 | 测试用例设计输入 |
| 开发与自测 | DoD 中的共同检查项生效，如代码评审、单元测试 | 开发 | 提测交接 |
| 测试验证 | 按验收标准逐条核对验收条件 | 测试 | 验收结论与缺陷记录 |
| 上线检查与关闭 | DoD 中的文档、发布检查项完成，验收条件全部通过 | 开发、测试、发布负责人 | 工作项关闭 |
从表中可以看到，验收条件在澄清阶段就要成形，验收标准在评审阶段补齐，DoD 则在开发到交付的完成判定环节持续生效。三者与评审、测试、上线检查的衔接点各不相同：验收条件进入评审材料，验收标准进入测试用例设计，DoD 进入工作项关闭前的检查。需求内容本身是否合理、是否需要拆分的判断属于需求分析与澄清的工作，本文不展开。
在实际协作中，这三类内容往往散落在需求文档、测试用例和工作项字段里。把验收条件写进需求文档的固定字段、把验收标准挂在对应条件之后、把 DoD 作为团队统一检查项单独维护，评审和测试时就能按同一份材料核对，减少口头确认。ONES 这类研发管理工具可以把验收条件放在工作项的描述或自定义字段中，把 DoD 做成团队级的检查项模板，让需求流转到测试和关闭环节时有据可查；具体字段配置方式以团队实际使用的版本为准。
写错位置会带来什么问题
混用通常不是有意为之，而是写的时候没有区分层级。以下四种情形比较常见，可以对照识别。
- 把 DoD 当验收条件。需求文档里只写“代码已评审、测试已通过、文档已更新”，没有描述这条需求本身要达成什么结果。这类内容对每个工作项都成立，无法说明这条需求的验收范围，验收时只能凭印象判断。
- 把验收标准写成验收条件。条件里直接写“响应时间小于 200 毫秒”“成功率不低于 99%”，却没有说明在什么场景、用什么方法测量。阈值本身是判定口径，缺少对应的结果描述，测试人员不知道要验证哪个功能点。
- 验收条件缺少判定口径。条件写成“系统运行稳定”“界面友好”，听起来是要求，实际无法判定。评审时没人反对，测试时无法给出结论，返工和争议往往在这一步集中出现。
- 在需求文档中重复抄写团队级 DoD。每条需求都附一份完整的完成检查清单，内容高度重复。DoD 一旦调整，历史需求文档全部过期，维护成本高，也容易让读者误以为这些检查项是这条需求特有的验收要求。
识别方法比较直接：读一条验收条件，问“测试人员能不能据此给出通过或不通过的结论”。能给出结论，说明条件和标准配套；给不出，通常缺的是判定口径，或者写成了团队级检查项。
如何在同一条需求上配套使用
下面用一条演示需求说明三者的配套写法。示例仅作写法示范，不代表特定行业标准，实际阈值和判定方法应按团队业务确定。
演示需求：用户提交订单后可以查看订单详情。
验收条件（写在需求文档中，逐条编号）：
- 条件一：用户提交订单成功后，能看到包含订单号的提交结果。
- 条件二：用户在订单列表中能打开该订单的详情页。
- 条件三：重复提交同一订单时，系统只生成一条订单记录。
验收标准（挂在每条条件之后，说明判定方法）：
- 条件一对应：在正常网络环境下提交订单，提交成功后页面展示订单号，订单号与后台记录一致。
- 条件二对应：从订单列表点击该订单，详情页展示的商品、数量、金额与提交时填写的内容一致。
- 条件三对应：连续提交同一订单两次，订单列表中该订单只出现一条，后台记录数为一条。
完成定义（团队统一维护，不写进这条需求）：代码评审通过、单元测试通过、相关接口文档更新、提测说明已填写、上线检查项完成。这些检查项对团队所有工作项生效，单独放在团队规范或工作项模板中。
这样配套之后，评审时核对验收条件是否覆盖需求意图，测试时按验收标准逐条执行，关闭工作项前对照 DoD 检查共同环节。三类内容各在其位，任何一类调整都不会牵连另外两类。
适配场景与选择建议
不同团队的起点不同，补齐顺序也可以不同。以下建议按常见情形给出，采用时结合团队实际调整。
- 需求变更频繁、验收争议多的团队，优先补齐验收条件与验收标准。先把每条需求的可观察结果写出来，再为每条结果补上判定方法和阈值。争议往往来自条件模糊或缺少口径，这两项补齐后，验收讨论会从“我觉得可以了”转向逐条核对。
- 交付环节不统一的团队，先统一 DoD。如果同类工作项有的做了代码评审、有的没做，有的更新文档、有的没更新，先确定一份团队共同遵守的完成检查项，再讨论单条需求的验收细节。DoD 稳定之后，验收条件的讨论才有共同的流程基础。
- 小团队可以先合并维护，规模扩大后再拆分。人数少、需求简单的团队，可以把验收条件和验收标准写在同一段里，用“条件 + 判定方法”的句式表达；DoD 可以先做成一份简短清单。当需求数量增加、参与角色变多时，再把三者拆到不同字段和文档位置，避免早期就引入过重的模板。
- 用不同位置承载三类内容，避免混写在同一段落。验收条件放在需求工作项的描述或专用字段中，验收标准紧随对应条件，DoD 作为团队级检查项模板或工程规范单独维护。承载位置分开之后，评审、测试和关闭环节各自读取对应内容，减少重复抄写和口径漂移。
三类内容的维护责任也应分开：验收条件由需求提出方与验收方确认，验收标准由需求方与测试共同确认，DoD 由团队按工程实践定期评审。责任清晰之后，三者各回答各的问题，需求从提出到关闭的每个环节都能找到对应的判定依据。
常见问题
验收条件写几条比较合适，写多了会不会变成测试用例？
条数取决于需求复杂度，判断标准是覆盖需求意图且每条都能判定，没有固定数量。验收条件描述的是“要达成哪些可观察结果”，测试用例描述的是“用哪些步骤去验证”，两者可以一一对应，但不必把操作步骤、测试数据写进验收条件。如果一条条件需要多组步骤才能验证，把步骤留在测试用例里，条件本身保持结果描述即可。
团队已经有测试用例了，还需要单独写验收条件吗？
两者服务不同环节。验收条件在需求澄清和评审阶段就要成形，参与方包括需求提出方、产品和测试，作用是确认这条需求要达成什么；测试用例在评审之后设计，是把验收条件和验收标准转成可执行的验证步骤。缺少验收条件时，测试用例容易只覆盖实现细节，需求方在验收时也缺少逐条核对的依据。已有测试用例的团队可以反过来检查：每条用例对应哪条验收条件，找不到对应关系的用例往往说明需求侧的表达有缺口。
DoD 需要按需求类型区分吗，比如缺陷修复和普通需求用同一份？
可以统一，也可以按工作项类型分几份，取决于团队交付环节的差异程度。如果缺陷修复和普通需求在代码评审、测试、文档更新上的要求基本一致，一份 DoD 就够用；如果缺陷修复有额外的回归验证要求，或紧急修复允许简化部分检查项，按类型分份更贴合实际。无论哪种做法，DoD 都应作为团队级约定单独维护，避免每条需求各写一份，导致口径漂移。
需求变更后，验收条件和验收标准要一起改吗？
看变更影响的是结果还是判定方法。需求目标变化时，验收条件要重写，对应的验收标准随之调整；需求目标不变、只是判定手段或阈值需要调整时，通常只改验收标准。实际操作中建议把两者放在相邻位置维护，变更时一起过一遍，确认每条条件仍有可执行的判定口径。DoD 一般不随单条需求变更，按团队周期评审更新即可。
小团队人手少，三者合并写会不会出问题？
规模小、需求简单时合并维护可行，用“条件 + 判定方法”的句式把验收条件和验收标准写在一起，DoD 做成一份简短清单单独放。需要注意的是合并的是承载位置，不是概念本身：写的时候仍要能分清哪句是结果描述、哪句是判定口径。当需求数量增加、参与角色变多，再把三者拆到不同字段和文档位置，拆分时按已有内容归位即可，不需要重新梳理。
