验收退回后，任务应回到“整改中”继续处理，直接关闭或删除会丢失验收结论和整改依据。本文给出一套可落地的状态流转设置：明确退回、整改、复验、重开各自对应的状态，逐条定义迁移的触发条件、操作人和必填信息，并用示例和检查清单帮助团队核对配置是否可用。
要点总览（TL;DR）
- 验收退回应把任务从“待验收”迁到“整改中”，保留退回原因、问题清单和退回次数，直接关闭或删除会丢失验收依据。
- 建议的最小状态集为进行中、待验收、整改中、待复验、已完成，重开作为例外路径，仅在范围或方案实质变化时使用。
- 每条迁移写清触发角色、允许条件和必填字段：退回填原因与问题清单，提交复验附整改说明与证据，复验结论记录通过或不通过。
- 退回属于原范围内的返工，在待验收、整改中、待复验之间循环；重开回到进行中重新执行，由任务负责人判定并保留原验收记录。
- 配置完成后用真实任务走一遍退回与复验，再模拟一次重开，核对必填校验、退回次数和历史记录是否完整。
退回、整改、复验、重开各是什么状态
设置流转规则前，先把四个动作对应的状态和边界定清楚。最常见的错误是把“验收退回”和“重开”当成同一件事，结果要么退回后任务被直接关闭，要么轻微返工也走重开，导致历史记录断裂、退回次数失真。
验收退回是验收环节给出的判定结果，任务仍留在原执行闭环内，只是从等待确认转为返工处理。它改变的是任务的当前状态，不改变任务的目标和范围。整改中是执行人处理退回意见的状态，任务在这里等待执行人补充交付物。待复验是整改完成、等待验收人再次确认的状态，它与首次待验收的区别在于附带整改说明和证据。重开则用于范围或方案发生实质变化的情形，任务回到进行中重新执行，原验收记录保留但不再作为本次交付的判定依据。
四个动作对应的状态、触发人和进入条件如下表。退回次数与历史记录需要在每次迁移时保留，这是后续判断任务质量、复盘验收问题的依据。
| 动作 | 对应状态 | 触发人 | 进入条件 |
|---|---|---|---|
| 验收退回 | 整改中 | 验收人 | 验收判定不通过，已填写退回原因与问题清单 |
| 提交整改 | 待复验 | 执行人 | 整改完成，已附整改说明与证据 |
| 复验通过 | 已完成 | 验收人 | 逐项核对问题清单，确认全部关闭 |
| 复验不通过 | 整改中 | 验收人 | 仍有未关闭问题，退回次数加一 |
| 重开 | 进行中 | 任务负责人 | 范围或方案发生实质变化，需重新执行 |
建议的最小状态集为：进行中、待验收、整改中、待复验、已完成，另设重开作为例外路径。状态数量不必多，关键是每个状态都有明确的进入条件和责任角色。
状态流转怎么设置：从待验收到闭环的完整路径
把上表落到具体迁移规则上，每条迁移都要写清三件事：谁触发、什么条件下允许、必须填写什么信息。规则写得越具体，执行时的争议越少。以下清单可以直接作为配置依据。
- 待验收 → 整改中：由验收人触发。必填退回原因、问题清单（逐条列出缺项或不符合项）、期望完成时间。禁止只写“不合格”而不列具体问题。
- 整改中 → 待复验：由执行人触发。必填整改说明（对应问题清单逐条回应）和证据（修改后的交付物、截图、测试记录等）。未附证据的提交应被拦截。
- 待复验 → 已完成：由验收人触发。需逐项确认问题清单已关闭，记录复验结论。
- 待复验 → 整改中：由验收人触发。复验不通过时退回，退回次数累计加一，前次整改说明与证据保留，不覆盖。
- 整改中 → 进行中（重开）：由任务负责人触发，属于例外路径。仅在范围或方案发生实质变化时使用，必填重开原因和变更说明，原验收记录与退回次数保留。
同时要设置禁止迁移。待验收不能直接跳到已完成，验收结论必须经过验收人确认；任何状态下都不允许直接删除任务来“解决”退回，删除会让退回原因、整改过程和复验结论一并消失，后续无法追溯。如果确实要终止任务，应设置独立的“已取消”状态并填写取消原因，与退回区分开。
在工具层面承载这套规则时，可以把状态字段与必填校验绑定。以 ONES 为例，工作项支持自定义状态与流转，退回原因、整改说明可以作为字段随状态迁移一并记录，任务详情中保留完整的变更历史。具体配置方式建议在团队实际环境中按上述清单逐条验证后再固化。
角色分工与各环节交付物
状态流转能否跑通，取决于每个环节是否有人负责、有产出。退回闭环涉及三个角色，职责和交付物需要提前约定，避免出现“退回了但没人改”“改完了但没人验”的空档。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 验收人 | 判定验收结果、填写退回原因、复验确认 | 退回原因与问题清单、复验结论 |
| 执行人 | 按问题清单整改、提交复验 | 整改说明、整改证据 |
| 任务负责人 | 判断是否属于重开情形、决定范围变更 | 重开原因与变更说明 |
验收人的关键职责是把问题说清楚。退回原因应指向具体交付物和具体条款，问题清单逐条可核对，这样执行人才能针对性整改，复验时也有明确的关闭标准。执行人的整改说明要与问题清单一一对应，证据要能证明问题已解决，而不是笼统写“已修改”。任务负责人在退回与重开之间做判断：如果问题出在交付质量，走整改；如果验收过程中发现需求本身变了，才走重开。
退回原因、整改说明、复验结论三类记录要作为过程证据留存，随任务一起可查。它们既是本次交付的判定依据，也是后续复盘验收标准、评估执行质量的输入。
示例：一次退回与一次重开怎么走
以下两个示例为演示情景，用于对照规则，不代表特定团队的实际记录。
示例一：交付物缺项，退回整改后复验通过。任务处于待验收，验收人核对交付清单时发现缺少接口文档和一组边界测试记录，判定不通过，将任务退回整改中，填写退回原因“交付物不完整”，问题清单列出两项缺项，期望完成时间设为两个工作日后。执行人补齐文档和测试记录，在整改说明中逐条回应，附上文档链接和测试结果，提交至待复验。验收人复验确认两项均已关闭，任务进入已完成。整个过程退回一次，退回原因、整改说明、复验结论全部保留在任务记录中。
示例二：验收中发现范围变化，走重开。任务处于待验收，验收人核对时发现业务方在验收期间新增了一项数据导出要求，原交付物本身符合原定范围。任务负责人判断这属于范围实质变化，触发重开，任务回到进行中，填写重开原因“新增数据导出需求”和变更说明。执行人按新范围补充开发后重新提交待验收。原验收记录和此前的退回次数保留，但本次验收以新范围为准。两个示例的差异在于：示例一是同一范围内的返工，状态在待验收、整改中、待复验之间循环；示例二是范围变化后的重新执行，状态回到进行中，需要重新走完整的提交与验收流程。
配置后的完成检查
规则配置完成后，逐项核对以下检查项，确认状态流转在实际使用中可用。
- 每条迁移都有明确的触发角色，且必填字段已设置为不可跳过。重点检查退回时是否强制填写原因与问题清单、提交复验时是否强制附整改说明与证据。
- 退回次数与历史记录可查。任意打开一个经历过退回的任务，能看到每次退回的时间、原因、整改内容和复验结论。
- 重开与退回的边界已写入规则说明，任务负责人清楚什么情况走整改、什么情况走重开。
- 复验不通过能再次退回整改中，且前次记录不被覆盖，退回次数正确累加。
- 长期停留在整改中的任务有提醒或跟进方式，例如按期望完成时间设置到期提醒，避免任务在退回后无人跟进。
- 禁止迁移已生效：待验收无法直接跳到已完成，任务无法通过删除来规避退回记录。
检查时建议用一个真实任务完整走一遍退回、整改、复验的流程，再模拟一次重开，确认记录完整、状态正确、必填校验生效。流程跑通后再推广到团队，比先推广再修补更省成本。
常见问题
退回次数要不要设上限，超过上限怎么处理？
退回次数本身是质量信号，建议保留累计值并在任务记录中可查，是否设上限取决于团队对交付质量的要求。如果设置上限，例如同一任务退回三次后升级处理，应把升级动作定义为一次状态迁移或通知规则，由任务负责人介入判断问题出在交付质量、验收标准还是需求理解，而不是简单关闭任务。无论是否设上限，每次退回的原因和整改记录都要保留，上限只影响处理路径，不影响留痕。
验收人长期不处理待复验，任务卡住怎么办？
待复验停留过久通常说明复验责任没有落到具体人。可以在提交复验时指定复验人并设置期望复验时间，到期未处理时提醒复验人或其上级。另一个常见原因是整改说明和证据不充分，验收人无法判断是否关闭问题，此时应退回补充而不是搁置。建议在检查环节把“待复验超期”和“整改中超期”一起纳入跟进范围，两类停留都会让任务脱离正常闭环。
任务已经关闭后才发现验收有问题，还能退回吗？
可以，但要走与常规退回不同的路径。已完成的任务重新打开，本质上改变了原验收结论，建议由任务负责人确认后重开回到进行中，填写重开原因并说明原验收结论为何失效，再按新范围或新标准重新提交验收。这样处理能保留原验收记录和关闭时间，避免直接修改历史状态造成记录失真。如果问题只是文档或记录遗漏、交付物本身符合要求，也可以单独补记说明，不必重开任务。
不同任务类型需要不同的状态集吗？
可以按任务类型区分，但不宜过度细分。研发任务、文档任务、数据交付任务的验收标准不同，必填字段可以随类型调整，例如文档任务要求附评审意见，数据任务要求附校验结果。状态名称和主干路径建议保持一致，便于跨类型统计退回率和复验周期。如果某类任务确实存在额外环节，例如需要第三方确认，优先在待复验之后增加一个确认状态，而不是改动整条路径。
小团队也需要这么完整的状态流转吗？
状态数量可以精简，关键规则建议保留。小团队可以把状态压缩为进行中、待验收、整改中、已完成，把待复验合并进待验收，但退回原因、整改说明和复验结论三项记录仍要填写，否则退回后无法追溯改了什么、验了什么。重开路径同样需要保留，范围变化时回到进行中重新执行，比在已完成状态上反复修改更能反映实际工作量。规则复杂度应与任务量和协作人数匹配，随团队扩大再逐步细化。
