任务完成后，验收人按交付责任确定：单项任务通常由任务发起人或需求提出方验收，跨角色交付由下游接收方验收，高风险或对外交付增加独立评审人。结果记录至少留下验收结论、验收人、验收时间、验收依据和遗留问题五项，并把任务状态从“待验收”改为“已完成”或“已退回”。本文适用于单项任务的执行闭环，不展开组织级流程规则设计。
要点总览（TL;DR）
- 验收人按交付责任确定：内部需求发起的单项任务由发起人验收，跨角色交付由下游接收方验收，高风险、对外交付或合规任务增加独立评审人，并在任务开始前写入任务信息。
- 验收结论分通过、有条件通过、退回三类：通过直接关闭任务，有条件通过登记遗留问题并约定处理时间，退回需写明整改项和重新提交时间，复核只针对整改项。
- 验收记录至少包含验收结论、验收人、验收时间、验收依据、遗留问题五项，结论和状态以任务上的记录为准，文档与纪要作为依据附件关联。
- 退回循环要收敛：每次退回写清整改项、判断标准和重新提交时间，同一任务连续退回两次以上，由任务发起人确认验收标准是否存在歧义。
- 落地检查建议每月抽查一次，核对验收人是否提前明确、结论与状态是否一致、字段是否完整、退回是否有闭环、例外情形是否有说明。
验收人怎么定：按交付责任划分角色
验收人应当是对交付结果承担责任、并且与执行人分离的角色。判断时先看这项任务因谁的需求而产生、交付物交给谁使用、失败后果由谁承担，再对照下表确定验收人。任务开始前就应把验收人写进任务信息，避免完成时才临时找人。
| 任务类型 | 验收人 | 判定依据 |
|---|---|---|
| 由内部需求发起的单项任务，如报表整理、文案撰写、配置调整 | 任务发起人或需求提出方 | 发起人最清楚需求意图和验收标准，对结果是否可用直接负责 |
| 跨角色交付，如设计交付开发、上游模块交付下游模块、供应商交付内部团队 | 下游接收方 | 接收方要基于该交付继续工作，交付质量直接影响其后续任务 |
| 高风险任务，如涉及资金、权限、生产环境变更 | 下游接收方加独立评审人 | 单一验收人难以覆盖风险，需要第二双眼睛核对关键项 |
| 对外交付，如客户可见的文档、对外发布的版本 | 需求提出方加对外接口负责人 | 对外内容同时涉及业务意图和对外口径，两类责任都需确认 |
| 有合规要求的任务，如审计材料、资质申报文件 | 业务验收人加合规或质量角色 | 合规要求需要具备相应职责的人确认，普通业务验收无法替代 |
执行人自验与验收人确认是两道不同的动作。执行人在提交前完成自检，核对交付物是否齐全、是否满足事先约定的验收标准，并写明自检结论；验收人则在自检基础上独立核对，对是否通过作出判断。自验不能替代验收，验收人也不应直接替执行人修改交付物后自行确认。
验收人与执行人原则上不应为同一人。例外情形主要是两类：一是任务只涉及执行人自身的个人工作安排，没有其他利益相关方；二是紧急故障处理中，执行人先行处置并记录，事后由值班负责人或任务发起人补做确认。例外情形应在任务记录中注明原因和补确认人，避免形成长期惯例。
从提交到关闭：验收的操作步骤
验收是一段有输入、有动作、有输出的连续过程。把每一步的完成标志定清楚，可以减少“提交了但没人看”“退回了但不知道改什么”的情况。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 提交验收 | 交付物、自检结论、影响范围说明 | 执行人整理交付物，对照验收标准逐项自检，说明本次变更影响哪些模块或使用方，将任务状态改为“待验收” | 一份可核对的验收提交 | 任务状态为“待验收”，交付物和自检结论齐全 |
| 2. 核对 | 验收提交、验收标准或需求条目 | 验收人逐项核对交付物是否满足标准，检查影响范围是否被覆盖，必要时运行或试用交付物 | 核对意见 | 每个验收项都有明确判断 |
| 3. 给出结论 | 核对意见 | 验收人选择通过、有条件通过或退回，并写明依据 | 验收结论 | 结论已记录在任务上，验收人和时间明确 |
| 4. 处理结论 | 验收结论 | 通过则关闭任务；有条件通过则登记遗留问题并约定处理时间；退回则列出整改项 | 关闭记录或整改清单 | 任务状态与结论一致 |
| 5. 重新提交 | 整改清单 | 执行人完成整改后重新提交，验收人只针对整改项和受影响范围复核 | 新的验收结论 | 整改项逐条有回应 |
三种结论的处理方式需要区分清楚。通过表示交付物满足验收标准，任务可以直接关闭；有条件通过表示主体可用，但存在不影响当前使用的问题，验收人应把问题登记为遗留事项，明确责任人和处理时间，任务可以先关闭或保持跟踪状态；退回表示交付物不满足关键标准，任务回到执行中，执行人按整改项处理后重新提交。
退回后的循环要收敛，关键在于每次退回都写清整改项、判断标准和重新提交时间。验收人只针对整改项复核，避免每次重新提交都从头挑新问题；如果复核中发现新的关键问题，应作为新的退回理由单独记录。同一任务连续退回两次以上，建议由任务发起人介入确认验收标准是否本身存在歧义。
验收完成后，任务状态应从“待验收”流转为“已完成”或“已退回”，让状态与结论保持一致。状态停留在“待验收”而实际已经使用交付物，会让后续统计和追溯失真。
验收结果记录哪些字段
只写“已验收”三个字，无法回答谁验的、依据什么验的、还有什么没解决。验收记录至少应包含以下五项必填信息，并尽量与任务本身绑定。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 验收结论 | 从通过、有条件通过、退回中选择一项，不用模糊表述 | 有条件通过 |
| 验收人 | 填写实际作出判断的人，多人验收时全部列出并注明主验收人 | 李敏（主验收）、王强（合规复核） |
| 验收时间 | 填写结论作出的日期，补录时注明实际验收日期和补录日期 | 2025-03-14 |
| 验收依据 | 对照验收标准、需求条目或评审要点逐条写明，避免只写“符合要求” | 对照需求单第3、5条：字段完整、异常提示可读；对照接口文档第2节：返回码覆盖 |
| 遗留问题 | 无条件通过时填“无”；有条件通过或退回时逐条登记问题、责任人和处理时间 | 错误提示文案待统一，责任人张伟，3月21日前处理 |
验收依据的写法直接影响可追溯性。推荐写成“对照某份标准或需求条目，核对了哪几项，结果如何”，让后来的人不用追问就能判断验收是否充分。涉及多个验收人时，每个人的核对范围应分别写明。
记录位置有三种常见选择：任务字段适合结论、验收人、时间这类结构化信息，便于筛选和统计；验收记录文档适合需要附截图、测试结果或较长说明的场景；评审纪要适合多人评审会议形成的集体结论。三者可以并用，但结论和状态应以任务上的记录为准，文档和纪要作为依据附件关联到任务。
如果验收当时漏填字段，补录时应保留原始验收时间，并在说明中注明补录原因和补录人。补录信息同样需要验收人确认，避免由执行人单方面补齐。
当验收结论需要与任务状态联动、验收人和遗留问题需要长期留痕时，可以把这些信息放在任务工作项上承载。ONES 支持在任务工作项上记录字段并流转状态，验收结论、验收人和遗留问题可以随任务一起保留，状态变更与结论对应，减少结论散落在聊天记录中的情况。
一个完整示例：接口联调任务的验收
以下为演示情景。某内部系统需要与订单服务完成接口联调，开发人员完成联调后提交验收。
任务背景与交付物：任务为“订单查询接口联调”，执行人为开发张伟，需求由订单业务方提出。交付物包括联调完成的接口、联调记录、异常场景测试结果和影响范围说明，影响范围涉及订单列表页和报表取数两个使用方。
验收人确定：该任务由业务方需求发起，且交付物直接供订单列表页使用，因此主验收人为需求提出方李敏；由于接口涉及报表取数，报表使用方王强作为下游接收方参与验收；任务不涉及资金和对外发布，不额外增加独立评审人。
核对动作与结论：李敏对照需求单核对查询字段、分页和异常提示，王强核对报表取数口径。核对中发现异常提示文案与产品规范不一致，但不影响功能使用，两人给出“有条件通过”的结论。
验收记录填写：
| 字段 | 填写内容 |
|---|---|
| 验收结论 | 有条件通过 |
| 验收人 | 李敏（主验收）、王强（报表使用方） |
| 验收时间 | 2025-03-14 |
| 验收依据 | 对照需求单第2、4条：查询字段完整、分页正常；对照接口文档第3节：异常返回码覆盖；报表取数口径与报表需求第1条一致 |
| 遗留问题 | 异常提示文案与产品规范不一致，责任人张伟，3月21日前修改并通知李敏复核 |
退回与再次验收：假设首次提交时异常返回码未覆盖超时场景，李敏给出“退回”，整改项为补充超时返回码及对应提示，重新提交时间定为3月12日。张伟补充后重新提交，李敏和王强只复核超时场景及受影响的报表取数，确认通过后任务状态改为“已完成”。这个示例说明，退回时写清整改项和复核范围，可以让第二次验收快速收敛。
验收机制落地后的完成检查
机制建立后，需要定期抽查判断它是否真正运转。以下清单可按任务抽样逐项核对，建议每月抽查一次，每次抽取已完成、已退回和长期停留在待验收状态的任务各若干条。
- 验收人是否在任务开始前明确：抽查任务记录，确认验收人字段在任务进入执行阶段时就已填写，而非完成时补填。
- 验收结论是否与任务状态一致：结论为通过的任务状态应为已完成，结论为退回的任务应处于执行中或已重新提交，不存在结论已出但状态仍为待验收的情况。
- 验收记录字段是否完整可追溯：五项必填信息齐全，验收依据能对应到具体标准或需求条目，验收人与实际作出判断的人一致。
- 退回任务是否有闭环：每条退回记录都有整改项、责任人和重新提交时间，且后续能找到对应的再次验收结论。
- 例外情形是否有说明：执行人自验代替验收、验收人临时变更等情况，任务记录中注明了原因和补确认安排。
抽查时发现字段缺失或状态不一致，应当回溯到具体任务要求补录，并记录问题类型。连续多个周期出现同类问题，说明验收标准或字段填写口径需要重新对齐，而不是单纯提醒个人注意。检查结果可以作为下一轮验收规则调整的依据，让机制随实际执行情况逐步稳定。
常见问题
任务执行人自己最了解交付物，能不能由执行人自己验收？
原则上验收人应与执行人分离，由对交付结果承担责任的人作出判断。执行人可以做的是提交前的自检：核对交付物是否齐全、是否满足事先约定的验收标准，并写明自检结论。自检结论是验收人的核对输入，不能替代验收确认。
例外主要有两类：任务只涉及执行人自身的个人工作安排，没有其他利益相关方；紧急故障处理中执行人先行处置并记录，事后由值班负责人或任务发起人补做确认。例外情形应在任务记录中注明原因和补确认人，避免变成长期惯例。
有条件通过之后，遗留问题由谁跟踪，任务什么时候算真正结束？
有条件通过表示主体可用，但存在不影响当前使用的问题。验收人应把问题逐条登记为遗留事项，写明问题描述、责任人和处理时间，任务可以先关闭或保持跟踪状态，两种做法都可行，关键是团队内口径一致。
遗留问题的跟踪责任落在验收人身上：到期核对责任人是否完成处理，完成后在任务记录中补充处理结果。如果遗留问题长期无人跟进，说明登记时责任人或时间不明确，需要在下一轮验收中收紧填写要求。
验收人临时出差或离职，已经提交的验收怎么处理？
验收人变更时，应在任务记录中注明变更原因、原验收人和新验收人，由新验收人重新确认结论。原验收人已给出部分核对意见的，可以作为参考附在任务上，但结论需由新验收人作出。
如果任务已给出结论但验收人随后离职，结论仍然有效，补录或追溯时以任务上的记录为准。为减少这类情况，验收人字段应填写具体的人，并在任务开始前确认其可履职；关键任务可以设置备选验收人。
验收标准在任务开始时没写清楚，完成时验收人和执行人各执一词怎么办？
这种情况说明验收标准本身存在歧义，应由任务发起人介入，把需求意图转化为可核对的验收条目，再继续验收。处理时先明确本次交付必须满足的关键项，把争议点区分为必须满足和可以后续优化两类，分别对应退回和有条件通过。
为避免重复发生，后续任务在进入执行阶段时就应写明验收标准和验收人。同一任务连续退回两次以上，也建议由发起人确认标准是否需要重新对齐，而不是让执行人和验收人反复拉扯。
验收记录记在任务字段里还是单独建文档，两者冲突时以哪个为准？
结论、验收人、验收时间这类结构化信息适合记在任务字段上，便于筛选、统计和状态联动；需要附截图、测试结果或较长说明的场景，适合放在验收记录文档中；多人评审形成的集体结论适合放在评审纪要里。三者可以并用。
出现冲突时，以任务上的结论和状态为准，文档和纪要作为依据附件关联到任务。这样做的目的是让追溯有一个确定的入口，避免同一任务在不同位置出现两个结论。
