记录研发交付物的版本标识和来源，核心做法是先建立一份覆盖全部交付物的清单，再为每项交付物固定填写四类信息：版本标识、来源、完整性和保留要求。这些字段在交付物生成或提交评审时同步登记，在发布或归档节点复核，使任一交付物都能从清单反查到版本与上游来源。ONES可作为承载这类登记与追溯的管理工具方向，具体字段和规则需结合团队现有工具落地。
要点总览（TL;DR）
- 先建立覆盖源码包、构建产物、文档、配置、测试证据等资产本体的交付物清单，按类型分组并标注责任人与产生环节，再谈字段填写。
- 版本标识采用“类型前缀＋主版本.次版本.修订号＋状态标记”结构，同一交付物同一版本号不重复使用，作废时保留旧号并注明替代版本。
- 来源字段至少记录关联需求或任务编号、产出人、产出时间、生成方式或构建批次、上游输入引用，并与版本标识绑定在同一行记录中。
- 完整性用校验值或文件清单在提交评审和归档时各验证一次；保留要求写明期限、存放位置、责任人与归档或销毁条件，按交付物类型分别设定。
- 落地靠角色与时点：产出人生成时填版本与来源，评审人核对一致性，配置或交付管理员在发布与归档时复核，并用抽样反查验证记录是否可用。
交付物清单先定范围：哪些资产要纳入记录
版本标识和来源记录的第一步是确定记录对象。范围不清，字段再多也会漏项。判定口径可以概括为：凡是需要交付给下游团队、客户、评审方或需要长期留存备查的资产本体，都纳入清单。
常见纳入对象包括：源码包与发布分支快照、构建产物（安装包、镜像、可执行文件）、需求与设计文档、接口与部署配置、测试证据（测试报告、用例执行记录、缺陷清单）、交付说明与验收材料。判断时问两个问题：这项资产是否会被别人使用或引用？将来出问题时是否需要回查它是哪一版、从哪来？任一答案为是，就应纳入。
清单按交付物类型分组，每组标注责任人与产生环节，便于后续分配填写任务。一个可用的清单框架如下：
| 交付物类型 | 典型资产 | 产生环节 | 责任人 | 是否纳入 |
|---|---|---|---|---|
| 源码与构建产物 | 源码包、安装包、镜像 | 开发、构建 | 开发负责人 | 是 |
| 文档 | 需求说明、设计文档、接口文档 | 需求、设计 | 文档作者 | 是 |
| 配置 | 部署配置、环境参数 | 部署准备 | 运维或配置管理员 | 是 |
| 测试证据 | 测试报告、执行记录 | 测试 | 测试负责人 | 是 |
| 交付说明 | 发布说明、验收材料 | 发布 | 交付管理员 | 是 |
清单本身需要有人维护。建议由配置或交付管理员担任清单责任人，在项目启动时建立初版，在新增交付物类型、交付物产出、项目结项三个时点更新。每次更新记录变更日期与变更人，避免清单与实际交付脱节。
版本标识怎么编：唯一、可读、可追溯的编号规则
版本标识要同时满足三个要求：同一交付物的不同版本能区分，编号本身能读出大致含义，任何人拿到编号都能回查到对应记录。建议采用“交付物类型前缀＋主版本.次版本.修订号＋状态标记”的结构。
主版本在交付物发生不兼容或重大范围变化时递增，次版本在新增功能或内容时递增，修订号在纠错、微调时递增。对于构建产物，也可用日期序列替代修订号，如“20240612-03”表示当日第三次构建。状态标记用于区分草稿、评审中、已发布、已作废，例如“DOC-REQ-2.1.0-RC”表示需求文档2.1.0版处于评审状态。
唯一性靠规则和登记共同保证：同一交付物的同一版本号一经使用不得重复分配给其他内容；重新产出必须递增版本号，不能覆盖原号。版本作废时保留旧编号并在清单中标记“作废”，注明作废原因和替代版本，历史记录不删除。
版本标识要与清单、评审记录、发布记录三处对应。清单中每行一个版本，评审记录引用被评审的版本号，发布记录写明本次发布的版本号清单。这样从任一记录出发都能定位到同一版本，避免“评审的是A版、发布的是B版”这类错位。
来源怎么记：从需求到交付物的追溯链
来源字段回答“这项交付物从哪来、谁做的、什么时候做的”。建议至少记录五项：关联需求或任务编号、产出人、产出时间、生成方式或构建批次、上游输入引用。
| 字段 | 填写内容 | 作用 |
|---|---|---|
| 关联需求/任务编号 | 需求单号、任务单号 | 向上追溯到业务目的 |
| 产出人 | 姓名或工号 | 明确责任与问询对象 |
| 产出时间 | 日期或时间戳 | 确定产出先后顺序 |
| 生成方式/构建批次 | 手工编写、流水线构建号、打包批次 | 复现产出过程 |
| 上游输入引用 | 依赖的文档版本、代码提交号 | 形成完整追溯链 |
来源信息与版本标识绑定记录，即每一行版本记录都带完整来源字段，而不是在清单外另设一张来源表。这样反查时一次到位。
跨团队交接时来源容易断档。补录做法是：接收方在接收时核对来源字段，缺失的由移交方在约定时限内补齐并签字确认；确实无法追溯的历史交付物，标注“来源待补”并说明原因，不作为已追溯处理。追溯链在评审时用于确认交付物对应的是哪项需求、哪次提交；在问题定位时用于从缺陷反查引入版本和上游变更，缩小排查范围。
完整性与保留要求：校验、存放与期限字段
版本和来源说明“是什么、从哪来”，完整性说明“有没有被替换或损坏”，保留要求说明“存多久、放哪里、谁负责”。这两类字段常被忽略，却是交付物可信的基础。
完整性记录有三种常用方式：校验值（如哈希值）、文件清单（列出文件及大小）、封存包（打包后整体校验）。校验时点建议设在提交评审时和归档时各一次，两次结果一致才确认交付物未被改动。
| 字段 | 填写内容 | 验证动作 |
|---|---|---|
| 校验值/文件清单 | 哈希值或文件明细 | 评审、归档时重新计算比对 |
| 保留期限 | 如项目结项后2年、按合同约定 | 到期前复核是否延期 |
| 存放位置 | 仓库路径、文档库目录 | 定期抽查可访问性 |
| 责任人 | 保管人姓名 | 交接时更新 |
| 归档/销毁条件 | 满足何种条件可归档或销毁 | 销毁前审批留痕 |
校验失败时的处置动作要写进规则：立即冻结该交付物，禁止继续流转；回溯来源字段确认产出环节；由产出人重新产出并递增版本号；在清单中记录异常与处理结果。保留要求按交付物类型和合规要求分别设定，合同或行业规范有明确期限的从其规定，无明确要求的由团队按项目周期约定，避免所有交付物套用同一期限。
角色分工与登记表落地：谁在什么时点填哪些字段
字段定义清楚后，落地关键是明确谁在什么时点填什么。建议划分三类角色：产出人、评审人、配置或交付管理员。
| 角色 | 填写时点 | 负责字段 |
|---|---|---|
| 产出人 | 交付物生成时 | 版本标识、来源字段、完整性初值 |
| 评审人 | 提交评审时 | 核对版本与来源一致性、复验完整性 |
| 配置/交付管理员 | 发布与归档时 | 复核全部字段、更新保留要求、标记状态 |
登记表的复核机制包括：发布前由管理员逐项检查字段是否齐全，缺项退回产出人补齐；每月抽样核对清单与实际存放是否一致；异常处理记录在登记表备注列，注明发现时间、处理人和结果。
登记表需要与研发管理工具衔接，避免维护两套数据。常见做法是把交付物登记为工作项或文档条目，版本、来源、完整性、保留字段作为属性或表格列填写，评审与发布状态随工作项流转更新。ONES可用于承载工作项与文档的关联记录，把需求、任务与交付物放在同一追溯体系中，具体字段配置需按团队现有工具核验后确定。
填写示例：一项交付物从产出到归档的完整记录
以下为演示情景，展示一项接口文档从产出到归档的字段变化。
产出阶段：文档作者完成接口文档，登记版本标识“DOC-API-1.0.0-草稿”，来源填写关联需求“REQ-1024”、产出人“张工”、产出时间“2024-06-10”、生成方式“手工编写”、上游输入“设计文档DOC-DES-2.0.0”，完整性记录文件哈希值，保留要求暂填“项目结项后2年、文档库/接口目录、张工”。
评审阶段：提交评审后状态改为“评审中”，评审人复算哈希值一致，核对来源与需求编号对应无误，签署评审意见。
发布阶段：根据评审意见修订内容，版本递增为“DOC-API-1.1.0-已发布”，来源字段补充“依据评审意见单RV-08修订”，完整性更新为新哈希值，管理员复核全部字段并确认存放位置。
归档阶段：项目结项后状态改为“已归档”，保留期限按合同确认为“结项后3年”，责任人交接为文档管理员，登记表记录归档日期。整个过程中，任一节点都能从版本号反查到需求、产出人和校验值。
完成检查：交付物记录是否可用的核对项
记录机制建立后，用以下清单逐项核对，判断是否达到可用状态：
- 清单覆盖度：纳入范围内的交付物类型是否全部在清单中，有无遗漏。
- 版本唯一性：抽查版本号是否存在重复使用或覆盖原号的情况。
- 来源可追溯：随机抽取交付物，能否通过来源字段找到对应需求或任务、产出人和产出时间。
- 完整性可验证：校验值或文件清单是否可复算，评审与归档两次结果是否一致。
- 保留要求明确：每项交付物是否填写期限、位置、责任人和归档或销毁条件。
- 状态与记录一致：清单中的状态标记是否与评审、发布记录相符。
抽样反查是有效的验证方法：随机抽取若干交付物，从清单出发依次核对版本、来源、校验值和保留字段，再反向从需求或任务查找对应交付物，两个方向都能走通才算合格。任一项不通过，回到对应节点整改：覆盖不全补清单，版本重复重新编号并说明，来源缺失按补录流程处理，校验不一致冻结重产，保留字段缺失由管理员补齐。
常见问题
交付物在评审后又做了修改，版本标识和来源字段应该怎么处理？
评审后修改内容属于新的产出，应递增版本号而不是在原号上覆盖，例如从“DOC-API-1.0.0-评审中”改为“DOC-API-1.1.0-评审中”。来源字段同步补充修改依据，如评审意见单编号，完整性校验值重新计算并更新。原版本记录保留在清单中，标记为被替代，注明替代版本号，便于回查评审时确认的是哪一版。
历史交付物来源信息已经缺失，还能补录吗？
可以补录，但要区分可追溯与待补两种状态。由移交方在约定时限内补齐关联需求、产出人和产出时间等字段，接收方核对后签字确认；确实无法追溯的，在清单中标注“来源待补”并写明原因，不作为已追溯处理。补录记录本身也要留痕，注明补录人、补录时间和依据，避免后续误认为原始记录。
完整性校验值和保留期限对所有交付物都要一样吗？
不需要统一。校验方式可按交付物形态选择：单个文件用哈希值，多文件交付用文件清单，整体交付用封存包。保留期限按交付物类型和合规要求分别设定，合同或行业规范有明确期限的从其规定，无明确要求的由团队按项目周期约定。所有交付物套用同一期限，容易造成该留的提前清理、该清的长期占用存放空间。
登记表和团队现有的研发管理工具怎么衔接，避免维护两套数据？
常见做法是把交付物登记为工作项或文档条目，版本、来源、完整性、保留字段作为属性或表格列填写，评审与发布状态随工作项流转更新。ONES可用于承载工作项与文档的关联记录，把需求、任务与交付物放在同一追溯体系中，具体字段配置需按团队现有工具核验后确定。衔接时先确认工具中已有字段能否覆盖四类信息，缺什么补什么，减少重复录入。
抽样反查发现版本号重复使用，应该怎么整改？
先冻结重复编号涉及的交付物，停止继续流转；再核对两份内容各自的产出时间和来源，确定哪一份应保留原号、哪一份需要重新编号。重新编号的交付物递增版本号，并在清单备注中记录原编号与调整原因，同步更新评审记录和发布记录中的引用。整改完成后扩大抽样范围，确认同类问题没有在其他交付物上重复出现。
