研发交付物清单要同时回答两个问题：这份交付物从哪个版本、哪次构建或提交产生，以及它凭什么算完整。本文给出一张可直接复制到表格工具的空白清单，按“一物一行、一版本一记录”组织，把交付物本体、版本来源和完整性证据放在同一行，并附字段口径、必填规则、填写示例与版本迭代时的维护方法，适用于软件、固件及配套文档等需要按版本交付的研发场景。
要点总览（TL;DR）
- 清单按“一物一行、一版本一记录”组织，同一交付物新版本新增行，历史行保留不覆盖。
- 版本来源至少记录版本号、来源系统/仓库、构建或提交标识、产出时间，四项结合才能唯一定位一次产出。
- 完整性以组成文件清单、校验值、评审/验收记录、缺失项说明四类证据判断，缺失项无内容也须填“无”。
- 必填字段缺失时交付状态保持“待交付”，在缺失项说明中标注原因与补齐计划，补齐后再改为“已交付”。
- 清单随版本迭代维护，字段增删保留旧口径说明，按批次或里程碑导出只读版本归档。
可复制空白模板：研发交付物清单表
下表可直接复制到 Excel、在线表格或文档表格中使用。列按四组排列：基本信息、版本来源、完整性证据、交付状态。填写时一行对应一个交付物的一个版本，同一交付物出现新版本时新增一行，旧行保留。
| 分组 | 字段 | 填写内容 |
|---|---|---|
| 基本信息 | 记录编号 | |
| 基本信息 | 交付物名称 | |
| 基本信息 | 交付物类型 | |
| 基本信息 | 所属需求/模块 | |
| 基本信息 | 交付批次/里程碑 | |
| 版本来源 | 版本号 | |
| 版本来源 | 来源系统/仓库 | |
| 版本来源 | 构建或提交标识 | |
| 版本来源 | 产出时间 | |
| 版本来源 | 产出责任人 | |
| 完整性证据 | 组成文件清单 | |
| 完整性证据 | 校验值 | |
| 完整性证据 | 评审/验收记录 | |
| 完整性证据 | 缺失项说明 | |
| 交付状态 | 交付状态 | |
| 交付状态 | 备注 |
如果交付物数量较多，建议在表格上方加一行表头说明填写口径，例如“版本号与来源系统须对应同一构建记录”，避免不同填写人对字段理解不一致。表格本身保持纯数据行，便于后续筛选和统计。
字段说明：版本来源与完整性各记什么
版本来源回答“这份东西从哪来”，完整性证据回答“这份东西齐不齐”。两组字段要能相互对应：来源字段定位到唯一一次产出，完整性字段描述这次产出的实际内容与核对结果。只写版本号而不写来源标识，后续无法确认对应哪次构建；只写“已完成”而不写证据，完整性无法复核。
| 字段 | 含义 | 取值口径 |
|---|---|---|
| 版本号 | 交付物对外标识的版本 | 按团队版本规范填写，如 2.3.0；同一交付物不同版本号不得重复 |
| 来源系统/仓库 | 产出该版本的系统或代码仓库 | 写系统名与仓库路径，如“代码仓库/项目A/服务端” |
| 构建或提交标识 | 定位到具体一次构建或提交的唯一标识 | 填写构建号或提交哈希，能唯一定位即可 |
| 产出时间 | 该版本生成的时间 | 精确到日期与时分，使用统一时区 |
| 产出责任人 | 执行构建或整理交付物的人 | 写姓名或工号，便于回溯 |
| 组成文件清单 | 该交付物包含的文件或制品列表 | 列出文件名与数量，多文件可附清单编号 |
| 校验值 | 用于验证文件未被改动的摘要值 | 填写算法与值，如 SHA-256 摘要；多文件逐个记录或记录清单文件摘要 |
| 评审/验收记录 | 证明交付物通过检查的记录 | 写评审单号、评审结论与日期 |
| 缺失项说明 | 本次交付中未包含或待补的内容 | 写明缺失项、原因与计划补齐时间；无缺失填“无” |
来源与完整性的对应关系体现在同一行内：构建或提交标识确定唯一产出，组成文件清单和校验值描述这次产出的实际内容，评审记录说明内容经过检查，缺失项说明则交代检查中发现的缺口。四类信息齐全，一行记录才具备可追溯性。
必填与选填：哪些字段缺一不可
必填字段是判断“这份交付物是否存在、是否可追溯、是否完整”的最低信息集。缺少任一必填字段，该行记录不能标记为已交付。选填字段根据交付场景补充，不影响基本判断。
| 字段 | 必填/选填 | 理由或适用场景 |
|---|---|---|
| 记录编号 | 必填 | 唯一标识一行，便于引用和核对 |
| 交付物名称 | 必填 | 识别交付对象 |
| 交付物类型 | 必填 | 区分安装包、文档、配置文件等，影响完整性判断方式 |
| 版本号 | 必填 | 版本追溯的基础 |
| 来源系统/仓库 | 必填 | 定位产出位置 |
| 构建或提交标识 | 必填 | 定位到唯一一次产出 |
| 产出时间 | 必填 | 判断版本先后与时效 |
| 组成文件清单 | 必填 | 完整性判断的直接依据 |
| 校验值 | 必填 | 验证文件未被改动 |
| 缺失项说明 | 必填 | 无缺失也须填“无”，避免空白被误解为未检查 |
| 交付状态 | 必填 | 标明当前处于待交付、已交付或已撤回 |
| 所属需求/模块 | 选填 | 交付物与需求关联紧密时填写，便于按需求汇总 |
| 交付批次/里程碑 | 选填 | 按批次集中交付时填写 |
| 产出责任人 | 选填 | 需要回溯到人时填写；小团队可省略 |
| 评审/验收记录 | 选填 | 交付物需要正式评审或客户验收时填写 |
| 备注 | 选填 | 记录特殊情况 |
必填字段缺失时的处理规则：先在缺失项说明中标注缺什么、为什么缺、计划何时补齐，交付状态保持“待交付”；补齐后更新该行并改为“已交付”。如果校验值暂时无法提供，应在备注中说明原因，并在约定时间内补录，不能以空白代替。团队可将必填字段设为表格的必填校验或条件格式，减少漏填。
填写示例：一条完整交付物记录
以下是一条已填写的记录，演示版本来源与完整性字段如何写实、写全。
| 字段 | 示例取值 |
|---|---|
| 记录编号 | DLV-2024-0312-01 |
| 交付物名称 | 订单服务安装包 |
| 交付物类型 | 安装包 |
| 所属需求/模块 | 订单模块 |
| 交付批次/里程碑 | 2024年3月迭代 |
| 版本号 | 2.3.0 |
| 来源系统/仓库 | 代码仓库/项目A/订单服务 |
| 构建或提交标识 | 构建号 build-20240312-07 |
| 产出时间 | 2024-03-12 15:40 |
| 产出责任人 | 张工 |
| 组成文件清单 | order-service-2.3.0.tar.gz、部署说明.md、配置样例.yaml，共3个文件 |
| 校验值 | SHA-256：3f9c…（安装包）；清单文件摘要另记 |
| 评审/验收记录 | 评审单 RV-118，结论通过，2024-03-12 |
| 缺失项说明 | 无 |
| 交付状态 | 已交付 |
| 备注 | 配置样例仅含测试环境参数 |
逐项看，版本号 2.3.0 与构建号 build-20240312-07 对应同一次产出，来源仓库写明到服务目录，产出时间精确到分钟，三者结合可以唯一定位这次构建。组成文件清单列出三个文件及数量，校验值针对安装包记录摘要，评审记录给出单号与结论，缺失项明确写“无”。这样一行记录既能回答“从哪来”，也能回答“齐不齐”。
常见简写与规范写法对比：版本来源只写“最新版”，应改为具体版本号加构建标识；完整性只写“已完成”，应改为组成文件清单加校验值加评审结论；缺失项留空，应写“无”或写明缺失内容与补齐计划；来源写“本地打包”，应写清仓库路径与构建号。规范写法的共同点是每个字段都能被他人独立核对。
调整与维护：清单随版本迭代的更新方法
清单的价值在于长期可追溯，维护规则要在第一次填写时就确定。核心原则是历史行不覆盖、不删除，新版本以新增行体现，字段调整保留旧口径说明。
- 新增版本行：同一交付物发布新版本时，复制上一行结构，更新版本号、构建或提交标识、产出时间、组成文件清单与校验值，记录编号按规则递增，旧行保持原样。
- 保留历史行：已交付的历史行不修改内容；如需更正，在备注中注明更正原因与时间，保留原值可查。
- 字段增删：新增字段时在表头说明中注明启用日期与填写口径，旧行该字段留空并标注“启用前不适用”；删除字段前先确认无追溯依赖，历史数据保留在归档版本中。
- 定期核对：按交付批次或固定周期核对必填字段是否齐全、校验值是否与文件一致、缺失项是否已补齐，核对结果记入备注或单独的核对记录。
- 归档：每个里程碑或交付批次结束后，将清单导出为只读版本归档，归档文件与交付物一并保存，后续查询以归档版本为准。
当交付物数量增多、参与角色变多时，清单的维护动作可以放到工作项和文档管理中完成：交付物对应到具体工作项，版本来源与构建标识随工作项流转记录，评审结论和验收状态在评审环节更新，清单文档按批次归档并保留历史版本。ONES 支持工作项状态流转、文档协作与版本记录，可用于承载这类“交付物—版本—评审—归档”的连续过程，让清单中的来源与完整性字段有对应的过程记录可查，减少手工补录。是否引入工具承载，取决于团队交付频次和参与人数；交付物少、节奏慢的团队用共享表格配合上述规则即可。
常见问题
交付物由外部供应商提供，来源系统和构建标识怎么填？
外部交付物同样需要定位到唯一一次产出。来源系统/仓库可填写供应商名称与交付包编号或合同编号，构建或提交标识填写供应商提供的版本标识、交付批次号或签收单号，产出时间以供应商实际交付时间为准。组成文件清单和校验值由供应商随包提供，接收方在核对后记录。若供应商无法提供校验值，应在缺失项说明中注明原因，并在备注中记录替代核对方式，例如开箱检查记录或签收单号。
同一版本需要补发或重新打包时，清单怎么记录？
补发或重新打包会产生新的产出，应新增一行记录，版本号可沿用并在备注中注明“补发”或“重新打包”，构建或提交标识、产出时间、组成文件清单和校验值按新产出填写。原行保留，交付状态可改为“已撤回”或保持“已交付”并在备注中说明替代关系。这样后续追溯时能区分原始交付与补发交付，避免用新文件覆盖旧记录。
清单里的校验值是否每个文件都必须单独记录？
校验值的目的是验证交付内容未被改动，记录粒度可与交付物形态匹配。单文件交付物直接记录该文件的摘要值；多文件交付物可以逐个文件记录，也可以为文件清单生成一个摘要值并记录清单文件本身的摘要。无论哪种方式，都应在清单中写明算法和覆盖范围，使他人能按同样方式复核。若部分文件暂无法提供校验值，在缺失项说明中标注并约定补录时间。
交付物数量少、团队规模小，是否也需要完整执行必填字段规则？
必填字段规则用于保证可追溯和可核对，交付物少时同样建议保留最低信息集，但字段的呈现方式可以简化。例如记录编号可按日期加序号简写，产出责任人可由团队共用账号或角色代替。简化的是填写形式，版本号、来源标识、组成文件清单、校验值和缺失项说明这些判断依据仍应保留。团队可在清单表头说明中写明简化口径，保持前后一致。
清单归档后发现问题需要更正，应该改原记录还是新增记录？
归档版本以只读方式保存，发现问题时不直接修改归档文件。可在当前使用的清单中新增一条更正记录，引用原记录编号，写明更正内容、原因和时间，并将原记录状态标注为“已更正”。若团队使用文档或工作项承载清单，可保留历史版本并在新版本中说明变更。这样既保留原始证据，也能看到更正过程。
