质量整改记录模板要同时支撑两件事：跟踪整改进度，判定能否关闭。本文给出一张可直接复制填写的单项目整改台账，把字段分成跟踪区和关闭区，并说明必填取舍、完整填写示例和维护规则。示例中的编号、日期与结论均为演示情景，实际使用时按项目情况替换。
要点总览（TL;DR）
- 质量整改记录模板按“登记信息—跟踪信息—关闭信息”三段设计字段，跟踪字段回答谁在何时做到哪一步，关闭字段回答凭什么可以结束。
- 必填字段以“缺少它就无法跟踪或无法判定关闭”为标准，核心包括整改编号、问题描述、责任人、整改措施、计划完成日期、当前状态、验证人和验证结论。
- 验证结论是跟踪区与关闭区之间唯一的衔接点，结论为空或不通过时关闭状态保持未关闭。
- 整改数量多、跨部门协作多的项目，可把问题等级、整改进度、最近更新日期转为必填，并将关闭依据设为关闭时的强制项。
- 台账迁移到协作工具时，保持字段名称与模板一致，用状态字段承载当前状态，用自定义字段承载来源、责任部门和计划日期。
可复制空白整改记录模板
下表是一张空白台账，按“登记信息—跟踪信息—关闭信息”三段排列。复制到文档或表格工具后，逐列保留表头，逐行填写一条整改记录。表中不预填任何结论，状态列留空由填写人按实际进展选择。
| 区段 | 字段 | 填写内容 |
|---|---|---|
| 登记信息 | 整改编号 | |
| 问题来源 | ||
| 问题描述 | ||
| 问题等级 | ||
| 发现日期 | ||
| 责任部门 | ||
| 责任人 | ||
| 跟踪信息 | 整改措施 | |
| 计划完成日期 | ||
| 整改进度 | ||
| 当前状态 | ||
| 最近更新日期 | ||
| 延期原因 | ||
| 验证人 | ||
| 验证日期 | ||
| 关闭信息 | 验证结论 | |
| 关闭依据 | ||
| 关闭状态 | ||
| 关闭人 | ||
| 关闭日期 | ||
| 备注 |
这张表适合放在项目共享文档中，一行一条整改记录，按整改编号排序。需要按状态筛选时，把“当前状态”和“关闭状态”作为筛选列；需要统计逾期情况时，用“计划完成日期”与“最近更新日期”对比即可。
跟踪字段与关闭字段各自解决什么问题
字段分组的依据是回答两个不同问题：跟踪字段回答“谁在什么时候做到哪一步”，关闭字段回答“凭什么可以结束”。两类字段混在一起，容易出现进度写着“已完成”但没人验证、或者验证通过了却没有关闭记录的情况。
跟踪字段：建立责任与进度的基线
跟踪区从登记信息开始。“整改编号”是这条记录的唯一标识，便于在会议、邮件和文档中引用；“问题来源”说明问题从哪里被发现，常见来源包括内部评审、过程检查、客户反馈和测试环节；“问题描述”写清现象、发生位置和影响范围，避免只写一句“质量有问题”；“责任部门”和“责任人”确定由谁推进；“计划完成日期”给出可考核的时间点。
进入整改阶段后，“整改措施”记录具体动作，“整改进度”用百分比或阶段描述反映完成程度，“当前状态”标记记录处于待整改、整改中、待验证还是已关闭，“最近更新日期”用于判断记录是否长期无人跟进，“延期原因”只在计划日期之后仍未完成时填写。跟踪区的共同作用是让任何人在不看聊天记录的情况下，判断这条整改是否在正常推进。
关闭字段：给出放行依据
关闭区以“验证结论”为起点。验证人对照整改措施检查实际结果，给出通过、不通过或有条件通过三种结论之一。结论为通过时，填写“关闭依据”，写明支撑关闭的证据，例如复检记录编号、现场照片说明、评审会议纪要或测试报告结论；随后由关闭人填写“关闭状态”和“关闭日期”。“关闭人”与“验证人”可以由同一人担任，也可以在项目要求下分开设置，分开时关闭人对验证结论做最终确认。
验证结论是跟踪区与关闭区之间唯一的衔接点。进度到100%只说明整改动作做完了，验证结论为通过才说明问题确实解决。台账中应把“验证结论”设为关闭的前置条件：结论为空或不通过时，关闭状态保持未关闭。
必填与选填字段怎么划分
必填字段的判定标准是：缺少它，这条整改记录就无法被跟踪或被判定关闭。其余字段按项目需要保留为选填，避免初次建表时字段过多导致填写负担过重。
| 字段 | 必填/选填 | 判定理由或适用情形 |
|---|---|---|
| 整改编号 | 必填 | 唯一标识，缺少则无法引用和检索 |
| 问题来源 | 必填 | 支撑后续按来源统计和复盘 |
| 问题描述 | 必填 | 整改对象本身，缺少则无法验证 |
| 责任部门 | 必填 | 确定推进主体 |
| 责任人 | 必填 | 确定具体跟进人 |
| 整改措施 | 必填 | 验证时对照的依据 |
| 计划完成日期 | 必填 | 逾期判断的时间基准 |
| 当前状态 | 必填 | 台账筛选与流转的基础 |
| 验证人 | 必填 | 关闭判定的责任主体 |
| 验证结论 | 必填 | 关闭的唯一放行条件 |
| 关闭状态 | 必填 | 记录是否结束的标志 |
| 关闭日期 | 必填 | 关闭时间留痕 |
| 问题等级 | 选填 | 问题数量多、需要排优先级时启用 |
| 发现日期 | 选填 | 需要统计发现到关闭周期时启用 |
| 整改进度 | 选填 | 整改周期较长、需要阶段汇报时启用 |
| 最近更新日期 | 选填 | 需要识别长期停滞记录时启用 |
| 延期原因 | 选填 | 仅在实际延期时填写 |
| 验证日期 | 选填 | 需要区分验证与关闭时间时启用 |
| 关闭依据 | 选填 | 项目要求留存证据时建议设为必填 |
| 关闭人 | 选填 | 验证人与关闭人分设时启用 |
| 备注 | 选填 | 补充说明用，不作考核依据 |
按项目规模调整时，可以遵循两条原则。整改数量少、周期短的项目，保留必填字段即可运转，选填字段按需补充；整改数量多、跨部门协作多的项目，建议把“问题等级”“整改进度”“最近更新日期”转为必填，并把“关闭依据”设为关闭时的强制项，便于统计和审计。调整时保持字段含义稳定，避免同一字段在不同项目中承担不同用途。
填写示例：一条整改记录从登记到关闭
以下示例演示一条整改记录从登记到关闭的完整填写过程，字段与上文模板一一对应。示例内容为演示情景。
| 字段 | 示例值 |
|---|---|
| 整改编号 | QR-2024-017 |
| 问题来源 | 阶段评审 |
| 问题描述 | 交付文档中的接口说明与最新版本不一致，涉及三个接口的参数定义 |
| 问题等级 | 中 |
| 发现日期 | 2024-05-08 |
| 责任部门 | 研发组 |
| 责任人 | 张工 |
| 整改措施 | 核对三个接口的实际参数，更新接口说明文档并提交评审确认 |
| 计划完成日期 | 2024-05-15 |
| 整改进度 | 100% |
| 当前状态 | 待验证 |
| 最近更新日期 | 2024-05-14 |
| 延期原因 | （未延期，留空） |
| 验证人 | 李工 |
| 验证日期 | 2024-05-16 |
| 验证结论 | 通过：三个接口参数与系统实际一致，文档已更新至最新版本 |
| 关闭依据 | 评审记录 QR-REV-009，文档版本 V2.3 |
| 关闭状态 | 已关闭 |
| 关闭人 | 王工 |
| 关闭日期 | 2024-05-16 |
| 备注 | 建议后续接口变更时同步更新说明文档 |
这条记录的关键写法有三处。验证结论写成“结论+事实”的结构，先给通过与否，再写核对的具体内容，避免只写“已通过”。关闭依据指向可查证的证据，写明记录编号和文档版本，使关闭动作可以被复核。延期原因在未延期时留空，不用“无”或“正常”填充，保持字段语义清晰。
如果验证不通过，示例中的处理方式是：验证结论填写“不通过：接口二参数仍与系统不一致”，关闭状态保持“未关闭”，当前状态回到“整改中”，由责任人补充整改措施后再次提交验证。台账中保留这次验证记录，不覆盖前一次结论，便于复盘整改反复的原因。
台账的调整与维护方法
台账建好后，维护质量决定它能否长期使用。以下规则可按项目节奏取舍。
- 状态流转规则：当前状态按“待整改—整改中—待验证—已关闭”推进，每次变更同步更新“最近更新日期”。状态只能由责任人推进到待验证，由验证人推进到已关闭，避免同一人既整改又自行关闭。
- 更新频率：整改周期在一周内的项目，建议每周更新一次；周期更长或问题较多的项目，按项目例会节奏更新，会上逐条过“当前状态”和“计划完成日期”。逾期记录在例会上说明延期原因。
- 归档与复盘：项目阶段结束时，将已关闭记录归档，保留原表不做删改。复盘时按“问题来源”和“责任部门”统计数量，按“发现日期”到“关闭日期”计算平均处理周期，找出反复出现的问题类型。
- 字段增删原则：新增字段前先确认它服务于跟踪还是关闭，并明确由谁填写、何时填写。删除字段时检查是否影响关闭判定，验证结论和关闭状态不建议删除。字段调整后，在台账说明中记录变更日期和原因，保持历史记录可读。
当台账从单张文档迁移到协作工具时，可以把每条整改记录作为独立工作项管理，用状态字段承载“当前状态”，用自定义字段承载问题来源、责任部门和计划完成日期，让筛选、提醒和统计在工具内完成。ONES 支持围绕项目任务跟踪进度并开展协同管理，ONES Wiki 提供页面模板库用于一键创建制式化文档模板，并记录页面版本、支持按角色配置读写权限，适合把整改台账做成固定模板并区分登记人、验证人与关闭人的操作权限。迁移时保持字段名称与本文模板一致，可以减少填写习惯的切换成本。
常见问题
整改记录关闭后，如果同类问题再次出现，应该新建一条记录还是重新打开原记录？
建议新建一条整改记录，并在“问题描述”或“备注”中引用原整改编号。原记录保持已关闭状态，不重新打开，这样能保留每次整改的独立验证结论和关闭依据，复盘时也能看出同类问题重复发生的次数。如果项目要求追溯关联，可以在新记录中增加“关联整改编号”字段，或在备注中写明原编号。
验证人和关闭人必须分开设置吗？什么情况下可以合并？
验证人和关闭人是否分开，取决于项目对独立复核的要求。整改数量少、周期短的项目，可以由同一人担任，但该人应具备验证整改结果的职责权限。整改涉及跨部门、或问题等级较高时，建议分开设置：验证人负责对照整改措施检查实际结果并给出结论，关闭人对验证结论做最终确认。分开设置时，在台账中分别记录验证日期和关闭日期，便于区分两个动作的时间。
台账放在共享文档里，多人同时填写时怎么避免状态和关闭信息被误改？
可以从字段权限和填写规则两方面处理。字段权限上，把“验证结论”“关闭状态”“关闭人”“关闭日期”限定为验证人或关闭人可编辑，责任人只能更新整改进度和当前状态。填写规则上，约定状态只能按“待整改—整改中—待验证—已关闭”顺序推进，每次变更同步更新最近更新日期。如果使用协作工具承载台账，可参考 ONES Wiki 按角色配置读写权限的方式，区分登记人、验证人与关闭人的操作范围。
项目结束后，已关闭的整改记录还需要保留哪些字段用于复盘？
复盘时主要用到问题来源、责任部门、发现日期、关闭日期和验证结论。问题来源和责任部门用于统计问题分布，发现日期到关闭日期用于计算处理周期，验证结论用于判断整改是否真正解决。已关闭记录归档时保留原表全部字段，不做删改；如果后续字段有调整，在台账说明中记录变更日期和原因，保证历史记录仍可读。
