研发基线清单的核心，是记录一次基线冻结了哪些受控资产，以及这些资产在冻结时的身份、版本、状态和审批信息。一份可直接使用的清单通常包含基线标识、类型与建立时机、纳入范围的资产条目、版本与来源位置、变更与例外状态、审批与发布记录、存放与访问方式七类信息。清单记录的是资产被纳入基线时的引用与版本，需求版本本身的变更流程归需求变更与版本管理，交付制品的构建与分发归研发交付物与制品管理。下文提供空白表格、字段口径、必填取舍、完整示例与维护方法；清单的版本引用与审批记录也可以放在ONES这类协作工具中承载。
要点总览（TL;DR）
- 研发基线清单记录一次基线冻结的受控资产组合，核心信息包括基线标识、类型与建立时机、资产条目、版本与来源位置、变更与例外、审批与发布、存放与访问七类。
- 清单采用引用写法：登记资产唯一标识、版本号和可定位的来源位置，资产正文留在原系统，避免冻结后版本漂移。
- 必填字段以能否唯一识别和追溯为标准，基线编号、名称、类型、负责人、冻结状态及资产唯一标识、版本号、来源位置缺一不可；增量基线必须注明基准基线。
- 不同基线类型必填项有差异：需求基线重需求单号与修订版本，设计基线重文档编号与版本，发布基线覆盖多类资产并要求完整审批记录。
- 基线冻结后变更走变更单并在记录表追加，增量与全量基线维护重点不同，废止时标注替代基线并保留完整记录。
可复制空白研发基线清单模板
下面三张表构成一份完整的基线清单。使用时先填主表确定这次基线是什么，再用资产明细表逐条登记纳入范围的资产，变更与审批记录表随基线生命周期持续追加。表格中的字段与后文字段说明、填写示例保持一致，可以直接复制到文档或表格工具中填写。
表一：基线主表
| 字段 | 填写内容 |
|---|---|
| 基线编号 | |
| 基线名称 | |
| 基线类型 | |
| 建立时机 | |
| 基线负责人 | |
| 建立日期 | |
| 生效日期 | |
| 冻结状态 | |
| 废止日期 | |
| 存放位置 | |
| 访问范围 | |
| 备注 |
表二：基线资产明细表
| 序号 | 资产类别 | 资产名称 | 唯一标识 | 版本号 | 来源位置 | 纳入方式 | 条目状态 |
|---|---|---|---|---|---|---|---|
| 1 | |||||||
| 2 | |||||||
| 3 | |||||||
| … |
表三：变更与审批记录表
| 记录类型 | 记录编号 | 变更或评审内容 | 影响条目 | 评审角色 | 结论 | 审批人 | 日期 | 生效日期 | 发布位置 |
|---|---|---|---|---|---|---|---|---|---|
| 变更 | |||||||||
| 例外 | |||||||||
| 审批 |
每个字段的含义与填写口径
字段填写的关键原则是引用而非复制：清单登记资产的标识、版本和位置，资产正文仍留在原来的需求库、代码库或文档库中。这样基线冻结后，资产内容更新不会让清单失真，追溯时按来源位置和版本号即可定位到当时冻结的那一份。下表逐字段说明含义、填写口径与常见错误。
| 字段 | 含义 | 填写口径 | 常见错误 |
|---|---|---|---|
| 基线编号 | 基线的唯一标识 | 按团队规则生成，如“项目代号-类型-序号-日期”，全组织内不重复 | 用名称代替编号；不同项目编号重复 |
| 基线名称 | 便于人识别的简短名称 | 写明版本或阶段，如“V2.3 发布基线” | 只写“基线1”，无法区分用途 |
| 基线类型 | 基线所属阶段 | 从需求基线、设计基线、代码基线、发布基线等类型中选择 | 类型与建立时机不匹配 |
| 建立时机 | 触发建立基线的节点 | 写明具体事件，如“需求评审通过后”“提测前” | 只写日期，看不出触发条件 |
| 资产类别 | 资产所属的管理域 | 按需求、设计文档、代码、配置、测试用例等分类 | 类别混用，同一资产重复登记 |
| 资产名称 | 资产的可读名称 | 与来源系统中的名称一致 | 自行改写名称，与来源对不上 |
| 唯一标识 | 资产在来源系统中的编号 | 填写需求单号、文档编号、代码仓库路径等可唯一定位的标识 | 只写名称，同名资产无法区分 |
| 版本号 | 资产被冻结时的版本 | 引用来源系统的版本号或提交号，不复制内容 | 写“最新版”；冻结后版本漂移 |
| 来源位置 | 资产所在的位置 | 写到可定位的层级，如“需求库/模块A/需求单REQ-1024” | 只写系统名，无法定位到具体条目 |
| 纳入方式 | 资产进入基线的方式 | 标注全量或增量，增量需注明相对哪次基线 | 增量基线未写基准基线 |
| 条目状态 | 资产在基线中的状态 | 填写有效、已变更、已豁免等状态 | 状态长期不更新 |
| 建立日期 | 清单完成登记的时间 | 填写实际登记完成日 | 与生效日期混用 |
| 生效日期 | 基线开始约束变更的时间 | 审批通过后填写，可与建立日期不同 | 未审批先填生效 |
| 冻结状态 | 基线当前是否处于冻结 | 填写草稿、已冻结、已废止 | 冻结后仍按草稿修改明细 |
| 废止日期 | 基线停止使用的时间 | 被新基线替代或项目结束时填写 | 废止后未标注替代基线 |
| 基线负责人 | 对基线内容负责的人 | 填写具体姓名与角色 | 写部门名，找不到责任人 |
| 评审角色 | 参与评审的岗位 | 按类型列出，如需求负责人、开发负责人、测试负责人 | 只写“已评审”，无角色记录 |
| 审批结论 | 评审的最终意见 | 填写通过、有条件通过、驳回，有条件通过需附条件 | 结论含糊，无法判断是否生效 |
版本号与来源位置两个字段最容易出问题。版本号应引用来源系统在冻结时刻的版本，例如需求单的修订号或代码仓库的提交标识；来源位置要写到能直接打开对应条目的层级。两者配合，才能在几个月后回答“这次发布到底冻结了哪一版需求、哪一段代码”。
哪些字段必填、哪些可以选填
必填字段的判断标准是：缺少它，基线就无法被唯一识别或无法追溯。按这个标准，基线编号、名称、类型、建立日期、冻结状态、负责人，以及明细表中的资产类别、唯一标识、版本号、来源位置属于必填。选填字段用于补充管理信息，可按团队成熟度逐步启用。
| 字段 | 必填/选填 | 理由与适用条件 |
|---|---|---|
| 基线编号、名称、类型 | 必填 | 缺任一项则基线无法被唯一识别和检索 |
| 建立日期、冻结状态、负责人 | 必填 | 缺任一项则无法判断基线是否生效、由谁负责 |
| 资产类别、唯一标识、版本号、来源位置 | 必填 | 缺任一项则资产无法定位到冻结时的具体版本 |
| 纳入方式 | 必填（增量基线时） | 全量基线可默认全量；增量基线必须注明基准基线 |
| 生效日期、废止日期 | 按阶段必填 | 审批通过后填生效日期；废止时填废止日期与替代基线 |
| 评审角色、审批结论 | 必填（需审批的基线） | 正式对外或对下游交付的基线应有审批记录 |
| 存放位置、访问范围 | 选填 | 清单本身集中存放时可省略；多团队共享时建议填写 |
| 条目状态、备注 | 选填 | 用于标注豁免、待确认等特殊情况 |
不同基线类型的必填差异主要体现在明细范围和审批要求上。需求基线以需求条目为主，必填需求单号与修订版本，评审角色通常包含需求负责人和开发负责人；设计基线以设计文档为主，必填文档编号与文档版本；发布基线覆盖需求、代码、配置和测试用例等多类资产，必填项最全，且通常要求完整的审批记录与发布位置。例外与豁免条目无论哪种类型，都应填写豁免原因、批准人和有效期，避免豁免变成长期默认状态。
一份填写完整的基线清单示例
以下为演示情景，用于说明字段如何联动填写，不对应真实项目。场景是某产品准备发布 V2.3 版本，在提测前建立一次发布基线。
主表填写为：基线编号“PROD-REL-023-20240610”，名称“V2.3 发布基线”，类型“发布基线”，建立时机“提测前”，负责人“张明（项目经理）”，建立日期“2024-06-10”，生效日期“2024-06-11”，冻结状态“已冻结”，存放位置“项目空间/基线库/发布基线”，访问范围“项目组全员只读，负责人可编辑”。
| 序号 | 资产类别 | 资产名称 | 唯一标识 | 版本号 | 来源位置 | 纳入方式 | 条目状态 |
|---|---|---|---|---|---|---|---|
| 1 | 需求 | 订单导出功能 | REQ-1024 | 修订版 v3 | 需求库/订单模块/REQ-1024 | 全量 | 有效 |
| 2 | 需求 | 权限校验优化 | REQ-1031 | 修订版 v2 | 需求库/权限模块/REQ-1031 | 全量 | 有效 |
| 3 | 设计文档 | 订单导出设计说明 | DOC-208 | v1.2 | 文档库/设计/订单模块/DOC-208 | 全量 | 有效 |
| 4 | 代码 | 订单服务 | repo-order | 提交 a1b2c3d | 代码库/repo-order/分支 release/2.3 | 全量 | 有效 |
| 5 | 测试用例 | 订单导出用例集 | TC-556 | v4 | 测试库/订单模块/TC-556 | 全量 | 有效 |
变更与审批记录表填写为：一条审批记录，编号“AP-023”，内容“V2.3 发布基线评审”，影响条目“全部 5 项”，评审角色“需求负责人、开发负责人、测试负责人”，结论“通过”，审批人“李华”，日期“2024-06-10”，生效日期“2024-06-11”，发布位置“项目空间/基线库/发布基线”。另有一条变更记录，编号“CR-118”，内容“REQ-1031 权限规则调整”，影响条目“序号 2”，结论“有条件通过”，条件为“仅调整校验顺序，不影响接口”，生效日期“2024-06-14”。
对照字段说明可以看出：明细表中的版本号全部采用引用写法，代码条目引用提交标识而非复制代码；来源位置写到可直接定位的层级；变更记录通过“影响条目”与明细表序号关联，审批记录则覆盖整次基线。增量基线场景下，纳入方式改为“增量”，并在备注中写明基准基线编号，例如“基于 PROD-REL-022-20240520 增量”。
清单的调整与日常维护方法
基线冻结后，清单本身仍需维护，但维护的对象是记录而非资产内容。资产内容要改，走变更流程；清单要改，走记录追加。把这两条路径分开，基线才有可信度。
冻结后的变更路径
冻结后的变更统一走变更单：提出变更、评估影响条目、审批、在变更记录表中追加一行，并同步更新对应明细条目的版本号与条目状态。原版本信息保留在变更记录中，便于回溯。紧急修复也按同一路径补录，不允许直接改明细表而不留记录。
增量基线与全量基线的维护差异
全量基线每次建立都完整登记资产，维护重点是防止冻结后明细被直接修改。增量基线只登记相对基准基线发生变化的条目，维护重点是基准基线编号始终可查、变更条目与基准条目的对应关系清晰。团队连续发布多个小版本时，增量基线能减少登记工作量，但要求基准基线长期可访问。
定期复审的触发条件与检查项
复审可由版本发布、里程碑评审、季度配置审计或负责人变更触发。检查项包括：冻结状态是否与实际一致；明细条目的版本号是否仍能在来源位置找到；变更记录是否覆盖所有已发生的调整；豁免条目是否到期；废止基线是否标注了替代基线。复审结论记入变更与审批记录表，注明复审日期与结论。
废止与归档
基线被新基线替代或项目结束时，在主表填写废止日期和替代基线编号，冻结状态改为已废止。归档时保留主表、完整明细表和全部变更与审批记录，保存期限按项目合同或组织配置管理要求确定；没有明确要求时，至少保留到产品停止维护。清单与需求变更台账、交付物管理台账的衔接边界是：需求版本变化记在需求变更台账，制品构建与分发记在交付物台账，基线清单只记录这些对象被纳入基线时的引用与版本。
当团队在协作工具中维护这套清单时，可以把清单作为受控文档管理，利用ONES Wiki的页面版本记录查看与回滚历史，用权限配置区分基线负责人的编辑权与其他成员的只读权，并通过页面模板库建立统一的清单模板。ONES方案覆盖需求、基线、版本、变更、测试与发布，围绕需求、基线、版本和变更建立统一管理对象，支撑需求变更影响分析与交付结果回溯，适合把清单中的版本引用与审批记录同需求、变更记录放在同一条追溯链上。具体字段结构和冻结操作方式以团队实际开通版本与配置为准。
常见问题
基线清单里的版本号应该写“最新版”吗？
不建议。版本号应引用来源系统在冻结时刻的具体版本，例如需求单的修订号、文档版本号或代码仓库的提交标识。写“最新版”会让清单在资产继续更新后失去追溯意义，几个月后无法回答当时冻结的是哪一版。若来源系统只提供时间戳，可记录时间戳并注明对应版本，保持可定位。
增量基线需要把基准基线的全部条目再抄一遍吗？
不需要。增量基线只登记相对基准基线发生变化的条目，在纳入方式中标注“增量”，并写明基准基线编号。维护重点是保证基准基线长期可访问、变更条目与基准条目的对应关系清晰。如果基准基线已废止或无法访问，增量清单的追溯链会断，此时应改为全量登记或先恢复基准基线的可查状态。
豁免条目在清单里怎么记录才不会变成长期默认？
豁免条目应在明细表中标注条目状态为“已豁免”，并在变更与例外记录表中填写豁免原因、批准人和有效期。复审时把“豁免条目是否到期”列为固定检查项，到期未续批的条目恢复为有效状态或走正式变更。这样豁免有明确的时间边界和责任人，不会因为没人跟进而长期存在。
基线清单和需求变更台账、交付物台账如何分工？
三者记录对象不同。需求版本本身的变化记在需求变更台账，交付制品的构建、存储与分发记在交付物台账，基线清单只记录这些对象被纳入基线时的引用与版本。实际操作中，基线清单通过唯一标识和版本号与另外两本台账关联，变更发生时先在对应台账登记，再在基线清单的变更记录中追加影响条目，避免同一件事在多处重复描述。
用协作工具维护基线清单时要注意什么？
工具承载的是清单文档和审批记录，冻结语义仍需团队约定。可以把清单作为受控文档管理，用页面版本记录查看与回滚历史，用权限区分基线负责人的编辑权与其他成员的只读权，并通过页面模板建立统一格式。ONES Wiki 支持页面版本记录与角色权限配置，也提供页面模板库；具体字段结构和冻结操作方式以团队实际开通版本与配置为准。
