项目交付物检查的依据通常来自四个层面：合同、需求规格与验收标准界定合格条件；质量计划、检查规程和模板规定检查方法；设计文档、技术标准与行业规范用于判断技术正确性；评审记录、变更单和测试报告支撑当前状态可追溯。本文按这四类依据展开，说明如何把交付物清单转成可执行的检查依据清单，并给出角色分工、示例和完成前核对项。
要点总览（TL;DR）
- 交付物检查依据分四类：合同与验收标准等约定类、质量计划与检查规程等管理类、设计文档与技术标准等技术类、评审记录与变更单等证据类。
- 编制检查依据清单分五步：列交付物清单并分级、匹配依据文件与条款、把条款转成可判定的检查项、确定检查方式与责任人时点、记录结论与证据。
- 交付物负责人先自检并提供证据，检查人按清单核对，质量或技术评审角色确认判定，项目经理协调依据冲突与检查节奏。
- 检查完成前核对四项：每项交付物都有对应依据、检查项可判定且有证据、问题项已记录并明确处理人、依据版本与交付物版本一致。
- 依据清单、检查记录与问题项可在同一协作平台中承载，ONES 的项目计划、里程碑基线与效能度量可作为检查安排与统计的参考。
交付物检查依据分哪几类
检查依据的作用是让“合格”有出处、让“不合格”有对照。收集依据时按四类归档，可以避免检查时只凭经验判断，也便于后续追溯。四类依据分别回答不同问题，缺一类都会让检查结论缺少支撑。
| 依据类别 | 典型文件 | 回答的问题 | 使用时的注意点 |
|---|---|---|---|
| 约定类依据 | 合同、需求规格说明书、验收标准、客户确认的需求变更 | 做到什么程度算合格 | 以已批准版本为准，口头约定需补成书面记录 |
| 管理类依据 | 项目质量计划、检查规程、交付物模板、评审规则 | 按什么方法、什么频次检查 | 检查规程应与项目实际裁剪情况一致 |
| 技术类依据 | 设计文档、接口说明、技术标准、行业规范 | 技术内容是否正确、完整 | 注明标准编号与版本，避免引用过期规范 |
| 证据类依据 | 评审记录、变更单、测试报告、问题跟踪记录 | 当前状态是否可查、问题是否闭环 | 证据应与交付物版本对应，能定位到具体条目 |
四类依据之间存在引用关系。约定类文件提出要求，技术类文件说明实现方式，管理类文件规定检查动作，证据类文件记录执行结果。编制检查依据清单时，把这种引用关系写清楚，检查人就能顺着条款找到判定出处，而不是在多个文档之间反复查找。
需要区分“依据”和“参考”。依据是判定合格与否的直接来源，参考是帮助理解背景的材料。检查项必须挂在依据上；背景说明、会议纪要中未形成决议的内容，可以作为参考，不宜单独作为判定不合格的理由。
从交付物清单到检查依据清单的操作步骤
检查依据清单的编制从交付物清单出发，经过匹配依据、转成检查项、确定检查安排、记录结论五步。每一步都有明确输入和输出，完成后形成一份可执行的清单，而不是一份文件目录。
第一步：列出交付物清单并分级
输入是项目计划、WBS或合同交付条款。动作是把本项目需要检查的交付物逐项列出，按重要程度分级，例如关键交付物、一般交付物、过程记录。输出是一张带编号的交付物清单。分级的作用是分配检查力度：关键交付物逐条核对并组织评审，一般交付物按清单抽查，过程记录以完整性检查为主。完成标志是每项交付物都有唯一编号、负责人和计划完成时间。
第二步：为每项交付物匹配依据文件与条款
输入是交付物清单和四类依据文件。动作是逐项写明该交付物依据哪些文件、具体到哪一章哪一条。输出是“交付物—依据文件—条款”的对应关系。匹配时优先使用已批准版本，遇到依据之间冲突，例如需求规格与合同附件表述不一致，应先提交变更或澄清，形成书面结论后再写入清单。完成标志是每项交付物至少有一条约定类依据和一条技术类依据，关键交付物还应关联评审规则和证据要求。
第三步：把依据转成可判定的检查项
输入是依据条款。动作是把条款改写成检查人能直接判断“是或否”的检查项，并写明判定标准和证据形式。输出是检查项列表。判定标准要具体，例如“需求条目均有唯一编号，且与验收标准逐条对应”，避免“内容完整”“描述清晰”这类无法留证的表述。完成标志是每个检查项都能回答三个问题：查什么、合格长什么样、用什么证明。
第四步：确定检查方式、责任人与时点
输入是检查项列表和项目角色安排。动作是为每个检查项指定检查方式（文档审查、逐条比对、演示验证、抽样检查）、检查人和检查时点（交付物提交前自检、提交后检查、里程碑评审）。输出是带责任人和时间安排的检查依据清单。完成标志是每个检查项都有明确检查人，且检查时点早于该交付物被下游使用或对外提交的时间。
第五步：记录检查结论与证据
输入是执行检查后的结果。动作是逐项记录结论（符合、不符合、不适用）、证据位置和问题描述。不符合项要写明对应依据条款、影响范围和整改要求。输出是检查记录和问题清单。完成标志是所有检查项都有结论，不符合项已指定处理人和计划完成时间，证据能通过编号或链接定位。
这五步完成后，检查依据清单至少包含以下字段：交付物编号、交付物名称、级别、依据文件及条款、检查项、判定标准、检查方式、检查人、检查时点、结论、证据位置、问题编号。字段不必一次求全，但依据条款、检查项和判定标准三项应在检查开始前确定，避免检查过程中临时调整标准。
检查中的角色分工与交付物
检查依据由不同角色提供，检查动作也由不同角色执行。分工不清时，常见结果是交付物负责人认为依据应由质量角色准备，检查人等到交付物提交后才开始找标准。把提供依据、执行检查、确认结论三类职责分开，可以让检查在交付物形成过程中就介入。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 交付物负责人 | 提供自检结果和支撑证据，说明交付物与依据条款的对应关系 | 自检记录、交付物、证据清单 |
| 检查人 | 依据检查依据清单逐项核对，记录结论和问题 | 检查记录、问题清单 |
| 质量角色或技术评审角色 | 确认判定标准适用性，复核争议项和关键交付物结论 | 评审意见、结论确认记录 |
| 项目经理 | 确认检查范围与时机，协调依据冲突，决定问题处理优先级 | 检查计划、问题处理决定 |
| 问题处理人 | 按整改要求修改交付物并提交复检证据 | 整改记录、复检申请 |
交付物负责人的自检应发生在正式检查之前。自检时按检查依据清单逐项对照，把证据放到指定位置，对无法满足的条款提前说明原因。检查人拿到的是带自检结论的交付物，检查工作就从“找问题”转为“验证结论”，效率更高，也更容易发现自检遗漏。
质量或技术评审角色的确认重点在判定标准本身。当检查人与交付物负责人对某条款理解不一致时，由该角色给出解释并记录，避免同类问题在后续交付物中反复争论。项目经理则负责检查节奏：关键交付物的检查时点应安排在阶段评审或里程碑之前，给整改留出时间。
问题项的跟踪责任要落到具体人。检查记录中的每个不符合项都应有唯一编号、对应依据条款、处理人和计划完成时间。复检通过后关闭问题，复检不通过则重新指定处理要求。问题清单与检查记录分开维护，便于按交付物、按依据条款或按责任人汇总查看。
当项目使用协作平台承载这些记录时，可以把交付物、依据清单、检查记录和问题项放在同一工作空间中，让版本和责任人保持对应。ONES 的项目计划支持按交付物或项目阶段分解工作，里程碑可用于标记检查时点；计划和里程碑基线可用于对比交付进度与检查安排的偏差。检查结论和问题项可以在工作项中流转，依据文件与交付物版本在文档中关联，便于检查人按同一编号追溯。具体字段和流程配置需按团队实际检查规程确定。
示例：一份需求文档的检查依据如何落地
以下示例为演示情景，用于说明依据如何对应到检查项，不代表特定项目的实际记录。假设某项目需要检查一份已提交的需求文档，检查时点为需求评审前。
| 检查项 | 依据来源 | 判定标准 | 证据形式 |
|---|---|---|---|
| 需求条目完整性 | 需求规格说明书模板第3节；项目质量计划中需求评审规则 | 每条需求有唯一编号、优先级、验收标准，无空白字段 | 文档编号与条目清单 |
| 与合同范围一致性 | 合同附件一交付范围；需求规格第2章范围说明 | 文档中功能范围不超出合同约定，超出部分有已批准变更单 | 范围对照表、变更单编号 |
| 评审意见闭环 | 上一版评审记录；问题跟踪记录 | 上一版评审提出的问题均有处理结论，未关闭项有处理计划 | 评审记录与问题编号对应表 |
| 变更可追溯 | 变更单及其影响分析 | 本版相对上一版的修改均能对应到变更单或评审意见 | 版本对比说明、变更单编号 |
| 验收标准可验证 | 验收标准文件；行业或技术规范相关条款 | 每条验收标准有对应测试或验证方法，表述可判定 | 验收标准与验证方法对照表 |
检查人按上表逐项核对后，在检查记录中填写结论。例如“需求条目完整性”一项，若发现三条需求缺少验收标准，结论记为不符合，问题描述写明条目编号和缺失字段，对应依据为模板第3节，处理人为需求文档负责人，计划完成时间设在评审前。复检时只核对这三条及受影响的关联条目，不必重查全部内容。
这个示例说明两点。第一，检查项来自依据条款的改写，而不是凭经验列出的通用问题。第二，证据形式在检查前就确定，检查人不需要在检查过程中临时决定用什么证明。需求文档之外，设计文档、测试报告、部署方案等交付物也按同样方式处理，区别只在依据文件和技术标准的选取。
检查完成前要核对什么
检查记录填写完毕不等于检查完成。完成前按以下清单逐项核对，可以避免“查过了但说不清依据”“问题记了但没人处理”这类情况。
- 每项交付物都有对应依据。交付物清单中的每一项都能在检查依据清单中找到至少一条约定类依据和技术类依据；标记为不适用的检查项写明了理由和确认人。
- 检查项可判定、有证据。每个检查项的判定标准能回答“合格长什么样”，结论有对应的证据位置；没有出现“基本符合”“大致满足”这类无法复核的结论。
- 问题项已记录并明确处理人。每个不符合项有唯一编号、对应依据条款、处理人和计划完成时间；影响关键交付物的问题已告知项目经理，并确定了是否影响后续阶段。
- 依据版本与交付物版本一致。检查所引用的需求规格、设计文档、标准和模板均为当前有效版本；交付物在检查后发生修改的，修改部分已重新对照依据并补充检查记录。
- 结论已确认。关键交付物的检查结论经质量或技术评审角色确认；检查记录、问题清单和证据已归档到项目约定的位置，下游角色可以按编号查阅。
核对中发现缺项，先补依据或补证据，再确认结论。依据本身存在冲突且未形成书面结论的，该交付物的检查暂不判定为完成，待澄清后再记录。完成核对后，检查依据清单、检查记录和问题清单构成该交付物的质量证据，随项目阶段归档，供后续评审和验收引用。
常见问题
检查依据之间互相冲突时，应该以哪一份为准？
依据冲突常见于合同附件与需求规格表述不一致，或技术标准版本更新后与设计文档引用不一致。处理原则是先确认哪份文件经过正式批准且处于有效版本，再判断冲突是否涉及范围或验收条件的变化。
涉及合同范围、验收标准的冲突，应提交变更或澄清，形成书面结论后再写入检查依据清单；涉及技术标准版本的，以项目质量计划中指定的标准版本为准，并在清单中注明编号与版本。冲突未形成书面结论前，相关检查项暂不判定为符合，也不宜由检查人自行选择其中一份作为判定依据。
交付物在检查后发生修改，原来的检查记录还能用吗？
检查记录对应的是被检查的那个版本，交付物修改后原记录不能直接沿用。可行的做法是保留原记录作为历史证据，同时明确修改涉及哪些检查项和依据条款，只对受影响部分重新对照依据并补充检查记录。
如果修改涉及范围、验收标准或关键设计，应重新走一遍对应检查项，必要时请质量或技术评审角色确认。检查依据清单中记录交付物版本号，可以让后续查阅的人分清每条结论对应哪个版本。
项目周期紧，能不能只检查关键交付物？
可以按交付物分级分配检查力度，这是检查依据清单中设置级别的目的。关键交付物逐条核对并组织评审，一般交付物按清单抽查，过程记录以完整性检查为主。
需要守住的条件是：被抽查或简化检查的交付物，其依据条款和判定标准仍需在检查前写明，抽查范围和抽样规则也要记录，避免事后无法说明检查覆盖了哪些内容。涉及对外提交、验收或下游阶段启动的交付物，即使级别不高，也建议保留完整检查记录。
检查人由谁担任比较合适，能否由交付物负责人自己检查？
交付物负责人先做自检是必要环节，自检结果和证据是正式检查的输入。正式检查由独立于交付物编写的人执行更合适，可以是同项目的其他成员、质量角色或技术评审角色，具体取决于交付物类型和项目安排。
关键交付物建议由具备相应技术判断力的人检查，并在结论上经质量或技术评审角色确认。检查人与交付物负责人对条款理解不一致时，由评审角色给出解释并记录，避免同类争议在后续交付物中重复出现。
检查依据清单需要覆盖项目全部交付物吗？
清单应覆盖项目计划或合同交付条款中列出的交付物，但检查深度可以不同。编制时先列出全部交付物并分级，再为每项匹配依据；对不适用检查的条目写明理由和确认人，而不是直接省略。
项目执行中新增的交付物，应在纳入计划时同步补充依据条款和检查安排。清单字段不必一次求全，但依据条款、检查项和判定标准三项应在检查开始前确定，避免检查过程中临时调整标准。
