项目质量整改台账用一张表把问题记录、整改过程和关闭依据串起来，适合单项目质量控制场景。表格由三部分组成：字段说明每条记录填什么，证据说明关闭前要留存哪些材料，状态说明记录当前走到哪一步。下面先给可复制的空白表，再逐项解释填写口径、必填规则，并用一条完整记录示范三者如何对应。
要点总览（TL;DR）
- 台账用一张表承载三部分：字段（问题编号、来源、描述、责任人、期限、整改措施、验证结论等）、证据（问题记录、原因分析、整改过程材料、验证记录、关闭确认）、状态（待确认、整改中、待验证、已关闭、挂起、重开）。
- 必填字段包括问题编号、发现日期、问题来源、问题描述、责任人、整改期限、整改措施、证据材料、验证人、验证结论和状态，缺项时状态只能停留在待确认。
- 状态按“待确认→整改中→待验证→已关闭”主线流转，挂起与重开作为分支状态，每次变更同步记录日期和原因。
- 关闭前需集齐五类证据：问题记录、原因分析记录、整改过程材料、验证记录和关闭确认，表格中填写材料名称与存放位置。
- 台账需每周复核一次，重点检查临近期限未完成、长期停留在待验证和必填缺失的记录，项目收尾时按问题编号归档。
可复制空白整改台账模板
将下表复制到 Excel、在线表格或文档表格中即可使用。列顺序按“识别问题—分派责任—跟踪整改—验证关闭”排列，前六列用于定位问题，中间四列用于跟踪执行，最后四列用于留存证据和判断状态。证据列填写材料名称或存放位置，状态列从预设值中选择。
| 问题编号 | 发现日期 | 问题来源 | 关联交付物/工序 | 问题描述 | 严重程度 | 责任人 | 责任部门 | 整改期限 | 原因分析 | 整改措施 | 证据材料 | 验证人 | 验证结论 | 关闭日期 | 状态 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
状态列建议预设以下取值，便于筛选和统计：待确认、整改中、待验证、已关闭、挂起、重开。证据材料列可填写多个材料名称，用分号分隔，例如“问题照片；原因分析记录；整改后复检记录”。如果团队使用共享目录存放附件，可在备注列写明目录路径或文件编号。
台账字段说明：每个字段填什么
字段说明的作用是让不同人填写时口径一致。下表按四类字段解释含义和填写要求，其中“填写口径”一列给出可操作的判断标准。
| 字段 | 类别 | 含义 | 填写口径 |
|---|---|---|---|
| 问题编号 | 问题标识 | 台账内唯一标识一条整改记录 | 按“项目简称-年份-序号”编制，如“A项目-2025-001”，一经分配不再复用 |
| 发现日期 | 问题标识 | 问题被记录的时间 | 填写实际发现或首次记录的日期，不填计划日期 |
| 问题来源 | 问题标识 | 问题通过什么途径暴露 | 从预设来源中选择：内部检查、阶段评审、客户反馈、测试发现、巡检、其他 |
| 关联交付物/工序 | 问题标识 | 问题指向的具体对象 | 写明交付物名称、文档编号或工序名称，便于回溯上下文 |
| 问题描述 | 问题标识 | 对问题事实的客观陈述 | 写清“在哪里、什么现象、影响什么”，避免只写“质量差”这类判断 |
| 严重程度 | 问题标识 | 问题对交付的影响等级 | 按团队约定分级，如严重、一般、轻微，并说明分级依据 |
| 责任人 | 责任与时限 | 负责组织整改的人 | 填具体姓名，不填部门或岗位代称 |
| 责任部门 | 责任与时限 | 责任人所属部门 | 用于按部门汇总整改完成情况 |
| 整改期限 | 责任与时限 | 要求完成整改的日期 | 与责任人确认后填写，期限变更需在备注中记录原因 |
| 原因分析 | 整改与验证 | 问题产生的直接原因和根本原因 | 区分直接原因与根本原因，根本原因指向可改进的流程、标准或资源 |
| 整改措施 | 整改与验证 | 为消除问题采取的具体动作 | 写动作和产物，如“修订作业指导书第3.2节并重新培训班组”，不写“加强管理” |
| 证据材料 | 证据与状态 | 支撑问题成立、整改完成和关闭判断的材料 | 填写材料名称及存放位置，关闭前须与实际材料对应 |
| 验证人 | 证据与状态 | 独立确认整改效果的人 | 原则上不由整改责任人本人担任 |
| 验证结论 | 证据与状态 | 验证后的判断结果 | 填写“通过”“不通过”或“有条件通过”，不通过时说明需补充的动作 |
| 关闭日期 | 证据与状态 | 记录正式关闭的时间 | 验证通过且证据齐全后填写，与状态“已关闭”同步更新 |
| 状态 | 证据与状态 | 记录当前所处环节 | 从预设状态中选择，每次变更保留变更日期 |
| 备注 | 证据与状态 | 补充说明 | 记录期限变更、挂起原因、重开原因、证据存放路径等 |
证据材料是台账中最容易被写空的一列。一条整改记录通常需要五类证据：问题记录（照片、检查表、评审意见）、原因分析记录、整改过程材料（修订后的文件、培训签到、更换记录）、验证记录（复检报告、验证人签字）、关闭确认（关闭审批或会议纪要）。证据不必全部塞进表格，但表格中要能指向它们。
必填与选填：哪些字段不能空
必填字段决定一条记录能否被跟踪和关闭。建议将以下字段设为必填：问题编号、发现日期、问题来源、问题描述、责任人、整改期限、整改措施、证据材料、验证人、验证结论、状态。缺少其中任何一项，记录都无法完成从分派到关闭的闭环。
选填字段包括关联交付物/工序、严重程度、责任部门、原因分析、关闭日期、备注。这些字段在记录建立初期可以留空，但在状态推进到相应环节前需要补齐：严重程度应在问题确认时填写，用于排定处理优先级；原因分析应在进入“待验证”前填写；关闭日期在关闭时填写。
必填缺失时的处理规则可以这样设定：新建记录时若必填字段不全，状态只能停留在“待确认”，不得进入“整改中”；进入“待验证”前，整改措施和证据材料必须已填写；进入“已关闭”前，验证人、验证结论和关闭日期必须齐全。定期复核时，将必填缺失的记录单独列出，按责任部门催办，避免台账中出现长期空白的“僵尸记录”。
填写示例：一条完整整改记录
以下示例为演示情景，用于说明字段、证据与状态的对应关系。某项目在阶段评审中发现一份接口文档缺少异常处理说明，记录如下。
| 字段 | 填写内容 |
|---|---|
| 问题编号 | A项目-2025-007 |
| 发现日期 | 2025-03-12 |
| 问题来源 | 阶段评审 |
| 关联交付物/工序 | 接口设计文档 V1.2 |
| 问题描述 | 支付回调接口未说明超时和重复通知的处理方式，下游联调时无法确定异常分支行为 |
| 严重程度 | 一般 |
| 责任人 | 接口负责人（示例姓名略） |
| 责任部门 | 研发组 |
| 整改期限 | 2025-03-19 |
| 原因分析 | 直接原因：文档编写时遗漏异常分支；根本原因：接口文档评审清单未包含异常处理项 |
| 整改措施 | 补充超时重试与幂等处理说明，更新文档至 V1.3；在评审清单中增加异常处理检查项并组织一次宣贯 |
| 证据材料 | 评审意见记录；接口文档 V1.3；评审清单修订版；宣贯签到表；复检记录 |
| 验证人 | 质量负责人（示例姓名略） |
| 验证结论 | 通过 |
| 关闭日期 | 2025-03-18 |
| 状态 | 已关闭 |
| 备注 | 证据存放于项目质量目录/2025-03/整改-007 |
这条记录的状态流转为：3月12日记录后处于“待确认”，确认问题成立并分派责任人后进入“整改中”；3月17日整改措施完成、证据材料齐备，转入“待验证”；3月18日验证人复检通过，填写验证结论和关闭日期，状态更新为“已关闭”。如果复检不通过，状态回到“整改中”，并在备注中记录不通过原因；如果因外部依赖暂时无法推进，可置为“挂起”，恢复时改为“重开”再进入“整改中”。
台账的调整与维护方法
台账字段应随项目阶段和团队反馈调整，但调整要有原则。新增字段前先确认它是否服务于跟踪或关闭判断，例如项目进入验收阶段后可增加“客户确认”字段；删除字段时保留历史记录中的已有内容，避免追溯断档。字段名称和取值口径一旦在项目内统一，就应写入填表说明，减少不同人理解不一致。
状态维护的关键是定期复核。建议每周固定一次台账复核，检查三类情况：临近整改期限仍未完成的记录、长期停留在“待验证”的记录、必填字段缺失的记录。复核结果按责任部门汇总，在项目例会上通报。状态每次变更时同步更新变更日期，必要时在备注中写明原因，使状态变化可回溯。
关闭后的归档同样需要安排。项目阶段结束或项目收尾时，将台账连同证据材料按问题编号整理归档，保留问题描述、原因分析、整改措施和验证结论的完整链条。归档后的台账可作为后续类似项目的检查参考，也可用于统计问题来源分布和重复问题类型，为改进检查清单和评审流程提供依据。
当台账需要在多人之间协同维护时，可以把表格承载在项目管理工具中。以 ONES 为例，可将每条整改记录作为工作项跟踪，责任人、期限和状态对应工作项字段，整改证据通过 ONES Wiki 的文档页面留存，文档支持关联项目任务、记录页面版本并配置读写权限，附件可在线预览；项目层面的整改完成情况则可借助多维度统计查看。具体字段配置和状态流转方式以实际环境为准。无论使用表格还是工具，字段、证据与状态三者对应的规则不变，这是台账能够支撑跟踪与关闭的基础。
常见问题
整改期限到了但整改还没完成，台账里应该怎么处理？
期限到期未完成时，不建议直接修改原期限掩盖延期。可以在备注列记录延期原因和新的预计完成日期，同时保留原期限作为对比依据，状态维持“整改中”。如果延期涉及外部依赖或资源未到位，可先置为“挂起”，恢复时改为“重开”再进入“整改中”。每周复核时把这类记录单独列出，按责任部门催办，避免延期记录在台账中静默堆积。
验证人一定要和整改责任人分开吗？小团队人手紧张怎么办？
验证人与整改责任人分开，目的是让关闭判断有独立视角，避免自己整改自己验收。人手紧张的小团队可以安排同部门其他成员或项目质量负责人担任验证人，关键是验证人实际查看了证据材料并留下验证记录。如果确实只能由责任人自验，建议在备注中说明原因，并由项目负责人在阶段复核时抽查该条记录的证据完整性。
整改记录关闭后又被发现同类问题，应该新建记录还是重开原记录？
取决于问题是否同一事实。如果原问题整改不彻底、同一现象在原范围内再次出现，可将原记录状态改为“重开”，在备注中写明重开原因，补充新的整改措施和证据，保留完整的历史链条。如果是不同交付物或不同工序出现同类问题，建议新建记录，并在备注中关联原问题编号，便于后续统计重复问题类型、改进检查清单。
台账放在共享表格里多人维护，容易出现状态和证据不同步，有什么办法？
共享表格的常见问题是状态已改但证据未补、或多人同时编辑覆盖内容。可以设两条约束：状态每次变更时同步填写变更日期，并在备注中写明依据；进入“待验证”和“已关闭”前，由验证人核对证据材料列与实际材料是否对应。记录数量较多时，可把每条整改记录作为工作项跟踪，责任人、期限和状态对应工作项字段，证据通过文档页面留存。以 ONES 为例，ONES Wiki 支持文档关联项目任务、记录页面版本并配置读写权限，附件可在线预览，便于状态与证据保持对应；具体配置以实际环境为准。
项目结束后台账还需要保留吗，保留哪些内容？
建议保留。项目收尾时将台账连同证据材料按问题编号整理归档，至少保留问题描述、原因分析、整改措施、验证结论和关闭确认这条完整链条，证据原件可按存放路径单独保存。归档台账可用于后续类似项目的检查参考，也能统计问题来源分布和重复问题类型，为修订检查清单和评审流程提供依据。归档时同步确认证据材料的存放位置仍然可访问，避免台账指向已失效的路径。
