任务验收要形成单项任务的闭环，核心是三件事：开工前把完成条件写成可逐项核对的条目，执行中由交付人提交成果和自检说明、验收人按条目核对并留下证据，结束时给出明确结论——通过则关闭归档，不通过则写明差距、责任人和返工期限，重新提交后再验收。下面按定标准、走流程、分角色、看示例、做检查的顺序展开，适用于单个任务的验收执行，不涉及组织级流程规则设计。
要点总览（TL;DR）
- 开工前把完成条件写成可逐项核对的条目，由验收人和交付人共同确认，作为唯一验收依据。
- 验收按提交成果与自检说明、逐项核对留证、给出结论、返工再验收、关闭归档五个动作推进。
- 任务负责人对交付负责，验收人对判定负责，需求提出方对要什么负责，裁决归属提前约定。
- 不通过时逐条写明差距、返工责任人和期限，返工后按同一标准再验收，重点核对差距项。
- 用八项自查清单在开工前和关闭前各查一次，确认标准前置、证据可追溯、结论明确、记录归档。
验收前先定标准：把完成条件写成可核对的条目
验收争议大多源于标准没提前定清楚。开工前把“怎样算完成”写下来，验收时才有共同依据。标准不必复杂，但要能被不同的人独立判断出同一结果。
从任务描述中提取交付物与完成标准
先读任务描述，把两类信息分开：一类是交付物，即任务结束时必须存在的东西，如文档、代码分支、配置变更、数据报表、培训记录；另一类是完成标准，即交付物要满足什么条件才算合格，如覆盖范围、准确率、评审通过、上线验证结果。交付物回答“交什么”，完成标准回答“交到什么程度”。两者都写出来，验收才有落点。
把模糊表述改写为可判断的条目
“基本完成”“效果良好”“尽快上线”这类表述无法核对，需要改写成能勾选、能取证的说法。改写时可以问三个问题：看什么（具体对象）、达到什么（可量化的状态或明确的通过条件）、谁来确认（判定人）。例如把“接口文档整理完成”改写为“接口文档覆盖本期新增的 12 个接口，每个接口含入参、出参、错误码，经后端负责人评审通过”。条目数量控制在能逐项勾选的范围内，过多会拖慢验收，过少会留下模糊地带。
开工前由验收人与交付人共同确认
标准写好后，由验收人和交付人在任务开始前确认一遍，重点确认三件事：条目是否覆盖了需求提出方真正关心的结果；每条标准的判定方式是否可行（有没有数据、环境或评审机制支撑）；是否存在依赖外部条件、本期无法验证的条目。确认方式可以是在任务下留言确认，也可以在一次短会中过一遍并记录结论。确认后的标准作为验收依据固定下来，执行中如需调整，由验收人同意并记录变更原因，避免验收时临时加码。
一份可逐项勾选的验收标准清单，通常包含这些字段：
| 字段 | 填写内容 | 示例 |
|---|---|---|
| 序号 | 条目编号 | 1 |
| 验收条目 | 可判断的完成条件 | 新增接口文档覆盖 12 个接口，含入参、出参、错误码 |
| 判定方式 | 如何核对 | 对照接口清单逐项检查，后端负责人评审 |
| 证据形式 | 需要提交什么 | 文档链接、评审记录 |
| 判定人 | 谁确认 | 后端负责人 |
| 结果 | 通过 / 不通过 / 有条件通过 | 通过 |
验收执行的五个动作：从提交到结论
标准定好后，验收按固定动作推进。每个动作都有输入、做法和输出，输出物是下一步的起点，也是事后追溯的依据。
动作一：交付人提交成果与自检说明
输入是已确认的验收标准清单。交付人对照清单逐条自查，提交两类材料：成果本身（文档、代码、配置、截图、测试结果等可访问的载体）和自检说明（每条标准对应的完成情况、证据位置、未覆盖项及原因）。自检说明的作用是让验收人快速定位证据，也促使交付人在提交前发现明显缺口。输出是一份带证据指向的提交记录。
动作二：验收人逐项核对并记录证据
输入是提交材料与验收标准清单。验收人按条目顺序核对，每条记录三样内容：核对方式（查看了什么、运行了什么、询问了谁）、核对结果、证据位置。核对中发现标准本身有歧义，应暂停该条并回到标准确认环节，不在核对中临时改变判定口径。输出是一份逐项有结论、有证据指向的核对记录。
动作三：给出通过、有条件通过或不通过的结论
全部条目核对完后给出整体结论。三种结论的适用条件要事先说清：全部条目通过为通过；核心条目通过、少量非关键条目存在不影响使用的缺口，可给有条件通过，并写明遗留项、责任人和补齐期限；关键条目未通过则为不通过。结论要写在任务记录中，包含结论类型、依据的核对记录、遗留事项，避免只在口头或聊天中传达。
动作四：不通过时的返工与再验收
结论为不通过时，验收人逐条写明差距：哪条标准未达到、差在哪里、需要补什么。任务负责人据此安排返工，明确返工责任人和完成期限，并把任务状态退回执行中。返工完成后，交付人重新提交成果和自检说明，验收人按同一份标准再验收，重点核对上次的差距项，同时确认返工没有影响已通过的部分。再验收同样留下核对记录和新结论，形成可追溯的往返过程。
动作五：关闭任务并归档
结论为通过或有条件通过且遗留项已补齐后，关闭任务。归档内容包括：确认后的验收标准、提交的成果与自检说明、逐项核对记录、最终结论、返工过程记录（如有）。归档的意义在于后续复盘、审计或同类任务复用标准时能直接查到依据。有条件通过的遗留项在补齐前，任务保持未关闭状态，或单独建立跟进项并关联原任务。
把验收标准、提交证据、核对记录和结论放在同一个任务记录里，状态流转与证据就自然对应起来。在 ONES 中，工作项可以承载验收条目、附件与评论记录，验收结论通过状态流转体现，后续查证时从任务即可回溯整个过程；具体字段与流转配置可按团队现有工作项方案设置。
角色分工与各自交付物
验收涉及三个角色，职责边界清楚，验收才不会变成互相等待。任务负责人对交付结果负责，验收人对判定负责，需求提出方对“要什么”负责。
| 角色 | 主要职责 | 验收节点提交物 |
|---|---|---|
| 任务负责人（交付人） | 按标准完成交付，组织自检，安排返工 | 成果材料、自检说明、返工计划与完成情况 |
| 验收人 | 确认标准、逐项核对、给出结论、记录证据 | 确认后的验收标准、核对记录、验收结论、差距说明 |
| 需求提出方 | 说明业务目标与关键结果，确认标准覆盖真实需求 | 需求说明、对标准的确认意见、对有条件通过遗留项的接受意见 |
争议时的裁决归属需要提前约定。常见做法是：标准理解分歧由验收人依据确认后的标准文本裁定；标准是否覆盖业务目标的分歧由需求提出方裁定；涉及跨团队资源或优先级的分歧，提交双方共同的上级或项目负责人裁定。裁决结果同样记录在任务中，作为后续同类问题的参照。裁决机制写在验收开始前，比争议发生后再找人更有效。
一个完整示例：需求变更任务的验收过程
以下为演示情景，用于说明标准、提交、核对、结论的完整链条。
任务与验收标准
任务：将订单列表页的默认排序由创建时间改为支付时间，并同步更新相关说明文档。开工前确认的验收标准条目为：
- 订单列表页默认按支付时间倒序展示，未支付订单排在已支付订单之后。
- 排序规则在页面说明文档中更新，文档与实现一致。
- 回归验证覆盖列表加载、翻页、筛选三种操作，结果记录在测试记录中。
- 变更说明同步给客服团队，并有确认回复。
提交材料与自检说明
交付人提交：测试环境地址与操作路径、页面说明文档链接、测试记录链接、客服群确认截图。自检说明逐条对应：第 1 条已完成并在测试环境验证；第 2 条文档已更新；第 3 条三种操作均已回归；第 4 条已发送变更说明，客服团队尚未回复确认。
核对记录与结论
验收人核对：第 1 条在测试环境实际操作，排序符合预期，记录操作截图；第 2 条对照文档与页面，发现文档中翻页后的排序描述仍为旧规则，判定不通过；第 3 条查看测试记录，三种操作均有结果，通过；第 4 条确认截图，客服尚未回复，判定未完成。整体结论为不通过，差距项两条：文档翻页排序描述未更新；客服确认未取得。
返工与再验收
验收人写明返工要求：文档翻页排序描述按新规则更新，责任人文档负责人，期限两个工作日；取得客服团队确认回复，责任人任务负责人，期限一个工作日。返工完成后重新提交，验收人只核对这两条差距项，并抽查第 1 条未被返工影响。两条均通过后给出通过结论，关闭任务，归档标准、提交材料、两次核对记录和结论。
验收完成检查：判断这次验收是否合格
验收结束后，用下面这份清单自查，确认动作做到位。任何一项为否，都说明这次验收存在可改进之处，应在下次任务中修正。
- 标准是否在开工前形成条目，并由验收人与交付人确认，确认记录可查。
- 每条标准是否有明确的判定方式和证据形式，不存在“效果良好”这类无法核对的表述。
- 交付人是否提交了自检说明，且每条标准都能指向具体证据位置。
- 核对记录是否逐条对应标准，写明了核对方式和结果，而非只给整体结论。
- 结论是否明确为通过、有条件通过或不通过，并写明依据。
- 不通过时是否写清了差距项、返工责任人和期限，返工后是否按同一标准再验收。
- 有条件通过的遗留项是否有责任人和补齐期限，补齐前任务是否保持跟进状态。
- 验收标准、提交材料、核对记录、结论和返工记录是否归档在同一任务下，可被后续查证。
这份清单也可以反过来用作验收前的准备检查：标准条目是否齐全、证据要求是否可行、判定人是否明确。把检查动作放在开工前和关闭前两个时点，单项任务的验收就能稳定地形成闭环。
常见问题
任务验收的标准在执行过程中可以调整吗？
可以调整，但要留下记录。执行中如果发现某条标准依赖的外部条件发生变化，或原条目本身存在歧义，由提出调整的一方说明原因，经验收人同意后更新标准，并把变更原因和变更后的条目记录在任务中。验收时以最新确认的版本为准，避免出现两套标准各说各话。临时加码的情况要特别避免：验收阶段新增的条目如果开工前没有约定，应先回到标准确认环节，由验收人和需求提出方共同判断是否纳入本次验收。
有条件通过和通过有什么区别，遗留项怎么跟进？
通过表示全部条目达到标准，任务可以直接关闭。有条件通过表示核心条目已通过，少量非关键条目存在不影响当前使用的缺口，需要写明遗留项、责任人和补齐期限。两者的区别在于是否还有未完成的动作。遗留项补齐前，任务保持未关闭状态，或者单独建立一个跟进项并关联原任务，补齐后由验收人确认再关闭。需求提出方对遗留项是否可接受要有明确意见，避免有条件通过变成事实上的默认放行。
验收人和任务负责人是同一个人时怎么办？
小团队里交付人兼任验收人的情况并不少见，这时需要补一道独立确认。常见做法是把判定权交给需求提出方或另一位同事，至少对关键条目做一次交叉核对；也可以由交付人提交自检说明后，请需求提出方在任务中回复确认。自检和判定由同一人完成时，核对记录要写得更细，逐条写明查看了什么、证据在哪里，方便事后复查。涉及对外交付或合规要求的任务，建议固定由独立于交付的人担任验收人。
验收记录需要保存多久，保存在哪里比较合适？
保存期限取决于任务的用途和所在行业的记录要求，没有统一标准。通用做法是：验收标准、提交材料、核对记录、结论和返工记录与任务本身保存在一起，跟随任务的归档周期管理；涉及合同交付、审计或合规要求的任务，按相关规定延长保存时间。保存在任务记录中的好处是查证时从任务直接回溯，不必再到聊天记录或邮件里翻找。如果证据体量较大，可以在任务中保留链接和说明，原始文件放在团队约定的存储位置。
多个任务共用一套验收标准时，怎么组织比较省事？
把重复出现的验收要求整理成标准模板，每个任务引用模板后再补充本次特有的条目。模板适合放通用判定方式，比如文档类交付的评审要求、代码类交付的测试覆盖要求；任务特有的范围、数量、对象放在任务自己的条目里。使用模板时仍要在开工前由验收人和交付人确认一遍，确认本次引用的版本和补充条目，避免模板更新后旧任务按新标准被验收。模板本身也应有维护人，定期清理已经不适用的条目。
