任务验收退回后整改与复验流程怎么设计

任务验收被退回后，整改和复验最容易卡在两个地方：退回原因只留在聊天记录里，整改做到什么程度算完成没有统一口径。要把这条路径跑通，需要把状态、字段、角色、时限四件事固定下来：任务从验收退回进入“整改中”，责任人提交说明和证据后转为“待复验”，复验人按首次验收的同一口径逐项核对，通过则关闭，不通过则再次退回并累计轮次。下面按状态机、字段设计、角色分工、过程示例和上线前检查五部分展开，可直接作为流程设计底稿使用。

要点总览（TL;DR）

• 把退回当成一次有记录、有期限、有口径的返工：任务从验收中进入整改中，整改提交后转为待复验，复验通过关闭，不通过则再次退回并累计轮次。
• 整改与重开要分开：整改是验收未通过后的定向返工，保留原验收记录；重开针对已关闭任务因新问题重新打开，两者记录路径不同。
• 退回时验收人必须写清退回原因分类、对应检查项、整改要求、期望完成时间和责任人；整改责任人提交说明与证据；复验人按首次验收同一口径逐项核对并签署。
• 复验人可由验收人兼任或另指定：同一人口径一致，适合依赖业务判断的任务；不同人可降低确认偏差，适合合规与质量类任务，但检查项清单不更换。
• 上线前用一条真实任务走完整路径，并人为制造一次复验不通过，确认轮次累计、超期标记和升级提醒都按预期出现。

退回后先定状态：整改中、待复验、关闭怎么流转

状态机的作用是让每一次退回都有明确的下一步，避免任务在“已验收”和“待处理”之间反复摇摆。设计时先明确一个前提：整改是验收未通过后的定向返工，任务保留原验收记录并进入整改态；重开针对的是已经关闭的任务因新问题被重新打开，两者在状态路径和记录上应当分开，否则退回次数和返工成本无法统计。

建议的最小状态集合是四个：验收中、整改中、待复验、关闭，另加一个“再次退回”动作，它不新增状态，而是把任务从待复验送回整改中并将轮次加一。每次流转都要有触发动作、操作角色和完成标志，缺一项就会出现“状态改了但没人知道该干什么”的情况。

当前状态	触发动作	操作角色	目标状态	必填字段
验收中	按检查项判定不通过，提交退回	验收人	整改中	退回原因分类、具体检查项、整改要求、期望完成时间、整改责任人
整改中	提交整改说明与证据，声明可复验	整改责任人	待复验	整改说明、证据附件、实际完成时间
待复验	按同一口径逐项核对，判定通过	复验人	关闭	复验结论、复验人、复验时间
待复验	核对不通过，再次退回	复验人	整改中	复验结论、未通过项、新的整改要求、轮次加一

退回轮次和超期标记建议挂在任务本身而不是某条评论上：轮次在每次“再次退回”时自动加一，超期标记由“期望完成时间”与当前时间比较得出，整改中和待复验两个状态都要显示。这样在任务列表里就能直接筛出“退回两次以上”或“整改已超期”的任务，不必逐条翻记录。

状态流转落到工具里时，需要工作项支持自定义状态和流转控制。ONES 的工作项可以承载任务状态与流转记录，退回原因、整改说明、复验结论这类信息适合作为任务上的结构化字段随状态一起留存，使每次退回都有据可查；具体字段配置以团队实际使用的工作项类型为准。

退回单要写清什么：整改要求与复验口径的字段设计

退回信息写得含糊，复验就只能靠印象判断。字段设计的目标是让退回原因能对应到具体检查项，让整改要求能被逐条核对，让复验结论能追溯到人。下面这份清单按“退回时填写”和“复验时填写”两段组织，可直接作为字段配置参考。

字段名	填写角色	必填	示例值
退回原因分类	验收人	是	交付物缺失 / 内容不符合要求 / 证据不足 / 格式不规范
对应检查项	验收人	是	检查项 3：接口文档需包含错误码说明
问题描述	验收人	是	错误码章节只有 2 个示例，缺少限流与鉴权失败场景
整改要求	验收人	是	补齐限流、鉴权失败两类错误码，并注明触发条件
期望完成时间	验收人	是	退回后 3 个工作日内
整改责任人	验收人	是	文档负责人
整改说明	整改责任人	是	已补充 6 个错误码，覆盖限流与鉴权失败场景
证据附件	整改责任人	是	更新后的文档链接或截图、变更记录
实际完成时间	整改责任人	是	提交整改当日时间
复验结论	复验人	是	通过 / 不通过（附未通过项）
复验人签署	复验人	是	复验人姓名与复验时间

其中“对应检查项”是连接首次验收与复验的关键字段。首次验收时使用的检查项清单应当在退回时被引用，复验时逐项对照同一份清单勾选，而不是重新拟一套标准。退回原因分类则用于后续统计：按分类汇总一段时间内的退回分布，能看出问题集中在交付完整性还是证据规范上，为改进验收前置条件提供依据。

证据附件建议要求“可打开、可核对”，例如更新后的文档版本、测试记录截图、变更说明，避免只写一句“已修改”。复验结论为不通过时，未通过项要写清对应哪条整改要求，使下一轮整改有明确起点。

谁在什么时点做什么：验收人、责任人、复验人的分工

三类角色在退回闭环中承担不同动作，交接时点决定流程是否顺畅。验收人负责判定和口径，整改责任人负责动作和证据，复验人负责核对和签署。把动作和时点对齐，可以减少“退回了但没人接”“整改完了但没人看”的空档。

角色	动作	时点	交付物
验收人	按检查项判定不通过，填写退回原因、整改要求、期望完成时间和责任人	验收判定当时	退回记录
整改责任人	按整改要求执行返工，提交整改说明与证据	期望完成时间之前	整改说明、证据附件
复验人	按首次验收同一口径逐项核对，给出结论并签署	收到待复验后约定时限内	复验结论
验收人或其上级	整改超期时发起提醒与升级	期望完成时间到期后	升级记录

复验人与验收人是否同一人，需要按组织情况取舍。由同一人复验，口径一致性最好，适合检查项偏主观、依赖业务判断的任务；由不同人复验，可以降低确认偏差，适合合规、质量类任务。无论哪种安排，复验都必须引用首次验收的检查项清单，人员可以换，口径不能换。若选择不同人复验，退回记录中应写明复验人，避免责任模糊。

超期未整改需要一条明确的升级路径：到期当天系统提醒整改责任人，到期后一个工作日内提醒其直接上级，仍未处理则升级到任务所属项目的负责人。升级触发条件建议写成可判断的规则，例如“期望完成时间已过且状态仍为整改中”，而不是依赖人工发现。多轮退回同样需要可见标记，轮次达到设定阈值（如两轮）时在任务上标出，便于复盘时优先关注。

完整走一遍：一次退回、整改、复验的过程示例

以下示例为演示情景，用于说明状态、字段和角色如何配合，不代表真实项目数据。

某任务的交付物是一份接口文档，验收人按检查项核对时发现错误码章节不完整，判定不通过并提交退回：退回原因分类选“内容不符合要求”，对应检查项为“接口文档需包含错误码说明”，问题描述写明缺少限流与鉴权失败场景，整改要求为补齐两类错误码并注明触发条件，期望完成时间设为退回后 3 个工作日，整改责任人指定为文档负责人。任务状态由验收中变为整改中，轮次记为 1。

文档负责人在第 2 个工作日完成补充，提交整改说明“已补充 6 个错误码，覆盖限流与鉴权失败场景”，附上更新后的文档链接和变更记录，任务状态转为待复验。复验人打开首次验收的检查项清单逐项核对，确认错误码章节已覆盖要求场景，填写复验结论“通过”并签署，任务关闭。

如果复验时发现鉴权失败场景仍缺一个错误码，复验人填写复验结论“不通过”，未通过项指向原整改要求中的鉴权失败部分，任务再次回到整改中，轮次变为 2。此时任务上同时保留两轮退回记录：第一轮的退回原因与整改说明、第二轮的未通过项与新的整改要求。复盘时可以直接看到这份文档在两轮内解决的问题类型，判断是验收标准传达不清还是交付习惯问题。

上线前自查：流程能否真正跑通

流程设计完成后，建议用下面这份清单逐项核对，每项都给出可判断的通过标准，避免流程只停留在文档里。

检查项	通过标准
状态覆盖退回全路径	验收中、整改中、待复验、关闭四个状态齐全，再次退回有明确路径，重开与整改在记录上可区分
字段覆盖退回与复验	退回原因分类、对应检查项、整改要求、期望完成时间、责任人、整改说明、证据附件、复验结论、复验人签署均有配置，关键字段设为必填
退回原因可统计	退回原因分类为固定选项，可按分类和时间段汇总退回分布
复验口径与首次验收一致	复验时引用首次验收的检查项清单，人员可更换，清单不更换
超期与多轮退回可见	整改中和待复验状态显示超期标记，轮次自动累计并在任务列表可筛选
升级路径可触发	超期提醒与逐级上报有明确触发条件和接收人，不依赖人工发现

核对时建议用一条真实任务走一遍完整路径：提交退回、完成整改、执行复验，再人为制造一次复验不通过，确认轮次累计和超期标记都按预期出现。走通之后，这套状态、字段和角色分工就可以作为任务验收退回后的标准处理方式固定下来，后续只需按实际退回分布调整检查项和时限设置。

常见问题

任务已经关闭后才发现问题，应该走重开还是走整改？

看问题性质。如果任务在验收环节被判定不通过，走整改：任务进入整改中，保留原验收记录和检查项，整改完成后进入待复验。如果任务已经验收关闭，之后因新发现的问题需要继续处理，走重开：任务回到执行态重新推进，原关闭记录保留。两者分开记录，退回次数和返工成本才能统计清楚；混在一起会导致退回轮次失真，复盘时无法判断问题出在验收标准还是交付质量。

复验必须由验收人本人执行吗？

不强制。由验收人复验，口径一致性最好，适合检查项偏主观、依赖业务判断的任务；另指定复验人，可以降低确认偏差，适合合规、质量类任务。无论哪种安排，复验都要引用首次验收的检查项清单逐项核对，人员可以换，口径不能换。若选择不同人复验，退回记录中要写明复验人，避免出现问题时责任模糊。

整改超期了但责任人没有响应，流程上怎么处理？

把升级写成可判断的规则，而不是靠人工发现。例如到期当天提醒整改责任人，到期后一个工作日内提醒其直接上级，仍未处理则升级到任务所属项目负责人。触发条件建议设为“期望完成时间已过且状态仍为整改中”，这样系统可以自动识别。升级记录本身也要留痕，便于后续判断是排期冲突还是责任不清。

退回原因分类设多少个合适，会不会增加填写负担？

建议先设四到六个固定选项，覆盖团队最常见的退回情形，例如交付物缺失、内容不符合要求、证据不足、格式不规范。分类的作用是支持统计：按分类和时间段汇总，能看出问题集中在交付完整性还是证据规范上。选项过多会增加验收人的判断成本，过少则统计不出有效信息。可以先按现有退回记录归纳一轮，再确定分类，后续按实际分布调整。

多轮退回的任务，复盘时重点看什么？

重点看两轮之间的问题是否同类。如果第二轮未通过项仍指向第一轮已提出的整改要求，说明整改没有到位或要求传达不清；如果两轮问题类型不同，说明首次验收的检查项可能覆盖不全。任务上保留每轮的退回原因、整改说明和未通过项，复盘时可以直接对照。轮次达到设定阈值时在任务上标出，便于在任务列表中优先筛出反复退回的任务。