任务验收具体怎么做：步骤、角色与检查清单

任务验收要解决的是把“做完了”变成“可核对”。做法分四步：开工前把验收标准写成可判断的条目，执行人完成后提交交付物和自检说明，验收人按条目逐项核对并给出通过、有条件通过或不通过，最后把结论、遗留项和后续动作写回任务记录。本文面向单项任务的执行人和验收人，给出标准写法、当天操作顺序、角色分工、完整示例和关闭前检查清单。

要点总览（TL;DR）

• 验收前把标准写成可判断的条目，每条对应明确的证据形式，并事先约定通过、有条件通过、不通过三种判定口径。
• 验收当天按提交、核对、判定、记录四个动作推进：执行人交交付物与自检说明，验收人逐条核对，结论写回任务记录。
• 角色上区分执行人、验收人、需求提出方和最终判定人，争议按开工前约定的升级路径裁定。
• 关键条目未满足只能判不通过，非关键问题可登记为遗留项，明确责任人与期限后随任务关闭或转入后续任务。
• 关闭任务前逐项确认：每条标准有判定结果、证据可查、遗留项已登记、结论已通知相关方、任务状态与结论一致。

验收前先把标准写清楚：条目、证据与判定口径

验收争议大多不是发生在验收当天，而是发生在任务开始时。标准写得模糊，验收人只能凭印象判断，执行人也无法确认自己是否做到位。开工前把标准定成条目，后续核对才有依据。

把标准写成可判断的条目

一条合格的验收标准应当让两个人分别看，能得出相同结论。写法上尽量包含对象、动作和可观察的结果。对比下面两组表述：

模糊表述	可判断的条目
完成用户信息页改版	用户信息页按设计稿完成改版，包含头像、昵称、联系方式三个区块，在桌面端和移动端各验证一次
数据准确	导出报表的订单数与后台订单列表一致，抽取最近7天的数据核对，差异为0
文档写好	提交操作手册，覆盖安装、配置、常见问题三章，每章至少包含一个可执行的步骤示例
性能达标	首页在测试环境加载时间不超过约定值，连续测试5次取中位数

条目数量控制在能逐条核对的范围内。一项任务拆出三到八条比较常见，条目过多说明任务本身需要拆分。每条标准只描述一个可验证的结果，避免把多个要求塞进一句话。

为每条标准指定证据形式

标准之后要跟证据。证据是验收人核对时实际看到的东西，常见形式有文档、截图、数据、演示和录屏。指定证据形式的作用是让执行人知道交付什么，也让验收人知道看什么。

• 文档类：交付文件本身，注明版本和存放位置。
• 界面或流程类：关键页面截图，或一段完整操作的录屏。
• 数据类：导出文件、查询结果或核对记录，注明取数时间和范围。
• 功能类：可现场演示的环境与操作路径，或演示录屏。

证据要求与标准一一对应。某条标准如果找不到合适的证据形式，说明这条标准可能无法验收，需要改写或删除。

事先约定三种判定口径

验收结论建议只设三种，并在开工前说明各自的含义和后续动作：

• 通过：全部条目满足，任务可以关闭。
• 有条件通过：主体结果满足，存在不影响使用的遗留项，登记责任人和期限后关闭或转入后续任务。
• 不通过：存在关键条目未满足，需要返工并重新验收。

“有条件通过”容易被滥用，建议在开工前明确哪些条目属于关键条目。关键条目未满足时只能判不通过，其余条目的问题可以进入遗留项。

开工前完成标准确认

标准由任务负责人起草，验收人和需求提出方在开工前确认。确认的动作可以是一次简短评审，也可以是任务记录里的一条回复，关键是留下“标准已确认”的记录。确认之后如需修改标准，要说明原因并通知相关方，避免验收当天才调整口径。

验收执行的四个动作：提交、核对、判定、记录

验收当天按固定顺序推进，每个动作都有明确的输入和输出，可以减少来回沟通。

动作一：执行人提交交付物与自检说明

提交的内容包括交付物、证据和自检说明。自检说明按验收标准逐条写，每条注明“已完成，证据见某处”或“未完成，原因是什么”。自检说明的价值在于让验收人先看到执行人的判断，核对时重点检查分歧点。

提交时同时说明本次交付的范围和已知限制，例如哪些环境未覆盖、哪些数据未取到。提前说明限制，比验收时被追问更有利于形成一致结论。

动作二：验收人逐条核对

核对按标准条目顺序进行，每条记录核对方式和结果。核对方式包括查看文档、比对数据、现场演示或抽查。涉及数据或批量结果的条目，可以约定抽样比例和抽样方法，例如随机抽取若干条记录核对，并在记录中写明抽样范围。

需要演示的条目提前约定时间和环境，演示过程中按标准描述的操作路径走一遍，避免临时发挥。核对中发现证据不足的条目，当场记录为待补充，不凭口头说明判定通过。

动作三：给出判定结论

全部条目核对完成后给出整体结论，并说明依据。三种结论对应不同后续动作：

结论	适用情形	后续动作
通过	全部条目满足	关闭任务，归档证据
有条件通过	关键条目满足，存在非关键遗留项	登记遗留项、责任人和期限，任务可关闭或转入后续任务
不通过	存在关键条目未满足	列出返工条目，约定复验时间，任务保持进行中

动作四：把结论写回任务记录

验收结论要落在任务记录里，而不是只存在于聊天或会议中。记录内容包括：整体结论、每条标准的判定结果、遗留项清单（事项、责任人、期限）、复验安排（如有）以及通知了哪些相关方。写回记录后，任务状态与结论保持一致：通过或有条件通过的任务进入完成状态，不通过的任务回到进行中并注明返工内容。

在工具中执行这套流程时，验收结论和遗留项需要与任务本身关联，方便后续追溯。ONES 的任务工作项支持状态流转和记录留痕，可以把验收结论、遗留项和责任人写在任务记录中，使任务状态与验收结果对应，复验时也能直接查看上一轮的判定依据。

角色分工：谁定标准、谁交证据、谁签字

验收时无人拍板，通常是因为角色没有提前分清。单项任务验收涉及四类角色，各自的职责和交接点如下。

角色	主要动作	交付物	交接点
任务负责人（执行人）	起草验收标准，完成任务，整理证据，写自检说明	验收标准初稿、交付物、证据、自检说明	向验收人提交验收申请
验收人	确认标准，逐条核对，给出判定结论	核对记录、判定结论、遗留项清单	向执行人和需求方反馈结论
需求提出方或业务方	确认标准是否符合业务预期，确认验收结果	标准确认记录、结果确认意见	在开工前和结论给出后两个节点参与
最终判定人	在争议时裁定结论	裁定意见	争议发生后介入

执行人对交付质量和证据完整性负责，自检说明要如实反映完成情况。验收人对核对过程和判定结论负责，核对记录要能支撑结论。需求提出方不代替验收人逐条核对，其职责是确认标准与业务目标一致，并在结论给出后确认结果可接受。

争议的升级路径在开工前约定。常见做法是：执行人与验收人对某条标准的判定有分歧时，先回到标准原文核对；标准本身存在歧义时，由需求提出方解释；仍无法达成一致时，提交事先约定的最终判定人裁定。最终判定人一般由对该任务结果承担责任的管理者担任。升级路径写进任务记录，争议发生时按路径走，避免临时找人拍板。

一个完整示例：从任务下达到验收关闭

以下示例为演示情景，用于说明标准、证据与结论如何对应。

任务：为客服团队整理一份退款操作手册，供新入职客服使用。

验收标准条目

编号	验收标准	证据形式	是否关键
1	手册覆盖退款申请、审核、打款三个环节，每个环节有操作步骤	手册文档	是
2	每个环节配至少一张系统界面截图，截图与当前系统版本一致	文档内截图	是
3	列出5个常见异常场景及处理方式	手册“常见问题”章节	否
4	由一名未接触过退款流程的客服按手册独立完成一次模拟操作	模拟操作记录	是

执行人提交的证据

执行人提交手册文档、界面截图、模拟操作记录和自检说明。自检说明逐条对应：条目1至3已完成并注明位置；条目4已完成，模拟操作由一名新客服执行，过程中在审核环节卡住一次，经口头指导后完成，已在记录中注明。

验收人核对与判定

验收人按条目核对：条目1、2满足；条目3的异常场景只写了4个，记录为未满足；条目4的模拟操作记录显示新客服需要口头指导才能完成，说明手册在该环节的说明不够清楚，记录为部分满足。由于条目4属于关键条目，整体判定为不通过，返工要求为补齐第5个异常场景，并补充审核环节的操作说明后重新做一次模拟操作。

返工与复验

执行人按返工要求修改手册，补充审核环节的分步说明和第5个异常场景，重新安排一名新客服做模拟操作，本次独立完成。复验时验收人只核对返工涉及的条目和受影响的条目，其余条目沿用上一轮结论。复验通过，任务关闭，两轮验收记录都保留在任务中。

验收完成检查：关闭任务前逐项确认

关闭任务前，用下面的清单逐项确认。任何一项不满足，先补齐再关闭。

• 每条验收标准都有明确的判定结果，没有“待确认”“基本满足”这类中间状态。
• 判定结果有对应的证据支撑，证据位置在记录中可查。
• 遗留项已登记，每项都有责任人和期限，并说明是随任务关闭还是转入后续任务。
• 验收结论已通知执行人、需求提出方等相关方，通知方式和时间有记录。
• 任务状态与验收结论一致：通过或有条件通过的任务为完成状态，不通过的任务为进行中并注明返工内容。
• 复验安排（如有）已写入任务记录，包含复验范围和预计时间。
• 标准在验收过程中如有调整，调整原因和确认人已记录。

这份清单同时可以作为验收记录的模板：把每项的确认结果填进去，任务就有了完整的验收留痕，后续复盘或交接时可以直接查阅。

常见问题

验收标准在任务进行中需要调整，怎么处理才不影响后续验收？

调整标准要留下记录：说明调整原因、由谁确认、影响哪些条目。调整后通知执行人、验收人和需求提出方，避免验收当天才用新口径核对。如果调整发生在执行人已按旧标准完成部分工作之后，要一并说明已完成部分是否仍然有效，防止返工范围被临时扩大。

验收人核对时发现证据不足，但执行人口头说明已经做到，可以判通过吗？

建议不判通过。证据不足的条目当场记录为待补充，由执行人补齐后再核对。口头说明可以作为线索，用来确定需要补哪份证据，不能替代核对依据。如果某条标准反复出现证据难以提供的情况，说明这条标准在开工时的证据形式定得不合适，应在记录中注明并作为下次定义标准的参考。

有条件通过之后，遗留项应该随任务关闭还是单独建任务？

取决于遗留项是否影响任务目标的达成。不影响使用的非关键问题，可以登记责任人和期限后随任务关闭，在任务记录中保留遗留项清单；会影响后续环节或需要独立排期的问题，建议转入后续任务，并在原任务记录中注明去向。两种做法都要保证遗留项有人负责、有期限、可追溯。

复验时是否需要把所有条目重新核对一遍？

通常只核对返工涉及的条目和受影响的条目，其余条目沿用上一轮结论，并在记录中写明沿用的依据。如果返工改动范围较大，或者距离上一轮验收时间较长，可以扩大复验范围。复验结论同样按通过、有条件通过、不通过三种口径给出，两轮记录都保留在任务中。

验收结论记录在任务工具里，需要包含哪些内容才算完整？

至少包含整体结论、每条标准的判定结果与证据位置、遗留项清单（事项、责任人、期限）、复验安排（如有）以及通知了哪些相关方。记录的作用是让后续复盘或交接的人不看聊天记录也能还原验收过程。ONES 的任务工作项支持状态流转和记录留痕，可以把这些内容写在任务记录中，使任务状态与验收结论对应。