任务因验收退回、方案变更或外部条件变化需要重新执行时，重开记录要能回答四个问题：为什么退回、谁决定重开、重开后做什么、最后是否通过。本文给出一张以“一次重开一行”的空白记录表，按基本信息、退回与重开原因、处理安排、闭环结果四段组织，并配套字段口径、必填清单、完整示例和维护方法，可直接复制到文档或表格工具中使用。
要点总览（TL;DR）
- 模板以“一次重开一行”的表格为主体，按基本信息、退回与重开原因、处理安排、闭环结果四段组织，同一任务多次重开用“重开次数”区分。
- 填写时区分现象与根因：“具体问题”写观察到的事实，“根因说明”写原因；复验标准要与整改措施一一对应，写成可判定的检查条件。
- 任务标识、重开次数、重开日期、发起人、退回环节、具体问题、整改措施、责任人、复验标准为必填；根因说明在第二次及以后重开时必填，复验结论在关闭时必填。
- 模板可按任务类型裁剪字段，新增字段只对生效日期之后的记录生效，并在模板顶部标注版本号与生效日期，每季度复核字段使用情况。
可复制空白模板：任务重开记录表
下表为空白模板，复制后保留表头与分区行即可使用。同一任务每发生一次重开就新增一行，用“重开次数”区分第几次重开；同一任务的多行记录通过“任务标识”关联。分区行仅用于阅读时定位，填入表格工具后可改为分组标题或单独一列“记录分区”。
| 分区 | 字段 | 填写内容 |
|---|---|---|
| 基本信息 | 任务标识 | |
| 基本信息 | 任务名称 | |
| 基本信息 | 重开次数 | |
| 基本信息 | 重开日期 | |
| 基本信息 | 发起人 | |
| 基本信息 | 原责任人 | |
| 退回与重开原因 | 退回环节 | |
| 退回与重开原因 | 退回依据 | |
| 退回与重开原因 | 具体问题 | |
| 退回与重开原因 | 问题分类 | |
| 退回与重开原因 | 根因说明 | |
| 处理安排 | 整改措施 | |
| 处理安排 | 责任人 | |
| 处理安排 | 计划完成时间 | |
| 处理安排 | 复验标准 | |
| 闭环结果 | 复验结论 | |
| 闭环结果 | 关闭日期 | |
| 闭环结果 | 遗留问题 |
如果团队习惯横向表头，可将上表转置：第一行放字段名，第二行起每行一条重开记录，并在字段名前加“基本信息_”“原因_”“安排_”“结果_”前缀保持分区可辨。两种排法记录内容一致，选择哪种取决于团队查看记录的习惯，横向表头更适合在表格工具中筛选和统计。
重开记录需要附着在具体任务上才有意义。在ONES中，任务以工作项形式存在，状态流转、退回说明和重开后的处理安排可以记录在同一工作项下，重开次数与关闭结果随任务状态变化保留，便于后续按任务回溯每次重开的来龙去脉。
字段说明：每个字段记录什么、怎么填
字段口径统一，不同人填出的记录才能互相对照。以下按四段说明每个字段记录的内容和填写要求。
基本信息类字段
- 任务标识：填任务在工作项系统或任务清单中的唯一编号，保证多条重开记录能归到同一任务。
- 任务名称：填任务当前名称，便于不打开系统也能识别记录对象。
- 重开次数：填本次是该任务的第几次重开，首次重开填1，再次退回累加。该字段是区分同一任务多行记录的关键。
- 重开日期：填任务被退回并决定重开的日期，与关闭日期形成时间跨度。
- 发起人：填提出退回或批准重开的人，通常是验收人或任务负责人。
- 原责任人：填被退回前承担该任务的人，便于判断重开后责任是否调整。
退回与重开原因类字段
这类字段要区分现象与根因。“具体问题”写观察到的事实，例如“接口返回超时未处理”“交付文档缺少验收章节”；“根因说明”写导致问题的原因，例如“异常分支未覆盖”“模板版本未同步”。只写现象不写根因，重开后的整改容易停留在表面；只写根因不写现象，复验时缺少可对照的检查点。
- 退回环节：填问题在哪个环节被发现，如自检、评审、验收、上线验证。
- 退回依据：填判定退回所依据的标准、需求条目或检查项编号。
- 问题分类：填统一分类，如质量缺陷、范围遗漏、标准不符、外部条件变化，便于后续统计哪类问题最常导致重开。
处理安排类字段
整改措施、责任人和计划完成时间构成一组，复验标准要与整改措施一一对应：每条措施都应能回答“改完后用什么检查确认改好了”。复验标准写成可判定的条件，例如“异常分支补充用例并通过回归”“文档补齐验收章节并经评审签字”，避免写成“已修复”“已完善”这类无法核验的表述。
闭环结果类字段
- 复验结论：填通过或不通过；不通过时在遗留问题中说明，并视情况发起下一次重开。
- 关闭日期：填复验通过、任务重新关闭的日期，未通过时留空。
- 遗留问题：填本次未解决、需转入后续任务或下次重开处理的事项，没有则填“无”。
必填与选填：哪些字段不能空
必填字段缺失时，该条重开记录视为未完成，不应进入关闭状态。团队可将必填校验放在记录提交或任务状态流转环节，缺项时提示补填，避免记录事后补造。
| 字段 | 要求 | 缺失时的处理 |
|---|---|---|
| 任务标识 | 必填 | 阻断提交，无法关联任务 |
| 重开次数 | 必填 | 阻断提交，无法区分多次重开 |
| 重开日期 | 必填 | 阻断提交 |
| 发起人 | 必填 | 阻断提交 |
| 退回环节 | 必填 | 阻断提交 |
| 具体问题 | 必填 | 阻断提交 |
| 整改措施 | 必填 | 阻断提交 |
| 责任人 | 必填 | 阻断提交 |
| 复验标准 | 必填 | 阻断提交 |
| 复验结论 | 关闭时必填 | 未填则任务不能标记为关闭 |
| 任务名称 | 选填 | 可由任务标识带出 |
| 原责任人 | 选填 | 责任未调整时可省略 |
| 退回依据 | 选填 | 有明确标准条目时填写 |
| 问题分类 | 选填 | 团队需要统计时填写 |
| 根因说明 | 条件必填 | 重开次数≥2时必填，用于避免同类问题反复出现 |
| 计划完成时间 | 条件必填 | 问题分类为质量缺陷或范围遗漏时必填 |
| 关闭日期 | 条件必填 | 复验结论为通过时必填 |
| 遗留问题 | 选填 | 无遗留时填“无” |
条件必填按重开次数和问题类型设置：第二次及以后的重开必须写根因说明，因为重复退回通常意味着首次整改未触及原因；质量缺陷和范围遗漏类问题必须给出计划完成时间，便于跟踪整改节奏。字段留空的记录在补录时，应同时补上补录人和补录日期，注明信息为事后补充，避免与当时记录混淆。
填写示例：一条完整重开记录
以下为一条已填写的记录，演示四段字段如何配合使用。示例为演示情景，任务与人员信息为虚构。
| 分区 | 字段 | 填写内容 |
|---|---|---|
| 基本信息 | 任务标识 | TSK-1042 |
| 基本信息 | 任务名称 | 订单查询接口异常处理改造 |
| 基本信息 | 重开次数 | 1 |
| 基本信息 | 重开日期 | 2025-03-11 |
| 基本信息 | 发起人 | 验收人 李某 |
| 基本信息 | 原责任人 | 开发 王某 |
| 退回与重开原因 | 退回环节 | 验收 |
| 退回与重开原因 | 退回依据 | 验收检查项 AC-07：接口超时须返回明确错误提示 |
| 退回与重开原因 | 具体问题 | 模拟下游超时时，接口返回空白页，未给出错误提示 |
| 退回与重开原因 | 问题分类 | 质量缺陷 |
| 退回与重开原因 | 根因说明 | 超时异常分支未捕获，直接抛出到页面层 |
| 处理安排 | 整改措施 | 补充超时异常捕获，统一返回错误码与提示文案 |
| 处理安排 | 责任人 | 开发 王某 |
| 处理安排 | 计划完成时间 | 2025-03-14 |
| 处理安排 | 复验标准 | 模拟下游超时，接口返回约定错误码与提示文案；补充对应用例并通过回归 |
| 闭环结果 | 复验结论 | 通过 |
| 闭环结果 | 关闭日期 | 2025-03-17 |
| 闭环结果 | 遗留问题 | 无 |
示例中“具体问题”描述的是验收时看到的现象，“根因说明”指向代码层的异常处理缺失，两者分工明确；“整改措施”针对根因，“复验标准”则把措施转成可执行的检查动作，复验人按标准操作即可判断是否通过。若复验未通过，复验结论填“不通过”，关闭日期留空，并在遗留问题中写明未达标项，随后以重开次数2新增一行记录。
调整与维护：模板怎么随团队变化更新
模板投入使用后，字段会随任务类型和团队分工变化。调整时把握一条原则：保留能支撑“为什么退回、改了什么、是否改好”这条主线的字段，其余按需增减。
按任务类型裁剪字段
研发类任务通常保留根因说明和复验标准中的用例要求；文档、设计类任务可弱化根因说明，强化退回依据中的评审意见编号；外部依赖导致的重开，可在问题分类中单列“外部条件变化”，并允许计划完成时间随外部方反馈调整。裁剪时先确认该字段是否被其他记录或统计引用，被引用的字段即使当前任务类型不常用也建议保留。
新增字段与历史记录处理
新增字段时，旧记录该字段留空并在模板说明中标注“自某版本起启用”，不要求回溯补填；若新字段属于必填，则只对生效日期之后的记录生效。需要迁移历史数据时，先明确迁移范围和映射规则，迁移后保留原记录编号，便于对照。
版本与生效日期标注
每次调整在模板顶部标注版本号和生效日期，例如“重开记录表 v1.2，2025-04-01 起生效”，并在版本说明中列出本次增删的字段。记录本身也应带版本号，保证日后查看旧记录时知道当时适用哪套字段。
定期复核字段使用情况
建议每季度检查一次：哪些字段长期为空、哪些分类几乎不用、哪些问题反复出现在根因说明中。长期为空的字段考虑删除或改为选填；反复出现的根因则提示需要在流程或标准层面处理，而不只是逐条重开。复核结论记入版本说明，形成模板演进的连续记录。
常见问题
任务第二次被退回重开时，记录要新增一行还是修改原记录？
新增一行，用“重开次数”填2区分。原记录保留首次重开的完整信息，包括当时的整改措施和复验结论，这样能看出第一次整改为什么没有解决问题。第二次重开的记录中，“根因说明”为必填，重点写清首次整改未触及的原因；如果两次问题属于同一类，可在根因说明中引用首次记录的重开次数，便于对照。
退回依据在什么情况下必须填写？
退回依据属于选填字段，团队有明确的标准条目、需求编号或检查项编号时填写，例如“验收检查项 AC-07”。如果退回是基于评审人的经验判断，暂时没有对应条目，可先留空，在具体问题中写清判断依据；后续若该判断被固化为检查项，再补填编号。需要按标准追溯的场景，可将退回依据设为条件必填，与问题分类联动。
复验不通过时，这条记录怎么处理？
复验结论填“不通过”，关闭日期留空，在遗留问题中写明未达标的具体项。随后以重开次数加1新增一行记录，把未达标项作为新的具体问题，重新给出整改措施和复验标准。原记录保持不通过状态，不改为通过，保证每次重开的结论都能被追溯。
模板字段太多，小团队可以只保留一部分吗？
可以按任务类型裁剪，但建议保留支撑“为什么退回、改了什么、是否改好”这条主线的字段：任务标识、重开次数、具体问题、整改措施、复验标准和复验结论。任务名称、原责任人、退回依据、问题分类等字段可按需取舍。裁剪前先确认该字段是否被其他记录或统计引用，被引用的字段即使当前不常用也建议保留，避免历史记录出现断档。
重开记录放在任务系统里还是单独维护一张表？
两种方式都能用，取决于团队查看记录的习惯。记录附着在具体任务上时，重开次数、退回说明和关闭结果随任务状态变化保留，回溯时不用跨表查找；单独维护表格则便于跨任务筛选和统计，但需要靠任务标识与任务系统对应。在ONES中，任务以工作项形式存在，状态流转、退回说明和重开后的处理安排可以记录在同一工作项下，适合需要按任务回溯每次重开来龙去脉的团队。
