项目质量不符合项登记表建议覆盖“发现—分级—责任—原因—整改—验证—关闭”七类信息，让每条记录都能回答：发现了什么问题、影响多大、由谁处理、为什么发生、怎么改、改完是否有效。本文给出一张可直接复制到表格工具中的空白登记表，并配套字段说明、必填规则、完整填写示例和长期维护方法，适用于单项目质量控制场景，组织可结合自身质量制度裁剪。
要点总览（TL;DR）
- 登记表按“发现—分级—责任—原因—整改—验证—关闭”七段组织字段，一条不符合项占一行，覆盖从识别到关闭的完整信息。
- 必填字段围绕可追溯性设置：编号、项目名称、发现日期、发现人、不符合对象、标准要求、实际状况、严重程度、责任人、整改措施、验证结论、关闭状态。
- 证据附件、影响范围、根本原因、计划完成日期、验证人、关联变更等按触发条件填写，条件写进填表说明，避免执行时凭个人理解取舍。
- 填写时把“标准要求”与“实际状况”分开写，先完成原因分析再定整改措施，验证人由发现方或独立质量人员担任，不由整改人自验。
- 模板调整优先保持字段口径稳定，用下拉选项统一严重程度、原因类别和关闭状态，并标注模板版本号与生效日期。
可复制空白登记表模板
下表按“基础标识—不符合描述—分级判定—责任归属—原因分析—整改计划—验证关闭”的顺序排列列名，复制到 Excel、在线表格或文档表格中即可逐行填写。表头下方保留三行空白行，便于直接录入；实际使用时按一条不符合项一行记录，不把多条问题挤在同一行。
| 编号 | 项目名称 | 发现日期 | 发现人 | 发现环节 | 不符合对象 | 位置/批次 | 标准要求 | 实际状况 | 证据附件 | 严重程度 | 影响范围 | 是否阻断 | 责任部门 | 责任人 | 发现方 | 处理方 | 直接原因 | 根本原因 | 原因类别 | 整改措施 | 计划完成日期 | 所需资源 | 关联变更 | 验证人 | 验证日期 | 验证结论 | 关闭状态 | 复发预防 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
列数较多时，可把“证据附件”“所需资源”“关联变更”“复发预防”放在表格右侧作为补充信息区，主表保留编号、描述、分级、责任人、整改措施、验证结论等核心列，打印和日常跟踪会更方便。
字段说明：每个字段填什么、怎么填
字段说明与上表列名一一对应。填写口径的原则是：同一字段在不同记录中保持同一种写法，便于筛选、统计和交接。
| 字段名 | 含义 | 填写口径 |
|---|---|---|
| 编号 | 不符合项的唯一标识 | 采用“项目缩写-年份-流水号”，如 PRJ-2025-001；一经分配不再修改 |
| 项目名称 | 所属项目 | 写项目正式名称，与项目立项文件一致 |
| 发现日期 | 首次识别问题的日期 | 填写发现当天日期，不填整改日期 |
| 发现人 | 最先识别问题的人员 | 写姓名，可附岗位；多人同时发现时填第一记录人 |
| 发现环节 | 问题被识别时所在的阶段或活动 | 使用统一选项，如设计评审、采购验收、施工检查、测试执行、交付验收 |
| 不符合对象 | 出现问题的具体对象 | 写可定位的对象，如某模块、某批次材料、某工序、某文档 |
| 位置/批次 | 对象所在位置或批次信息 | 写楼层、区域、版本号、批次号等可追溯信息 |
| 标准要求 | 应达到的要求 | 引用标准条款、图纸编号、合同条款或验收规范，写清出处 |
| 实际状况 | 实际观察到的偏差 | 用事实描述，写清偏差量、现象和发生条件，避免“质量差”这类判断词 |
| 证据附件 | 支撑问题成立的证据 | 填写照片、检测报告、记录表等附件名称或存放位置 |
| 严重程度 | 问题的影响等级 | 按项目约定分级，如一般、较重、严重、重大；分级标准需事先定义 |
| 影响范围 | 问题波及的对象和范围 | 写受影响的工序、批次、交付物或下游环节，能量化则写数量 |
| 是否阻断 | 是否导致后续工作无法继续 | 填“是/否”；填“是”时说明被阻断的活动 |
| 责任部门 | 对问题负直接责任的部门 | 写部门名称，避免只写个人 |
| 责任人 | 负责组织整改的人员 | 写姓名；责任人应与整改措施执行人一致或明确授权关系 |
| 发现方 | 提出问题的一方 | 写内部岗位或外部单位，如质量部、监理、客户 |
| 处理方 | 承接整改的一方 | 写部门或单位；与责任部门不同时需说明协作关系 |
| 直接原因 | 直接引发问题的原因 | 写具体动作或条件，如参数设置错误、材料未复检 |
| 根本原因 | 导致直接原因产生的深层原因 | 从流程、培训、资源、制度等角度分析，避免停留在“人员疏忽” |
| 原因类别 | 原因的归类 | 使用统一选项，如人、机、料、法、环、测 |
| 整改措施 | 消除问题及原因的具体动作 | 写可执行、可验证的动作，包含对象和完成标准 |
| 计划完成日期 | 整改完成的截止日期 | 填写明确日期；延期需记录新日期和原因 |
| 所需资源 | 整改需要的人力、材料或审批 | 写资源名称和数量，便于提前协调 |
| 关联变更 | 整改引发的变更 | 填写变更单号或说明，如设计变更、工艺调整 |
| 验证人 | 负责确认整改效果的人员 | 原则上由发现方或独立质量人员担任，不由整改人自验 |
| 验证日期 | 完成验证的日期 | 填写实际验证当天日期 |
| 验证结论 | 整改是否有效的判定 | 填“通过/不通过/有条件通过”，不通过时说明需补充的动作 |
| 关闭状态 | 记录当前所处状态 | 使用统一状态，如待处理、整改中、待验证、已关闭 |
| 复发预防 | 防止同类问题再次发生的安排 | 写标准修订、培训、检查频次调整等具体安排 |
“标准要求”和“实际状况”两列是判断问题是否成立的核心，填写时把要求与事实分开写，评审时更容易达成一致。“根本原因”一列决定整改能否真正解决问题，建议在原因分析完成后再填写整改措施，避免措施与原因脱节。
必填与选填：哪些字段不能空
必填字段围绕可追溯性设置：没有这些信息，记录无法被识别、分派和关闭。条件必填字段在特定情形下必须填写，其余字段可按项目实际裁剪。
| 档位 | 字段 | 说明 |
|---|---|---|
| 必填 | 编号、项目名称、发现日期、发现人、不符合对象、标准要求、实际状况、严重程度、责任人、整改措施、验证结论、关闭状态 | 缺少任一项，记录无法完成从发现到关闭的闭环 |
| 条件必填 | 证据附件 | 问题涉及实物、现场或检测数据时必须附证据；纯文档笔误类问题可注明“无需附件” |
| 条件必填 | 影响范围、是否阻断 | 严重程度为“严重”或“重大”时必须填写，用于判断是否暂停后续工作 |
| 条件必填 | 根本原因、原因类别 | 问题重复发生或严重程度较高时必须分析；一般问题可只写直接原因 |
| 条件必填 | 计划完成日期 | 进入整改状态后必须填写 |
| 条件必填 | 验证人、验证日期 | 提交验证时必须填写，验证人不能与整改人为同一人 |
| 条件必填 | 关联变更 | 整改涉及设计、工艺、合同变更时必须填写变更单号 |
| 选填 | 位置/批次、发现环节、发现方、处理方、所需资源、复发预防 | 小项目可精简；跨部门协作或需要资源协调时建议保留 |
裁剪时优先保留必填字段，条件必填字段的触发条件写进填表说明，避免执行时凭个人理解取舍。选填字段可以合并，例如把“发现方”和“处理方”合并为一列“相关方”，但合并后要在字段说明中写清填写格式。
填写示例：一条完整的不符合项记录
以下为演示情景，不对应真实项目。示例展示一条记录从发现到关闭的填写方式，重点看字段之间的对应关系。
| 字段 | 填写内容 |
|---|---|
| 编号 | PRJ-2025-007 |
| 项目名称 | 某园区机电安装项目 |
| 发现日期 | 2025-03-12 |
| 发现人 | 张工（质量工程师） |
| 发现环节 | 施工过程检查 |
| 不符合对象 | 地下二层消防管道支架 |
| 位置/批次 | 地下二层东区，批次 GD-0311 |
| 标准要求 | 支架间距不大于 3 米，依据施工图纸 SD-2024-118 第 5.2 条 |
| 实际状况 | 抽查 12 处支架，其中 3 处间距为 3.6 米至 4.1 米，超出图纸要求 |
| 证据附件 | 现场照片 6 张、抽查记录表 1 份 |
| 严重程度 | 较重 |
| 影响范围 | 影响该区域管道受力及后续吊顶安装，涉及支架约 20 处 |
| 是否阻断 | 否 |
| 责任部门 | 机电施工班组 |
| 责任人 | 李工 |
| 发现方 | 项目质量部 |
| 处理方 | 机电施工班组 |
| 直接原因 | 支架安装时未按图纸间距放线，凭经验布置 |
| 根本原因 | 班组交底未覆盖支架间距要求，现场无放线复核环节 |
| 原因类别 | 法（作业方法） |
| 整改措施 | 对超距支架全部调整至 3 米以内，完成后提交调整前后对比照片；班组补充专项交底并增加放线复核 |
| 计划完成日期 | 2025-03-18 |
| 所需资源 | 支架配件 20 套、复核人员 1 名 |
| 关联变更 | 无 |
| 验证人 | 王工（质量部） |
| 验证日期 | 2025-03-17 |
| 验证结论 | 通过 |
| 关闭状态 | 已关闭 |
| 复发预防 | 将支架间距列入班组交底清单，后续同类工序按 10% 比例抽查 |
示例中“标准要求”引用了图纸条款，“实际状况”给出了抽查数量和偏差数值，两者对照即可判断问题成立。“直接原因”写具体动作，“根本原因”落到交底和复核环节，整改措施因此同时包含返工和流程补充。验证由质量部人员完成，与整改人分开，验证结论和关闭状态同步更新，记录才具备闭环条件。
模板调整与维护方法
登记表在使用中会随项目阶段和问题类型变化，调整时保持字段口径稳定比增加字段更重要。以下操作清单可按项目节奏执行。
- 字段裁剪：项目初期先用必填字段加少量条件必填字段运行一到两周，统计哪些列长期为空、哪些信息反复写在备注里，再决定增删。新增字段前先确认它服务于分派、跟踪还是复盘，避免为记录而记录。
- 选项统一：严重程度、原因类别、关闭状态等字段使用下拉选项，选项值在项目启动时确定并写入填表说明，中途不随意增加同义选项。
- 状态流转：明确每个状态的进入条件和责任人，例如“待处理”由发现人提交后进入，“整改中”由责任人认领后进入，“待验证”由责任人提交整改证据后进入，“已关闭”由验证人确认通过后进入。状态变更时同步更新对应日期字段。
- 更新责任：发现人负责描述和证据的完整性，责任人负责整改措施和计划日期，验证人负责验证结论和关闭。登记表由项目质量负责人统一保管，每周检查一次超期未关闭记录。
- 定期复盘：按月度或阶段节点统计问题数量、严重程度分布和原因类别占比，把重复出现的原因反馈到交底、检查和标准修订中。复盘后如需调整字段，保留旧记录的原始写法，在新记录中启用新口径。
- 版本管理：登记表模板本身标注版本号和生效日期，修改字段时记录修改原因，避免不同阶段记录无法合并统计。
当项目从表格工具迁移到项目管理系统时，登记表可以作为工作项批量导入，编号、描述、责任人、状态等字段对应到工作项属性，整改证据和验证记录通过附件与文档留存。ONES 支持文档关联项目任务，页面树可组织项目文档与知识信息；ONES Wiki 提供页面模板库，可一键创建制式化文档模板，并记录页面版本、支持查看与回滚，适合把填表说明和模板固定在项目知识空间中。对于采用瀑布方式管理的项目，ONES 瀑布项目管理解决方案支持设置计划和里程碑基线、对比计划与执行偏差，并提供多维度数据统计，便于把不符合项的关闭情况纳入阶段评审。具体可用范围以实际开通版本为准。
常见问题
小项目字段太多填不过来，最少保留哪些列？
可以先保留必填字段：编号、项目名称、发现日期、发现人、不符合对象、标准要求、实际状况、严重程度、责任人、整改措施、验证结论、关闭状态。这十二项能支撑一条记录被识别、分派和关闭。位置/批次、发现环节、发现方、处理方、所需资源、复发预防等选填字段，在小项目中可以合并或暂时省略，例如把发现方和处理方合并为一列“相关方”。裁剪后要在填表说明中写清合并列的填写格式，避免不同人写法不一致。
问题整改后又复发，登记表上怎么记录？
建议新开一条记录，在编号上与原记录区分，并在“复发预防”或备注中注明与原记录的关联编号。原记录保持已关闭状态，不直接改写历史内容，这样统计时能看出同类问题出现的频次。新记录的原因分析要重点写清上次整改为何未覆盖该情形，整改措施相应补充到流程、交底或检查频次上。如果项目使用项目管理系统承载记录，可通过关联工作项或文档引用把两条记录连起来，便于复盘时追溯。
验证不通过时，关闭状态和日期怎么处理？
验证结论填“不通过”，关闭状态回到“整改中”，不填写关闭日期。同时在验证结论或补充说明中写清不通过的具体原因和需要补充的动作，责任人据此更新整改措施和计划完成日期。原计划完成日期保留，延期另记新日期和原因，便于统计超期情况。只有验证结论为“通过”或“有条件通过”且条件已落实时，才把关闭状态改为“已关闭”。
登记表用表格工具维护，什么时候适合迁到项目管理系统？
当不符合项数量增多、需要多人同时更新状态、或者要把整改任务与项目计划关联时，表格工具容易出现版本分散和状态不同步。此时可以考虑迁到项目管理系统，把每条记录作为工作项承载，编号、描述、责任人、状态对应到工作项属性，证据和验证记录通过附件与文档留存。ONES 支持文档关联项目任务，ONES Wiki 提供页面模板库，可一键创建制式化文档模板并记录页面版本、支持查看与回滚，适合把填表说明和模板固定在项目知识空间中；ONES 瀑布项目管理解决方案支持设置计划和里程碑基线、对比计划与执行偏差，便于把不符合项关闭情况纳入阶段评审。具体可用范围以实际开通版本为准。
严重程度的分级标准由谁定，登记表里要写吗？
分级标准属于项目质量控制约定，通常由项目质量负责人牵头，在项目启动时与相关方确定，并写入填表说明。登记表的“严重程度”列只填等级值，如一般、较重、严重、重大，具体判定条件放在填表说明或单独的分级规则文档中，避免每行记录重复描述。分级标准确定后中途不随意增加同义等级；确需调整时，保留旧记录的原始写法，在新记录中启用新口径，并在模板版本记录中注明修改原因。
