交付清单核验表要回答两个问题：这次交付到底完成了没有，以及凭什么判定。做法是把核验项作为行，把判定结果和证据引用作为列，让复核人只看表就能定位到具体文件、版本或记录编号。下面给出一张可直接复制填写的空白表，并说明核验项怎么拆、证据字段怎么填、哪些字段必填，以及模板如何随项目变化维护。表内记录也可以放在ONES中，与需求、版本、测试和发布记录关联，便于回溯。
要点总览（TL;DR）
- 交付清单核验表以核验项为行，以判定结果和证据引用为列，让复核人只看表就能定位到具体文件、版本或记录编号。
- 核验项按交付物类别拆分，每条写成可独立判定的陈述，并配套核验方法与判定标准，一条只回答一个问题。
- 证据引用字段组包含证据类型、引用编号或链接、版本与时间、存放位置与责任人，并与核验项序号建立对应关系。
- 判定结果只取通过、不通过、待确认三值；不通过或待确认时强制填写原因与整改要求，日期统一格式。
- 模板保留版本与变更记录，按项目类型裁剪核验项，并与交付评审流程衔接，评审后集中修订。
可复制空白核验表模板
下表为空白模板，可整体复制到文档或表格工具中，按项目实际增删行。表头分为三组：核验项信息、判定信息、证据信息。每组字段在后续章节和示例中保持同名同义。
| 序号 | 交付物类别 | 核验项 | 核验方法 | 判定标准 | 判定结果 | 不通过原因/待确认事项 | 证据类型 | 证据引用（编号/链接/位置） | 证据版本/时间 | 证据责任人 | 核验人 | 核验日期 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 通过/不通过/待确认 | ||||||||||||
| 2 | 通过/不通过/待确认 | ||||||||||||
| 3 | 通过/不通过/待确认 |
表尾建议保留汇总区：核验项总数、通过数、不通过数、待确认数、核验结论（可交付/有条件交付/不可交付）、核验负责人签字与日期。汇总区不替代逐行记录，只用于快速判断整体状态。
核验项怎么拆：按交付物类别设计条目
核验项是表的行，设计质量决定整张表能否用。拆分的基本单位是“一个可独立判定的陈述”，每条只回答一个问题，配套写明核验方法和判定标准。一条核验项里混入两个判断，出现部分通过时就无法记录。
常见做法是先按交付物类别分组，再在组内逐条拆分。以下类别可作为起点，按项目实际取舍：
- 文档类：需求说明、设计文档、用户手册、运维手册是否齐全，版本是否为约定版本，评审记录是否闭环。
- 代码与构建类：代码是否合入约定分支，构建是否成功且产物可获取，构建编号与交付版本是否对应。
- 环境与部署类：目标环境是否按约定配置，部署脚本或制品是否可重复执行，部署记录是否留存。
- 测试与质量类：测试用例执行范围与结果，遗留缺陷的数量与等级，回归结论是否明确。
- 接口与集成类：接口清单与版本是否与对接方确认，联调记录是否完整，异常场景是否有结论。
- 培训与移交类：培训材料与场次记录，操作账号与权限移交清单，接收方确认记录。
拆分时遵循三条规则。第一，核验项写成可判定的陈述，例如“用户手册已更新至V2.3并通过评审”，避免“文档较完善”这类无法判定的描述。第二，核验方法与判定标准成对出现：方法是看什么、查什么、跑什么，标准是达到什么条件算通过。第三，同一交付物涉及多个判断点时拆成多行，例如“手册已更新”和“手册已通过评审”分列两行，便于分别取证。
核验项数量按交付复杂度控制，单个交付批次通常控制在可逐条复核的范围内。条目过多时可按类别拆成多张子表，用同一套字段，汇总时合并统计。
证据引用字段：类型、编号与定位方式
证据引用字段的目标是让复核人不依赖口头说明，直接找到判定依据。字段组包括证据类型、证据引用、版本与时间、存放位置与责任人，以及与核验项的对应关系。
| 字段 | 作用 | 填写方式 |
|---|---|---|
| 证据类型 | 区分证据形态，便于按类检索 | 从枚举中选择：文档、构建记录、测试报告、部署记录、会议或评审纪要、截图、系统记录编号、其他 |
| 证据引用 | 定位到具体证据 | 填文件编号、记录编号、工作项编号或可访问链接；链接需指向具体条目而非首页 |
| 证据版本/时间 | 确认证据对应的是本次交付版本 | 填版本号加日期，如“V2.3 / 2025-03-12”；无版本号时填生成时间 |
| 证据存放位置 | 说明证据在哪个库、目录或系统中 | 填文档库路径、制品库地址或系统名称 |
| 证据责任人 | 明确证据的提供与维护人 | 填姓名或角色，便于复核时追问 |
| 对应核验项 | 建立证据与行的关联 | 通过序号关联；一条核验项可引用多条证据，一条证据也可支撑多行 |
填写规则有三点。证据引用要精确到条目，例如测试报告填报告编号而非“测试组共享盘”；版本与时间要和交付版本对齐，避免用旧版本证据支撑新版本判定；证据责任人与核验人分开记录，核验人对判定负责，证据责任人对材料真实性负责。
在ONES中，核验记录可以作为工作项或文档条目承载，证据引用直接指向关联的需求、版本、测试与发布记录。ONES当前方案覆盖需求、基线、版本、变更、测试与发布，围绕这些对象建立统一管理，支撑过程状态追踪和交付结果回溯；测试用例、缺陷、版本和发布过程关联到需求链路后，出现问题时可以快速定位影响范围。这样证据引用填的是系统内可追溯的编号，复核时点开即可核对。
必填与选填：字段填写要求
必填字段保证每条记录可判定、可追溯；选填字段用于补充说明。条件必填在特定判定结果下触发，填写时按规则执行。
| 字段 | 要求 | 填写约束 |
|---|---|---|
| 序号 | 必填 | 表内唯一，按类别分段编号 |
| 交付物类别 | 必填 | 从约定类别中选择 |
| 核验项 | 必填 | 一句可判定的陈述，不含多个判断 |
| 核验方法 | 必填 | 写明查看、比对或执行的动作 |
| 判定标准 | 必填 | 写明通过条件，可量化时给出口径 |
| 判定结果 | 必填 | 仅取通过、不通过、待确认三值 |
| 不通过原因/待确认事项 | 条件必填 | 判定为不通过或待确认时必填，写明原因与整改或确认要求 |
| 证据类型 | 必填 | 从枚举中选择 |
| 证据引用 | 必填 | 判定为通过时必填；待确认时可填已获取的部分证据 |
| 证据版本/时间 | 必填 | 与交付版本对应，格式为版本号加日期 |
| 证据责任人 | 必填 | 填姓名或角色 |
| 核验人 | 必填 | 填实际执行核验的人 |
| 核验日期 | 必填 | 格式统一为YYYY-MM-DD |
| 证据存放位置 | 选填 | 链接已能定位时可省略 |
| 备注 | 选填 | 记录例外说明、后续动作或关联事项 |
格式约束统一后便于汇总统计：判定结果只用三个固定值，不写“基本通过”等中间表述；日期统一格式；证据引用中的链接使用完整地址，编号使用系统内唯一编号。判定为不通过的行，整改完成后在原行更新判定结果并保留原因记录，或新增一行记录复验，两种方式在模板说明中选定一种并保持一致。
填写示例：一条完整核验记录
以下示例演示各字段如何配合，字段与空白模板一一对应。示例为演示情景，不代表真实项目数据。
| 字段 | 填写内容 |
|---|---|
| 序号 | 3-02 |
| 交付物类别 | 测试与质量 |
| 核验项 | 本次交付版本的回归测试已执行完毕并出具结论 |
| 核验方法 | 查看测试报告中的执行范围与结论页，比对交付版本号 |
| 判定标准 | 报告覆盖约定回归范围，结论明确，遗留缺陷等级与数量在约定阈值内 |
| 判定结果 | 通过 |
| 不通过原因/待确认事项 | — |
| 证据类型 | 测试报告 |
| 证据引用 | 测试报告编号 TR-2025-0312-07，关联版本 V2.3 |
| 证据版本/时间 | V2.3 / 2025-03-12 |
| 证据责任人 | 测试负责人（示例） |
| 核验人 | 交付核验人（示例） |
| 核验日期 | 2025-03-13 |
| 备注 | 遗留2个低等级缺陷，已登记并约定下个版本处理 |
这条记录体现三个要点：判定标准写明了阈值口径，判定结果才有依据；证据引用精确到报告编号并绑定版本，复核时可直接调取；备注记录了例外情况，避免“通过”掩盖遗留问题。若该行判定为不通过，则“不通过原因/待确认事项”必须填写，例如“回归范围缺少接口异常场景，需补充执行后复验”。
调整与维护：让核验表随交付变化
模板需要随项目类型和交付节奏调整，否则会出现条目冗余或漏项。维护工作包括裁剪、版本管理、归档复核和流程衔接四件事。
按项目类型裁剪。新建项目时从标准模板复制一份，按交付形态增删行：纯文档交付可去掉构建与部署类条目；含外部接口的项目加强接口与集成类条目；首次移交的项目保留培训与移交类条目。裁剪只增删行，不改字段名，保证不同项目汇总时口径一致。
模板版本与变更记录。模板本身保留版本号和变更记录，记录每次调整的日期、调整人、增删的核验项及原因。项目内使用模板时注明所用模板版本，便于回溯某次核验依据的是哪一版要求。
归档与复核周期。核验表随交付物一并归档，归档内容包括填写完成的表、引用的证据和汇总结论。复核周期按交付节奏设定，例如每个交付批次结束后抽查一定比例的记录，检查证据引用是否可打开、判定与标准是否一致。
与交付评审流程衔接。核验表作为交付评审的输入材料，评审前完成填写，评审中重点看不通过和待确认的行及整改结论，评审结论回写到汇总区。ONES可将标准流程、评审节点、交付物模板和过程数据沉淀为可复用资产，核验表模板可作为其中一项复用；贯通需求、开发、测试等环节后，核验记录与需求链路保持关联，后续追溯时不必另行翻找。流水线相关的构建与部署证据，也可通过ONES与Jenkins等工具的集成记录对应到具体构建和部署状态，减少手工抄录。
维护节奏上，建议每次交付评审后收集填写中的问题，集中修订模板，避免在单个项目执行中途频繁改字段。字段一旦调整，同步更新填写说明和示例，保持模板、说明、示例三者一致。
常见问题
核验项写成“文档较完善”这类描述，为什么复核时容易产生分歧？
这类描述没有给出可观察的判定条件，不同核验人可能得出不同结论，出现部分满足时也无法记录。建议把核验项改写成可判定的陈述，例如“用户手册已更新至V2.3并通过评审”，同时写明核验方法（查看哪份文件、比对哪个版本）和判定标准（达到什么条件算通过）。一条核验项只保留一个判断点，涉及多个判断时拆成多行分别取证。
证据引用只填“测试组共享盘”可以吗？
不建议。共享盘只说明大致位置，复核人仍需自行翻找，无法确认看到的是否为本次交付对应版本。证据引用应精确到条目，例如测试报告编号、工作项编号或指向具体条目的链接，并配合“证据版本/时间”字段与交付版本对齐。链接已能定位到具体条目时，“证据存放位置”可作为选填字段省略。
判定为不通过的行，整改后是改原行还是新增一行？
两种方式都可以，关键是在模板说明中选定一种并保持一致。改原行的做法保留原因记录并更新判定结果，表内行数稳定；新增复验行的做法保留每次核验的完整轨迹，适合需要审计留痕的交付。无论选哪种，复验时都要重新填写核验人和核验日期，证据引用更新为整改后的材料，避免用旧证据支撑新结论。
核验记录放在ONES里，证据引用字段怎么填才便于回溯？
ONES当前方案覆盖需求、基线、版本、变更、测试与发布，测试用例、缺陷、版本和发布过程可以关联到需求链路。核验记录作为工作项或文档条目承载时，证据引用可直接填写关联对象的系统内编号，复核时点开即可核对。构建与部署类证据可通过ONES与Jenkins等工具的集成记录对应到具体构建和部署状态，减少手工抄录。具体字段配置方式以实际环境为准。
不同项目共用一张核验表，汇总统计时口径不一致怎么办？
裁剪模板时只增删行，不改字段名和枚举值，判定结果始终只用通过、不通过、待确认三个固定值，日期统一为YYYY-MM-DD。这样不同项目的表可以直接合并统计。项目内使用时注明所用模板版本号，模板本身保留变更记录，记录调整日期、调整人和增删条目及原因，便于回溯某次核验依据的是哪一版要求。
