验收退回与重开记录模板要解决的是：每次退回都有原因、有责任人、有可判定的重开条件，并且能按轮次追溯。本文提供可直接复制的主表与问题明细子表，说明每个字段的填写口径、必填规则，并用一条含两次退回的记录示范字段如何联动，最后给出模板裁剪与维护方法。
要点总览（TL;DR）
- 模板以“一次退回一条记录”为行粒度，主表承载任务标识、退回轮次、退回方与接收方、原因分类、重开条件、再次提交与复验结论，问题明细子表逐条记录待改项。
- 必填字段覆盖记录编号、任务编号、退回轮次、退回时间与退回方、接收方、原因分类、问题摘要、验收标准引用和重开条件；原因选“其他”时须补充说明。
- 重开条件要写成可判定的表述，验收标准引用要指向具体条款，退回原因使用固定分类，这三处决定记录能否被追溯和统计。
- 模板可按团队规模与任务类型裁剪，但需保留原因可归类、重开条件可判定、轮次可追溯三项基础，并同步维护版本号与统计口径。
- 记录可在 ONES Wiki 中以页面模板方式维护，页面版本可查看与回滚，文档可关联项目任务，便于保留模板与记录的变更历史。
可复制空白模板：退回与重开记录主表
模板采用“一次退回一条记录”的行粒度：同一任务被退回两次，就产生两行记录，通过任务编号关联。这样退回轮次、退回方、重开条件和复验结论都能独立追溯，统计时也不会把多次退回混成一条。
主表可直接复制到文档或表格工具中，列宽和行数按实际记录量调整。建议把表头固定，每行只填一条退回记录。
| 记录编号 | 任务编号 | 任务名称 | 所属项目/迭代 | 退回轮次 | 退回时间 | 退回方（验收人） | 接收方（责任人） | 退回原因分类 | 问题摘要 | 验收标准引用 | 附件/截图 | 重开条件 | 重开时间 | 重开责任人 | 再次提交时间 | 复验结论 | 关闭时间 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
主表记录的是“这次退回”的整体情况。具体要改哪些点，放在问题明细子表中，一条退回可以对应多条待改项。子表通过“记录编号”与主表关联，结构如下：
| 记录编号 | 问题序号 | 问题描述 | 对应验收标准条款 | 严重程度 | 整改责任人 | 计划完成时间 | 整改状态 | 验证结果 |
|---|---|---|---|---|---|---|---|---|
两张表配合使用：主表回答“这次退回是否已闭环”，子表回答“每条待改项改到什么程度”。复验时先看子表逐条验证，再在主表填写复验结论和关闭时间。
字段说明：每个字段记录什么、怎么填
字段填写的共同要求是：写事实、写可核对的内容。下面按四类字段说明含义、填写口径和常见填错方式。
| 字段名 | 含义 | 填写口径 | 示例值 |
|---|---|---|---|
| 记录编号 | 本条退回记录的唯一标识 | 建议用“任务编号-轮次”组合，保证与子表可关联 | PAY-128-02 |
| 任务编号 | 被验收任务的系统编号 | 照抄任务系统中的编号，不自行改写 | PAY-128 |
| 任务名称 | 任务标题 | 与任务系统中的名称一致，便于检索 | 支付结果页改版 |
| 所属项目/迭代 | 任务归属 | 写到当前迭代或项目名称，跨迭代任务注明所属迭代 | 支付迭代 2024-06 |
| 退回轮次 | 该任务第几次被退回 | 从 1 开始递增，同一任务连续编号，不跳号 | 2 |
| 退回时间 | 验收方做出退回决定的时间 | 精确到日期，需要时加时间；以验收动作发生时间为准 | 2024-06-18 |
| 退回方（验收人） | 做出退回判断的人 | 填具体姓名，不填“测试组”这类集体名称 | 李敏 |
| 接收方（责任人） | 承接整改的人 | 填具体负责人；多人协作时填主责人，其余人写入子表 | 王磊 |
| 退回原因分类 | 退回原因所属类别 | 使用固定分类，如功能未达标准、缺陷未修复、文档缺失、环境问题、其他 | 功能未达标准 |
| 问题摘要 | 本次退回的核心问题 | 一两句话写清现象和影响，细节放子表 | 支付失败后未展示失败原因 |
| 验收标准引用 | 退回依据的标准条款 | 引用验收标准文档的章节号或条目原文，不写“不符合要求” | 验收标准 3.2 条：失败场景需提示原因 |
| 附件/截图 | 支撑退回判断的证据 | 放截图、日志或录屏的存放位置或链接说明 | 失败页截图 2 张 |
| 重开条件 | 满足什么条件可以重新提交验收 | 写成可判定的表述，逐条对应问题明细 | 失败场景均展示原因文案，且通过回归用例 |
| 重开时间 | 任务重新进入待验收状态的时间 | 整改完成并提交复验的时间 | 2024-06-21 |
| 重开责任人 | 负责推动重开的人 | 通常与接收方一致，若转交需写明 | 王磊 |
| 再次提交时间 | 整改后提交复验的时间 | 与重开时间区分：重开是状态变化，再次提交是提交动作 | 2024-06-21 |
| 复验结论 | 复验结果 | 填“通过”“部分通过”“不通过”，部分通过需说明剩余项 | 通过 |
| 关闭时间 | 本条退回记录闭环的时间 | 复验通过当天填写；未通过则留空，进入下一轮 | 2024-06-22 |
| 备注 | 补充信息 | 只写与本次退回相关的事实，不写讨论过程 | 第二轮退回仅剩文案问题 |
常见填错集中在三处：退回原因分类随手写成自由文本，导致后续无法统计；重开条件写成“再优化一下”，复验时无法判断是否满足；验收标准引用只写“不符合需求”，没有指向具体条款。填写时把这三处当作检查重点，模板的追溯价值才能体现出来。
当团队在 ONES 中管理任务时，退回与重开对应任务状态的流转，记录本身可以放在 ONES Wiki 的页面中维护。ONES Wiki 支持页面模板库，可把本文主表做成制式化文档模板反复创建；文档可关联项目任务，页面版本会被记录并支持查看与回滚，便于在模板调整后保留历史填写内容。
必填与选填：哪些字段不能空
必填字段的作用是保证每条记录都能被追溯和统计。以下字段在记录创建时就应填写，不能等到关闭时补。
| 类别 | 字段 | 要求与理由 |
|---|---|---|
| 必填 | 记录编号、任务编号、任务名称 | 缺少则无法定位任务，也无法与子表关联 |
| 必填 | 退回轮次 | 轮次是追溯多次退回的基础，缺失会导致统计失真 |
| 必填 | 退回时间、退回方 | 明确退回动作的发生时间和判断人 |
| 必填 | 接收方（责任人） | 没有责任人，整改无法推进 |
| 必填 | 退回原因分类 | 统计退回原因的前提 |
| 必填 | 问题摘要、验收标准引用 | 让退回有依据，避免口头退回 |
| 必填 | 重开条件 | 复验时判断是否可重开的依据 |
| 条件必填 | 原因说明 | 退回原因分类选择“其他”时，必须补充文字说明具体原因 |
| 条件必填 | 附件/截图 | 问题无法用文字准确描述时必填，如界面错位、偶现故障 |
| 条件必填 | 复验结论说明 | 复验结论为“部分通过”或“不通过”时，说明剩余问题 |
| 选填 | 所属项目/迭代 | 任务系统已能体现归属时可省略，跨项目统计时建议填写 |
| 选填 | 重开时间、重开责任人 | 与接收方一致且同日重开时可简化，转交他人时必须填写 |
| 选填 | 备注 | 无补充信息时留空 |
留空与填“无”要区分开：留空表示该字段不适用或尚未发生，例如记录创建时关闭时间自然为空；填“无”表示已确认该项不存在，例如确认没有附件。两者混用会让统计时无法判断是漏填还是确实没有。建议在模板说明中约定：尚未发生的字段留空，已确认不存在的填“无”。
填写示例：一条完整的退回与重开记录
下面用一条经历两次退回的任务示范字段联动。示例为演示情景，任务与人员均为虚构。
主表两行记录：
| 记录编号 | 任务编号 | 任务名称 | 所属项目/迭代 | 退回轮次 | 退回时间 | 退回方 | 接收方 | 退回原因分类 | 问题摘要 | 验收标准引用 | 重开条件 | 重开时间 | 再次提交时间 | 复验结论 | 关闭时间 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| PAY-128-01 | PAY-128 | 支付结果页改版 | 支付迭代 2024-06 | 1 | 2024-06-18 | 李敏 | 王磊 | 功能未达标准 | 支付失败后未展示失败原因 | 验收标准 3.2 条 | 失败场景均展示原因文案并通过回归用例 | 2024-06-21 | 2024-06-21 | 部分通过 | 2024-06-22 |
| PAY-128-02 | PAY-128 | 支付结果页改版 | 支付迭代 2024-06 | 2 | 2024-06-22 | 李敏 | 王磊 | 文案问题 | 失败原因文案与文案规范不一致 | 文案规范 2.1 条 | 按规范修改 3 处文案并复核 | 2024-06-24 | 2024-06-24 | 通过 | 2024-06-25 |
第一轮退回对应的问题明细子表：
| 记录编号 | 问题序号 | 问题描述 | 对应验收标准条款 | 严重程度 | 整改责任人 | 计划完成时间 | 整改状态 | 验证结果 |
|---|---|---|---|---|---|---|---|---|
| PAY-128-01 | 1 | 支付失败页无失败原因提示 | 3.2 条 | 高 | 王磊 | 2024-06-20 | 已修复 | 通过 |
| PAY-128-01 | 2 | 超时场景未覆盖回归用例 | 3.2 条 | 中 | 王磊 | 2024-06-20 | 已补充 | 通过 |
| PAY-128-01 | 3 | 失败原因文案长度超出展示区域 | 文案规范 2.1 条 | 低 | 王磊 | 2024-06-20 | 已修复 | 未通过 |
时间线可以这样读：6 月 18 日第一轮退回，问题明细列出 3 条待改项；6 月 21 日整改完成并重开、再次提交；复验时前两条通过，第 3 条文案问题未通过，因此主表复验结论填“部分通过”，关闭时间填写后仍产生第二轮记录。6 月 22 日第二轮退回，仅针对文案问题；6 月 24 日修改完成重开并提交，6 月 25 日复验通过并关闭。两轮记录通过任务编号串起，轮次连续，子表与主表通过记录编号对应，任何一轮的问题都能单独回查。
调整与维护方法：按团队情况改字段并保持可用
模板落地后需要按团队实际裁剪，但裁剪不能破坏三个基础：退回原因可归类、重开条件可判定、轮次可追溯。围绕这三点，可以按以下清单调整。
- 按团队规模裁剪：小团队可合并“重开时间”和“再次提交时间”，保留一个时间字段；任务量大、退回频繁的团队保留全部时间字段，便于分析退回停留时长。
- 按任务类型裁剪：缺陷修复类任务可省略“验收标准引用”，改为引用缺陷编号；需求类任务保留标准引用，因为退回依据通常来自验收标准文档。
- 固定分类不随意增加：退回原因分类保持 5 至 7 个，新增分类前先确认现有分类无法覆盖，避免分类膨胀后统计失效。
- 保留版本号与变更记录：模板每次调整字段，在模板页首记录版本号、调整内容和生效时间，旧记录按原字段保留，不回溯改写。
- 同步统计口径：字段调整后，退回原因统计、平均退回轮次、平均闭环时长等指标的计算口径同步更新，并在统计说明中注明适用版本。
- 与任务状态流转衔接：退回时任务状态置为“已退回”或团队约定的对应状态，重开时回到“待验收”，关闭时进入“已完成”；记录中的时间字段与状态变更时间保持一致。
基于记录做改进时，建议按季度汇总退回原因分类的分布和平均退回轮次，找出高频原因对应的环节。例如“功能未达标准”集中在某类需求，说明验收标准编写需要前置细化；“文案问题”反复出现，可以在提交验收前增加自查项。统计结果用于调整流程，不用于评价个人。
如果记录在 ONES 中维护，可以把主表做成 Wiki 页面模板，每次退回按模板创建页面并关联对应任务，页面版本记录可保留模板与记录的变更历史；测试环节的退回还可结合 ONES TestCase 中未通过用例快速创建缺陷任务的方式，让问题明细与缺陷跟踪对应起来。具体字段配置和模板形式以团队实际使用的产品功能为准。
常见问题
同一任务被退回多次，记录应该合并成一条还是分开写？
分开写。每次退回产生一条独立记录，通过任务编号关联，退回轮次从 1 开始连续编号。合并成一条会让退回时间、退回方、重开条件和复验结论互相覆盖，后续统计平均退回轮次或退回停留时长时无法还原过程。问题明细子表也按记录编号归属到对应轮次，复验时逐轮核对。
退回原因分类应该设多少个，能不能让填写人自由输入？
建议保持 5 至 7 个固定分类，并保留“其他”作为兜底，选择“其他”时强制补充文字说明。自由输入会让同一类问题出现多种写法，季度汇总时无法归并。新增分类前先确认现有分类确实无法覆盖，避免分类持续膨胀导致统计口径失效。
重开时间和再次提交时间看起来是一回事，可以只留一个字段吗？
两者记录的动作不同：重开时间指任务重新进入待验收状态的时间，再次提交时间指整改后提交复验的动作时间。小团队或退回频率低时可以把两个字段合并为一个时间字段；退回频繁、需要分析整改停留时长的团队建议分开保留，否则无法区分状态变更与提交动作之间的间隔。
复验结论填“部分通过”时，这条记录算闭环吗？
不算闭环。复验结论为“部分通过”时，主表关闭时间留空，在结论说明中列出剩余问题，并针对剩余项产生下一轮退回记录。只有复验结论为“通过”时才填写关闭时间。这样轮次连续、子表逐条验证结果可回查，避免部分通过被当作完成处理。
模板调整字段后，之前填写的旧记录要不要按新格式改写？
不改写。模板每次调整在页首记录版本号、调整内容和生效时间，旧记录按原字段保留，新记录使用新版本。统计时在说明中注明各指标适用的模板版本，避免新旧口径混算。若记录在 ONES Wiki 中维护，页面版本记录可查看与回滚，模板与填写内容的变更历史都能保留。
