验收检查清单模板通常分成三块：检查项目、通过情况记录和遗留问题台账。检查项目覆盖范围、交付物、质量、文档、合同与商务、移交与收尾；通过情况用“通过/有条件通过/不通过”三档加证据记录；遗留问题单列台账，写明等级、责任人、计划完成时间和关闭条件。本文面向项目整体生命周期结束或转换时的验收，单次软件交付的测试与追溯不在本文展开。
要点总览（TL;DR）
- 验收检查清单模板由三块组成：检查项与通过情况记录表、遗留问题台账、验收结论汇总区，三块共用编号体系便于对应。
- 检查项按范围与目标、交付物与质量、文档与知识移交、合同与商务、资源释放与收尾五类组织，按项目类型增减条目。
- 通过情况用“通过/有条件通过/不通过”三档加“不适用”记录，每条结论附可定位证据，检查人与复核人分开签字。
- 遗留问题单列台账，写明等级、责任人、计划完成时间和可验证的关闭条件；高等级问题通常阻止放行，中低等级可约定在运营期跟踪。
- 模板按项目类型裁剪，验收后一周内回顾条目，用重复出现的遗留问题反哺检查项，并保留版本与变更记录。
可复制空白验收检查清单模板
下面两张表加一个汇总区构成模板主体。第一张表记录检查项与通过情况，第二张表登记遗留问题，汇总区给出总体结论和放行条件。使用时把空白单元格填满，不适用的检查项在“结论”列标注“不适用”并说明原因，不要直接删除行，保留裁剪痕迹便于复盘。
表一：检查项与通过情况记录表
| 编号 | 检查项 | 验收标准 | 结论 | 证据 | 检查人 | 日期 |
|---|---|---|---|---|---|---|
| 1.1 | ||||||
| 1.2 | ||||||
| 2.1 | ||||||
| 2.2 | ||||||
| 3.1 | ||||||
| 4.1 | ||||||
| 5.1 |
编号建议按检查类目分段，例如1.x对应范围与目标、2.x对应交付物与质量、3.x对应文档与移交、4.x对应合同与商务、5.x对应资源释放与收尾。这样遗留问题台账引用编号时能直接定位到类目。
表二：遗留问题台账
| 编号 | 关联检查项 | 问题描述 | 等级 | 责任人 | 计划完成时间 | 关闭条件 | 状态 |
|---|---|---|---|---|---|---|---|
| L-01 | |||||||
| L-02 | |||||||
| L-03 |
验收结论汇总区
| 汇总项 | 填写内容 |
|---|---|
| 总体结论 | 通过 / 有条件通过 / 不通过 |
| 检查项总数与结论分布 | 共__项，通过__项，有条件通过__项，不通过__项，不适用__项 |
| 遗留问题数量 | 高__项，中__项，低__项 |
| 放行条件 | 写明哪些遗留问题必须在移交前关闭，哪些可带入运营期跟踪 |
| 验收组织人签字与日期 | |
| 接收方确认签字与日期 |
检查项目分几类、每类放什么
检查项按验收对象分类，比按部门分类更容易裁剪。项目类型不同，类目可以增减，但范围、交付物、文档、合同、收尾这五类基本覆盖整体验收的主要判断面。下表给出每类的典型条目，实际使用时按项目规模保留必要项。
| 类目 | 典型检查条目 | 常见证据 |
|---|---|---|
| 范围与目标达成 | 合同或立项文件约定的范围是否全部交付；目标指标是否达成；范围变更是否均已审批并留痕 | 立项文件、变更单、指标对比表 |
| 交付物与质量 | 交付物清单是否齐全；抽检或评审结论是否达标；缺陷收敛情况是否满足约定 | 交付物清单、评审记录、质量报告 |
| 文档与知识移交 | 操作手册、维护文档、配置说明是否齐全；接收方培训是否完成；关键知识是否完成交接 | 文档目录、培训签到、交接记录 |
| 合同、商务与付款 | 合同条款履行情况；结算金额与付款节点是否确认；发票与验收单据是否齐备 | 合同、结算单、付款凭证 |
| 资源释放与收尾 | 人员与设备是否释放；账号权限是否回收或转移；环境与资产是否完成交接或下线 | 资源清单、权限回收记录、资产交接单 |
条目措辞要写成可判断的陈述，避免“文档较完整”这类模糊表述，改为“维护手册覆盖全部模块，且接收方确认可独立操作”。单次软件交付的功能测试、缺陷追溯属于交付验收主题，本文只在整体收尾层面检查其结论是否已归档、遗留缺陷是否已转入台账。
通过情况怎么记：结论档位与证据要求
每条检查项的结论只允许三个档位，外加“不适用”。档位定义统一，复核人才能快速判断结论是否成立。三档的使用条件如下表。
| 结论档位 | 使用条件 | 对总体结论的影响 |
|---|---|---|
| 通过 | 验收标准全部满足，证据可查 | 计入通过项 |
| 有条件通过 | 主要标准满足，存在不影响核心使用的缺口，且缺口已登记为遗留问题并约定完成时间 | 需在汇总区列明附加条件 |
| 不通过 | 关键标准未满足，或证据缺失无法判断 | 通常阻止放行，需整改后复验 |
| 不适用 | 该类目或条目对本项目不成立，需写明原因 | 不计入通过率分母 |
证据是结论成立的前提。每条结论至少附一项可定位的证据：文档名称与章节、系统截图、签字记录、测试结果链接或会议纪要编号。证据写在“证据”列，指向具体位置而非笼统写“见文档”。检查人与复核人分开设置：检查人负责填写结论和证据，复核人抽查证据是否支撑结论，两人签字后才计入汇总。有条件通过的附加条件要写进清单本身，例如“L-02关闭并经复核后，本项转为通过”，避免条件只停留在口头。
遗留问题怎么记：台账字段与关闭条件
遗留问题是验收结论的一部分，不能混进“通过”里一笔带过。台账的必填字段包括：编号、关联检查项、问题描述、等级、责任人、计划完成时间、关闭条件、状态。选填字段包括：发现日期、影响范围、复验人、实际关闭日期、备注。问题描述写清现象和影响，例如“某报表导出缺少权限校验，接收方无法自助导出”，不写“报表有问题”。
等级建议分高、中、低三档，并与验收结论挂钩：高等级问题通常阻止放行，须在移交前关闭；中等级问题可有条件放行，约定在运营期首个周期内关闭；低等级问题可带入常规跟踪。等级划分标准在模板中固定下来，避免每次验收临时争论。关闭条件要可验证，写明“复验方式+通过标准”，例如“接收方按手册完成一次导出操作并签字确认”。状态建议使用“待处理、处理中、待复验、已关闭、已取消”五个值，取消需注明原因。
遗留问题与检查项通过“关联检查项”编号建立对应关系，一个问题可以关联多个检查项，一个检查项也可以对应多条遗留问题。汇总区按等级统计数量，并明确放行条件。当检查项状态和遗留问题需要在多个角色间流转时，可以把检查项建成工作项、把台账放在与项目关联的文档页面中：ONES Wiki 支持页面组关联项目、文档关联项目任务，检查结论与遗留问题能在同一项目上下文中被查阅；文档支持嵌入任务进度和报表，汇总区的统计可以直接引用工作项数据，减少手工誊抄。模板本身可通过页面模板库一键创建，版本记录支持查看与回滚，便于模板随复盘迭代。
完整填写示例
以下为演示情景，用于说明字段如何对应，数据不代表真实项目。背景：某内部系统建设项目进入整体收尾验收，验收范围包括交付物、文档移交、合同结算和资源释放，共设8个检查项。
| 编号 | 检查项 | 验收标准 | 结论 | 证据 | 检查人 | 日期 |
|---|---|---|---|---|---|---|
| 1.1 | 范围变更审批 | 全部变更均有审批记录 | 通过 | 变更单CR-03至CR-07 | 张工 | 6月10日 |
| 2.1 | 交付物清单齐全 | 清单内12项交付物全部到位 | 通过 | 交付物清单v2.0 | 张工 | 6月10日 |
| 3.1 | 维护手册移交 | 覆盖全部模块，接收方可独立操作 | 有条件通过 | 手册v1.2；培训签到表 | 李工 | 6月11日 |
| 4.1 | 结算金额确认 | 双方确认结算金额与付款节点 | 不通过 | 结算单待财务复核 | 王工 | 6月11日 |
| 5.1 | 账号权限回收 | 项目临时账号全部停用 | 通过 | 权限回收记录 | 李工 | 6月12日 |
| 编号 | 关联检查项 | 问题描述 | 等级 | 责任人 | 计划完成时间 | 关闭条件 | 状态 |
|---|---|---|---|---|---|---|---|
| L-01 | 3.1 | 手册缺少报表模块的异常处理章节，接收方遇到报错时无法自助排查 | 中 | 李工 | 6月25日 | 补充章节并经接收方按场景复验签字 | 处理中 |
| L-02 | 4.1 | 结算单缺少财务复核意见，付款节点无法确认 | 高 | 王工 | 6月18日 | 财务复核通过并出具确认单 | 待处理 |
结论汇总区填写为：总体结论“有条件通过”；检查项共8项，通过5项，有条件通过1项，不通过1项，不适用1项；遗留问题高1项、中1项、低0项；放行条件为“L-02须在移交前关闭，L-01可在运营期首月内关闭并复验”。这样，不通过项与高等级遗留问题形成对应，接收方清楚知道放行前必须完成什么。
模板的裁剪与维护方法
模板要能长期使用，需要按项目类型裁剪条目，并把每次验收暴露的问题反哺回模板。可按下面的操作清单执行。
- 按项目类型增减类目：纯内部交付可弱化合同商务类，涉及外部供应商的项目保留并细化付款与验收单据条目；运维交接类项目加强文档与权限回收条目。
- 条目措辞维护：每条验收标准写成可判断的陈述，出现“基本”“较好”等词时改为具体数量、范围或签字确认动作。
- 模板版本与变更记录：在模板首页记录版本号、修订日期、修订人和变更说明，旧版本归档保留，便于追溯某次验收使用的是哪一版。
- 用历史遗留问题反哺检查项：复盘时统计遗留问题集中的类目，若同类问题重复出现，说明对应检查项的验收标准不够具体，应补充检查点或提高标准。
- 定期清理不适用项：连续多个项目标注“不适用”的条目，评估是否移出主模板，放入可选条目库。
模板维护的责任人建议由验收组织方固定，每次验收结束后一周内完成一次条目回顾。模板文件本身可放在与项目关联的文档页面中，借助版本记录保留每次修订，检查项与遗留问题台账在同一页面树内维护，下一项目复用时直接复制页面即可。
常见问题
检查项结论填了“有条件通过”，放行前还需要做什么？
有条件通过意味着主要标准已满足，但存在不影响核心使用的缺口。放行前需要确认两件事：缺口已在遗留问题台账中登记，且写明了责任人和计划完成时间；附加条件已写入清单或汇总区，例如“L-02关闭并经复核后本项转为通过”。如果附加条件无法在移交前落实，应重新评估是否降为不通过。
遗留问题等级由谁定，出现分歧怎么办？
等级划分标准应在模板中预先固定，验收时按标准对号入座，减少临时争论。常见做法是由检查人初判、验收组织人复核，接收方对影响其使用的等级有异议时，以“是否影响核心使用、是否有替代方案”作为判断依据。等级调整需在台账备注中记录原因，保持可追溯。
遗留问题关闭后，检查项结论要不要同步修改？
要改。遗留问题关闭并复验通过后，应回到检查项记录表，把对应条目的结论从“有条件通过”更新为“通过”，并在证据列补充复验记录。汇总区的结论分布和遗留问题数量同步更新，确保汇总数据与明细一致。若问题关闭发生在项目移交之后，可在运营期跟踪记录中注明，不必回改已归档的验收结论。
小项目条目少，还需要保留完整的五类检查项吗？
可以精简，但建议保留类目框架。纯内部交付的小项目可弱化合同与商务类，保留范围、交付物、文档移交和资源收尾四类；涉及外部供应商或资产交接的项目，则应保留并细化对应条目。连续多个项目都标注“不适用”的条目，可移入可选条目库，主模板保持精简。
检查项和遗留问题台账放在哪里，方便多方查阅和流转？
常见做法是把检查项建成工作项、把台账放在与项目关联的文档页面中，让结论、证据和遗留问题在同一项目上下文中被查阅。ONES Wiki 支持页面组关联项目、文档关联项目任务，文档可嵌入任务进度和报表，汇总区统计可直接引用工作项数据；模板可通过页面模板库一键创建，版本记录支持查看与回滚。具体功能以实际开通的产品版本为准。
