任务验收要先把完成标准写进任务本身，再由执行人提交交付物、验收人按标准逐项核对，结论只有通过、退回、有条件通过三种；退回必须写明差距和重交时间，重开则回到执行状态重新走同一套标准。本文按单项任务的执行闭环展开，给出完成标准要素、验收步骤、角色分工、退回重开规则和一份完整示例，适用于执行人与验收人共同落地一次可查证的验收。
要点总览（TL;DR）
- 任务验收的关键在标准前置：任务开始前把交付物、质量要求、范围边界写清楚，并确定验收人、验收时点和证据形式。
- 验收按提交、核对、结论、整改重交四步推进，结论限定为通过、退回、有条件通过三种，每种都要写明依据。
- 退回意见必须包含差距项、整改要求和重交时间；重开适用于已通过或已关闭但需重新处理的情形，范围实质变化应新建任务。
- 同一任务多次退回或超时未重交时，由任务负责人介入，判断是标准不清、资源不足还是范围需要调整。
- 验收做完整与否，可用标准前置、证据留存、结论明确、状态正确四组检查项逐条核对。
验收前先把完成标准写清楚
验收争议大多不是发生在验收当天，而是发生在任务开始前：标准写得含糊，验收时只能靠口头解释。把完成标准前置到任务创建或任务启动环节，验收才有可对照的依据。一份可用的完成标准至少包含三部分：可观察的交付物、质量要求、范围边界。
可观察的交付物指验收时能直接打开、查看或运行的东西，例如一份文档、一张配置清单、一段可执行的脚本、一次已上线的变更记录。质量要求描述交付物达到什么程度算合格，尽量写成可判断的条件，例如“覆盖全部五个业务场景”“关键字段无缺失”“在约定数据量下完成一次完整运行”。范围边界说明本次任务包含什么、不包含什么，避免验收时把相邻任务的内容算进来或漏掉。
标准之外还要同时确定三件事：验收人是谁、验收在什么时点触发、证据以什么形式提交。验收人应当是能对质量作出判断的角色，并在任务开始前就知晓自己被指定；验收时点通常与交付物提交同步，也可以约定为阶段性节点；证据形式要具体到附件、记录或截图等可留存的形式，避免验收结论只存在于聊天记录里。
标准在任务执行中发生变更时，要留下变更记录：谁提出、变更了哪一条、变更原因、是否影响交付时间。变更后的标准以最新记录为准，验收人按变更后的版本核对。没有变更记录的调整，验收时容易各执一词。
| 要素 | 填写内容 | 判断是否合格 |
|---|---|---|
| 交付物 | 名称、形式、存放位置 | 验收时能否直接打开核对 |
| 质量要求 | 逐条列出合格条件 | 每条能否给出是或否的判断 |
| 范围边界 | 包含项、不包含项 | 是否与相邻任务划清 |
| 验收人 | 姓名或角色 | 是否在任务开始前确定 |
| 验收时点 | 提交时、阶段节点或约定日期 | 是否与交付节奏匹配 |
| 证据形式 | 附件、记录、截图、运行结果 | 是否随任务留存可回查 |
| 变更记录 | 变更条目、原因、提出人、时间 | 验收是否按最新版本执行 |
任务验收的操作步骤
验收按固定顺序推进，每一步都有明确的输入、动作、输出和完成标志，验收人和执行人都能据此判断当前走到哪一步。
第一步：执行人自检并提交验收。输入是任务中的完成标准和已完成的交付物。动作是逐条对照标准自查，把交付物、自检记录和提交说明一并提交，提交说明写清本次交付覆盖了哪些标准条目、哪些条目存在已知限制。输出是一份完整的验收提交。完成标志是验收人收到提交并能打开全部证据。
第二步：验收人核对标准与证据。输入是完成标准、交付物和自检记录。动作是逐条核对，每条给出符合或不符合的判断，不符合的写明具体差距，例如缺哪个场景、哪个字段为空、哪项质量要求未达到。核对时以证据为准，不以口头说明替代。输出是一份逐条核对记录。完成标志是每条标准都有对应判断，没有悬空条目。
第三步：给出验收结论。结论限定为三种。通过：全部标准条目符合，交付物与范围边界一致。退回：存在影响交付使用的不符合项，需要整改后重交。有条件通过：主体交付可用，剩余不符合项属于不影响当前使用的补充内容，需在约定时间内补齐并记录。三种结论都要写明依据，避免只写“可以”或“再看看”。
第四步：退回后的整改与重交。输入是退回意见。动作是执行人按差距项逐条整改，在约定重交时间前重新提交，并在提交说明中标注每条差距的处理结果。输出是新一轮验收提交。完成标志是验收人按同一套标准重新核对，形成新的结论。重交走的是同一套标准，不因整改而降低要求。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 提交验收 | 完成标准、交付物 | 自检、整理证据、写提交说明 | 验收提交 | 验收人可打开全部证据 |
| 核对 | 标准、交付物、自检记录 | 逐条判断并记录差距 | 核对记录 | 每条标准均有判断 |
| 结论 | 核对记录 | 判定通过、退回或有条件通过 | 验收结论 | 结论有明确依据 |
| 整改重交 | 退回意见 | 逐条整改、重新提交 | 新验收提交 | 按同一标准重新核对 |
验收中的角色分工与交付物
验收环节涉及三个角色：执行人、验收人、任务负责人。分工不清时常见两种问题，一是验收人既提要求又自己改交付物，二是任务负责人只在出争议时出现、平时不确认标准。把每个角色的动作和产出固定下来，可以减少职责重叠和空缺。
执行人负责交付物本身、自检记录和提交说明。自检记录要能对应到标准条目，提交说明要写清覆盖范围和已知限制。执行人不自行判定验收通过，也不在未整改的情况下反复提交相同内容。
验收人负责核对记录、验收结论和退回意见。核对记录逐条对应标准，结论从三种中选一种，退回意见写清差距项、整改要求和重交时间。验收人不在验收环节直接修改交付物，需要修改时退回给执行人处理。
任务负责人负责标准确认、争议裁决和状态维护。标准在任务开始时由任务负责人确认，变更时同样确认；执行人与验收人对结论有分歧时由任务负责人裁决；任务状态在提交、退回、通过各节点由任务负责人或按约定规则更新，保证任务记录与实际进度一致。
| 角色 | 主要动作 | 交付物 | 不承担的事项 |
|---|---|---|---|
| 执行人 | 完成交付物、自检、提交验收、按退回意见整改 | 交付物、自检记录、提交说明 | 判定验收结论 |
| 验收人 | 逐条核对、给出结论、写退回意见 | 核对记录、验收结论、退回意见 | 直接修改交付物 |
| 任务负责人 | 确认标准、裁决争议、维护任务状态 | 标准确认记录、裁决记录、状态更新 | 替代验收人做质量判断 |
当验收结论、退回意见和整改记录都随任务留存时，后续复盘和交接才有依据。在任务管理工具中，这类信息通常以任务状态、验收结论字段和评论或附件的形式沉淀。以 ONES 为例，任务可以在同一工作项中记录状态流转、验收结论与退回说明，使标准、证据和结论留在一条任务记录里，便于执行人和验收人按同一份记录推进。具体字段与配置方式以实际使用环境为准。
退回与重开怎么处理
退回是验收不通过时的标准处置方式，目的是让任务回到执行闭环，而不是停在“已提交待处理”的状态。退回意见要写成可执行的结构，至少包含三项：差距项、整改要求、重交时间。差距项对应到具体标准条目，写清哪一条不符合、不符合在哪里；整改要求说明需要补什么、改到什么程度；重交时间给出明确日期或时限。三项齐全，执行人才能直接开始整改。
重开与新建任务是两种不同处置，适用情形要区分。重开适用于任务已经通过或关闭，但交付物需要重新处理的情形，例如上线后发现遗漏场景、交付内容需要按新证据补充。重开时任务回到执行状态，沿用原有的完成标准重新走验收流程，历史记录保留。新建任务适用于范围发生实质变化的情形，例如原任务只覆盖一个模块，现在要扩展到三个模块，此时应新建任务并重新确定标准、验收人和时点，避免在原任务上不断追加导致记录失真。
多次退回需要设置升级触发条件，常见的有两类：退回次数超过约定上限，例如同一任务退回两次以上；整改超出约定重交时间仍未提交。触发后由任务负责人介入，判断是标准本身需要澄清、执行资源不足，还是范围需要调整，并给出处理结论。升级不是惩罚，而是把卡住的问题放到有裁决权的层级解决。
| 退回意见字段 | 填写要求 | 示例写法 |
|---|---|---|
| 差距项 | 对应标准条目，写明不符合点 | 质量要求第2条：三个场景中缺少异常场景的处理说明 |
| 整改要求 | 补什么、改到什么程度 | 补充异常场景处理步骤，并附一次实际运行记录 |
| 重交时间 | 明确日期或时限 | 三个工作日内重新提交 |
| 结论类型 | 退回或有条件通过 | 退回 |
| 记录人 | 验收人姓名与日期 | 验收人：李某；日期：示例日期 |
一个任务验收的完整示例
以下为演示情景，用于说明标准、提交、核对、退回、重交、通过的全过程，不指向具体组织或真实项目。
任务与标准。任务内容为整理一份客户信息字段说明文档。完成标准写明：交付物为一份字段说明文档，存放在任务附件中；质量要求为覆盖全部八个字段、每个字段包含类型、取值范围和示例三项、字段命名与现有系统一致；范围边界为只覆盖客户基础信息，不包含订单字段；验收人为数据负责人；验收时点为提交当日；证据形式为文档附件加一份自检清单。
提交与核对。执行人完成文档后自检，提交时附上文档和自检清单，提交说明写明八个字段已覆盖、其中两个字段的示例待补充。验收人逐条核对，发现质量要求第二条不满足：两个字段缺少示例；同时发现一个字段命名与系统不一致。核对记录逐条标注，结论为退回。
退回意见。差距项写明两条：字段示例缺失两项、字段命名不一致一处。整改要求为补齐示例并核对命名。重交时间约定为两个工作日内。
整改与重交。执行人补齐示例、修正命名，在提交说明中逐条标注两条差距的处理结果，重新提交。验收人按同一套标准重新核对，八项标准全部符合，结论为通过。任务状态更新为已完成，核对记录、退回意见和重交说明随任务留存。
| 环节 | 记录内容 | 结论 |
|---|---|---|
| 提交 | 文档附件、自检清单、提交说明 | 进入核对 |
| 核对 | 两条不符合：示例缺失、命名不一致 | 退回 |
| 退回意见 | 差距项、整改要求、两个工作日内重交 | 待整改 |
| 重交 | 补齐示例、修正命名、逐条标注处理结果 | 重新核对 |
| 通过 | 八项标准全部符合 | 通过，任务完成 |
验收完成检查清单
一次任务验收是否做完整，可以按下面几组检查项逐条核对。全部满足，说明验收形成了可回查的闭环；存在未满足项，按对应位置补齐后再判定完成。
- 完成标准在任务开始前已写入任务，包含交付物、质量要求、范围边界三部分。
- 每条质量要求都能给出是或否的判断，没有“基本完成”“大致符合”这类表述。
- 验收人、验收时点、证据形式在任务开始时已确定，并在提交前未发生未记录的变更。
- 执行人提交时附有自检记录和提交说明，交付物可直接打开核对。
- 验收人的核对记录逐条对应标准，每条都有判断，没有悬空条目。
- 验收结论为通过、退回或有条件通过之一，并写明了依据。
- 退回意见包含差距项、整改要求和重交时间三项，执行人可据此直接整改。
- 重交按同一套标准重新核对，未降低要求。
- 重开与新建任务的适用情形已区分，范围实质变化时新建任务而非反复重开。
- 多次退回或超时未重交时，已按约定触发任务负责人介入。
- 标准、证据、结论和退回意见随任务留存，任务状态与实际进度一致。
常见问题
任务验收的完成标准由谁定，执行人自己写可以吗？
可以由执行人起草，但需要任务负责人在任务开始前确认。执行人最了解交付内容，起草时容易把标准写具体；任务负责人确认能保证标准与任务目标、相邻任务边界一致。验收人应参与标准确认，避免验收时才发现标准无法判断。标准在任务执行中变更时，同样要记录变更条目、原因和提出人，验收按最新版本执行。
有条件通过之后，剩余项一直没补齐怎么办？
有条件通过时应在结论中写明剩余不符合项、补齐要求和补齐时限，并指定跟进人。补齐时限到期后由跟进人核对，未补齐的按退回处理，给出差距项和新的重交时间；若多次超时，按升级条件交由任务负责人处理。有条件通过的任务在剩余项补齐前，状态应保持可识别的未完结状态，避免被当作已完成任务统计。
任务已经关闭，发现交付物有问题，应该重开还是新建任务？
看问题性质。交付物本身需要重新处理、完成标准仍然适用时，重开原任务，回到执行状态按原有标准重新验收，历史记录保留。范围发生实质变化，例如原任务只覆盖一个模块、现在要扩展到多个模块，应新建任务并重新确定标准、验收人和时点。判断依据是完成标准是否仍然适用，而不是问题大小。
验收人和执行人对结论有分歧，怎么处理？
先回到核对记录：每条标准是否有对应判断、判断依据是否是可查证的证据。分歧通常来自标准表述含糊或证据不足，此时由任务负责人裁决，并把澄清后的标准补充记录到任务中。裁决结论要写明理由，供后续同类任务参考。若分歧反复出现在同一类标准上，说明标准写法需要调整，应在下一次任务开始前修订。
小任务也需要走完整的验收流程吗？
流程可以简化，要素不能省。小任务可以把完成标准写成一句话，验收人由任务负责人兼任，证据用一条记录或一个附件代替。提交、核对、结论三个动作仍然保留，退回意见至少写清差距和重交时间。省掉的是表格和文档量，保留的是标准可对照、结论可回查，这样任务交接和复盘时才有依据。
