完成定义（Definition of Done，DoD）和单条需求的验收条件（Acceptance Criteria，AC）经常被混用，实际分工很清楚：完成定义是团队对所有工作共用的完成门槛，验收条件只描述某一条需求要做成什么样。前者决定“能不能对外交付”，后者决定“这条需求做对没有”。本文围绕敏捷交付场景，说明两者的对象、差异、配合方式与落地写法。
要点总览（TL;DR）
- 完成定义（DoD）是团队对所有需求共用的交付门槛，验收条件（AC）只描述单条需求要做成什么样。
- 两者在适用对象、制定者、覆盖范围、变更频率、判断时点和缺失后果六个维度上差异明显，通用动作归完成定义，业务结果归验收条件。
- 同一条需求上先按验收条件判断内容是否做对，再按完成定义判断是否具备交付条件，两个方向的处理结果不同。
- 团队缺少统一交付门槛时先建立完成定义，需求描述含糊、返工多时优先补验收条件；两者都薄弱时先做完成定义。
- 完成定义适合用团队共享文档维护并定期评审，验收条件随需求条目编写并在评审时确认，检查动作落到工作项和文档上。
完成定义与验收条件各自管什么
完成定义是团队级约定，回答“一项工作达到什么状态才算完成”。它跨需求适用，通常覆盖代码提交、自动化测试通过、代码评审完成、必要文档更新、部署到指定环境等收尾动作。团队一旦约定，所有进入交付流程的需求都按同一门槛检查，不因某条需求特殊而降低。
验收条件是单条需求的交付说明，回答“这条需求要满足哪些具体行为、结果或边界才算做对”。它随需求内容变化，写法偏向可观察的业务结果，例如“用户提交订单后，库存扣减在3秒内生效”“手机号格式错误时提示具体错误原因”。验收条件由需求提出方与开发、测试共同确认，是需求评审和测试设计的直接依据。
两者在交付顺序上前后衔接：先用验收条件判断需求内容是否达标，再用完成定义判断达标之后是否具备交付条件。一条需求可能业务行为全部符合验收条件，但自动化测试未跑通或文档未更新，此时它“做对了”却“还不能交付”。反过来，完成定义全部满足，验收条件中某条业务规则未实现，也不能算这条需求完成。这个先后关系是理解两者区别的关键。
同一口径下的差异对照
把两个概念放到相同维度上对照，差异会更具体。下表按适用对象、制定者、覆盖范围、变更频率、判断时点和缺失后果六个维度展开。
| 对照维度 | 完成定义（DoD） | 验收条件（AC） |
|---|---|---|
| 适用对象 | 团队所有需求与增量，跨需求共用 | 单条需求，只对该需求生效 |
| 制定者 | 团队共同约定，开发、测试、产品共同认可 | 需求提出方主导，开发与测试参与确认 |
| 覆盖范围 | 交付流程的通用收尾动作与质量门槛 | 该需求的业务行为、结果与边界条件 |
| 变更频率 | 相对稳定，团队能力或流程变化时评审调整 | 逐条编写，随需求澄清和范围调整而变化 |
| 判断时点 | 需求收尾、准备交付或发布前检查 | 需求评审确认，测试与验收阶段逐条核对 |
| 缺失后果 | 交付质量参差，收尾动作靠个人习惯 | 需求理解不一致，返工和争议增多 |
从表中可以看出，完成定义偏交付门槛，验收条件偏需求内容正确性。完成定义稳定，团队才有可比较的交付质量；验收条件逐条编写，才能覆盖每条需求的业务差异。两者出现重叠时，按“通用动作归完成定义、业务结果归验收条件”处理。例如“接口测试通过”属于完成定义，“下单接口在库存不足时返回明确提示”属于验收条件。若某条验收条件实际上对所有需求都成立，应把它上移到完成定义，避免每条需求重复书写。
一条需求从验收到完成的过程示例
以下为演示情景，用于说明两类标准如何先后起作用。假设一条需求是“会员在结算页使用积分抵扣订单金额”。
验收条件可以写成：会员积分足够时，结算页显示可用积分与抵扣金额；抵扣后应付金额等于原价减去抵扣金额；积分不足时给出提示并允许取消抵扣；抵扣结果在订单确认后写入订单记录。这些条件描述的是这条需求特有的业务行为，测试人员据此设计用例。
完成定义在该需求收尾时检查：代码已合并到主干、自动化测试全部通过、代码评审完成、相关接口文档更新、已部署到验收环境。这些动作对所有需求一致，不因积分抵扣这条需求而改变。
验收通过但完成定义未满足时，例如业务行为全部正确但接口文档未更新，需求状态停留在待交付，补齐文档后再进入发布。完成定义满足但验收条件未通过时，例如测试和评审都完成，但积分不足场景没有提示，需求退回开发修改，不能因为“流程动作都做完了”就放行。两种处理方向不同，正好体现两类标准各管一段。
常见混淆与写法边界
实践中写混的情形集中在四类，下面给出区分写法。
- 把通用门槛写进单条需求的验收条件。例如在每条需求下都写“单元测试通过”“代码已合并”。这类内容应归入完成定义，验收条件只保留该需求特有的业务判断。
- 把某条需求的业务规则写进团队完成定义。例如把“积分抵扣金额计算正确”写进完成定义。完成定义面向所有需求，业务规则应留在对应需求的验收条件中。
- 验收条件写成实现方案而非可验证结果。例如写“使用缓存优化查询”，这描述的是做法，无法直接判断对错。可改为“商品列表在常用筛选条件下2秒内返回结果”，让测试有明确核对对象。
- 完成定义写得过细，导致每条需求都要申请例外。例如把特定模块的部署步骤写进通用门槛。完成定义应保留团队普遍适用的检查项，特殊流程放到该需求的补充说明或单独检查清单中。
区分写法的共同原则是：能被所有需求共用、用于判断交付条件的，放进完成定义；只对某条需求成立、用于判断业务结果是否正确的，写进验收条件。按这个原则检查一遍，大部分混淆可以当场消除。
在团队协作中如何落地这两类标准
完成定义适合作为团队共享文档维护，由团队在迭代回顾或流程评审时定期检查，确认检查项仍然适用。文档放在团队都能访问的位置，新成员加入时直接阅读，减少口头传达。验收条件随需求条目编写，在需求评审会上由提出方、开发和测试共同确认，确认后再进入开发。
需求状态流转时，两类标准承担不同检查动作。进入开发前核对验收条件是否清晰可测；准备交付时按完成定义逐项检查收尾动作。把标准放在工作项和文档中，检查时有据可查，避免依赖个人记忆。
在 ONES 中，产品负责人可按优先级把需求规划到对应迭代，并在迭代计划会议上与团队共同评审需求；对当前迭代要完成的需求与验收标准达成一致后，设计、研发、测试人员可用子任务拆分需求，便于后续跟踪。测试工程师可依据需求与验收标准编写测试用例，未通过的用例可转为缺陷提交至项目并指派工程师修复。迭代结束后，团队还可用 ONES Wiki 沉淀经验，形成知识库。完成定义的专门模板或状态校验能力，现有资料未涉及，选型时可另行核验；团队可先用共享文档承载完成定义，与需求工作项配合使用。
适配场景与使用建议
团队交付质量参差、收尾动作靠个人习惯时，优先建立完成定义。做法是先列出当前交付前实际会做的检查动作，收敛成一份团队认可的清单，再在几次迭代中试用并调整。完成定义稳定后，交付质量才有可比较的基础。
需求描述含糊、评审后返工多时，优先补验收条件。可以从返工最多的需求类型入手，要求每条需求至少写出可观察的业务结果和关键边界，评审时逐条确认。验收条件写清楚后，测试设计和开发理解都会更一致。
两者都薄弱时，建议先建立完成定义，再补验收条件。原因是完成定义条目少、团队容易达成一致，能较快形成统一交付门槛；验收条件需要逐条练习，适合在门槛稳定后逐步推进。标准建立后，验证是否真正执行可以看三个信号：交付前检查是否按完成定义逐项进行、需求评审是否因验收条件不清而反复、缺陷中是否出现本可在验收条件阶段发现的问题。按这些信号调整标准内容，比单纯增加条目更有效。
常见问题
完成定义和验收条件可以合并成一份清单吗？
不建议合并。完成定义面向团队所有需求，验收条件只对单条需求生效，两者的适用范围和变更节奏不同。合并后容易出现两种问题：通用门槛被逐条需求重复书写，或者某条需求的业务规则被误当成团队标准。可行的做法是分开维护，在需求评审和交付检查时分别引用，遇到重叠内容按“通用动作归完成定义、业务结果归验收条件”归位。
一条需求的验收条件通过了，但完成定义没满足，应该怎么处理？
需求状态停在待交付，补齐完成定义中的检查项后再进入发布。常见情形是业务行为全部正确，但接口文档未更新、自动化测试未跑通或代码评审未完成。这类情况说明需求内容已经做对，交付条件还不具备，处理方向是补收尾动作，不需要退回重做业务逻辑。
完成定义需要多久评审一次？
没有统一周期，按团队流程变化和检查项失效的情况安排。团队能力提升、工具链调整或交付环境变化时，原有检查项可能不再适用，需要评审更新。实践中可以在迭代回顾时顺带确认完成定义是否仍然有效，发现某条检查项长期被跳过或频繁申请例外，就是调整的信号。评审频率取决于变化速度，不必为了形式固定周期。
验收条件写成实现方案有什么问题？
实现方案描述的是做法，无法直接判断对错，测试人员难以据此设计用例，开发改动实现方式后也无法确认需求是否仍然达标。验收条件应写成可观察的业务结果或边界，例如把“使用缓存优化查询”改为“商品列表在常用筛选条件下2秒内返回结果”，让核对对象明确。
团队刚开始推行这两类标准，先做哪一个？
建议先建立完成定义。完成定义条目少，团队容易达成一致，能较快形成统一交付门槛；验收条件需要逐条练习，适合在门槛稳定后逐步推进。标准建立后可以看三个信号验证执行情况：交付前是否按完成定义逐项检查、需求评审是否因验收条件不清而反复、缺陷中是否出现本可在验收条件阶段发现的问题。
