任务验收退回记录表用于记录一次验收未通过的事实、原因和后续返工安排，让退回有据可查、重开有明确责任人和时限。本文提供一张可直接复制的空白表格，按任务标识、退回事实、退回原因、重开安排、闭环结果五组排列字段，并逐项说明填写口径、区分必填与选填，最后用一条完整记录示范字段之间的对应关系。
要点总览（TL;DR）
- 退回记录表以“一次退回一条记录”为行结构，字段分为任务标识、退回事实、退回原因、重开安排、闭环结果五组，同一任务多次退回按任务编号串联。
- 必填字段建议控制在六项：任务编号、退回时间、退回人、具体描述、期望结果、重开状态，其余按团队管理颗粒度选填。
- 退回类型与问题分类使用受控枚举而非自由文本，枚举值控制在五到八个，便于后续统计高频退回原因。
- 具体描述、期望结果、关联证据与复验结论要前后呼应，复验人据此即可判定是否通过，无需再追问退回细节。
- 模板按季度检查枚举、按空置率调整选填字段，已闭环记录按项目或季度归档，保留关键列用于复盘。
可直接复制的任务验收退回记录表
下表以“一次退回一条记录”为行结构：同一任务如果经历多次退回，每次单独占一行，用任务编号串联，便于统计累计退回次数。复制到文档或表格工具后，按列填写即可。
| 分组 | 字段 | 填写内容 |
|---|---|---|
| 任务标识 | 任务编号 | |
| 任务名称 | ||
| 所属项目/迭代 | ||
| 当前负责人 | ||
| 退回事实 | 退回时间 | |
| 退回人 | ||
| 验收轮次 | ||
| 退回类型 | ||
| 退回原因 | 问题分类 | |
| 具体描述 | ||
| 期望结果 | ||
| 关联证据 | ||
| 重开安排 | 重开状态 | |
| 返工负责人 | ||
| 新截止时间 | ||
| 复验人 | ||
| 闭环结果 | 复验时间 | |
| 复验结论 | ||
| 累计退回次数 |
如果团队使用在线表格，可以把“分组”列合并为表头色块，或拆成五张关联子表；如果使用文档记录，建议保留分组标题作为小标题，让填写人按顺序补齐，减少漏填。
每个字段记录什么、怎么填
字段的含义决定取值口径。下表逐项说明每个字段记录什么、常见取值方式，以及容易填错的地方。
| 字段 | 记录内容 | 填写口径 |
|---|---|---|
| 任务编号 | 任务在项目管理系统中的唯一标识 | 直接复制系统编号，保持与任务一一对应，便于回溯 |
| 任务名称 | 被验收任务的标题 | 与任务原始标题一致，避免自行改写造成对不上 |
| 所属项目/迭代 | 任务归属的项目或迭代周期 | 填写项目名与迭代编号，跨项目任务注明主责项目 |
| 当前负责人 | 退回发生时任务的负责人 | 填姓名或工号，与返工负责人不同时需分别记录 |
| 退回时间 | 验收判定不通过的时间 | 精确到日期，需要区分同日多次退回时精确到时分 |
| 退回人 | 做出退回判定的人 | 填验收人或验收小组代表，便于后续沟通 |
| 验收轮次 | 该任务第几次提交验收 | 用整数递增，首次验收不通过记为第1轮 |
| 退回类型 | 退回的性质归类 | 建议枚举：质量不达标、交付物缺失、需求理解偏差、范围变更、环境或依赖问题 |
| 问题分类 | 退回原因所属的问题类别 | 建议枚举：功能缺陷、性能问题、文档缺失、界面与交互、数据错误、流程不合规 |
| 具体描述 | 验收不通过的具体表现 | 写清“在什么场景下、出现什么现象、影响什么结果”，避免只写“不合格” |
| 期望结果 | 返工后应达到的验收标准 | 用可验证的表述，如“提交包含三项数据的测试报告”，与具体描述一一对应 |
| 关联证据 | 支持退回判定的材料 | 填写附件名或链接地址，指向截图、日志、测试记录、评审意见等可复核内容 |
| 重开状态 | 退回后任务的当前处理状态 | 建议枚举：待返工、返工中、待复验、已关闭 |
| 返工负责人 | 实际执行返工的人 | 与当前负责人不同时必填，明确到人而非只写团队 |
| 新截止时间 | 返工完成的期限 | 填写日期，与原计划时间冲突时注明调整依据 |
| 复验人 | 负责再次验收的人 | 通常与退回人一致，更换时说明原因 |
| 复验时间 | 再次验收的时间 | 精确到日期，未复验时留空 |
| 复验结论 | 复验是否通过 | 建议枚举：通过、再次退回、部分通过，再次退回时新开一行记录 |
| 累计退回次数 | 该任务截至本次的退回总次数 | 按任务编号汇总计数，可由表格公式自动计算 |
退回类型与问题分类使用受控枚举，是让记录可统计的关键。自由文本会让“质量不达标”“质量不合格”“质量问题”变成三个不同值，后续统计高频原因时无法归并。枚举值建议控制在五到八个，超出时先考虑合并相近项。
关联证据的填写要能被人复核。附件命名建议包含任务编号和日期，链接指向具体页面而非首页；证据较多时在字段中列出主要材料，其余放入同一目录并在描述中说明位置。
哪些字段必填、哪些可以选填
必填字段的作用是保证每条记录都能被追溯和推进，选填字段则服务于更细的管理需要。建议把必填控制在六项，其余按团队颗粒度取舍。
| 字段 | 填写要求 | 理由或适用场景 |
|---|---|---|
| 任务编号 | 必填 | 记录与任务的唯一连接点，缺失则无法回溯 |
| 退回时间 | 必填 | 判断退回时效和统计周期的基础 |
| 退回人 | 必填 | 明确判定责任，便于返工后对接 |
| 具体描述 | 必填 | 返工的直接依据，缺失会导致返工方向不明 |
| 期望结果 | 必填 | 复验时的对照标准，与描述配套使用 |
| 重开状态 | 必填 | 反映记录是否仍在处理中，决定是否需要跟进 |
| 任务名称 | 选填 | 便于人工阅读，系统可自动带出时不必手填 |
| 所属项目/迭代 | 选填 | 需要按项目或迭代统计退回率时填写 |
| 当前负责人 | 选填 | 负责人与返工负责人一致时可省略 |
| 验收轮次 | 选填 | 关注多次退回的任务时填写 |
| 退回类型 | 选填 | 需要按退回性质做趋势分析时填写 |
| 问题分类 | 选填 | 与退回类型配合，用于归并高频问题 |
| 关联证据 | 选填 | 退回原因需要截图或日志佐证时填写 |
| 返工负责人 | 选填 | 返工由他人执行时填写，明确到人 |
| 新截止时间 | 选填 | 返工需要重新约定期限时填写 |
| 复验人 | 选填 | 复验人与退回人不同时填写 |
| 复验时间 | 选填 | 复验完成后回填，未复验时留空 |
| 复验结论 | 选填 | 闭环时填写，未闭环记录可暂空 |
| 累计退回次数 | 选填 | 需要识别反复退回任务时由公式生成 |
字段精简与扩充的判断依据可以归纳为三条：一是记录是否用于某个具体决策，例如是否要统计退回原因分布，决定是否保留退回类型和问题分类；二是字段能否被稳定填写，长期空置的字段应删除或合并；三是填写成本是否超过收益，如果团队规模小、退回量少，保留六项必填即可支撑追溯，不必一次铺满全部字段。
当退回记录需要与任务状态同步时，可以把记录页与任务关联起来。ONES Wiki 支持文档关联项目任务，并可在文档中嵌入任务进度和报表，适合把退回记录放在任务旁边，让退回、返工、复验的过程和任务进展在同一处查看；页面版本记录也便于回看某次退回时的原始描述。
一条完整退回记录的填写示例
以下示例为演示情景，用一条记录展示各字段如何相互对应。任务为“订单导出功能开发”，首次验收发现导出文件缺少字段。
| 字段 | 示例内容 |
|---|---|
| 任务编号 | ORD-2317 |
| 任务名称 | 订单导出功能开发 |
| 所属项目/迭代 | 订单系统优化 / 迭代 2024-06 |
| 当前负责人 | 李工 |
| 退回时间 | 2024-06-18 |
| 退回人 | 王验收 |
| 验收轮次 | 1 |
| 退回类型 | 质量不达标 |
| 问题分类 | 功能缺陷 |
| 具体描述 | 导出近30天订单时，结果文件缺少“下单渠道”和“优惠金额”两列，与需求文档第3节字段清单不一致 |
| 期望结果 | 导出文件包含需求文档列出的全部字段，用近30天数据验证两列均有值 |
| 关联证据 | 附件：ORD-2317_导出结果截图_20240618.png；链接：需求文档字段清单页 |
| 重开状态 | 待返工 |
| 返工负责人 | 李工 |
| 新截止时间 | 2024-06-20 |
| 复验人 | 王验收 |
| 复验时间 | 2024-06-20 |
| 复验结论 | 通过 |
| 累计退回次数 | 1 |
这条记录中，具体描述指出了缺失的两列并引用了需求文档，期望结果把“补齐字段”转成可验证的动作，关联证据提供了截图和文档位置，复验结论据此判定通过。四个环节前后呼应，复验人不需要再追问“当时到底缺了什么”。如果复验时仍不通过，则新开一行，验收轮次记为2，累计退回次数更新为2，原记录的重开状态改为“待复验”或保持历史状态不变。
模板的调整与长期维护方法
退回记录表会随团队流程变化而调整，维护的重点是让字段跟着实际决策走，避免越加越多却无人填写。可以按以下规则定期检查。
- 新增字段的触发条件：当某类信息在沟通中被反复追问，例如“这次退回是谁复验的”“返工是否影响原计划”，且现有字段无法回答时，再新增字段，并同步更新字段说明。
- 合并字段的触发条件：当两个字段长期同时填写、取值高度相关，例如退回类型与问题分类经常重复，可合并为一个字段并保留枚举值。
- 删除字段的触发条件：连续一个季度空置率较高的选填字段，先评估是否无人负责填写，再决定删除或转为自动带出。
- 枚举维护：退回类型和问题分类每季度检查一次，新增枚举前先确认现有值无法覆盖；合并相近值时保留历史记录的映射说明，避免统计口径断裂。
- 归档做法：按项目或季度归档已闭环记录，保留任务编号、退回时间、复验结论和累计退回次数等关键列，原始附件按同一目录存放。
- 定期复盘：每月或每迭代统计退回次数、高频问题分类和平均返工时长，用结果判断哪些字段真正被使用，再调整模板。
模板落地时，可以用 ONES Wiki 的模板库创建制式化记录页，让每次退回都从同一结构开始填写；对需要控制查看范围的项目，可按角色配置读写权限。记录页与任务关联后，退回描述、返工安排和复验结论都留在任务附近，复盘时直接按任务编号检索即可。ONES 具体能力以产品实际配置为准，模板字段可按团队流程增减。
常见问题
同一任务被多次退回，记录表应该怎么记？
每次退回单独占一行，用任务编号串联，验收轮次用整数递增，首次验收不通过记为第1轮。复验时再次退回，就新开一行，验收轮次记为2，累计退回次数更新为2。原记录的重开状态改为“待复验”或保持历史状态不变，两种做法都可以，关键是团队内统一口径，避免同一任务的历史记录出现两种处理方式。
退回原因写得很笼统，返工后还是对不上，怎么改？
问题通常出在具体描述和期望结果没有配套。具体描述要写清“在什么场景下、出现什么现象、影响什么结果”，期望结果要转成可验证的动作，例如“导出文件包含需求文档列出的全部字段，用近30天数据验证两列均有值”。两者一一对应后，复验时直接对照期望结果判定，减少来回沟通。关联证据同时指向截图或文档位置，复验人不必再追问当时缺了什么。
团队退回量很少，还需要铺满全部字段吗？
不需要。退回量少、团队规模小时，保留六项必填字段即可支撑追溯：任务编号、退回时间、退回人、具体描述、期望结果、重开状态。退回类型、问题分类、验收轮次等字段用于趋势分析和多次退回识别，等团队开始关注退回原因分布或反复退回任务时再逐步补充。字段长期空置的，先评估是否无人负责填写，再决定删除或改为自动带出。
退回记录放在文档里，怎么和任务状态保持同步？
可以把记录页与任务关联起来，让退回描述、返工安排和复验结论留在任务附近。ONES Wiki 支持文档关联项目任务，并可在文档中嵌入任务进度和报表，适合把退回记录放在任务旁边查看；页面版本记录也便于回看某次退回时的原始描述。记录页与任务状态变更之间是否自动联动，取决于团队实际配置，落地前建议先确认产品当前支持的方式。
退回类型和问题分类的枚举值多久调整一次？
建议每季度检查一次。新增枚举前先确认现有值无法覆盖，合并相近值时保留历史记录的映射说明，避免统计口径断裂。枚举值控制在五到八个，超出时先考虑合并相近项。如果某个枚举值连续两个季度几乎没有使用，可以评估删除，让填写人少做选择。
