研发交付物清单把每次交付的构建制品、发布包和交付文档逐项登记下来，用版本标识、来源、完整性校验、保留期限、交付对象与状态固定每个交付物的身份和去向。本文提供可直接复制的空白表格、逐字段填写说明、必填与选填划分、一份完整填写示例，以及清单随版本迭代的调整与维护方法。
要点总览（TL;DR）
- 空白模板采用一行一个可交付对象的结构，表头包含交付物名称、类型、版本标识、来源、完整性校验、保留期限、交付对象、交付状态、责任人、交付日期与备注。
- 必填字段为交付物名称、类型、版本标识、来源、完整性校验、交付对象与交付状态；责任人、保留期限、交付日期、备注按交付场景选填。
- 填写示例以一次 v2.3.1 版本发布演示四类交付物的登记方式，制品类记录哈希与保留期限，文档类记录评审状态与页数。
- 维护动作与发布节奏绑定：每次发布后更新状态与日期，新增交付物另起一行，历史清单按发布批次留存，每季度复核保留期限。
可复制空白模板：研发交付物清单表
下表为空白模板，一行对应一个可交付对象。复制到 Excel、在线表格或文档表格中即可使用，表头保持原样，行数按交付范围增减。
| 序号 | 交付物名称 | 交付物类型 | 版本标识 | 来源 | 完整性校验 | 保留期限 | 交付对象 | 交付状态 | 责任人 | 交付日期 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | |||||||||||
| 2 | |||||||||||
| 3 | |||||||||||
| 4 | |||||||||||
| 5 |
使用前先确定本次交付的范围：一次版本发布通常包含构建制品、发布包、部署说明、测试报告、用户文档等若干行。清单顶部建议另起一行记录“项目名称、发布批次、清单维护人、最后更新时间”，便于区分不同批次的清单。
字段说明：每个字段记录什么、怎么填
字段的取值口径统一后，开发、测试、运维和交付对接人才能填出一致的结果。下表逐字段说明含义、取值示例与填写要点。
| 字段名 | 含义 | 取值示例 | 填写要点 |
|---|---|---|---|
| 序号 | 行号，便于引用和核对 | 1、2、3 | 按交付顺序编号，删除行后不重排，保留原编号便于追溯 |
| 交付物名称 | 可交付对象的正式名称 | 订单服务发布包 | 使用团队内通用叫法，与制品库或文档库中的名称一致，避免同一对象出现多个别名 |
| 交付物类型 | 交付物的类别 | 构建制品、发布包、交付文档、测试报告、部署脚本 | 从团队约定的类型清单中选择，不临时造词；类型决定后续校验和保留方式 |
| 版本标识 | 该交付物的唯一版本号 | v2.3.1、build-20240612-07 | 与构建系统或发布记录中的版本号一致；同一名称的不同版本各占一行 |
| 来源 | 交付物的产生位置或生成方式 | CI 流水线 build-118、文档库“发布说明”目录 | 记录可回查的位置，如流水线编号、仓库分支、文档目录，便于需要时重新获取 |
| 完整性校验 | 确认交付物完整、未被篡改的依据 | SHA-256：a1b2…；校验通过 | 制品类记录哈希值或校验结果，文档类可记录页数、附件数或评审通过状态 |
| 保留期限 | 该交付物需要保存的时长 | 12 个月、随项目归档长期保留 | 按合同、合规或团队约定填写；期限到期前复核，不默认永久保留 |
| 交付对象 | 接收该交付物的一方 | 客户 A 运维团队、内部测试组 | 写清接收方名称，涉及外部交付时注明对接人 |
| 交付状态 | 交付物当前所处的环节 | 待交付、已交付、已签收、已撤回 | 状态随实际进展更新，每次变更记录日期 |
| 责任人 | 对该交付物负责的人 | 张工（后端）、李工（文档） | 填具体人名而非岗位，人员变动时及时更新 |
| 交付日期 | 实际交付或计划交付的日期 | 2024-06-15 | 计划日期与实际日期不一致时，在备注中说明原因 |
| 备注 | 补充说明 | 客户要求补充安装手册 | 记录例外情况、特殊要求或后续动作 |
版本标识与来源两个字段配合使用，才能定位到具体的那一份交付物：版本标识回答“是哪一版”，来源回答“从哪里取”。完整性校验与保留期限则回答“这份交付物是否可信、需要留多久”，四者共同构成交付物的身份记录。
必填与选填：哪些字段不能空
必填字段决定一行记录是否成立，缺失时该行不能进入“已交付”状态；选填字段按交付场景补充。下表给出划分与理由。
| 字段 | 必填/选填 | 理由与适用场景 |
|---|---|---|
| 交付物名称 | 必填 | 没有名称无法识别对象 |
| 交付物类型 | 必填 | 决定校验方式与保留策略 |
| 版本标识 | 必填 | 区分同一对象的多次交付 |
| 来源 | 必填 | 保证交付物可回查、可重新获取 |
| 完整性校验 | 必填 | 交付前确认对象完整可信 |
| 交付对象 | 必填 | 明确交付去向，支撑签收确认 |
| 交付状态 | 必填 | 反映交付进展，是清单的核心状态字段 |
| 责任人 | 选填 | 小团队可由清单维护人统一负责；多人协作或外部交付时建议填写 |
| 保留期限 | 选填 | 有合同或合规要求时填写；内部迭代制品可按团队默认策略处理 |
| 交付日期 | 选填 | 计划阶段可先留空，实际交付时补录 |
| 备注 | 选填 | 记录例外与补充信息 |
必填字段缺失时的处理规则：清单维护人在交付评审前逐行检查，发现必填为空的行，将该行状态置为“待补充”，不允许标记为“已交付”；补齐后由维护人复核再更新状态。若交付物确实无法提供完整性校验（例如第三方提供的文档），在备注中写明原因，并由责任人确认后放行，避免用空白掩盖例外。
填写示例：一次版本发布对应的完整清单
以下为演示情景：某内部系统发布 v2.3.1 版本，交付给客户 A 的运维团队，交付范围包括发布包、部署脚本、测试报告和用户手册。示例不对应任何真实客户或真实发布。
| 序号 | 交付物名称 | 交付物类型 | 版本标识 | 来源 | 完整性校验 | 保留期限 | 交付对象 | 交付状态 | 责任人 | 交付日期 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 订单服务发布包 | 发布包 | v2.3.1 | CI 流水线 build-118 | SHA-256：a1b2…校验通过 | 12 个月 | 客户 A 运维团队 | 已交付 | 张工 | 2024-06-15 | |
| 2 | 数据库变更脚本 | 部署脚本 | v2.3.1-db | 仓库 release/2.3 分支 | 评审通过，脚本行数 86 | 12 个月 | 客户 A 运维团队 | 已交付 | 王工 | 2024-06-15 | 需在发布包之前执行 |
| 3 | 系统测试报告 | 测试报告 | v2.3.1 | 测试管理目录“2.3.1 回归” | 评审通过，用例 214 条 | 随项目归档 | 客户 A 项目组 | 已签收 | 李工 | 2024-06-14 | |
| 4 | 用户操作手册 | 交付文档 | v2.3.1 | 文档库“交付文档”目录 | 评审通过，共 42 页 | 随项目归档 | 客户 A 项目组 | 已签收 | 赵工 | 2024-06-14 | 客户要求补充安装章节，已更新 |
关键字段的填写理由：发布包与数据库脚本版本标识都带 v2.3.1，来源分别指向流水线和代码分支，需要重新获取时可按来源回查；测试报告与用户手册属于文档类，完整性校验用评审状态和页数记录，比哈希值更贴合文档的实际使用方式；保留期限上，制品类按合同约定保留 12 个月，文档类随项目归档长期保留，两类对象采用不同策略。
当清单需要多人协作维护、并与需求、测试和发布记录关联时，可以把清单作为文档放在 ONES Wiki 中承载，把每个交付物对应到 ONES Project 的工作项或版本记录上，让状态变更和评审留下过程记录。ONES 的 ALM 方案覆盖需求、基线、版本、变更、测试与发布，并把测试用例、缺陷、版本和发布过程关联到需求链路中，出现问题时可以据此定位影响范围；交付物模板和过程数据也可以沉淀为可复用资产，供后续批次沿用。
调整与维护：清单随版本和交付方式变化如何更新
清单不是一次填完就固定的表格，字段和行都会随交付方式变化而调整。维护的重点是让每次发布后的更新有固定动作，让字段增删有判断依据。
字段增删的判断依据
出现以下情况时考虑增加字段：交付对象开始要求签收凭证，可增加“签收记录”；同一交付物需要区分多个接收方，可增加“接收方联系人”；合规审计要求说明审批过程，可增加“评审记录”。删除字段的前提是该字段连续两个发布批次无人填写、且没有外部使用方依赖它，删除前在清单说明中记录原因，避免历史清单无法对照。
每次发布后的更新动作
- 发布完成后，由清单维护人核对本次实际交付的对象，逐行更新交付状态与交付日期。
- 对未按计划交付的行，在备注中写明原因和后续安排，状态保持“待交付”。
- 新增的交付物另起一行，沿用同一套字段口径，不临时加列。
- 将本次清单按“项目名称＋发布批次”命名留存，作为该批次的历史版本。
定期复核与历史版本保留
建议每个发布批次结束后做一次清单复核，检查必填字段是否齐全、状态是否与实际一致；每季度对保留期限做一次集中检查，临近到期的交付物提前确认是否续留或清理。历史清单按发布批次留存，不覆盖旧版本；字段口径发生变化时，在新批次清单中启用新口径，旧批次保持原样，便于对照追溯。清单维护人变动时，在清单顶部更新维护人信息，并交接未完成的待交付行。
常见问题
交付物由第三方提供、无法计算哈希值时，完整性校验怎么填？
在完整性校验字段写明可获得的替代依据，例如对方提供的校验文件、交付邮件中的附件清单或签收单编号，并在备注中说明无法计算哈希的原因。该行由责任人确认后放行，状态照常推进，避免用空白掩盖例外。后续如取得原始文件，再补录哈希值。
同一交付物分批交付给多个接收方，清单要拆成多行吗？
建议拆行。每行对应一个接收方与一次交付动作，交付对象、交付日期和交付状态各自独立记录，签收情况才能逐项核对。若交付物本体完全相同，版本标识与来源字段保持一致，用备注注明“同一制品分批交付”，避免被误认为不同版本。
清单里的交付状态和项目管理工具中的任务状态需要保持一致吗？
两者口径可以不同，但对应关系要写清楚。清单状态描述的是交付物本身的去向，例如待交付、已交付、已签收、已撤回；任务状态描述的是工作进展。团队可在清单说明中列一张对照表，明确任务完成到哪一步时清单状态随之变更，减少两处记录互相矛盾。
发布批次结束后发现清单漏登了交付物，怎么补录？
补录时另起一行，序号接续原清单末尾，不插入已有行打乱编号。在备注中写明“批次结束后补录”及补录原因，交付日期填实际交付日期。若该交付物已影响签收或验收结论，由清单维护人通知交付对象确认，并在复核记录中留痕。
清单需要多人协作维护时，如何避免字段口径被改乱？
把表头和字段说明放在同一份文档中，指定一名清单维护人负责字段增删，其他人只填写行内容。字段调整按批次进行，新批次启用新口径，旧批次保持原样。需要与需求、测试和发布记录关联时，可将清单放在 ONES Wiki 中承载，把交付物对应到 ONES Project 的工作项或版本记录上，让状态变更留下过程记录。
