交付清单核验表用于单次研发交付的完成确认：把交付要求拆成一条条可判定的核验项，逐项记录判定结果和证据引用，再由核验人签字确认。本文给出一张可直接复制填写的空白表，并说明每列怎么填、哪些列不能空、判定与证据怎么写，以及模板如何按交付类型裁剪和长期维护。
要点总览（TL;DR）
- 空白模板以核验项为行，固定九列：编号、类别、核验内容与通过标准、判定结果、证据引用、问题说明、整改状态、核验人、核验日期。
- 判定结果只用通过、不通过、不适用三种；证据缺失按不通过处理，不适用须写明原因。
- 编号、类别、核验内容与通过标准、判定结果、核验人、核验日期为必填；证据引用在判定通过时必填，问题说明与整改状态在不通过时必填。
- 证据引用写到可定位的文档名称、版本、章节或记录编号，避免只写“见文档”。
- 模板按交付物类型裁剪核验项，增删与标准调整记入版本变更记录，历史核验表沿用发出时版本。
可复制空白核验表模板
下表可直接复制到文档或表格工具中使用。一行对应一个核验项，核验项之间保持独立，便于逐项判定和追溯。表头顺序固定，复制后不要调换列，避免不同批次的核验表难以对照。
| 核验项编号 | 核验类别 | 核验内容与通过标准 | 判定结果 | 证据引用 | 问题说明 | 整改状态 | 核验人 | 核验日期 |
|---|---|---|---|---|---|---|---|---|
| □通过 □不通过 □不适用 | ||||||||
| □通过 □不通过 □不适用 | ||||||||
| □通过 □不通过 □不适用 | ||||||||
| □通过 □不通过 □不适用 | ||||||||
| □通过 □不通过 □不适用 |
表格上方建议补一行表头信息，记录交付名称、交付批次或版本号、核验范围、核验负责人和核验截止日期。这些信息不占核验行，但决定了这张表对应哪一次交付，归档时是检索入口。
核验类别可按交付物类型预设，例如需求文档、设计说明、代码与构建产物、测试记录、部署与发布记录、操作手册。类别的作用是让核验项成组出现，便于分工：不同角色只核验自己负责的类别，减少遗漏和重复。
字段说明：每个核验列记录什么
模板的九列各有明确职责。核验项编号和类别解决“这是哪一项、属于哪类”；核验内容与通过标准解决“核验什么、什么算通过”；判定结果、证据引用、问题说明与整改状态解决“结论是什么、凭什么、有问题怎么处理”；核验人和核验日期解决“谁在什么时候确认的”。
| 字段 | 记录内容 | 填写口径 |
|---|---|---|
| 核验项编号 | 该项在本次核验表中的唯一标识 | 建议按“类别缩写-序号”编写，如 DOC-01、TST-03；同一交付批次内不重复 |
| 核验类别 | 核验项所属的交付物或检查分组 | 从预设类别中选取，如需求文档、测试记录、发布记录；新增类别需在模板变更记录中登记 |
| 核验内容与通过标准 | 一条可判定的核验要求，以及满足什么条件算通过 | 一项一行，写成“检查对象＋检查点＋通过条件”，避免把多个要求合并成一行 |
| 判定结果 | 该项核验的结论 | 只填通过、不通过、不适用三种；不适用须在问题说明中写明原因 |
| 证据引用 | 支撑判定结果的可回溯凭据 | 写文档名称、记录编号、链接或存放位置，精确到可定位的章节、条目或版本 |
| 问题说明 | 不通过或不适用时的具体说明 | 不通过写清缺什么、差在哪；不适用写清为何不涉及本次交付 |
| 整改状态 | 不通过项的后续处理进展 | 可用待整改、整改中、已整改待复验、已关闭；通过项留空 |
| 核验人 | 对该项结论负责的人 | 填姓名或工号，同一类别可由同一人核验，不同类别可分派不同角色 |
| 核验日期 | 完成该项核验的日期 | 填实际核验当天日期，补验时更新为复验日期并在问题说明中注明 |
判定结果的三值口径需要统一理解。“通过”表示核验内容满足通过标准且有证据支撑；“不通过”表示未满足标准，或无法提供有效证据；“不适用”表示该项要求与本次交付范围无关。证据缺失时按不通过处理，等补齐证据后再复验改为通过，这样核验结论始终有据可查。
证据引用的写法直接影响追溯效率。只写“见文档”无法定位，建议写到“《接口设计说明书》v1.2 第3章 接口清单”或“测试报告 TR-2024-031，用例 TC-118 执行记录”。链接类证据要确认访问权限对核验相关角色开放，否则归档后无法复查。
必填与选填：哪些列不能空
核验表的必填列决定这张表能否作为交付确认依据。核验项编号、核验内容与通过标准、判定结果、核验人、核验日期五列在任何情况下都不能为空；证据引用在判定为通过时必填；问题说明在不通过或不适用时必填；整改状态仅在不通过时填写。
| 字段 | 填写要求 | 空值处理 |
|---|---|---|
| 核验项编号 | 必填 | 不得为空；缺失则整行无效 |
| 核验类别 | 必填 | 不得为空；无法归类时归入“其他”并在变更记录中说明 |
| 核验内容与通过标准 | 必填 | 不得为空；标准模糊的核验项应退回重写后再核验 |
| 判定结果 | 必填 | 不得为空；未核验的项不能以空白代替结论 |
| 证据引用 | 判定为通过时必填 | 通过但无证据，按不通过处理；不适用时写“不适用，原因见问题说明” |
| 问题说明 | 不通过或不适用时必填 | 通过项可留空；不通过项留空视为填写不完整 |
| 整改状态 | 不通过时必填 | 通过项留空；不通过项至少填“待整改” |
| 核验人 | 必填 | 不得为空；代填需注明实际核验人 |
| 核验日期 | 必填 | 不得为空；日期晚于交付截止日需在问题说明中注明原因 |
空值对核验结论的影响要提前约定。判定结果为空的行不能计入通过率，也不能默认视为通过；证据引用为空而判定为通过的行，复核时应打回。对于确实不涉及的核验项，正确做法是填“不适用”并写明原因，而不是删行或留空，删行会让核验范围无法还原。
填写示例：一次研发交付的完整核验行
以下示例对应一次版本发布类研发交付，交付物包括需求文档、测试记录和发布记录。示例行与模板列顺序一致，判定结果、证据引用和整改状态配合使用，可直接对照填写。
| 核验项编号 | 核验类别 | 核验内容与通过标准 | 判定结果 | 证据引用 | 问题说明 | 整改状态 | 核验人 | 核验日期 |
|---|---|---|---|---|---|---|---|---|
| DOC-01 | 需求文档 | 本次交付范围内的需求条目均有验收标准，且与版本范围一致 | 通过 | 《需求规格说明书》v2.1 第2章需求清单，共18条，均含验收标准 | 张敏 | 2024-06-11 | ||
| TST-02 | 测试记录 | 本次版本关联的测试用例全部执行，遗留缺陷均有处理结论 | 不通过 | 测试报告 TR-2024-031，用例执行率96%，缺陷单 BUG-207 未关闭 | BUG-207 为支付回调超时问题，修复版本待验证 | 整改中 | 李伟 | 2024-06-12 |
| REL-01 | 发布记录 | 发布包版本号与构建记录一致，部署日志可查 | 通过 | 构建记录 BUILD-0612-03，部署日志位于发布平台 2024-06-12 批次 | 王磊 | 2024-06-12 | ||
| OPS-01 | 操作手册 | 面向运维的部署与回滚说明已更新至本版本 | 不适用 | 不适用，原因见问题说明 | 本次为内部灰度发布，未对外提供运维手册，回滚由发布平台自动完成 | 王磊 | 2024-06-12 |
从示例可以看出判定与证据的配合方式：TST-02 判定不通过，证据引用直接指向未关闭的缺陷单，问题说明写清影响和后续动作，整改状态标为整改中，复验通过后把判定改为通过、整改状态改为已关闭，并保留原问题说明作为过程记录。OPS-01 判定不适用，证据引用写明不适用并指向原因，避免被误读为漏检。
示例中的日期按核验实际发生顺序排列，不同类别由不同角色核验，核验人列体现责任归属。实际使用时，核验项编号和类别按本次交付的模板预设填写，核验内容与通过标准从模板中复制，判定和证据在核验时现场填写。
调整与维护：按交付类型裁剪核验项
同一张核验表不必适用于所有交付。按交付物类型裁剪核验项，可以让核验聚焦在本次真正需要确认的内容上。裁剪的基本方法是：先确定本次交付包含哪些交付物类型，再从模板库中选取对应类别的核验项，删除与本次范围无关的类别，保留通用项，如范围一致性、版本号一致性、审批记录完整性。
新增核验项需要满足准入条件：核验内容可以明确判定通过或不通过；通过标准有可观察的依据；证据能够被定位和复查；该项对应的责任角色明确。四条同时满足才纳入模板，否则先作为临时核验项记录，待口径成熟后再固化。
模板版本与变更记录是长期复用的基础。每次增删核验项或调整通过标准，都应记录变更日期、变更内容、变更原因和影响范围，并给模板分配版本号。已发出的核验表沿用发出时的版本，不随模板更新而追溯修改，保证历史核验结论可还原。
核验表归档时，按交付批次或版本号存放，与对应的交付物、测试记录和发布记录放在同一归档位置，形成从核验项到证据的完整链路。需要复查某次交付时，从核验表出发即可定位每一项结论的依据。
当核验表需要与工作项、文档和评审记录联动时，可以把核验表作为交付确认环节的交付物挂接到对应工作项下，让核验结论、证据文档和评审记录处在同一条记录链上。ONES 覆盖需求、基线、版本、变更、测试与发布，围绕需求、基线和版本建立统一管理对象，支撑过程状态追踪和交付结果回溯；测试用例、缺陷、版本和发布过程可以关联到需求链路中，出现问题时便于定位影响范围。标准流程、评审节点和交付物模板也可以沉淀为可复用资产，把核验规范落到实际项目的执行流程里。具体字段配置和关联方式以实际产品资料和试用验证为准。
常见问题
核验项判定为“不适用”后，还需要补证据吗？
不需要补通过类证据，但要在证据引用列写明“不适用，原因见问题说明”，并在问题说明中写清该项为何与本次交付范围无关。这样处理可以保留核验范围，复查时能区分“不涉及”和“漏检”。
核验过程中发现通过标准本身写得模糊，应该怎么处理？
把该核验项退回重写，标准明确后再核验，不在标准模糊的情况下直接判定通过。若交付时间紧张，可先按临时核验项记录，写明待明确的标准点，待口径成熟后固化进模板并登记变更。
不通过项整改完成后，原记录要删除还是保留？
保留原记录。复验通过后把判定结果改为通过、整改状态改为已关闭，原问题说明作为过程记录留存。这样核验表既能反映最终结论，也能还原问题发现和整改的过程。
同一交付批次里不同类别由不同角色核验，核验表怎么组织？
仍用一张表，按核验类别分组排列核验项，核验人列填写各类别实际核验人。表头信息中记录核验负责人，负责汇总和确认整张表。类别分组让分工边界清晰，也便于按类别统计核验进度。
核验表需要和交付物、测试记录一起归档吗？
建议放在同一归档位置，按交付批次或版本号存放。核验表的证据引用指向具体文档和记录，集中归档后从核验表出发就能定位每一项结论的依据。当核验表需要与工作项、文档和评审记录联动时，可以把它挂接到对应工作项下，让结论、证据和评审处在同一条记录链上；ONES 覆盖需求、基线、版本、变更、测试与发布，测试用例、缺陷、版本和发布过程可关联到需求链路，便于回溯交付结果，具体配置以实际产品资料和试用验证为准。
