任务验收被退回后，最容易出问题的环节是“退回去就散了”：缺陷没写清、整改做到哪一步没人知道、复验时又换了一套标准。要避免这种情况，需要把退回设计成一条可追踪的闭环，固定状态、字段、角色和证据四件事。下面按状态流转、退回单字段、角色分工、完整示例和落地检查五个部分展开，适用于单项任务的验收整改与复验场景。
要点总览（TL;DR）
- 把验收退回设计成“验收退回—整改中—待复验—已关闭/再次退回”五态闭环，任务全程不回退到“进行中”，退回轮次挂在任务上累计。
- 退回单按条目记录缺陷项描述、严重程度、期望结果、复验标准和要求完成时间；整改说明与证据附件在提交复验时必填。
- 验收人负责退回判定、复验判定和关闭，任务责任人负责整改与提交复验，复验依据始终是当轮退回单写明的标准。
- 复验人与原验收人是否同一人按缺陷严重程度取舍：严重缺陷可增加交叉复核，一般缺陷由原验收人复验。
- 上线前核对状态配置、字段必填性、角色权限、轮次与超时提醒、历史数据统计，并用一条真实任务试运行一轮再推广。
退回后走哪几个状态：一条可执行的状态流转
退回后的流程建议用五个状态承载：验收退回、整改中、待复验、已关闭、再次退回。核心原则是任务从“待验收”被退回时，进入独立的“验收退回”状态，再由责任人接手转入“整改中”，全程不回退到“进行中”。这样退回轮次、退回原因和历史记录都挂在同一条任务上，不会因为状态重置而丢失。
每个状态都要有明确的进入条件、责任人和出口动作，否则状态只是标签，无法驱动动作。可参照下表配置：
| 状态 | 进入条件 | 责任人 | 出口动作 | 需记录字段 |
|---|---|---|---|---|
| 验收退回 | 验收人判定交付物不满足验收标准，填写退回单并提交 | 验收人 | 责任人确认接单，转入整改中 | 退回人、退回时间、退回轮次、缺陷项、复验标准、要求完成时间 |
| 整改中 | 责任人已确认退回单，开始处理缺陷项 | 任务责任人 | 全部缺陷项处理完毕并附证据，提交复验 | 整改说明、证据附件、实际完成时间 |
| 待复验 | 责任人提交复验，缺陷项逐项标记为已处理 | 验收人（或指定复验人） | 给出复验结论：通过转已关闭，不通过转再次退回 | 复验人、复验时间、逐项复验结论 |
| 再次退回 | 复验判定仍有缺陷项未达标 | 验收人 | 补充或更新缺陷项后，责任人再次进入整改中 | 新一轮缺陷项、累计退回轮次、复验意见 |
| 已关闭 | 复验全部通过 | 验收人 | 归档，任务结束 | 关闭时间、最终复验结论、总轮次 |
退回轮次建议作为任务上的一个计数字段，每次进入“验收退回”或“再次退回”时加一，而不是靠人工在描述里记。超时提醒挂在“整改中”和“待复验”两个状态上：前者按退回单里的要求完成时间提醒责任人，后者按约定的复验时限提醒验收人。这样提醒跟着状态走，状态一变提醒对象也随之切换。
要特别防止一种常见退化：责任人为了“看起来在推进”，把任务手动改回“进行中”。一旦允许这种回退，退回轮次、退回单和复验记录就与当前状态脱节。设计时可以把状态流转做成受控路径，只允许“验收退回→整改中→待复验→已关闭/再次退回”这一条主线，其他跳转需要说明理由并留痕。在ONES这类工作项管理工具中，可以通过自定义工作项状态和流转规则来承载这条主线，把退回单字段配置为工作项属性，复验证据作为附件或关联记录挂在同一工作项下，使状态、字段和证据落在同一条记录上，便于追溯。
退回单要写清什么：缺陷项与复验标准字段
退回单的作用是让整改有目标、复验有依据。它应当是一组结构化字段，而不是一段自由描述。字段设计的关键是区分“退回时必填”和“提交复验时必填”，前者约束验收人，后者约束责任人。
| 字段名 | 填写人 | 必填性 | 示例 |
|---|---|---|---|
| 缺陷项描述 | 验收人 | 退回时必填 | 登录页在弱网下超时无提示，用户停留在空白页 |
| 严重程度 | 验收人 | 退回时必填 | 严重 / 一般 / 轻微 |
| 期望结果 | 验收人 | 退回时必填 | 超时后 3 秒内展示重试提示，并可一键重试 |
| 复验标准 | 验收人 | 退回时必填 | 在限速 200kbps 环境下复现，提示出现且重试成功 |
| 退回人、退回时间 | 系统自动 | 必填 | 张三，2024-06-11 15:20 |
| 要求完成时间 | 验收人 | 退回时必填 | 2024-06-14 18:00 |
| 整改责任人 | 验收人或任务负责人 | 退回时必填 | 李四 |
| 协同人 | 责任人 | 选填 | 前端王五、测试赵六 |
| 整改说明 | 责任人 | 提交复验时必填 | 已增加超时监听与重试按钮，附改动说明 |
| 证据附件 | 责任人 | 提交复验时必填 | 弱网测试录屏、日志截图 |
| 复验结论 | 验收人 | 复验时必填 | 逐项通过 / 第 2 项未通过 |
缺陷项建议按条目拆开，每条独立记录描述、严重程度、期望结果和复验标准，而不是把所有问题写在一段话里。这样复验时可以逐项打勾，哪一项没过一目了然，再次退回时也只需针对未通过项补充说明。复验标准要写成可观察、可复现的条件，避免“体验更好”“基本可用”这类无法判定的表述。严重程度则用于分级处理：严重缺陷必须整改后复验，轻微缺陷可以约定合并到下一轮处理，但要在退回单里写明处理方式，避免口头豁免。
整改与复验怎么分工：角色与交付物
退回流程涉及三类主要角色，职责边界和交接物要提前定清楚，否则容易出现“验收人替责任人改”“责任人自己宣布通过”的混乱。
| 角色 | 主要动作 | 交付物 | 权限边界 |
|---|---|---|---|
| 验收人 | 判定是否退回、填写退回单、执行复验、给出结论 | 退回单、复验结论 | 拥有退回与关闭权限，不直接修改交付物 |
| 任务责任人 | 接单、逐项整改、提交复验并附证据 | 整改说明、证据附件 | 可提交复验，不能自行关闭任务 |
| 协同角色 | 补充材料、参与评审、协助复现 | 评审意见、补充证据 | 按需参与，不改变验收结论 |
复验人与原验收人是否同一人，是一个需要按组织情况取舍的问题。同一人复验的优点是标准连贯、上下文清楚，适合缺陷明确、判定客观的场景；交叉复验的优点是降低主观偏差和人情因素，适合严重缺陷或争议较多的场景。一种折中做法是按严重程度分级：严重缺陷由原验收人复验并增加一名交叉复核人，一般和轻微缺陷由原验收人复验即可。无论哪种方式，复验依据都应是退回单里写明的复验标准，而不是复验时临时提出的新要求；如果确需新增标准，应作为新一轮退回单记录，保持每轮判定有据可查。
交接物要形成固定链条：验收人交出的退回单，是责任人整改的输入；责任人交出的整改说明和证据，是复验的输入；验收人交出的复验结论，是关闭或再次退回的依据。三份交接物都挂在同一条任务记录上，任何人查看任务时都能看到完整历史。在ONES中，可以把退回单字段、整改说明和复验结论作为工作项的属性与评论记录保存，证据以附件形式关联，复验结论变更时保留历史版本，从而让这条交接链在工具里可查。
一次完整退回的示例：从退回单到复验通过
以下为演示情景，用于说明状态、字段和角色如何串联，不作为真实案例引用。
初始任务：“订单导出功能”开发任务，责任人李四，验收人张三，任务处于待验收状态。
第一次退回：张三验收时发现导出文件在数据量超过一万条时字段错位。他填写退回单：缺陷项描述为“大数据量导出字段错位”，严重程度“严重”，期望结果“十万条以内导出字段与表头一一对应”，复验标准“用十万条测试数据导出，抽查首尾各 100 行字段对齐”，要求完成时间“6 月 14 日 18:00”，整改责任人李四。任务进入“验收退回”，退回轮次记为 1。
整改与提交复验：李四确认接单，任务转入“整改中”。他修正了分页写入逻辑，在整改说明中写明改动点，附上十万条数据的导出文件与字段核对截图，提交复验，任务转入“待复验”。
复验不通过再退回：张三按复验标准抽查，发现末尾 20 行仍有个别字段为空，判定不通过，任务转入“再次退回”，轮次累计为 2，并在退回单中补充“末尾空字段”这一新缺陷项及对应复验标准。
第二轮整改与复验通过：李四补齐边界数据处理，再次提交复验并附新的核对结果。张三复验全部通过，填写复验结论“两项缺陷均已修复，抽查通过”，任务转入“已关闭”，记录关闭时间和总轮次 2。
这个例子说明两点：每次退回都产生独立的缺陷项和复验标准，复验只对照当轮标准判定；轮次累计在任务上，关闭时能直接看到这条任务被退回过几次、每次原因是什么。
流程落地前的完成检查
流程设计完成后，先做一轮核对，确认它能实际运行，再推广使用。可按以下清单逐项检查：
| 检查项 | 通过标准 | 负责人 |
|---|---|---|
| 状态配置齐全 | 五个状态均已建立，流转路径受控，无法随意跳回“进行中” | 流程管理员 |
| 退回单字段完整 | 必填与选填划分清楚，缺陷项可逐条记录，复验标准字段存在 | 流程管理员 |
| 角色权限明确 | 退回、关闭权限归验收人，提交复验权限归责任人，权限与角色对应 | 团队负责人 |
| 轮次与提醒生效 | 每次退回轮次自动加一，整改中和待复验状态能触发超时提醒 | 流程管理员 |
| 历史数据可统计 | 能按任务查询退回次数、退回原因分布和平均整改时长 | 团队负责人 |
| 试运行一轮 | 选取一条真实任务走完整流程，记录卡点并修正字段或流转规则 | 验收人与责任人 |
试运行阶段重点观察三类问题：退回单是否有人漏填关键字段、复验时是否出现标准之外的新要求、超时提醒是否发给了正确的人。发现后直接调整字段必填性或流转规则，再进入常规使用。流程稳定后，退回轮次和整改时长可以作为过程指标定期回顾，帮助团队判断验收标准是否清晰、交付质量是否稳定。
常见问题
退回后责任人迟迟不接单，流程上怎么处理？
在“验收退回”状态上设置接单时限，超时后提醒任务责任人和其直接负责人。接单动作本身要留痕，记录确认时间；超过约定时限仍未接单的，由任务负责人重新指派整改责任人，并在退回单中更新责任人字段，原退回单和轮次保持不变。这样处理可以避免任务长期停在退回状态无人推进，同时保留完整的退回历史。
复验时发现新问题，应该算本轮不通过还是另开一条任务？
如果新问题属于本次交付物范围、且与退回单的验收标准相关，按本轮复验不通过处理，任务转入“再次退回”，把新问题作为新一轮缺陷项补充进退回单，轮次加一。如果新问题超出本次任务范围，属于新需求或独立缺陷，建议另开任务跟踪，避免把不同性质的工作混在同一条退回记录里，导致轮次和整改时长统计失真。
轻微缺陷能不能不退回，直接约定后续处理？
可以，但要在退回单或验收记录里写明处理方式、责任人和计划处理时间，形成书面约定，避免口头豁免。常见做法是严重缺陷必须整改后复验，轻微缺陷经验收人确认后可合并到下一轮或另开任务处理。无论哪种方式，验收结论字段都要如实记录“有条件通过”及附加条件，便于后续追溯。
退回轮次多了，怎么判断是流程问题还是交付质量问题？
可以按任务汇总退回次数、退回原因分布和平均整改时长，定期回顾。如果同一类缺陷在多条任务上反复出现，通常指向验收标准不清晰或需求说明不完整，应回到退回单字段和验收标准上修正；如果集中在个别责任人，则更适合从任务分配和辅导入手。指标用于定位问题方向，具体结论仍需结合具体任务记录判断。
流程刚上线，团队嫌填字段麻烦怎么办？
先压缩必填范围，只保留缺陷项描述、期望结果、复验标准、要求完成时间和整改责任人这几项，其余字段设为选填，降低填写负担。同时用一条真实任务做示范，让团队看到逐项记录后复验判定更快、争议更少。试运行一轮后，再根据实际卡点决定是否增加字段，避免一开始就追求字段齐全而影响使用意愿。
