研发交付物与制品管理的难点，往往不在构建本身，而在构建完成之后：同一个发布包在不同人手里有不同叫法，交付时说不清它对应哪次代码提交，归档几个月后无法确认文件是否被替换。本文按“定分类、定标识、定来源记录、定完整性校验、定保留规则、定交付清单”的顺序，给出可直接落地的规则、字段、角色分工与检查清单，适用于需要向内部团队、客户或验收方交付软件版本的研发组织。
要点总览（TL;DR）
- 先按构建制品、发布包、交付文档、配套说明四类划分交付物，每类指定唯一负责人和唯一登记位置，再用“项目代号+版本号+构建序号+构建日期”形成唯一版本标识。
- 每件交付物登记代码版本、构建任务、构建时间、构建环境，并关联需求或变更单，形成“需求—提交—构建—交付物”的可追溯链路。
- 构建完成后立即生成 SHA-256 校验值并随交付物登记，交付方与接收方各自复算，结果一致才进入验收，不一致时暂停交接并记录处置过程。
- 保留策略按类别区分期限，明确归档位置与访问权限；到期清理前做影响检查，例外保留走审批并留存记录。
- 交付清单汇总名称、版本标识、校验值、来源和文档清单，双方逐项核对签字；以标识、来源、完整性、保留、清单五类检查项验证流程是否可运行。
先定交付物分类与版本标识规则
交付物管理的起点是让每件资产有唯一身份。分类解决“这是什么”，标识解决“这是哪一版”，两者确定后，登记、追溯、校验和交接才有共同语言。建议在流程启动阶段用一张分类表覆盖全部交付对象，避免后续出现同一文件多处登记、名称各写一套的情况。
交付物分类框架
按用途和形态划分四类，每类指定唯一负责人和唯一登记位置。分类不宜过细，四类足以覆盖多数研发交付场景；团队规模较大时可在“发布包”下再按交付渠道细分，但登记位置仍保持一处。
| 类别 | 典型内容 | 负责人 | 登记位置 |
|---|---|---|---|
| 构建制品 | 编译产物、镜像、库文件、安装程序 | 构建负责人 | 制品库或交付物登记表 |
| 发布包 | 面向环境的整包、补丁包、升级包 | 发布负责人 | 发布记录与交付物登记表 |
| 交付文档 | 安装手册、部署说明、接口文档、验收报告 | 文档负责人 | 文档库，与版本关联 |
| 配套说明 | 版本说明、已知问题、配置清单、第三方依赖清单 | 版本负责人 | 随发布包同目录归档 |
版本标识的构成与命名规则
版本标识建议由四段组成：产品/项目代号、语义化版本号、构建序号、构建日期。例如 PROJ-2.4.0-b0138-20250612。规则要点有三条：同一交付物只保留一个权威标识，其他位置的引用一律指向该标识；构建序号在同一版本号下单调递增，不复用；预发布与正式发布用后缀区分，如 -rc1、-ga。命名规则由配置管理员制定并发布，研发与构建人员按规则生成，配置管理员负责登记与核对。
记录来源与构建信息，保证可追溯
可追溯的含义是：拿到任意一件交付物，能回答它从哪段代码、哪次构建、哪个需求或变更而来。实现方式是在交付物登记时同步写入来源字段，并与需求、代码提交、构建任务建立关联，而不是事后凭记忆补充。
来源信息字段清单
| 字段 | 说明 | 填写人 |
|---|---|---|
| 代码版本 | 分支名与提交哈希，或标签名 | 构建负责人 |
| 构建任务 | 构建流水线编号或任务链接 | 构建负责人 |
| 构建时间 | 精确到分钟，注明时区 | 构建系统自动记录 |
| 构建环境 | 操作系统、编译器/运行时版本、依赖锁定文件版本 | 构建负责人 |
| 关联需求/变更单 | 需求编号或变更单编号，可多条 | 版本负责人 |
关联方式与缺失补录
关联建议在构建任务中完成：构建时自动写入代码版本与构建信息，发布前由版本负责人补充需求与变更单编号，形成“需求—提交—构建—交付物”的链路。若登记时发现字段缺失，按补录流程处理：由构建负责人回溯构建日志补齐代码版本与构建环境，由版本负责人核对需求关联，补录完成后由配置管理员复核并标注补录时间。补录记录本身应保留，便于后续审计区分原始登记与事后补充。
当交付物需要沿需求链路回溯影响范围时，ONES 可将需求、版本、变更、测试与发布作为关联对象管理，需求变化时沿关联关系定位受影响的任务、测试与交付内容，并保留过程记录（依据官网 ALM 解决方案描述，具体配置以实际环境为准）。
用校验值确认完整性
完整性校验回答的是“这份文件还是当初构建出来的那一份吗”。做法是用哈希算法生成校验值，随交付物登记，交付与接收双方各自复核，结果一致才进入交接。
操作步骤
- 构建完成后立即对每个交付文件生成校验值（常用 SHA-256），由构建系统自动输出校验文件。
- 登记时把校验值与版本标识写入同一行记录，校验文件随发布包一起归档。
- 交付前，交付方对准备发出的文件重新计算校验值，与登记值比对。
- 接收方收到文件后独立计算一次，与交付清单上的校验值比对，双方结果一致后在验收记录上签字确认。
不一致时的处置
校验不一致时暂停交接，不进入验收环节。处置顺序为：确认传输过程是否完整（重新传输并复算）；确认是否取错版本（核对版本标识与登记记录）；确认文件是否被改动（比对文件大小、修改时间，必要时回溯构建记录重新构建）。每次异常都应在异常处置记录中写明发现时间、涉及交付物、比对结果、原因判断和处理结论，由配置管理员归档。
制定保留策略与归档规则
保留策略要回答三个问题：每类交付物留多久、放在哪里、谁能访问。策略按类别区分，避免“一刀切”导致该留的删了、该清的占着空间。
| 类别 | 建议保留期限 | 归档位置 | 访问权限 |
|---|---|---|---|
| 构建制品 | 最近若干个版本，正式发布版本长期保留 | 制品库，按项目与版本目录归档 | 研发与构建人员可读，删除需审批 |
| 发布包 | 与对应版本的维护周期一致 | 发布归档区，与交付清单同目录 | 发布与交付对接人员可读 |
| 交付文档 | 随版本长期保留 | 文档库，按版本打标签 | 项目成员可读，对外交付版本单独授权 |
| 配套说明 | 随发布包同期保留 | 与发布包同目录 | 同发布包 |
到期清理前先做影响检查：确认无在维护版本引用、无未关闭的客户问题关联。例外保留（如合同要求、审计需要、在用旧版本）须提交审批，写明保留原因、延长时限和责任人，审批记录与交付物一并归档。清理操作保留操作日志，便于事后核查。
编写交付清单并完成交接验收
交付清单是整条流程的收口文件，它把前面所有登记信息汇总成一页可核对的凭证。清单应在交付前由版本负责人编制，交接双方逐项确认。
交付清单字段
| 字段 | 填写要求 |
|---|---|
| 交付物名称 | 与登记名称一致，不使用简称 |
| 版本标识 | 完整标识，含构建序号与日期 |
| 校验值 | SHA-256 值，逐文件列出 |
| 来源 | 代码版本、构建任务、关联需求/变更单 |
| 文档清单 | 随附文档名称与版本，注明是否必读 |
| 交付日期与双方 | 交付方、接收方、交付时间 |
交接与验收流程
流程为：交付方编制清单并自检 → 双方约定交接方式与时间 → 接收方按清单逐项核对文件与校验值 → 核对通过后双方在验收记录上签字，记录归档；核对不通过则填写缺失或差异项，退回交付方处理并约定重新交付时间。退回记录要写明退回原因、责任人和再次交付日期，作为版本发布记录的一部分保留。
在 ONES 中，交付物模板、评审节点与版本发布记录可以沉淀为可复用资产，使交付清单和验收记录按统一格式在项目中执行，而不是每次重新约定（依据官网 ALM 解决方案描述）。
角色分工与各环节交付物
流程能否运行，取决于每个环节是否有人负责、有产出可查。下表按角色列出职责与对应交付物，交接点即上一环节的产出成为下一环节的输入。
| 角色 | 主要职责 | 产出 | 交接给 |
|---|---|---|---|
| 研发人员 | 提交代码并关联需求/变更单 | 代码提交记录、变更说明 | 构建负责人 |
| 构建负责人 | 执行构建、生成校验值、登记来源信息 | 构建制品、校验文件、来源记录 | 配置管理员 |
| 配置管理员 | 维护标识规则、核对登记、管理归档与清理 | 交付物登记表、归档记录、清理审批记录 | 版本负责人 |
| 版本负责人 | 编制交付清单、组织交接 | 交付清单、版本说明 | 交付对接人员 |
| 交付对接人员 | 与接收方交接、组织验收、记录退回 | 验收记录、退回处理记录 | 配置管理员归档 |
职责冲突或空缺时，由流程负责人指定临时责任人并书面记录，临时责任人的产出同样进入登记与归档。常见空缺是构建负责人与配置管理员由同一人兼任，此时应在流程文件中明确该人员对登记信息的自检要求，并由版本负责人在交付前做一次独立核对。
示例：一次版本发布的交付物管理过程
以下为演示场景，用于说明各环节如何衔接，不代表真实客户案例。假设某项目发布 2.4.0 版本，交付给客户现场部署。
- 构建：研发完成合并，构建任务执行成功。输入为代码提交与构建配置，动作为编译打包并生成 SHA-256 校验文件，输出为构建制品、校验文件与构建日志，检查点为构建任务编号与提交哈希已记录。
- 登记：配置管理员按命名规则登记版本标识
PROJ-2.4.0-b0138-20250612，写入代码版本、构建任务、构建时间、构建环境，版本负责人补充关联的需求与变更单。检查点为登记表字段完整、无空缺。 - 组包：版本负责人将发布包、交付文档、配套说明放入同一归档目录，生成交付清单初稿。检查点为清单中每个文件都有校验值。
- 自检与交接：交付方复算校验值并与登记值比对，一致后与接收方约定交接。接收方独立复算，逐项核对清单，双方签字确认验收记录。检查点为验收记录已归档、校验结果一致。
- 归档与保留：配置管理员将本次交付物按保留策略归档，标注保留期限与访问权限。检查点为归档目录与登记记录指向同一版本标识。
整个过程的关键控制点是：构建后立即生成校验值、登记时字段齐全、交付前双方各自复算、验收记录与交付清单同目录归档。任一检查点不通过，流程停在该环节处理，不进入下一环节。
完成检查：交付物管理是否到位
用下表逐项核对，每项以可查证据为准，不以口头说明作为通过依据。
| 检查类别 | 检查项 | 通过标准与证据 |
|---|---|---|
| 标识 | 每件交付物是否有唯一版本标识 | 登记表中无重复标识，命名符合规则；证据为登记记录 |
| 来源 | 来源字段是否完整并与需求/变更关联 | 代码版本、构建任务、构建时间、构建环境齐全；证据为登记记录与构建日志 |
| 完整性 | 校验值是否生成、登记并在交付时复核 | 每个文件有校验值，双方复核结果一致；证据为校验文件与验收记录 |
| 保留 | 保留期限、归档位置、权限是否明确并执行 | 有保留策略表，归档记录可查，清理有审批；证据为策略文件与审批记录 |
| 清单 | 交付清单字段是否齐全、验收是否留痕 | 清单含名称、标识、校验值、来源、文档清单，双方签字；证据为清单与验收记录 |
常见缺口有三类：一是标识规则存在但登记表里仍有手写简称，整改方向是把登记入口收敛到一处并做交付前核对；二是校验值只在构建时生成、交付时未复算，整改方向是把复算写入交接步骤并纳入验收记录；三是保留策略缺失导致旧版本被误删，整改方向是先补策略表再执行清理，清理前增加影响检查。五类检查全部有证据支撑，流程即可视为可运行；出现缺项时按对应整改方向处理，并在下一次版本发布中验证。
常见问题
交付物数量不多的小团队，是否也需要完整的分类表和版本标识规则？
建议保留分类和标识两项，其余环节可以简化。分类表即使只有四行，也能避免同一文件在多个位置以不同名称出现；版本标识规则确定后，构建、登记和交付引用同一个标识，后续追溯成本明显降低。小团队可以把登记表与交付清单合并为一张表，由一人兼任构建与配置管理职责，但交付前的独立核对仍需保留，可由版本负责人执行。
交付物已经交付给客户，后来发现来源信息登记不全，应该怎么处理？
按补录流程处理，并保留补录痕迹。由构建负责人回溯构建日志补齐代码版本与构建环境，由版本负责人核对需求与变更单关联，配置管理员复核后在登记记录中标注补录时间和补录人。已经发出的交付清单不做覆盖修改，另附补充说明并与原清单同目录归档，便于审计时区分原始登记与事后补充。若补录中发现交付物本身与登记不符，应转入完整性异常处置流程。
校验值一致是否就说明交付物没有问题？
校验值一致说明收到的文件与登记时计算的文件内容相同，能确认传输完整、文件未被替换。它不能证明这份文件来自正确的代码版本，也不能证明构建过程符合要求。因此完整性校验需要与来源记录配合使用：先核对版本标识与来源字段，确认取的是正确版本，再复算校验值确认文件内容一致。两者都通过，交付物才具备进入验收的条件。
保留期限到期后，如何判断某个旧版本能不能清理？
清理前做三项影响检查：确认没有仍在维护的版本引用该交付物，确认没有未关闭的客户问题关联该版本，确认合同或审计要求未覆盖该版本。三项均无关联时按策略清理，并保留操作日志。存在任一关联时提交例外保留审批，写明保留原因、延长时限和责任人。清理操作建议由配置管理员执行、版本负责人复核，避免误删仍在使用的资产。
交付清单被接收方退回后，重新交付时清单怎么处理？
退回时在清单上填写缺失或差异项、退回原因、责任人和约定的再次交付日期，原清单作为记录保留。重新交付时编制新版本清单，版本标识注明修订次数，校验值按实际发出的文件重新登记。再次交接仍按原流程逐项核对并签字，退回记录与新清单一并归档，作为版本发布记录的一部分。若退回原因是交付物本身需要重新构建，则从构建环节重新走流程，不在原交付物上直接修补。
