任务退回整改到复验通过的操作步骤怎么安排

任务验收被退回后，整改能否一次走完，取决于退回时是否把缺陷项、验收标准和责任人写清楚，以及复验时是否沿用同一份检查口径。本文按“退回—整改—复验”三步给出可执行的操作安排，并说明状态字段设计、角色分工、走查示例和完成检查清单，适合单项任务执行闭环的落地参考。文中也会说明ONES工作项状态与字段配置如何承载这套流转。

要点总览（TL;DR）

• 退回时把缺陷项、标准依据、责任人、期限一次写清，形成编号固定的缺陷项清单，作为整改与复验共用的核对表。
• 状态只设待整改、待复验、已关闭三个节点，允许的流转为验收退回或复验不通过进入待整改，提交证据后进入待复验，复验通过关闭。
• 用退回次数、缺陷项列表、复验结论、退回原因分类等字段留存过程，使每次退回可追溯、可复盘。
• 复验由原验收人按同一标准逐项核对，新问题追加编号后再次退回，避免口头补充要求。
• 闭环完成的标志是状态已关闭、每项缺陷都有通过结论、复验记录可追溯到标准条款。

退回整改闭环的核心步骤

退回整改的主干只有三步：退回、整改、复验。三步之间靠两份交接物串起来——退回时形成缺陷项清单，整改后形成带证据的整改说明，复验时在同一份清单上逐项签署结论。每一步都要有明确的输入、动作、输出和完成标志，否则任务容易在“退回—重开”之间反复空转。

步骤	输入	动作	输出	完成标志
1. 退回	验收记录、原任务交付物、验收标准	逐项列出未达标缺陷，写明每项对应的验收条款、整改责任人、整改期限；将任务状态置为“待整改”	缺陷项清单（含编号、描述、标准依据、责任人、期限）	缺陷项清单已发出，责任人已确认接收，任务状态为“待整改”
2. 整改	缺陷项清单	责任人按缺陷项逐条整改，每条附整改说明与证据（修改后的文档、截图、测试记录等），全部完成后提交复验申请	整改说明与证据包，逐条对应缺陷项编号	每条缺陷项都有对应证据，任务状态置为“待复验”
3. 复验	缺陷项清单、整改说明与证据包	原验收人按退回时的同一标准逐项核对，记录每项结论；全部通过则关闭，任一项不通过则带新增缺陷项再次退回	复验记录（逐项通过/不通过及理由）	复验结论已记录；通过则任务状态为“已关闭”，不通过则回到“待整改”

三步衔接的关键在交接物的一致性。退回时的缺陷项清单就是复验时的核对表，编号不变、标准不变，复验人只需在每一条后面填写结论。这样做的直接好处是：整改人知道要交什么，复验人知道要查什么，争议时也能回到同一条款上判断。若复验中发现新问题，应作为新增缺陷项追加编号后再次退回，而不是口头补充要求。

状态流转与字段设计

退回整改期间，任务状态只设三个核心节点：待整改、待复验、已关闭。状态少而明确，能避免“退回中”“整改中”“待确认”等模糊状态并存导致的跟踪混乱。允许的流转路径是：验收不通过 → 待整改 → 待复验 → 已关闭；待复验复验不通过 → 待整改。除这三条路径外，其他跳转都应被限制。

状态	允许进入方式	允许离开方式	说明
待整改	验收退回，或复验不通过再次退回	提交整改证据后进入待复验	责任人处理中，超期需预警
待复验	整改完成并提交证据	复验通过进入已关闭；复验不通过回到待整改	复验人处理中
已关闭	复验全部通过	无（如需返工应新建任务或重新打开并记录原因）	闭环完成

支撑字段至少包括：退回次数（每次退回加一，用于识别反复退回的任务）、缺陷项列表（编号、描述、标准依据、责任人、期限、当前结论）、复验结论（逐项通过/不通过及理由）、退回原因分类（如功能缺失、文档不全、标准未满足）。这些字段共同支撑追溯：查看一条任务时，能直接看到它被退回过几次、每次退回了什么、谁负责、最后怎么通过的。

需要明确禁止的流转：未提交任何证据时不能从“待整改”直接进入“待复验”；复验人不能在缺陷项未逐项记录结论的情况下将任务置为“已关闭”。这两条限制把“证据”和“逐项核对”变成状态推进的前置条件，是防止闭环流于形式的关键。在ONES中，这类约束可以通过工作项状态配置与必填字段来实现：状态流转绑定必填的缺陷项与复验结论字段，使状态变更与数据填写同步完成。

角色分工与交付物

退回整改涉及三类角色，职责边界清晰才能避免“谁都管、谁都不签字”。验收人（复验人）掌握判定权，整改责任人承担举证责任，任务发起人或项目负责人处理争议与超期。

角色	主要职责	判定权限	交付物
验收人/复验人	首次验收、编写缺陷项清单、按同一标准复验	决定退回与否、复验通过与否	缺陷项清单、复验记录
整改责任人	按缺陷项逐条整改、提交证据、申请复验	无判定权，可对缺陷项提出异议	整改说明与证据包
任务发起人/项目负责人	裁决缺陷项争议、处理超期未整改、决定是否升级	对争议项有最终裁定权	裁定记录、超期处理意见

分工中有两个容易含糊的点需要提前约定。其一，复验应由原验收人执行，保证标准口径不因换人而漂移；确需换人时，应移交缺陷项清单并说明标准依据。其二，整改责任人对某条缺陷项有异议时，应在整改期内提出，由任务发起人裁定后再整改，避免整改完成后才争论标准。超期未整改的任务，由项目负责人决定延期、调整责任人或升级处理，并把处理结果记录在任务上。

示例：一次退回整改的完整走查

以下为演示情景，用于说明字段与状态的实际填写方式。某接口文档交付任务进入验收，验收人对照验收标准发现两处未达标：错误码说明缺失、示例请求缺少鉴权头。任务被退回。

退回环节。验收人填写缺陷项清单：D1“错误码说明缺失”，标准依据为“接口文档规范第3节”，责任人张某，期限3个工作日；D2“示例请求缺少鉴权头”，标准依据同规范第5节，责任人张某，期限3个工作日。退回次数记为1，任务状态置为“待整改”。

整改环节。张某逐条处理：D1补充错误码表并附修改后文档链接；D2更新示例请求并附截图。每条证据对应缺陷项编号，整改说明写清修改位置。全部完成后提交复验申请，任务状态置为“待复验”。

复验环节（第一次不通过）。验收人核对D1通过；核对D2时发现鉴权头已补，但示例响应仍为旧格式，判定不通过并追加缺陷项D3“示例响应格式未同步更新”。任务再次退回，退回次数记为2，状态回到“待整改”。张某补充D3证据后再次提交，状态回到“待复验”。

复验通过。验收人逐项核对D1、D2、D3均通过，填写复验结论并关闭任务，状态为“已关闭”。整个过程中，退回次数、缺陷项编号、逐项结论都留在任务记录上，后续复盘可直接查看。

完成检查与常见失效点

复验前应先做一轮自检，确认闭环具备可验证的条件。以下清单可逐项核对：

• 每条缺陷项都有编号、描述、标准依据、责任人和期限；
• 每条缺陷项都有对应的整改证据，证据能定位到具体修改位置；
• 整改说明与缺陷项编号一一对应，无遗漏项；
• 复验人使用与退回时相同的标准依据逐项核对；
• 复验记录中每项都有明确结论，不通过项写清理由；
• 任务状态与实际进度一致，退回次数已如实记录；
• 关闭前确认无未处理的异议项或超期项。

流程落地时常见的失效点有三类。退回次数过多，通常说明首次退回时缺陷项描述不清或标准依据缺失，应对方法是退回时必须引用具体条款，避免“再完善一下”这类模糊要求。证据缺失，多因整改人只改不举证，可通过“无证据不能进入待复验”的状态约束来纠正。超期未整改，则需要在任务上设置期限预警，由项目负责人按约定处理，而不是等到复验时才暴露。

判断闭环真正完成的可验证标志是：任务状态为“已关闭”，缺陷项清单中每项都有通过结论，复验记录可追溯到具体标准条款，退回次数与处理过程完整留存。满足这些条件，才算一次退回整改真正走完，而不是任务被重新打开后继续拖延。

常见问题

退回时缺陷项写得比较笼统，整改后复验仍然不通过，怎么处理？

这种情况通常说明首次退回时标准依据没有落到具体条款。处理办法是把笼统要求拆成可核对的条目：每条缺陷项写明对应的验收条款、当前差距和期望结果，再追加编号后重新退回。复验时只按新清单逐项核对，避免在同一批缺陷项上反复口头补充要求。若已经发生多次退回，可在任务上记录退回次数和原因分类，用于后续复盘首次退回的质量。

整改责任人认为某条缺陷项判定有误，应该在什么时点提出？

异议应在整改期内提出，由任务发起人或项目负责人裁定后再动手整改。整改完成后再争论标准，会同时消耗整改和复验两轮时间。裁定结果记录在任务上，作为该缺陷项结论的依据。若异议涉及验收标准本身需要调整，应同步更新标准依据，并让复验人按更新后的口径核对。

复验时发现新问题，是并入原缺陷项还是新增编号？

建议新增编号后再次退回，原缺陷项的结论保持不变。这样每条缺陷项都有独立的整改与复验记录，退回次数也能如实反映。把新问题并入原条目，会让原条目的通过结论变得含糊，后续追溯时难以判断当时到底改了什么。新增编号后，任务状态回到待整改，责任人补充证据再提交待复验。

任务关闭后又被要求返工，状态应该怎么处理？

已关闭状态不再直接回退。返工需求应新建任务，或在重新打开时记录原因并重新走退回流程，同时保留原任务的缺陷项清单与复验记录作为参照。这样原闭环的完成记录不被覆盖，返工也有独立的跟踪链路。若返工频繁出现在同一类交付物上，可把原因分类汇总，用于调整验收标准或交付前的自检项。

超期未整改的任务由谁跟进，跟进结果记在哪里？

由任务发起人或项目负责人按约定处理，可选择延期、调整责任人或升级，处理意见记录在任务上。期限预警应在整改期内触发，而不是等到复验时才暴露。跟进记录与缺陷项清单放在一起，复验时能看清延期原因和当前责任人，避免任务长期停留在待整改状态而无人推进。