交付清单核验要回答的是：本次研发交付是否已经完成，能否判定通过。它把完成确认拆成一张可逐项判断的检查表，由交付负责人、验收方以及质量与运维移交接收人，在提交前、验收评审、发布后与移交前分别使用。下文按交付物完整性、证据可追溯、验收结果确认、发布后验证、服务移交五个阶段给出检查项、通过标准、证据与负责人，并单独标出阻断项；核验记录与追溯可借助 ONES 的工作项状态、文档与评审记录承载。
要点总览（TL;DR）
- 交付清单核验只确认一次具体研发交付是否完成，由交付负责人提交前自检、验收方评审时核验、质量与移交接收人在发布后与移交前复核。
- 检查项按交付物完整性、证据可追溯、验收结果确认、发布后验证、服务移交五个阶段排列，每项写明通过标准、证据、负责人和检查时点。
- 通过标准要指向可观察的产出或记录，写明数量、范围或状态条件；判定统一为通过、待补证据、阻断三类，建议类内容放备注。
- 关键交付物缺失、验收结论未确认、发布后验证未执行、移交接收人未确认属于阻断项，全部阻断项关闭且非阻断项有处理结论才判定完成。
- 核验记录把检查项、证据、检查人与结论放在同一处可查，ONES 的需求、版本、测试与发布关联能力可支撑交付结果回溯与追溯留痕。
谁在什么时点使用这份核验清单
这份清单只服务于一次具体研发交付的完成确认。它不承担项目整体收尾的职责，也不评估产品上线后的使用效果与业务价值。把范围限定在一次交付上，检查项才能落到具体的交付物、版本和记录上，判定结果也才有明确指向。
使用对象分三类。交付负责人负责提交前自检，确认清单所列产物齐备、版本对应；验收方在验收评审时逐项核验，对验收项、结论与遗留问题作出确认；质量复核人与运维移交接收人分别在发布后验证和移交前复核环节使用清单，确认发布检查已执行、移交内容与接收人已明确。
三个使用时点对应三种核验状态：提交前自检用于发现缺项并补齐；验收评审时核验用于形成验收结论；发布后与移交前复核用于确认发布验证结果和服务移交生效。同一张清单在三个时点重复使用，每次记录检查人、检查时间和结论，避免只在评审会上一次性过一遍。
| 使用对象 | 使用时点 | 主要动作 | 产出 |
|---|---|---|---|
| 交付负责人 | 交付物提交前 | 按清单自检交付物齐备性与版本对应关系 | 自检记录、缺项补齐说明 |
| 验收方 | 验收评审时 | 逐项核验并确认验收项、结论与遗留问题 | 验收结论与签字确认 |
| 质量复核人 | 发布后 | 核对发布后关键检查项的执行结果 | 发布后验证记录 |
| 运维与支持接收人 | 移交前 | 确认移交内容、接收人与生效时间 | 移交确认单 |
分阶段检查项：从交付物到服务移交
检查项按交付推进顺序排列，每个条目对应一个可判断是否完成的动作或产出。下表给出五个阶段的核心检查项，实际使用时可按交付类型增删条目，但每个保留条目都应能回答“完成了吗”。
| 阶段 | 检查项 | 通过标准 | 证据 | 负责人 | 检查时点 |
|---|---|---|---|---|---|
| 交付物完整性 | 清单所列产物是否齐备 | 清单每一项均有对应产物，无缺项 | 交付物文件及清单对照记录 | 交付负责人 | 提交前自检 |
| 交付物完整性 | 产物版本是否对应本次交付 | 产物版本号与本次交付版本一致，无混用旧版本 | 版本记录、产物文件属性 | 交付负责人 | 提交前自检 |
| 证据可追溯 | 需求与变更能否关联到本次交付 | 本次交付涉及的需求、变更均有记录并可关联 | 需求记录、变更记录 | 交付负责人 | 提交前自检 |
| 证据可追溯 | 测试与缺陷记录能否关联到本次交付 | 测试报告与缺陷记录可追溯到本次交付范围 | 测试报告、缺陷记录 | 质量复核人 | 验收评审前 |
| 验收结果确认 | 验收项与结论是否记录 | 验收项逐条有结论，遗留问题有处理意见 | 验收记录、签字确认 | 验收方 | 验收评审时 |
| 发布后验证 | 发布后关键检查项是否执行 | 发布后检查项全部执行并留存结果 | 发布记录、验证结果 | 质量复核人 | 发布后 |
| 服务移交 | 移交内容、接收人与生效时间是否明确 | 移交内容列明，接收人确认，生效时间明确 | 移交确认单 | 运维移交接收人 | 移交前 |
阶段之间存在依赖：交付物不齐备时，证据追溯往往也无从谈起；验收结论未确认，发布后验证缺少判定依据。因此检查顺序建议按表内阶段推进，前一阶段存在阻断项时，后续阶段的核验可以暂缓，但不必等待全部非阻断项处理完毕。
每项检查的通过标准怎么写
通过标准的作用是让不同检查人对同一项得出相同判断。写法上要指向可观察的产出或记录，写明数量、范围或状态条件，避免“基本完成”“质量良好”这类主观表述。
可用的写法通常包含三个要素：对象、条件、判定结果。例如“清单所列 12 项交付物均有对应文件，且版本号与本次交付版本一致”就是一个可判断的标准；而“交付物准备充分”无法判断，应改写或删除。
| 写法 | 示例 | 问题或优点 |
|---|---|---|
| 反例 | 测试工作已完成，质量有保障 | 无对象、无范围，无法判断 |
| 反例 | 建议补充发布说明 | 建议混入检查项，无法判定通过与否 |
| 正例 | 本次交付范围内的测试报告已归档，缺陷记录均标注处理状态 | 对象与状态明确，可核对 |
| 正例 | 验收记录中每个验收项均有结论，遗留问题均写明责任人与计划处理时间 | 范围与条件清楚，可逐条检查 |
判定方式统一为三类：满足标准记“通过”；标准本身成立但证据尚未归档记“待补证据”，并写明补交时间；标准不满足且影响交付完成判定记“阻断”。建议类内容不进入检查表，统一放到备注栏，避免把改进意见伪装成必须通过的条目。
证据与负责人如何分配到每一项
每项检查都要能回答两个问题：凭什么判断，由谁判断。证据类型按阶段区分：交付物完整性对应交付物文件与版本记录；证据可追溯对应需求记录、变更记录、测试报告与缺陷记录；验收结果确认对应验收记录与签字；发布后验证对应发布记录与验证结果；服务移交对应移交确认单。
负责人分工遵循“谁产出、谁提交，谁判定、谁签字”的原则。提交人对交付物与证据的真实性负责；验收人对验收结论负责；质量复核人对测试与发布验证记录负责；移交接收人对移交内容与生效时间负责。同一人可兼任多个角色，但验收判定与交付提交不宜由同一人完成。
| 证据类型 | 对应阶段 | 留存要求 | 责任人 |
|---|---|---|---|
| 交付物文件与版本记录 | 交付物完整性 | 按交付批次归档，文件名含交付标识与版本号 | 交付负责人 |
| 需求、变更、测试与缺陷记录 | 证据可追溯 | 与本次交付范围建立关联，可反查 | 交付负责人、质量复核人 |
| 验收记录与签字 | 验收结果确认 | 与验收评审同批归档，结论与遗留问题同页可查 | 验收方 |
| 发布记录与验证结果 | 发布后验证 | 按发布时间归档，检查项逐条留结果 | 质量复核人 |
| 移交确认单 | 服务移交 | 接收人签字，注明生效时间 | 运维移交接收人 |
证据缺失时按统一路径处理：先由该项负责人说明缺失原因并给出补交时间，记“待补证据”；补交时间超出验收评审窗口且影响完成判定的，转为阻断项，提交验收方决定是否延期评审。证据留存位置与命名要求在交付启动时确定，避免评审时临时查找。
阻断项与完成条件
阻断项是那些一旦缺失或未确认，就无法判定本次交付完成的检查项。常见阻断项包括：清单所列关键交付物缺失；验收结论未确认或验收方未签字；发布后关键检查项未执行；移交接收人未确认或生效时间未定。
阻断项与非阻断项的区分原则看是否影响“交付是否完成”这一判断。影响交付物可用性、验收结论成立或服务能否接续的，列为阻断；属于记录完善、格式统一、后续优化类的，列为非阻断，记录处理结论即可。区分标准应在交付启动时与验收方对齐，避免评审时争议。
整体完成条件为：全部阻断项关闭，且非阻断项均有明确处理结论（已处理或已约定处理时间与责任人）。只满足其一不能判定完成。未关闭阻断项时，由交付负责人汇总清单提交验收方，按约定升级至项目负责人决定延期、分批交付或退回整改，处理结果回填清单后再复核。
核验记录如何承载与追溯
核验结果需要形成一条可回查的链路：检查项、对应证据、检查人、检查时间与结论在同一处可查，验收结论、遗留问题与移交状态也能从同一入口找到。做法上，把检查项作为工作项或检查单条目管理，每条关联对应的交付物、测试报告或验收记录；检查结论通过状态字段体现，证据以附件或文档关联方式留存。
ONES 在这一环节的衔接方式体现在几个方面。需求、基线、版本和变更作为统一管理对象，支撑交付结果回溯；测试用例、缺陷、版本与发布过程关联到需求链路，出现问题时可以定位影响范围；交付物模板与评审节点可以沉淀为可复用资产，使每次交付的核验按同一套结构执行。这些能力对应的是核验留痕与追溯的管理动作，具体检查单模板与状态流转配置需按团队实际使用方式设置。
落地时建议保持三个一致：检查项编号与清单编号一致，证据命名与交付批次一致，状态字段含义与本文的通过、待补证据、阻断三类判定一致。这样在验收评审、发布后复核和移交确认时，不同角色看到的是同一份记录，追溯时不必再向多方收集材料。
常见问题
交付清单核验和项目验收有什么区别，什么时候该用哪一个？
交付清单核验针对一次具体研发交付，判断交付物是否齐备、证据能否追溯、验收结论是否确认、发布后验证是否执行、服务移交是否明确，结论是本次交付完成或未完成。项目验收关注项目整体目标、范围与收尾事项，通常在多个交付完成后进行。两者可以衔接使用：本次交付核验通过后，其结果作为项目验收的输入材料；项目层面的收尾安排、资源释放与经验总结不在交付核验清单内展开。
交付已经上线，但部分证据还没归档，能先判定完成吗？
要看缺失证据对应的检查项是否属于阻断项。如果缺失的是关键交付物、验收结论或发布后验证结果，应先记“待补证据”并给出补交时间；补交时间超出验收评审窗口且影响完成判定的，转为阻断项，由验收方决定是否延期评审。如果缺失的只是记录格式、命名统一等非阻断项，可以记录处理结论与责任人后判定完成。判定依据是阻断项是否全部关闭，而非交付是否已经上线。
同一人既提交交付物又做验收确认，清单还成立吗？
清单本身可以继续使用，但验收结论的可信度会下降。建议提交与验收判定由不同人完成；团队规模较小时，可由上一级负责人或质量角色承担验收确认，并在核验记录中注明角色兼任情况。清单要求每项写明负责人，目的是让判断可复核、可追责，角色兼任不改变这一要求，只需在记录中如实体现。
检查项数量多，评审会上逐条过一遍不现实，怎么安排核验节奏？
把核验分散到三个时点：提交前由交付负责人完成自检并补齐缺项，评审会只核验阻断项、争议项和验收结论，发布后与移交前的检查项由质量复核人和移交接收人分别执行并回填结果。这样评审会聚焦判定，不必逐条复述已完成的自检内容。前提是自检记录和证据已提前归档，评审时能直接调取。
核验记录放在协作工具里，需要保证哪些一致性才方便追溯？
至少保持三点一致：检查项编号与清单编号一致，证据文件命名与交付批次一致，状态字段含义与通过、待补证据、阻断三类判定一致。把检查项作为工作项或检查单条目管理，关联对应交付物、测试报告与验收记录，验收结论和遗留问题在同一入口可查。ONES 可将需求、版本、测试与发布过程关联到需求链路，便于出现问题时定位影响范围；具体检查单模板与状态流转需按团队实际使用方式配置。
