交付物完整性检查要回答的是“该交的是否都交齐、每项是否达到合格线、过程是否闭环、提交的是不是正确版本”。支撑这四个判断的依据分别是交付物清单与定义、验收标准与质量门槛、过程记录与评审证据、版本与状态记录。本文按这四类依据展开，说明如何拆出可核对条目、按步骤执行检查、划分角色并留下可复核的记录，检查范围限于交付物本体。
要点总览（TL;DR）
- 完整性检查需要四类依据：交付物清单与定义、验收标准与质量门槛、过程记录与评审证据、版本与状态记录，分别回答交什么、是否合格、是否闭环、提交的是哪一版。
- 判定顺序按清单索引→标准判定→记录确认→版本核对推进，依据本身须为当前有效版本，否则结论不可信。
- 检查前要把交付物按组成件拆成可勾选条目，并区分必交项与条件交付项，条件不成立时记录不适用而非缺失。
- 检查记录应包含对象、依据版本、逐条结论与依据指向、缺口责任人期限和总体结论，结论分通过、有条件通过、不通过三档。
- 依据缺失或版本不一致属于阻断情形，不得判定通过；检查完成后用自检清单确认结论可被他人复核。
完整性检查的四类依据与判定顺序
完整性检查的依据需要覆盖四个不同问题，缺一层就会留下判断盲区。只有清单，检查会停留在“有没有交”；只有标准，无法知道该检查哪些对象；只有记录，无法判断内容是否合格；只有版本信息，无法确认提交对象是否与基线一致。四层配合，才能得出可复核的结论。
| 依据类型 | 回答的问题 | 最小可用形态 | 缺失时的风险 |
|---|---|---|---|
| 交付物清单与定义 | 应交付什么，每项由哪些组成件构成 | 含编号、名称、组成件、责任人、适用阶段的清单 | 漏检整类交付物，检查范围无法界定 |
| 验收标准与质量门槛 | 每项达到什么程度算合格 | 与清单条目对应的合格条件与必填内容 | 只能判断有无，无法判断内容是否齐全 |
| 过程记录与评审证据 | 谁在何时确认过，评审是否闭环 | 评审记录、签字或审批状态、问题关闭记录 | 交付物存在但未经确认，结论缺乏支撑 |
| 版本与状态记录 | 当前提交的是哪一版，处于什么状态 | 版本号、基线标识、当前状态字段 | 检查了旧版或草稿，结论与实际交付不符 |
判定顺序按“清单索引→标准判定→记录确认→版本核对”推进。先用清单确定检查范围和逐项条目，再用验收标准判断每项内容是否齐全合格，接着用过程记录确认评审与签字是否闭环，最后用版本与状态记录核对提交对象是否为约定基线。顺序颠倒会做无用功，例如先核对版本再发现清单本身不完整，检查范围就要重来。
四类依据都应以当前有效版本为准。清单在项目执行中被修订过，就要确认使用的是最新版；验收标准随阶段变化，就要取对应阶段的版本。依据本身失效，检查结论同样不可信。
从交付物清单到检查项：如何拆出可核对条目
清单只写到“提交设计文档”这样的粒度，检查就只能回答“交了没有”。要把检查推进到内容层面，需要按组成件把每项交付物拆成可逐项勾选的条目，并让每个条目对应一条验收标准。
清单字段建议包含：编号、交付物名称、组成件、责任人、适用阶段、交付类型（必交或条件交付）、对应验收标准编号。编号用于在检查记录中引用，组成件是拆分的依据，适用阶段决定本次检查是否涉及该项。
| 编号 | 交付物 | 组成件（子检查项） | 责任人 | 适用阶段 | 类型 | 对应标准 |
|---|---|---|---|---|---|---|
| D-01 | 需求规格说明 | 功能需求条目、非功能需求条目、需求追溯关系、变更记录 | 需求负责人 | 设计准入前 | 必交 | STD-01 |
| D-02 | 接口说明 | 接口清单、字段定义、异常约定 | 开发负责人 | 联调前 | 条件交付（存在外部接口时） | STD-02 |
| D-03 | 测试报告 | 用例执行记录、缺陷清单、结论页 | 测试负责人 | 交付评审前 | 必交 | STD-03 |
拆分时把握两个原则。一是组成件应是可独立判断有无和合格与否的最小单元，例如“需求追溯关系”可以单独核对覆盖情况，就单独成条；二是每个子检查项都要挂上验收标准编号，没有标准的条目在检查时只能凭主观判断，应补充标准或明确由评审人裁定。
必交项与条件交付项要分开标注。必交项缺失直接构成不通过；条件交付项要先判断触发条件是否成立，例如“存在外部接口”才需要接口说明，条件不成立时记录“不适用”并说明理由，避免把不适用误记为缺失。
检查执行步骤：输入、动作、输出与完成标志
检查按准备、逐项核对、缺口登记、复核关闭四个阶段推进，每个阶段都有明确的输入和完成标志，便于他人接手或复核。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 | 负责人 |
|---|---|---|---|---|---|
| 1. 准备 | 交付物清单、验收标准、过程记录、版本信息 | 确认依据均为当前有效版本，确定本次检查范围与条目 | 检查范围说明与条目清单 | 依据版本已确认，条目数与清单一致 | 检查人 |
| 2. 逐项核对 | 条目清单、交付物实体、验收标准 | 逐条比对内容是否齐全、是否达到合格条件，记录结论与依据出处 | 逐条检查结论 | 每个条目都有结论和依据指向 | 检查人 |
| 3. 缺口登记 | 不通过或有条件通过的条目 | 描述缺口、指定责任人与整改期限 | 缺口清单 | 每条缺口都有责任人和期限 | 检查人、交付物责任人 |
| 4. 复核关闭 | 整改结果、原缺口清单 | 复核整改是否消除缺口，更新结论 | 关闭后的检查记录 | 缺口全部关闭或经评审人确认接受 | 检查人、评审人 |
逐项核对阶段要留下依据指向，例如“D-01 需求追溯关系：已覆盖全部功能条目，见追溯表第 3 节”，而不是只写“符合”。依据指向让复核人不必重新翻查全部材料，也能判断结论是否成立。
缺口登记要写到可整改的粒度。“测试报告不完整”难以跟踪，“D-03 缺陷清单缺少严重级别字段，责任人测试负责人，期限交付评审前”则可以验证关闭。复核阶段只核对原缺口是否消除，不在此时扩大检查范围，新增问题另开一轮记录。
角色分工与检查记录
检查涉及四类角色，职责边界清晰才能避免依据无人提供或结论无人确认。
| 角色 | 职责 | 产出 |
|---|---|---|
| 交付物责任人 | 按清单提交交付物及组成件，提供过程记录，整改缺口 | 交付物实体、整改结果 |
| 检查人 | 收集依据、执行逐项核对、登记缺口、复核整改 | 检查记录、缺口清单 |
| 评审人 | 确认检查结论，对争议条目和条件接受做出裁定 | 结论确认意见 |
| 项目负责人 | 确认检查范围与交付节点衔接，决定不通过时的后续安排 | 节点放行或推迟决定 |
检查记录至少包含：检查对象与范围、所依据的清单与标准版本、每个条目的结论及依据指向、缺口描述、责任人、期限、总体结论、检查人与确认人、检查日期。结论状态建议定义为三档：通过指全部必交项合格且过程记录闭环；有条件通过指存在不影响交付使用的缺口，已登记责任人与期限并经评审人确认；不通过指必交项缺失、关键标准未达到或版本与基线不一致。
记录要与后续节点衔接。有条件通过的缺口应带入交付评审或下一阶段准入检查，作为跟踪项；不通过的结论要触发整改后再检，不能以口头承诺替代记录。检查条目、结论与缺口跟踪如果分散在邮件和表格中，复核成本会明显上升。ONES 的工作项可以承载检查条目与缺口，文档承载检查记录与评审意见，状态字段反映条目结论，使检查范围、逐条结论和缺口关闭在同一处可查，便于评审人按记录复核。
示例：一次版本交付前的完整性检查
场景设定：某研发项目计划在交付评审前对 V1.2 版本做一次完整性检查，检查范围按清单中“交付评审前”适用的条目确定，共涉及需求规格说明、接口说明、测试报告三项。以下为演示情景。
准备阶段确认清单为最新修订版，验收标准取交付阶段版本，版本记录显示待检对象为 V1.2 基线候选。逐项核对结果如下：
| 条目 | 核对内容 | 结论 | 依据指向 |
|---|---|---|---|
| D-01 需求规格说明 | 功能与非功能条目、追溯关系、变更记录 | 通过 | 追溯表覆盖全部功能条目，变更记录至 V1.2 |
| D-02 接口说明 | 接口清单、字段定义、异常约定 | 不通过 | 缺少异常约定章节 |
| D-03 测试报告 | 用例执行记录、缺陷清单、结论页 | 有条件通过 | 缺陷清单未标严重级别，评审记录已闭环 |
本轮发现三类典型缺口：缺组成件（接口说明缺异常约定）、缺字段（缺陷清单缺严重级别）、版本核对中发现测试报告引用的是 V1.1 的执行记录，与待检版本不一致，需责任人更新后重新核对。缺口登记为：D-02 由开发负责人补齐异常约定，期限评审前两日；D-03 由测试负责人补充严重级别并更新版本引用，期限评审前一日。
总体结论为不通过，原因是存在必交项不通过且版本引用不一致。整改完成后进入复核，D-02 与 D-03 缺口关闭，版本引用更新为 V1.2，复检结论改为通过，记录随交付评审材料一并提交。这个示例说明四类依据各自发挥作用：清单界定范围，标准判定内容，记录确认评审闭环，版本核对发现引用错位。
完成检查：判断本次检查是否可信
检查结束后，用以下清单确认结论可以被他人复核。任何一条不满足，结论都应暂缓发布。
- 四类依据齐全，且均为当前有效版本，清单与标准的版本号已记入检查记录。
- 检查范围与清单中本次适用条目一致，必交项与条件交付项的判定理由已写明。
- 每个条目都有明确结论和依据指向，不存在只写“符合”而无出处的条目。
- 每条缺口都有责任人、期限和可验证的关闭条件。
- 总体结论与逐条结论一致，有条件通过的缺口已经评审人确认。
- 检查记录包含检查人、确认人和日期，他人可据此复现核对过程。
阻断条件需要单独强调：依据缺失或版本不一致时，不得判定通过。清单或标准版本无法确认、待检对象与基线不一致、关键条目缺少过程记录，都属于阻断情形，应先补齐依据或更正版本，再重新执行核对。把阻断项当作普通缺口放行，会让检查记录失去可信度，也会把风险带到交付节点之后。
常见问题
交付物清单在检查过程中被修订了，应该以哪个版本为准？
以检查开始时确认的最新有效版本为准，并把该版本号记入检查记录。如果修订发生在检查进行中，应暂停当前核对，重新确认检查范围与条目，再按新版本执行；已经完成的条目若涉及变更内容，需要重新核对。记录中写明所用清单版本，复核人才能判断结论对应的是哪一版依据。
条件交付项的触发条件由谁判断，判断结果怎么留痕？
触发条件通常由交付物责任人在准备阶段提出，检查人核对条件是否成立，争议时由评审人裁定。判断结果应写入检查记录，例如“D-02 接口说明：本次无外部接口，判定不适用”，并附上判断理由。这样既避免把不适用误记为缺失，也避免条件实际成立却被跳过。
检查发现缺口后，整改期限已到但未完成，结论应该怎么处理？
期限已到而缺口未关闭，结论维持不通过或有条件通过，并记录延期原因与新期限，由项目负责人确认对交付节点的影响。不能用口头承诺替代记录，也不宜在缺口未消除时直接改为通过。若缺口经评审人确认可以接受，应在记录中写明接受理由和后续跟踪安排。
同一交付物在多轮检查中反复出现同类缺口，说明什么？
通常说明验收标准或条目拆分不够具体，责任人无法据此判断合格条件。可以回到清单与标准层面，把反复出现的缺口转化为明确的必填字段或检查项，例如把“缺陷清单需标严重级别”写入标准。这样下一轮检查就有可核对的依据，减少同类问题重复登记。
检查记录需要保存到什么程度才算可复核？
至少做到他人仅凭记录就能复现核对过程：知道检查了哪些条目、依据的是哪版清单和标准、每个条目的结论及出处、缺口如何关闭、总体结论由谁确认。记录中保留依据指向（如追溯表章节、评审记录编号），复核人不必重新翻查全部材料即可判断结论是否成立。
