验收条件、验收标准和完成定义经常在同一份需求讨论里出现，却回答着不同问题：验收条件说明这条需求怎样算通过，验收标准说明按什么尺度判定通过，完成定义说明交付前团队必须共同做完哪些动作。本文按作用对象、粒度和使用位置展开对照，并用同一个需求示范三份写法，帮助你在需求流程中判断该写哪一个。
要点总览（TL;DR）
- 验收条件写在单条需求或用户故事上，用可判定的语句说明这条需求满足什么才算通过。
- 验收标准是验收条件所依据的判定口径与合格阈值，规定按什么尺度判通过，可跨多条需求复用。
- 完成定义（DoD）是团队对所有工作项统一的完成约定，覆盖开发、测试、文档、评审等共同环节。
- 判断该写哪一个，依次看对象是单条需求还是团队共性、是否需要阈值或判定口径、复用范围有多大。
- 三者常同时存在：先按完成定义确认共同动作，再逐条核对验收条件，需要量化判断时引用验收标准。
三者分别回答什么问题
三个概念处在需求表达的不同层级。把它们放在同一句话里理解：完成定义规定“做完的共同动作”，验收条件规定“这条需求的通过条件”，验收标准规定“判定通过时采用的尺度和阈值”。层级从团队共性到单条需求逐层收窄，适用范围也随之缩小。
验收条件写在单条需求或用户故事上，用可判定的语句说明这条需求满足什么才算通过。它针对具体功能或行为，例如“提交订单后库存扣减一次”“密码错误三次后锁定十分钟”。验收条件的价值在于把模糊的期望转成可以逐条核对的句子，评审时能直接回答“通过还是不通过”。
验收标准是验收条件所依据的判定口径与合格阈值。它不描述某条需求的具体行为，而是规定用什么尺度判。例如响应时间以哪个分位统计、金额误差允许到哪一位、兼容范围覆盖哪些浏览器版本。验收标准让不同人面对同一条验收条件时得出相同结论，减少“我觉得可以了”式的分歧。
完成定义（Definition of Done，DoD）是团队对“工作已完成”的统一约定，覆盖开发、测试、文档、评审等共同环节，适用于所有工作项。它回答的是“交付前必须做完哪些共同动作”，例如代码已合并、单元测试通过、文档已更新、已通过评审。完成定义不针对某条需求的具体行为，而是团队协作的底线。
三者的层级关系可以概括为：完成定义管所有工作项的共同完成动作，验收条件管单条需求的通过判定，验收标准管判定时采用的尺度。混用这三个词，常见后果是把团队共性约定写进单条需求，或者用一句“功能正常”代替可判定的条件。
同口径差异对照：对象、粒度与使用位置
把三者放在同一组维度下对照，差异会更清楚。下表按作用对象、粒度与复用范围、定义者、使用环节、判定方式和变更处理六个维度展开，后续场景判断都以这张表为依据。
| 维度 | 验收条件 | 验收标准 | 完成定义 |
|---|---|---|---|
| 作用对象 | 单条需求或用户故事 | 验收条件所依据的判定尺度 | 团队全部工作项 |
| 粒度与复用范围 | 逐条编写，随需求变化，复用范围限于同类需求 | 可跨多条需求复用，同一类判定口径可长期沿用 | 团队级统一约定，长期稳定，少量修订 |
| 定义者 | 需求提出方与开发、测试共同澄清后确定 | 由质量或业务口径的负责人确认，测试参与校准 | 团队共同约定，由团队负责人或质量角色维护 |
| 使用环节 | 需求澄清时写下，验收评审时逐条核对 | 澄清阶段明确，判定和验收时引用 | 开发、提测、交付各环节持续检查 |
| 判定方式 | 逐条判断通过或不通过 | 按阈值或口径计算、比对 | 逐项检查共同动作是否完成 |
| 变更处理 | 需求变更时同步修订，需重新确认 | 口径调整需评估对既有需求的影响 | 团队评审后统一修订，避免个人自行放宽 |
从表中可以看出，验收条件的数量最多、变化最频繁，完成定义的数量最少、最稳定。验收标准介于两者之间：它比验收条件更抽象，比完成定义更贴近具体判定。实际写作时，如果一条内容只对某条需求成立，它属于验收条件；如果它描述的是判定尺度，应归入验收标准；如果它对所有工作项都成立，应放进完成定义。
在需求流程中各自落在什么位置
按需求从提出到验收的顺序看，三个概念出现的时间和承担的角色不同。
需求澄清阶段是验收条件成形的主要环节。需求提出方说明期望，开发和测试追问边界，把“用户能顺利下单”拆成若干条可判定的语句。这个阶段同时要确认验收标准：库存扣减以哪个数据源为准、金额精度保留几位、并发场景如何判定。验收条件与验收标准配合使用，前者列出要核对的行为，后者给出核对时采用的尺度。
开发与提测阶段主要由完成定义发挥作用。开发完成编码后，按完成定义检查代码是否合并、单元测试是否通过、文档是否更新、是否通过评审。完成定义在这里的作用是防止“代码写完就算完成”，把测试、文档、评审等共同动作纳入完成判断。它不替代验收条件，因为完成定义检查的是动作是否做完，验收条件检查的是行为是否符合预期。
验收评审阶段三者同时被引用。评审人先按完成定义确认共同动作已完成，再逐条核对验收条件，遇到需要量化判断的条目引用验收标准。三者的引用顺序通常是：完成定义确认交付前提，验收条件逐条判定，验收标准提供判定依据。
常见错位是把完成定义当验收条件使用。例如在需求里写“测试通过即可验收”，这句话描述的是团队共同动作，放在完成定义里合适；作为某条需求的验收条件，它没有说明这条需求本身要满足什么行为，评审时无法据此判断功能是否正确。另一种错位是把验收标准写成验收条件，例如只写“响应时间符合标准”，却没有说明标准是多少、在什么条件下测量，导致判定时各说各话。
一个需求示例：三份表述如何配合
以下为演示情景，用于说明写法，不代表真实项目数据。假设需求是“用户提交订单后扣减库存”。
验收条件写成可逐条核对的句子：
- 用户提交订单成功后，对应商品的可售库存减少与订单数量相同的数量。
- 库存不足时，订单提交失败并提示库存不足，库存数量保持不变。
- 同一订单重复提交，库存只扣减一次。
- 订单取消后，已扣减的库存恢复。
验收标准给出判定口径与阈值：
- 库存数量以商品库存服务返回的可售数量为准，不以页面缓存展示值为准。
- 库存扣减在订单提交成功后完成，判定时以订单状态变为“已提交”后的库存查询结果为依据。
- 并发提交场景下，允许的库存差异为 0，即不出现超卖。
- 提示文案的判定以产品文案表为准，允许标点差异。
完成定义列出团队共同动作：
- 代码已合并到主干并通过代码评审。
- 单元测试与接口测试通过，覆盖正常扣减、库存不足、重复提交、取消恢复四类场景。
- 接口文档与库存字段说明已更新。
- 已在测试环境完成提测，缺陷修复后回归通过。
三者同时使用时的检查顺序建议为：先确认完成定义中的共同动作是否全部完成，再逐条核对验收条件，遇到需要量化或口径判断的条目引用验收标准。这个顺序能避免在共同动作未完成时过早进入功能判定，也能避免验收条件缺少判定尺度而反复返工。
怎么判断该写哪一个
判断规则可以按三个问题依次问自己。
第一，看对象是单条需求还是团队共性。内容只对当前这条需求成立，写成验收条件；内容对所有工作项都成立，写进完成定义。例如“订单取消后库存恢复”只属于库存相关需求，是验收条件；“接口文档已更新”对所有需求都适用，属于完成定义。
第二，看是否需要阈值或判定口径。需要说明按什么尺度判、允许多大误差、以哪个数据源为准，写成验收标准。验收条件本身可以判定，但当判定依赖量化口径时，应把口径单独写清楚，避免把阈值塞进条件句里造成歧义。
第三，看复用范围。预计会被多条需求反复引用的判定口径，适合沉淀为验收标准；只在一处使用的具体行为，写成验收条件即可；长期稳定的团队约定，放进完成定义并定期评审。
三者同时需要的情形很常见：一条涉及金额计算的需求，既需要验收条件列出计算行为，也需要验收标准说明精度和取数口径，还需要完成定义约束测试与文档动作。写多了的代价是维护成本上升，验收条件冗长导致评审失焦；写少了的代价是判定依赖口头共识，验收时反复争议。取舍的原则是：每条需求写清可判定的验收条件，判定口径有量化要求时补验收标准，团队共性动作统一放进完成定义，不在单条需求里重复抄写。
落地建议：在协作工具中承载这三类约定
三类约定要真正发挥作用，需要落到具体的工作项字段、文档和评审动作上，而不是停留在会议记录里。
- 验收条件作为需求工作项的字段或描述结构。在需求条目中设置验收条件区域，按条目列出，评审时逐条勾选通过或不通过，避免条件散落在评论和聊天记录中。
- 验收标准作为判定口径的文档或模板。把常用的判定口径整理成模板或文档，需求引用对应口径，减少每条需求重复描述阈值。
- 完成定义作为团队级约定文档，并关联工作项状态。将完成定义写成团队文档，在状态流转到“待验收”或“已完成”前作为检查依据，防止共同动作未完成就推进状态。
- 评审与交接时统一引用。验收评审记录中同时引用完成定义检查结果、验收条件核对结果和验收标准口径，形成可追溯的判定依据。
在协作工具中承载这些约定时，可以把需求条目、状态流转和文档协作放在同一处。ONES 提供需求与工作项管理、文档协作等能力，可用于承载需求条目及其验收条件、团队约定文档，以及状态推进时的检查动作；具体字段配置和状态流转方式需结合团队实际流程设置。把三类约定分别放到工作项字段、口径文档和团队约定文档中，并在评审时按顺序引用，能让“怎样算通过”“按什么尺度判”“交付前做完什么”三个问题各有归属，减少验收阶段的反复确认。
常见问题
验收条件和验收标准可以合并成一条写吗？
可以合并书写，但建议保留两层含义。合并时容易把阈值塞进条件句，造成判定歧义，例如“响应时间符合标准”既没有说明标准是多少，也没有说明在什么条件下测量。更稳妥的做法是验收条件只写可核对的行为，判定口径和阈值单独列出，需要时引用已有的验收标准。
如果团队规模小、判定口径简单，把两者写在同一段里也能用，前提是每条条件都能被不同的人得出相同结论。
完成定义已经覆盖测试和评审，还需要单独写验收条件吗？
需要。完成定义检查的是共同动作是否做完，例如测试是否通过、文档是否更新、评审是否完成；验收条件检查的是这条需求本身的行为是否符合预期。两者回答的问题不同，完成定义通过不代表功能行为正确。
常见错位是在需求里写“测试通过即可验收”，这句话属于团队共同动作，放在完成定义里合适，作为验收条件则无法说明这条需求要满足什么行为。
验收标准应该由谁确认，需求变更时怎么处理？
验收标准涉及判定尺度，通常由质量或业务口径的负责人确认，测试参与校准，需求提出方知悉。它比验收条件更稳定，可以跨多条需求长期沿用。
需求变更时，验收条件随需求同步修订并重新确认；验收标准的调整要评估对既有需求的影响，避免同一口径在新旧需求间不一致。完成定义的修订则由团队统一评审，防止个人自行放宽。
一条需求同时需要三者时，评审按什么顺序引用？
建议按“完成定义—验收条件—验收标准”的顺序：先确认共同动作是否全部完成，再逐条核对验收条件，遇到需要量化或口径判断的条目引用验收标准。
这个顺序能避免共同动作未完成就进入功能判定，也能避免验收条件缺少判定尺度而反复返工。评审记录中同时保留三部分结果，便于后续追溯。
三者写多少合适，写多了有什么代价？
取舍原则是：每条需求写清可判定的验收条件，判定有量化要求时补验收标准，团队共性动作统一放进完成定义，不在单条需求里重复抄写。
写多了的代价是维护成本上升，验收条件冗长导致评审失焦；写少了的代价是判定依赖口头共识，验收阶段反复争议。完成定义保持精简稳定，定期评审即可。
