制品元数据记录要解决的是“这个制品是什么、从哪来、是否完整、放在哪、交给谁”这几个问题。模板按一条制品一行组织，覆盖标识、来源、完整性、保留和交付五类字段，可直接复制到文档或表格工具中使用。下文先给出空白表，再说明每个字段的取数口径、必填与选填的划分，并用一条发布包记录示范填写，最后说明模板随团队演进的调整方法。
要点总览（TL;DR）
- 模板按“一条制品一行”组织，共十五列，覆盖标识、来源、完整性、保留与交付五类字段，可直接复制到文档或表格工具。
- 最小可用记录集包含制品名称、版本标识、制品类型、来源构建或提交号、校验值、存放位置、责任人、状态八项；校验算法应与校验值成对记录。
- 对外交付或需审计的制品，建议把构建时间、保留期限、交付去向、交付清单编号转为必填，使一条记录即可支撑交付核对。
- 填写时优先复制构建流水线、代码仓库、制品库和交付清单中的原始值，校验值完整复制、不截断，存放位置记录到可直接定位的层级。
- 维护上把字段更新绑定到构建完成、入库、交付、废弃等节点，并按月核对交付记录、按季度检查存放位置与保留期限。
可复制空白制品元数据记录表
下表为空白模板，一行登记一个制品。复制到在线表格时，建议保留表头行并冻结首行；复制到文档时，可将表头设为重复标题行。字段顺序按“先标识、再来源、再完整性、后保留与交付”排列，便于填写时按构建发生的先后顺序逐项核对。
| 序号 | 制品名称 | 版本标识 | 制品类型 | 来源构建/提交号 | 构建时间 | 校验算法 | 校验值 | 存放位置 | 保留期限 | 交付去向 | 交付清单编号 | 责任人 | 状态 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
表中共十五列，其中“校验算法”与“校验值”成对出现，“交付去向”与“交付清单编号”成对出现，填写时不要只填其中一半。若团队使用制品库自动生成校验值，可将这两列改为由系统回填、人工只做核对。
字段说明：每个字段记录什么、怎么取数
字段能否被正确填写，取决于取数位置是否明确。下表的“取数来源”一列指向日常已经在产生的记录，填写人应优先复制这些位置的原始值，减少手工转写带来的口径差异。
| 字段名 | 含义 | 取数来源 | 填写口径 |
|---|---|---|---|
| 制品名称 | 制品在团队内的通用叫法 | 构建产物命名或制品库条目名 | 使用稳定的业务名称，不带日期和临时后缀；同一制品多次构建时名称保持不变 |
| 版本标识 | 区分同一制品不同构建结果的唯一标识 | 版本号规则、构建流水线编号或提交标签 | 与发布记录、交付清单中的版本写法完全一致；语义化版本与构建号并用时，写明主标识 |
| 制品类型 | 制品的形态类别 | 构建配置或制品库分类 | 使用团队约定的有限枚举，如安装包、容器镜像、库文件、配置文件、数据包 |
| 来源构建/提交号 | 制品由哪次构建或哪个代码提交产生 | 持续集成流水线记录、代码仓库提交记录 | 填写可回溯的构建编号或提交哈希；两者都有时同时记录，用分号分隔 |
| 构建时间 | 该制品完成构建的时间 | 流水线日志时间戳 | 统一时区并写明，精确到分钟；不使用本地手工记录时间替代 |
| 校验算法 | 计算校验值所用的算法 | 构建脚本或制品库校验功能 | 写明算法名称，如 SHA-256、SHA-1、MD5；团队内统一一种主算法 |
| 校验值 | 制品内容的完整性指纹 | 构建输出或制品库详情页 | 完整复制，不截断、不改大小写；与校验算法成对记录 |
| 存放位置 | 制品实际可获取的位置 | 制品库路径、对象存储地址或发布目录 | 记录到可直接定位的层级，包含仓库名与路径；避免只写“制品库”这类笼统描述 |
| 保留期限 | 该制品需要保留的时长 | 团队保留策略或合同、合规要求 | 写明期限与起算点，如“发布后 12 个月”；长期保留的注明依据 |
| 交付去向 | 制品交付给的客户、环境或系统 | 交付清单、发布单 | 写具体对象，如某客户生产环境、某内部系统；多个去向逐条列出 |
| 交付清单编号 | 关联的交付清单标识 | 交付清单文档编号 | 填写清单编号而非清单标题，便于检索与核对 |
| 责任人 | 对该条记录准确性负责的人 | 构建负责人或发布负责人 | 填写具体人员，不填团队名；人员变动时同步更新 |
| 状态 | 制品当前所处环节 | 发布流程记录 | 使用有限枚举，如已构建、已校验、已交付、已归档、已废弃 |
| 备注 | 其他需要说明的信息 | 填写人补充 | 记录例外情况，如临时补丁、校验值重新生成的原因 |
命名口径是最容易产生分歧的部分。制品名称建议在项目启动时确定一次并写入团队约定，版本标识则应与发布记录保持同一写法。若同一制品存在多个构建产物，例如安装包与校验文件，应分别成行登记，通过相同的版本标识建立关联，避免把多个文件塞进一行。
必填与选填：最小可用记录集
最小可用记录集包含八个字段：制品名称、版本标识、制品类型、来源构建或提交号、校验值、存放位置、责任人、状态。这八项合起来能回答“是什么、从哪来、是否完整、在哪、谁负责、处于什么环节”，缺少任何一项都会让后续追溯出现断点。校验算法虽未列入最小集，但校验值离开算法无法复算，实际填写时应与校验值同时记录。
| 字段 | 必填/选填 | 理由或适用场景 |
|---|---|---|
| 制品名称 | 必填 | 检索与关联的基本入口 |
| 版本标识 | 必填 | 区分同一制品的不同构建结果 |
| 制品类型 | 必填 | 决定后续校验与部署方式 |
| 来源构建/提交号 | 必填 | 问题定位时回溯到代码与流水线 |
| 校验算法与校验值 | 必填 | 验证制品在传输与存放中未被改动 |
| 存放位置 | 必填 | 保证制品可被重新获取 |
| 责任人 | 必填 | 记录准确性与更新有明确归属 |
| 状态 | 必填 | 区分在用、已交付与已废弃制品 |
| 构建时间 | 选填 | 需要按时间排查构建问题时填写 |
| 保留期限 | 选填 | 对外交付、合同约定或合规审计场景建议填写 |
| 交付去向 | 选填 | 制品进入交付环节后填写 |
| 交付清单编号 | 选填 | 存在正式交付清单时填写，用于双向核对 |
| 备注 | 选填 | 记录例外与补充说明 |
必填范围可按交付类型调整。对外交付或需要接受审计的制品，建议把构建时间、保留期限、交付去向、交付清单编号一并转为必填，使一条记录即可支撑交付核对；内部迭代阶段可先采用八项最小集，待制品进入发布流程时再补齐。调整时应在模板说明中写明适用条件，避免同一张表在不同项目中执行不同标准。
填写示例：一条发布包的完整记录
以下为演示情景，用于说明字段之间的对应关系，不代表任何真实项目数据。假设某团队构建了一个客户端安装包并交付给客户生产环境，记录如下。
| 字段 | 填写内容 |
|---|---|
| 制品名称 | 客户端安装包 |
| 版本标识 | v3.2.0 |
| 制品类型 | 安装包 |
| 来源构建/提交号 | 构建号 20240612-07；提交 a1b2c3d |
| 构建时间 | 2024-06-12 15:40（UTC+8） |
| 校验算法 | SHA-256 |
| 校验值 | 9f2c…（完整 64 位十六进制值，此处省略中段） |
| 存放位置 | 制品库 release/client/v3.2.0/client-setup.exe |
| 保留期限 | 发布后 24 个月 |
| 交付去向 | 客户 A 生产环境 |
| 交付清单编号 | DL-2024-0612-01 |
| 责任人 | 发布负责人（示例） |
| 状态 | 已交付 |
| 备注 | 随包附带校验文件，交付时与清单同步发送 |
示例中校验值与交付清单编号形成两条核对路径：接收方用校验算法复算安装包，结果与记录一致即说明文件完整；交付清单编号则把该制品与当次交付的全部内容关联起来，核对时从清单反查制品记录，或从制品记录正查清单，都能定位到同一对象。来源构建号与提交号同时保留，使问题出现时可以分别回到流水线和代码两个层面排查。
调整与维护：模板随团队演进的改法
模板需要在长期使用中保持可用，调整的依据应来自实际填写中反复出现的问题，而非字段越多越好。新增字段的判断标准有三条：该信息在追溯或交付核对中被反复查询；取数来源稳定、不需要额外人工整理；新增后不显著增加每行填写时间。删除字段则需确认该字段不再被任何交付清单、审计要求或问题排查流程引用，删除前先保留一个版本周期的历史记录。
记录更新应绑定到具体时点，而不是依赖定期补录。建议在以下节点更新对应字段：构建完成时填写来源构建号、构建时间与校验值；制品入库时填写存放位置；进入交付时填写交付去向、交付清单编号并把状态改为已交付；制品废弃时更新状态并在备注中说明替代版本。责任人字段随构建负责人确定，人员变动时由接手人更新，避免记录长期挂在前任名下。
维护动作可按固定节奏执行：每月核对一次状态为“已交付”的记录与交付清单是否一致，重点检查校验值和清单编号；每季度检查一次存放位置是否仍然有效，清理已过保留期限且无追溯需求的制品；每次模板字段变更时，同步更新字段说明与填写示例，保证三者口径一致。团队规模扩大或交付类型增多时，可先在小范围试用新增字段，确认取数来源稳定后再推广到全部记录。
当制品记录需要与需求、版本、测试和发布过程关联时，可以把这张表作为交付物模板沉淀到研发管理工具中。ONES 当前方案覆盖需求、基线、版本、变更、测试与发布，围绕这些对象建立统一管理，支撑过程状态追踪和交付结果回溯；测试用例、缺陷、版本和发布过程可以关联到需求链路中，出现问题时便于定位影响范围。标准流程、评审节点和交付物模板也可以沉淀为可复用资产，让这张元数据表从文档要求变成项目中的实际执行环节。具体字段模板形态与构建系统集成方式，需结合团队实际环境另行确认。
常见问题
同一制品有多个构建产物时，应该合并成一行还是分行登记？
建议分别成行登记，通过相同的版本标识建立关联。例如安装包与随包校验文件属于两个文件，各自有独立的校验值，合并到一行会导致校验值无法对应到具体文件。分行后，检索同一版本标识即可看到该次构建的全部产物，交付核对时也能逐个文件比对。
团队暂时没有制品库，校验值和存放位置怎么填？
校验值可以在构建脚本中生成，或使用系统自带的摘要计算工具对构建输出文件计算后填入，算法名称与校验值同时记录。存放位置填写文件实际所在的共享目录、对象存储路径或发布服务器路径，写到可直接定位的层级。若制品暂存在个人电脑上，应尽快转移到团队可访问的位置再登记，避免记录指向无法获取的文件。
内部迭代项目也要按对外交付的标准填全部字段吗？
不必。内部迭代阶段可先采用八项最小记录集，保证制品可识别、可回溯、可获取。当制品进入发布或对外交付流程时，再补齐构建时间、保留期限、交付去向和交付清单编号。调整必填范围时应在模板说明中写明适用条件，让同一团队的不同项目按同一标准执行。
制品废弃后，元数据记录要删除吗？
记录建议保留，把状态更新为“已废弃”，并在备注中说明替代版本或废弃原因。删除记录会让历史交付和问题排查失去线索，尤其是已经对外交付过的制品。可以在保留期限到期且确认无追溯需求后，再按团队归档规则处理，处理前保留一个版本周期的历史记录。
制品元数据记录如何与需求、版本和发布过程关联起来？
可以把这张表作为交付物模板沉淀到研发管理工具中，让每条记录与对应的版本、发布单和交付清单建立引用关系。ONES 当前方案覆盖需求、基线、版本、变更、测试与发布，围绕这些对象建立统一管理，支撑过程状态追踪和交付结果回溯；测试用例、缺陷、版本和发布过程可以关联到需求链路中，出现问题时便于定位影响范围。标准流程、评审节点和交付物模板也可以沉淀为可复用资产。具体字段模板形态与构建系统集成方式，需结合团队实际环境另行确认。
