项目质量检查表用于在项目推进过程中逐项核对交付物和工作过程是否符合既定标准，并把发现的问题记录到整改关闭。本文提供一张可直接复制到表格工具中的空白检查表，配套字段说明、必填与选填规则、一份完整填写示例，以及按项目类型裁剪和维护的方法，适用于单项目层面的质量控制。
要点总览（TL;DR）
- 空白模板分为表头信息、检查明细区、不符合项登记与关闭区三部分，复制到表格工具后按检查项增减行即可使用。
- 结果判定统一为“符合”“不符合”“不适用”三种取值；判定为不符合时，必须同步填写不符合项描述、整改责任人与整改期限。
- 必填字段保证记录可追溯：项目名称与编号、检查阶段与检查人、检查项与检查标准、检查对象、结果判定；证据位置在判定为符合时必填。
- 填写示例演示了一条不符合项从登记、整改到复核关闭的完整过程，明细区与登记区通过检查项序号关联。
- 裁剪检查表按项目阶段和交付物分组，保留必填字段，每次调整更新版本号并记录变更内容。
可复制空白模板：项目质量检查表
下表分为表头信息、检查明细区、不符合项登记与关闭区三部分。复制到 Excel、在线表格或文档表格中时，保留表头字段作为固定信息区，检查明细区按实际检查项数量增减行，不符合项登记区随检查结果同步填写。
表头信息
| 字段 | 填写内容 |
|---|---|
| 项目名称 | |
| 项目编号 | |
| 检查阶段 | |
| 检查人 | |
| 检查日期 | |
| 版本 |
检查明细区
| 序号 | 检查项 | 检查对象/交付物 | 检查标准 | 检查方式 | 责任人 | 检查时点 | 结果判定 | 证据位置 | 不符合项描述 | 整改责任人 | 整改期限 | 复核结论 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | ||||||||||||
| 2 | ||||||||||||
| 3 | ||||||||||||
| 4 | ||||||||||||
| 5 | ||||||||||||
| 6 | ||||||||||||
| 7 | ||||||||||||
| 8 | ||||||||||||
| 9 | ||||||||||||
| 10 |
空白行按检查项数量预留，一般阶段检查预留 10 至 20 行，交付物验收检查按交付物清单逐项展开。填写提示：结果判定只填“符合”“不符合”“不适用”三种取值；判定为“不符合”时，必须同步填写不符合项描述、整改责任人与整改期限；判定为“符合”时，证据位置应指向可核查的材料。
不符合项登记与关闭区
| 不符合项编号 | 对应检查项序号 | 问题描述 | 影响程度 | 整改措施 | 整改责任人 | 整改期限 | 复核人 | 复核日期 | 复核结论 |
|---|---|---|---|---|---|---|---|---|---|
| NC-01 | |||||||||
| NC-02 | |||||||||
| NC-03 |
不符合项编号与检查明细区的序号建立对应关系，便于回溯。复核结论填写“关闭”“继续整改”或“转风险跟踪”，关闭时需注明复核依据。
字段说明：每个字段填什么、怎么判定
同一张检查表可能由项目经理、质量负责人、技术负责人分别填写，字段口径不统一会导致判定结果无法比较。下表逐字段说明含义与填写口径，示例值可直接参照。
| 字段 | 含义 | 填写口径 | 示例值 |
|---|---|---|---|
| 检查项 | 本次要核对的具体质量要求 | 一条只写一个可判定的要求，用动宾结构描述，避免“质量良好”这类无法判定的表述 | 接口文档包含全部字段说明与错误码 |
| 检查对象/交付物 | 检查项对应的具体材料或工作产物 | 写明交付物名称与版本，便于定位 | 《订单服务接口文档》V1.2 |
| 检查标准 | 判定符合与否的依据 | 引用规范条款、验收标准或模板要求，标准应可观察、可核对 | 字段说明覆盖率 100%，错误码与接口实现一致 |
| 检查方式 | 获取判定证据的手段 | 常用取值：文档评审、演示、抽样核对、现场查看、系统查询 | 文档评审 |
| 责任人 | 对该检查项质量负责的人 | 填写交付物负责人，而非检查人 | 后端负责人 张某 |
| 检查时点 | 该检查项应被检查的时间节点 | 写阶段节点或具体日期，与项目计划对应 | 开发完成、提测前 |
| 结果判定 | 检查结论 | 只填“符合”“不符合”“不适用”；“不适用”需在不符合项描述栏注明原因 | 不符合 |
| 证据位置 | 支撑判定结论的材料所在位置 | 指向可核查的具体位置，如文档章节、评审记录编号、系统截图存放路径 | 接口文档第 3 章；评审记录 RV-018 |
| 不符合项描述 | 不符合标准的具体事实 | 写清缺什么、差在哪、影响范围，不写评价性语言 | 缺少 4 个错误码说明，与接口实现不一致 |
| 整改责任人 | 负责完成整改的人 | 与不符合项描述对应，一人一项 | 后端负责人 张某 |
| 整改期限 | 整改完成的时间要求 | 写具体日期，与项目后续节点不冲突 | 2025-06-20 |
| 复核结论 | 整改后的复核结果 | 填“关闭”“继续整改”或“转风险跟踪”，关闭需注明复核依据 | 关闭，已补充错误码并完成二次评审 |
判定规则有三条需要统一：检查标准在检查前确定，检查过程中不临时放宽；判定为“不符合”时必须有证据位置支撑，避免凭印象判定；“不适用”只用于检查项与当前项目范围确实无关的情形，并在描述栏写明原因，便于后续裁剪时参考。
必填与选填：哪些字段不能空
必填字段保证检查记录可追溯、可复核；选填字段根据项目规模和风险等级取舍。裁剪检查项时，必填字段应完整保留。
| 字段 | 必填/选填 | 理由与适用情形 |
|---|---|---|
| 项目名称、项目编号 | 必填 | 定位检查记录归属，归档与检索依赖此信息 |
| 检查阶段、检查人、检查日期、版本 | 必填 | 确定检查的时间范围与责任人，版本用于区分多次检查 |
| 序号、检查项、检查标准 | 必填 | 构成检查表的主体，缺项则无法判定 |
| 检查对象/交付物 | 必填 | 明确检查针对的材料，避免结论悬空 |
| 结果判定 | 必填 | 每条检查项都应有结论 |
| 证据位置 | 判定为“符合”时必填 | 支撑结论可核查；判定为“不适用”时可注明原因代替 |
| 不符合项描述、整改责任人、整改期限 | 判定为“不符合”时必填 | 形成整改闭环的前提 |
| 复核结论 | 整改完成后必填 | 关闭不符合项的依据 |
| 检查方式 | 选填 | 检查方式较统一的项目可省略；多方交叉检查时建议填写 |
| 责任人、检查时点 | 选填 | 检查项已纳入项目计划并明确责任时，可在计划中体现，表中省略 |
| 影响程度 | 选填 | 不符合项较多、需要排优先级时填写 |
必填字段缺失时的处理规则：检查人当场补齐；无法补齐的，该检查项判定暂不生效，在复核结论栏标注“待补”，并在检查结束后一个工作日内补录。整改责任人或整改期限缺失的不符合项，视为未完成登记，不能进入关闭流程。
填写示例：一个阶段检查表的完整填法
以下示例为某订单系统项目在“开发完成、提测前”阶段的质量检查记录，演示字段之间的对应关系，以及一条不符合项从登记到复核关闭的完整过程。示例为演示情景，项目信息为虚构。
表头与检查明细
| 序号 | 检查项 | 检查对象/交付物 | 检查标准 | 检查方式 | 责任人 | 检查时点 | 结果判定 | 证据位置 | 不符合项描述 | 整改责任人 | 整改期限 | 复核结论 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 接口文档包含全部字段说明与错误码 | 《订单服务接口文档》V1.2 | 字段说明覆盖率 100%，错误码与接口实现一致 | 文档评审 | 后端负责人 张某 | 提测前 | 不符合 | 接口文档第 3 章；评审记录 RV-018 | 缺少 4 个错误码说明，与接口实现不一致 | 后端负责人 张某 | 2025-06-20 | 关闭，已补充错误码并完成二次评审 |
| 2 | 核心流程演示通过 | 订单创建与支付流程 | 主流程无阻断性缺陷 | 演示 | 测试负责人 李某 | 提测前 | 符合 | 演示记录 DM-006 | — | — | — | — |
| 3 | 数据库变更脚本经评审 | 《订单表结构变更脚本》 | 脚本有评审记录，回滚方案完整 | 文档评审 | DBA 王某 | 提测前 | 符合 | 评审记录 RV-021 | — | — | — | — |
| 4 | 性能压测报告覆盖峰值场景 | 《订单服务压测报告》 | 覆盖峰值流量，结论明确 | 抽样核对 | 性能负责人 赵某 | 提测前 | 不适用 | — | 本期不涉及峰值场景，压测安排在下一阶段 | — | — | — |
不符合项登记与关闭记录
| 不符合项编号 | 对应检查项序号 | 问题描述 | 影响程度 | 整改措施 | 整改责任人 | 整改期限 | 复核人 | 复核日期 | 复核结论 |
|---|---|---|---|---|---|---|---|---|---|
| NC-01 | 1 | 接口文档缺少 4 个错误码说明，与接口实现不一致 | 中 | 补充错误码说明，同步更新接口文档至 V1.3，组织二次评审 | 后端负责人 张某 | 2025-06-20 | 质量负责人 陈某 | 2025-06-19 | 关闭，已补充错误码并完成二次评审 |
逐项解释：第 1 项判定为“不符合”，因此不符合项描述、整改责任人与整改期限三栏同时填写，并在登记区生成 NC-01，通过“对应检查项序号”与明细区第 1 行关联；整改完成后，复核人依据二次评审记录确认关闭，明细区的复核结论与登记区保持一致。第 2、3 项判定为“符合”，证据位置指向评审或演示记录编号。第 4 项判定为“不适用”，在不符合项描述栏写明原因，整改相关字段留空，后续裁剪检查表时可据此判断该检查项是否保留。
调整与维护：按项目类型裁剪检查表
通用模板直接套用到所有项目会产生大量无关检查项，降低检查效率。裁剪的目标是保留与项目风险相关的检查项，同时保证必填字段完整、版本可追溯。
裁剪检查项的方法
- 按项目阶段分组：将检查项归入需求、设计、开发、提测、上线等阶段，每个阶段单独形成一张检查表，避免一张表跨阶段填写。
- 按交付物补充：在阶段分组基础上，为关键交付物（如接口文档、测试报告、上线方案）增加专项检查项。
- 按风险等级取舍：高风险项目保留全部检查项；规模较小、风险可控的项目可删减检查方式、责任人等选填字段，必填字段不删。
- 裁剪结果评审：裁剪后的检查表由项目经理与质量负责人确认，确认后作为该项目或该类项目的基准版本。
版本与变更记录
检查表每次调整都应更新版本号，并在表头下方或单独页面记录变更内容、变更人、变更日期和变更原因。同一项目多次检查时，各次记录保留各自版本号，便于对比不同阶段的检查口径。
检查结果的流转与归档
检查完成后，检查表随项目文档归档；不符合项转入整改跟踪，整改完成后回填复核结论；阶段结束时汇总本阶段检查项数量、不符合项数量与关闭情况，作为阶段评审的输入材料。
在项目协作工具中承载检查表与整改任务
当检查项数量较多、整改需要多人跟进时，可以把检查表从静态表格迁移到项目协作工具中。ONES Wiki 支持文档关联项目任务，页面树可组织项目文档与知识信息；其页面模板库支持一键创建制式化文档模板，检查表可作为模板沉淀，供同类项目复用；文档记录所有页面版本并支持查看与回滚，便于保留检查表的历次版本。检查项与整改任务可通过 ONES 的项目、任务场景承载，使文档记录与整改工作保持关联。对于采用瀑布方式管理的项目，ONES 瀑布项目管理方案支持用项目计划创建工作分解结构，按阶段或交付物分解工作，并可设置计划与里程碑基线、对比计划与执行的偏差，便于把检查时点与项目节点对齐。具体字段映射与流转配置以实际产品环境为准。
常见问题
检查表里的“不适用”和“不符合”怎么区分，填错了会有什么影响？
“不符合”表示检查项适用于当前项目，但实际结果未达到检查标准；“不适用”表示该检查项与当前项目范围确实无关，例如本期不涉及某项性能场景。两者填错会直接影响后续统计：把无关项判成“不符合”会虚增整改工作量，把未达标项判成“不适用”则会漏掉整改。
填写“不适用”时，在不符合项描述栏写明原因，整改相关字段留空；裁剪检查表时可以据此判断该检查项是否保留。
检查时发现的问题当场改好了，还需要登记不符合项吗？
建议登记。当场整改的问题同样在明细区判定为“不符合”，填写问题描述与整改措施，复核结论注明“关闭”及复核依据，例如“已现场修正并确认”。保留这条记录的价值在于：阶段汇总时能反映真实的问题数量，后续复盘也能看到该类问题是否反复出现。
如果问题轻微且不影响判定结论，也可以在不符合项描述栏简要记录处理方式，但结果判定仍应如实填写。
多个检查人分别填写同一张表，怎么保证判定口径一致？
关键在于检查前把检查标准写清楚，并统一判定取值。检查标准应引用规范条款、验收标准或模板要求，写成可观察、可核对的条件，避免“质量良好”这类无法判定的表述。判定取值只允许“符合”“不符合”“不适用”三种，不允许自行增加“基本符合”等中间状态。
检查前可以组织一次简短的口径对齐，由质量负责人说明判定规则和证据要求；检查后由复核人抽查判定与证据是否对应。
检查表需要随项目文档一起归档吗，保存多久合适？
需要归档。检查表是阶段评审和项目复盘的输入材料，归档时应与对应的评审记录、演示记录等证据材料放在一起，便于回溯。保存期限可按项目所属行业的合规要求和组织文档管理制度确定；没有明确要求时，至少保留到项目验收后一个完整的审计周期。
归档时保留各次检查的版本号，同一项目多次检查的记录分别保存，便于对比不同阶段的检查口径和问题分布。
检查项很多时，用表格逐条填还是放到项目协作工具里更合适？
取决于检查频次和整改跟进人数。单次检查、检查项在二三十条以内，用表格工具填写和归档更直接；检查项多、整改涉及多人、需要持续跟踪关闭状态时，放到项目协作工具中更便于跟进。
在 ONES 中，检查表可以作为文档模板沉淀在 Wiki 页面模板库，供同类项目复用，文档版本支持查看与回滚；检查项与整改任务可通过项目、任务场景承载，使文档记录与整改工作保持关联。具体字段映射与流转配置以实际产品环境为准。
