项目交付物检查清单的核心是一张能直接填写的表：横向记录“检查项—检查内容—判定标准—结果—证据—责任人—日期”，纵向按交付物类型分组。检查项通常覆盖完整性、格式规范、内容准确性、评审与审批、版本与归档五类，结果按“通过／有条件通过／不通过”判定，并用问题描述和整改状态形成闭环。以下模板适用于单个项目的交付物检查，可按交付物类型增删条目。
要点总览（TL;DR）
- 清单横向记录“检查项—检查内容—判定标准—结果—证据—责任人—日期”，纵向按交付物类型分组，可直接复制到文档或表格工具使用。
- 检查项覆盖完整性、格式与规范、内容准确性、评审与审批、版本与归档五类，每类给出典型条目，按项目实际增删。
- 结果按“通过／有条件通过／不通过”三档判定，未通过项必须填写问题描述和整改状态，形成整改闭环。
- 检查项、检查内容、判定标准、结果、责任人、日期为必填字段；证据建议必填，序号、交付物类型、复核人可按项目规模选填。
- 清单本身带版本号并与检查记录一并归档，交付物多、整改需跨人跟进时可把检查项录入协作工具跟踪。
可复制空白检查清单模板
下表可直接复制到文档或表格工具中使用。每个交付物类型占一个分组，组内逐条列出检查项；同一交付物只需填写一次表头中的项目名称、交付物名称、检查人和检查日期，组内各行共享这些信息。整改记录列用于记录未通过项的处理情况。
| 项目名称 | 交付物名称 | 交付物类型 | 检查人 | 检查日期 |
|---|---|---|---|---|
| 序号 | 检查项 | 检查内容 | 判定标准 | 结果 | 证据 | 责任人 | 日期 | 问题描述 | 整改状态 |
|---|---|---|---|---|---|---|---|---|---|
| 分组一：需求文档类 | |||||||||
| 1 | |||||||||
| 2 | |||||||||
| 分组二：设计文档类 | |||||||||
| 3 | |||||||||
| 分组三：代码与构建产物类 | |||||||||
| 4 | |||||||||
| 分组四：测试与验收材料类 | |||||||||
| 5 | |||||||||
| 分组五：交付与运维文档类 | |||||||||
| 6 | |||||||||
填写时先确定本次检查涉及的交付物类型，保留对应分组、删除无关分组，再在组内补充具体检查项。表格底部的汇总区用于记录整体判定和遗留问题数量，便于交接和归档。
| 整体判定 | 通过项数 | 有条件通过项数 | 不通过项数 | 遗留问题数 | 检查结论说明 |
|---|---|---|---|---|---|
检查项怎么分类：五类检查项与典型条目
检查项按“这份交付物是否可被接收和使用”这一目标分类，五类分别回答不同问题：东西齐不齐、形式合不合规、内容对不对、有没有经过该有的确认、后续能不能找到和追溯。分类的作用是让检查不漏项，也方便不同交付物复用同一套骨架。
完整性检查
确认交付物包含约定范围内的全部内容，没有缺章、缺附件、缺签字页。典型条目：交付物清单中列出的文件是否全部提交；文档目录与实际章节是否一致；必填附件（如审批单、测试报告）是否齐全；交付范围说明是否覆盖本期全部需求条目。
格式与规范检查
确认交付物符合团队或客户约定的模板、命名和排版要求。典型条目：是否使用指定模板；文件命名是否符合“项目代号_交付物名称_版本号_日期”规则；图表编号与引用是否连续；术语和单位是否统一。
内容准确性检查
确认交付物中的事实、数据和结论经得起核对。典型条目：需求描述与业务确认记录是否一致；关键数据是否有来源或计算过程；接口定义与联调结果是否吻合；文档中的交叉引用是否指向正确章节。
评审与审批检查
确认交付物经过了规定的评审和审批动作，意见已处理。典型条目：是否完成规定层级的评审；评审意见是否逐条回复并关闭；审批人签字或电子确认是否齐全；评审记录是否随交付物一并保存。
版本与归档检查
确认交付物的版本状态清晰、可追溯、已进入规定存放位置。典型条目：版本号是否与变更记录对应；是否为最终确认版本而非草稿；是否已上传至指定归档目录；历史版本是否保留并可查。
记录字段说明：每个字段填什么、怎么判定
记录字段的设计目标是让检查结果可复核、可追责、可整改。每个字段填写口径统一，换人检查时结论才具有可比性。下表逐字段说明含义与填写方式。
| 字段 | 填写内容 | 填写口径 |
|---|---|---|
| 检查项 | 简短名称，如“附件齐全” | 一条只对应一个可判定的检查点，避免一条包含多个要求 |
| 检查内容 | 具体查什么，如“核对交付物清单与实物文件” | 写清核对对象和动作，让未参与项目的人也能照做 |
| 判定标准 | 达到什么条件算通过 | 用可观察的事实描述，如“清单所列12份文件全部存在”，避免“基本完整”这类模糊表述 |
| 结果 | 通过／有条件通过／不通过 | 完全满足判定标准记“通过”；存在不影响接收的轻微问题、限期修正后可用记“有条件通过”；关键要求缺失或错误记“不通过” |
| 证据 | 支撑判定的材料位置或编号 | 填写文件路径、评审记录编号、截图编号等可回查的信息，不写“已确认”这类无指向内容 |
| 责任人 | 对该检查项结果负责的人 | 填写交付物作者或整改执行人，便于后续跟进 |
| 日期 | 检查完成日期 | 填写实际检查当天日期，整改完成后另记整改完成日期 |
| 问题描述 | 未通过或有条件通过时的具体问题 | 写清缺什么、错在哪、影响是什么，与判定标准对应 |
| 整改状态 | 待整改／整改中／已关闭／无需整改 | “通过”项填“无需整改”；其余项在问题解决并复核后改为“已关闭” |
结果判定建议由检查人初判、交付物负责人确认，出现分歧时以判定标准为准。整体判定取组内最严结果：任一项“不通过”，整体不得判为“通过”；仅有“有条件通过”项时，整体可判“有条件通过”，并注明修正期限。
必填与选填字段的划分
字段全部填写会让小项目负担过重，字段过少又会导致记录无法追溯。划分原则是：支撑判定和整改闭环的字段必填，辅助定位和统计的字段按项目情况选填。
| 字段 | 建议属性 | 理由或适用场景 |
|---|---|---|
| 检查项、检查内容、判定标准 | 必填 | 构成检查的基本单元，缺失则无法执行和复核 |
| 结果 | 必填 | 判定结论的唯一载体 |
| 责任人、日期 | 必填 | 支撑追责和时效判断 |
| 问题描述、整改状态 | 未通过或有条件通过时必填 | 形成整改闭环；全部通过时可留空 |
| 证据 | 建议必填 | 关键交付物（如验收报告、对外提交物）应填写；内部草稿类可简化为文件位置 |
| 序号、交付物类型 | 选填 | 条目多或跨类型汇总时填写，便于排序和统计 |
| 检查人所属角色、复核人 | 选填 | 需要独立复核或审计留痕的项目填写 |
按项目规模裁剪时，小型项目可只保留必填字段加证据位置，检查项控制在每类2至3条；中大型项目或对外交付项目建议补齐复核人和整改完成日期，并对关键交付物逐项留存证据。裁剪只减少字段和条目数量，不取消“结果—问题—整改”这条链路。
填写示例：一份完整的交付物检查记录
以下示例为演示情景：某项目向客户提交《系统接口设计说明书》V1.2，检查人按模板完成检查。示例用于展示字段如何配合，数值和结论均为示意。
| 序号 | 检查项 | 检查内容 | 判定标准 | 结果 | 证据 | 责任人 | 日期 | 问题描述 | 整改状态 |
|---|---|---|---|---|---|---|---|---|---|
| 1 | 章节完整 | 核对目录与正文，确认约定章节全部存在 | 8个约定章节齐全，无空章 | 通过 | 文档目录页 | 张工 | 6月3日 | — | 无需整改 |
| 2 | 附件齐全 | 核对接口清单附件与正文引用 | 正文引用的3份附件全部随附 | 有条件通过 | 附件目录 | 张工 | 6月3日 | 附件2为旧版字段表，与正文不一致 | 整改中 |
| 3 | 命名规范 | 检查文件名格式 | 符合“项目代号_名称_版本_日期”规则 | 通过 | 文件属性 | 张工 | 6月3日 | — | 无需整改 |
| 4 | 数据一致 | 抽查接口字段与联调记录 | 抽查10个接口，字段定义与联调记录一致 | 不通过 | 联调记录第4节 | 李工 | 6月3日 | 2个接口的返回码定义与联调结果不符 | 待整改 |
| 5 | 评审关闭 | 核对评审意见处理记录 | 评审意见全部回复并关闭 | 通过 | 评审记录R-021 | 王工 | 6月3日 | — | 无需整改 |
| 6 | 版本归档 | 确认最终版已上传归档目录 | 归档目录存在V1.2且标记为最终版 | 通过 | 归档目录路径 | 张工 | 6月3日 | — | 无需整改 |
该示例的整体判定为“不通过”：第4项关键内容错误，须修正后重新检查；第2项为有条件通过，需在提交前替换附件。整改完成后，将第2、4项的整改状态更新为“已关闭”，并补记整改完成日期，再由检查人复核签字。示例中每个“不通过”和“有条件通过”项都对应了问题描述和整改状态，与字段说明中的判定口径一致。
清单的调整与维护方法
清单的价值在于长期复用，需要随交付物类型和项目反馈持续更新，同时保留版本记录，避免不同项目使用不同口径却无从比较。
按交付物类型增删检查项
新增交付物类型时，从五类中各取1至2条通用条目作为骨架，再补充该类型特有的检查点，例如部署手册增加“回滚步骤可执行”条目。某类条目连续多个项目从未触发问题时，可合并或降为选填，但删除前应确认不是检查遗漏造成的。
判定标准的更新时机
出现以下情况时应修订判定标准：评审中多次对同一检查项结论产生分歧；客户或合规要求发生变化；因标准模糊导致整改返工。修订时记录变更原因和生效日期，旧版本清单保留备查。
清单版本与归档
建议清单本身带版本号，与项目交付物检查记录一并归档。每个项目的检查记录注明所用清单版本，便于后续追溯判定依据。项目结束后，将本项目的增删条目和典型问题汇总，作为下一版清单的输入。
在协作工具中承载清单与整改流转
当项目交付物较多、整改需要跨人跟进时，可以把检查项作为工作项录入协作工具，将结果、责任人、整改状态作为字段维护，未通过项直接转为整改任务并设定截止日期。ONES 的项目计划支持按交付物维度分解工作，并可设置里程碑基线对比计划与执行偏差，适合把交付物检查节点纳入项目计划统一跟踪；检查产生的整改任务与交付物状态在同一处更新，交接和归档时便于回查。是否采用工具承载，取决于交付物数量和参与人数，条目少、周期短的项目用表格即可满足。
常见问题
检查项和判定标准写多细才算够用？
判定标准写到“换一个没参与项目的人也能照着核对并得出相同结论”即可。比如“清单所列12份文件全部存在”可以判定，“基本完整”无法判定。检查项一条只对应一个检查点，把“附件齐全且命名规范”拆成两条，结果才能分别记录和整改。条目过细会增加填写负担，可按交付物重要程度控制：对外提交物和验收材料逐项细化，内部草稿类保留关键条目即可。
整体判定为“有条件通过”时，交付物能不能先提交？
可以提交，但要在检查结论说明中写明修正期限和遗留问题数量，并把对应条目整改状态置为“整改中”。有条件通过适用于存在不影响接收的轻微问题、限期修正后即可使用的情况；如果关键要求缺失或内容错误，应判“不通过”，修正后重新检查。提交前建议由交付物负责人确认修正期限，避免问题在交接后失去跟进。
小项目也要填满所有字段吗？
不需要。小型项目可只保留检查项、检查内容、判定标准、结果、责任人、日期，再加一个证据位置，检查项每类控制在2至3条。序号、交付物类型、检查人所属角色、复核人属于选填，条目多或需要审计留痕时再补。裁剪只减少字段和条目数量，“结果—问题—整改”这条链路要保留，否则未通过项无法闭环。
检查记录和清单本身怎么归档，后续怎么追溯？
清单带版本号，每个项目的检查记录注明所用清单版本，两者一并归档。项目结束后把本项目的增删条目和典型问题汇总，作为下一版清单的输入。出现评审多次对同一检查项结论分歧、客户或合规要求变化、标准模糊导致返工等情况时修订判定标准，并记录变更原因和生效日期，旧版本保留备查。
交付物检查和测试执行是什么关系，清单里要不要放测试用例？
交付物检查关注“这份材料是否可被接收和使用”，测试执行属于测试管理范畴，本文清单不展开用例设计与执行过程。清单中可以保留“测试报告是否随附”“评审意见是否关闭”这类条目，用于确认测试相关材料齐全、结论已确认，具体测试执行记录由测试管理流程承载。
