交付清单核验表围绕“核验项—判定结果—证据引用”三类字段组织：核验项把交付物拆成可逐条判断的条目，判定结果统一为通过、不通过、不适用三档，证据引用记录可定位的证据名称、位置或链接及版本。本文给出可直接复制的空白表、字段填写口径、必填与选填划分，并用一次研发交付的核验记录示范填写，适用于单次交付完成确认与后续追溯。
要点总览（TL;DR）
- 核验表以“核验项—判定结果—证据引用”为主线，另设编号、交付物、核验标准、责任人、核验日期与遗留问题等辅助字段。
- 核验项按交付物拆到可逐条判断的粒度，编号采用“交付物代码-序号”，一条核验项只对应一个可判定的结论。
- 判定结果统一为通过、不通过、不适用三档；不通过时须填写判定说明与遗留问题，未完成核验的行暂不填判定结果。
- 证据引用拆为名称、位置或链接、版本三列，每条核验项独立填写，保证后续可按位置和版本找到同一份材料复核。
- 最小可用表保留七列必填字段，完整表按交接、审计等场景补充判定说明、遗留问题、证据版本、责任人与核验日期。
可复制空白核验表模板
下表可直接复制到文档或表格工具中使用。表头固定，核验项按交付物分组填写，判定结果与证据引用相邻放置，便于逐行核对。示例保留三组交付物、六条核验项，实际使用时按交付范围增删行。
| 核验项编号 | 交付物 | 核验项 | 核验标准 | 判定结果 | 判定说明 | 证据名称 | 证据位置或链接 | 证据版本 | 责任人 | 核验日期 | 遗留问题 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 示例：D01-01 | 示例：需求规格说明书 | 示例：需求条目与评审结论一致 | 示例：评审通过的条目全部保留，变更条目有记录 | 示例：通过 | 示例：与评审纪要逐条比对无差异 | 示例：需求评审纪要 | 示例：项目文档库/评审/2024-06 | 示例：v1.2 | 示例：张×× | 示例：2024-06-18 | 示例：无 |
填写时先按交付物分组，同一交付物的核验项连续排列，编号带交付物前缀；每组填写完成后统一核对证据引用是否齐全，再进入下一组。表格行数按实际核验项增减，表头字段保持不变。
核验项字段说明与分类
核验项字段决定这张表能否逐条判断。拆分粒度以“一条核验项只对应一个可判定的结论”为准：一条核验项同时包含格式、内容和签字三项要求时，应拆成三条，否则判定结果无法准确表达。
核验项编号规则
编号采用“交付物代码-序号”两段式，例如 D01-01、D01-02。交付物代码在表头或分组行中定义，序号在该交付物内连续递增。编号一经使用不重复、不复用，删除的核验项保留编号并标注作废，避免后续引用错位。
交付物与核验项的关系
一个交付物对应一组核验项，交付物字段在组内重复填写或使用合并单元格。交付物名称写全称并带版本，例如“接口设计文档 v2.0”，避免同一交付物多版本混在一组核验项中。
核验标准的写法
核验标准写成可对照判断的条件，包含判断对象和判断依据。例如“接口清单覆盖需求规格中全部对外接口，缺项为零”，比“接口完整”更容易判定。标准中涉及数量、格式、签字的要求应写明具体口径。
按交付物类型划分核验项类别
| 交付物类型 | 典型核验项类别 | 判断要点 |
|---|---|---|
| 文档类 | 完整性、版本一致性、评审签字 | 章节齐全、与上游依据一致、评审记录可查 |
| 代码与构建产物 | 分支与标签、构建通过、依赖清单 | 发布分支正确、构建记录可查、依赖版本锁定 |
| 测试类 | 用例覆盖、执行记录、缺陷关闭 | 覆盖需求条目、执行结果留档、遗留缺陷有结论 |
| 部署与配置 | 配置项清单、环境一致性、回滚方案 | 配置与清单一致、环境参数核对、回滚步骤可执行 |
类别用于组织核验项，不限制具体条目数量。团队可按交付类型从对应类别中选取核验项，再补充本项目特有的条目。
判定结果与证据引用字段说明
判定结果与证据引用共同保证每条结论可回溯。判定结果只取三档，证据引用必须指向能直接支撑该判定的材料，两者在同一行内对应。
判定结果三档取值
通过表示核验项满足核验标准；不通过表示存在明确差距；不适用表示该核验项不适用于本次交付，例如某交付物不含对外接口时，接口相关核验项判为不适用。三档之外不设“待定”，未完成核验的条目暂不填写判定结果，核验完成后再补。
判定说明与遗留问题
判定说明写判定依据的一句话结论，通过时说明比对方式，不通过时写明差距内容。遗留问题字段记录不通过项的处理安排，包括处理责任人和计划完成时间；判定为通过或不适用时填“无”。判定说明与遗留问题分工明确：前者解释为什么这样判，后者说明接下来怎么办。
证据引用需记录的名称、位置、版本
证据引用拆为三列：证据名称写材料全称，如“需求评审纪要”；证据位置或链接写可定位的路径、文档编号或链接；证据版本写该材料的版本号或日期。三项齐全时，后续任何人可以按位置找到同一版本的材料复核结论。仅有名称没有位置，或位置指向的版本已更新，都会使追溯失效。
证据与核验项一一对应
每条核验项至少对应一条证据，一条证据可以支撑多条核验项，但每条核验项的证据引用需单独填写，不写“同上”或“见前文”。证据较多时，在证据名称中列主证据，其余在判定说明中补充说明。
必填与选填字段划分
必填字段保证核验结论可判断、可追溯；选填字段按交付类型和团队管理要求补充。字段取舍以最小可用表为底线，完整表用于需要跨团队交接或审计的场景。
| 字段 | 属性 | 说明 |
|---|---|---|
| 核验项编号 | 必填 | 保证条目可引用 |
| 交付物 | 必填 | 标明核验对象 |
| 核验项 | 必填 | 核验内容本身 |
| 核验标准 | 必填 | 判定依据 |
| 判定结果 | 必填 | 三档取值之一 |
| 证据名称 | 必填 | 支撑判定的材料 |
| 证据位置或链接 | 必填 | 可定位到具体材料 |
| 判定说明 | 条件必填 | 不通过时必填，通过时建议填写 |
| 遗留问题 | 条件必填 | 不通过时必填 |
| 证据版本 | 选填 | 材料有版本管理时填写 |
| 责任人 | 选填 | 需要明确核验执行人时填写 |
| 核验日期 | 选填 | 需要记录核验时间时填写 |
最小可用表保留编号、交付物、核验项、核验标准、判定结果、证据名称、证据位置七列，适用于团队内部快速核验。完整表在此基础上增加判定说明、遗留问题、证据版本、责任人和核验日期，适用于交付交接、跨团队确认或需要留档复核的场景。
缺失必填字段时，该行核验结论不成立，应退回补充后再提交。判定结果为空的行视为未完成核验，不计入核验完成率；证据位置为空的行按证据缺失处理，即使判定为通过也需补齐。
填写示例：一次研发交付的核验记录
以下示例为一次版本发布前的交付核验，交付物包括接口设计文档、发布构建包和测试报告，演示核验项、判定结果与证据引用如何对应填写。
| 核验项编号 | 交付物 | 核验项 | 核验标准 | 判定结果 | 判定说明 | 证据名称 | 证据位置或链接 | 证据版本 | 责任人 | 核验日期 | 遗留问题 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| D01-01 | 接口设计文档 v2.0 | 接口清单覆盖需求规格全部对外接口 | 需求规格中对外接口全部在清单中出现，缺项为零 | 通过 | 逐条比对需求规格第4章，接口数量一致 | 接口设计文档 | 项目文档库/设计/接口设计_v2.0 | v2.0 | 李×× | 2024-06-18 | 无 |
| D01-02 | 接口设计文档 v2.0 | 文档完成评审并留有签字记录 | 评审记录包含评审人签字和结论 | 通过 | 评审纪要签字齐全，结论为通过 | 接口设计评审纪要 | 项目文档库/评审/接口评审_0615 | 2024-06-15 | 李×× | 2024-06-18 | 无 |
| D02-01 | 发布构建包 v3.1.0 | 构建来自发布分支且标签正确 | 构建记录显示分支为 release/3.1，标签为 v3.1.0 | 通过 | 构建记录与标签核对一致 | 构建流水线记录 | 构建系统/任务#2210 | 2024-06-17 | 王×× | 2024-06-18 | 无 |
| D02-02 | 发布构建包 v3.1.0 | 依赖清单版本锁定 | 依赖清单中全部依赖写明版本号 | 不通过 | 两个间接依赖未写版本号 | 依赖清单 | 代码库/发布包/依赖清单.txt | 2024-06-17 | 王×× | 2024-06-18 | 王××于6月19日前补齐版本号并重新核验 |
| D03-01 | 测试报告 v3.1.0 | 测试用例覆盖需求条目 | 需求规格中每条需求至少对应一条用例 | 通过 | 覆盖矩阵显示需求条目全部有用例 | 测试覆盖矩阵 | 测试系统/报告/覆盖矩阵_3.1 | 2024-06-16 | 赵×× | 2024-06-18 | 无 |
| D03-02 | 测试报告 v3.1.0 | 遗留缺陷有明确结论 | 每个遗留缺陷标注修复版本或接受理由 | 不适用 | 本次发布无遗留缺陷 | 缺陷列表 | 缺陷系统/筛选/未关闭缺陷 | 2024-06-18 | 赵×× | 2024-06-18 | 无 |
示例中 D02-02 判为不通过，判定说明写明差距，遗留问题写明处理人和时间；D03-02 因无遗留缺陷判为不适用，仍保留证据引用以便复核。每条核验项的证据引用独立填写，后续按位置和版本即可找到对应材料。
当核验记录需要与需求、任务、测试和缺陷的状态联动时，可以把核验表作为交付确认环节的文档，与工作项关联管理。ONES 的方案覆盖需求、基线、版本、变更、测试与发布，数字线程连接这些环节，需求变化时可沿关联关系分析受影响的任务、测试和交付内容，并保留过程追踪依据；标准流程、评审节点和交付物模板也可沉淀为可复用资产。核验表中的证据引用与这些关联记录配合使用，便于在交付确认时回溯到具体条目。
模板调整与维护方法
模板需要随交付类型变化持续调整，同时保持字段口径稳定，否则不同批次的核验记录无法横向比较。
按交付类型扩展核验项
新增交付类型时，先在核验项类别表中补充该类别的典型核验项，再为具体项目增删条目。扩展时沿用编号规则，新交付物分配新代码，不复用旧代码。删除核验项时保留编号并标注作废原因，便于历史记录对照。
证据引用口径的统一维护
证据名称、位置和版本的写法由团队统一约定，例如位置统一写“系统/目录/文件名”，版本统一写版本号或日期。口径变更时同步更新模板说明，并对已填写的记录标注适用口径，避免新旧记录混用。
模板版本与变更记录
模板本身保留版本号和变更记录，记录每次增删字段、调整核验项类别和修改填写口径的内容与日期。核验记录引用模板版本，便于追溯某次核验使用的是哪一版表结构。
定期复核核验项有效性
按交付周期定期复核核验项：长期判为不适用或从未触发不通过的条目，检查是否仍与交付风险相关；频繁判为不通过的条目，检查核验标准是否表述不清。复核结论记入变更记录，作为下一版模板的调整依据。
常见问题
核验项判定为“不适用”时，还需要填写证据引用吗？
建议保留证据引用。判为不适用通常意味着该核验项对应的对象在本次交付中不存在，例如本次发布没有遗留缺陷，此时证据可以指向缺陷列表的筛选结果或说明性记录。保留证据的作用是让后续复核者能确认“不适用”这一判断本身有依据，而非遗漏填写。若确实无法提供材料，至少在判定说明中写清不适用的原因。
一次交付的核验项很多，证据引用能否合并填写以减少重复？
证据本身可以支撑多条核验项，但每条核验项的证据引用需要单独填写，不写“同上”或“见前文”。原因是后续复核往往按单条核验项定位材料，合并填写会让某条结论失去独立可追溯性。如果同一份材料支撑多条核验项，可以在各行的证据名称中重复写该材料，位置和版本保持一致；证据较多时，在证据名称中列主证据，其余在判定说明中补充。
核验进行到一半、部分条目尚未完成时，判定结果列应该怎么处理？
未完成核验的条目暂不填写判定结果，也不要用“待定”等第四种取值代替。判定结果只保留通过、不通过、不适用三档，空值本身表示该行尚未完成核验。统计核验完成率时，判定结果为空的行不计入已完成数量；提交交付确认前，应把这些行补齐或明确移出本次核验范围。
证据位置指向的文档后来更新了版本，原核验结论还有效吗？
原核验结论对应的是核验当时那一版材料，有效性以证据版本列为准。如果证据位置指向的文档已更新，复核时应按证据版本列记录的版本号或日期找到当时版本，再判断结论是否仍成立。若材料更新影响了核验标准涉及的内容，应重新核验并更新该行的判定结果、证据版本和核验日期，而不是直接沿用旧结论。
核验表需要与需求、任务、测试记录联动时，怎么组织更便于追溯？
可以把核验表作为交付确认环节的文档，与工作项、测试记录和缺陷记录建立关联，让每条核验项的证据引用指向具体的条目而不是笼统的目录。ONES 的方案覆盖需求、基线、版本、变更、测试与发布，数字线程连接这些环节，需求变化时可沿关联关系分析受影响的任务、测试和交付内容，并保留过程追踪依据；标准流程、评审节点和交付物模板也可沉淀为可复用资产。是否采用这种方式，取决于团队是否已有统一的需求与测试管理平台。
