研发基线清单应聚焦哪些受控对象

研发基线清单聚焦的是被正式批准、需要整体冻结并可回溯的一组配置项及其版本组合，典型对象包括已批准需求条目、设计与接口文档、代码分支与标签、构建产物标识，以及配套测试用例与记录。它记录某一时点的版本快照和批准状态，与全量登记的配置项清单、单一配置项的版本清单承担不同职责。

要点总览（TL;DR）

• 研发基线清单记录的是被正式批准、需要整体冻结并可回溯的一组配置项及其版本组合，核心字段包括对象标识、版本号、批准状态、批准时间与责任人。
• 应聚焦五类受控对象：已批准需求条目、架构与接口等设计文档、代码分支与标签、构建产物与部署配置、测试用例与测试记录。
• 配置项清单是全量资产底库，版本清单是单一对象的演进历史，基线清单是从中选取特定版本形成的批准快照，三者互相配合。
• 需求版本的日常变更归需求变更与版本管理，交付制品的分发归档归研发交付物与制品管理，基线清单只在边界处引用，不重复展开。
• 常见误解是把清单当成全量资产台账，以及基线批准后直接改动被冻结对象而不走变更流程。

研发基线清单是什么：一句话定义

研发基线清单是一份经正式批准、可回溯的配置项版本组合记录。它回答的问题很具体：在某个约定时点，哪些对象以哪个版本被纳入受控状态，由谁批准，从何时起生效。清单本身不承载对象内容，只承载对象标识与版本状态的对应关系。

一份可用的基线清单通常包含以下核心字段：

• 对象标识：配置项的唯一编号或名称，保证清单条目能准确指向配置库中的具体对象。
• 版本号：该对象被纳入基线时的版本，例如需求条目 V2.1、接口文档 V1.3、代码标签 release-2.4.0。
• 批准状态：标明该条目已通过评审或审批，处于受控状态。
• 批准时间：基线生效的时间点，是后续回溯和比对的时间锚点。
• 责任人：对该条目版本负责的角色，便于变更时找到确认人。

理解基线清单与配置库的关系，可以用一个比喻：配置库是持续演进的仓库，基线清单是从仓库中切出的一个时间切片。切片一旦形成，其中的版本组合就被固定下来，后续任何改动都需要通过变更流程重新形成新的切片。清单的价值在于让“当时批准的是什么”这件事可查、可比、可追责。

基线清单的边界：哪些对象进清单，哪些不进

判断一个对象是否进入基线清单，可以看两个条件：它是否已被正式批准，以及它是否需要与其他对象一起整体冻结并支持回溯。两个条件同时满足，才构成纳入理由。只满足其中一个，通常应留在原有管理流程中，不必进入清单。

按这个标准，几类相邻对象的归属需要说清楚：

• 需求版本变更的日常管理归需求变更与版本管理。基线清单只记录被纳入基线的那一版需求条目，不记录需求从草稿到定稿的每一次修改过程。
• 交付制品的分发、归档与制品库管理归研发交付物与制品管理。基线清单可以引用构建产物标识作为条目，但制品的存储、分发和归档策略不在清单中展开。
• 未批准、临时性、个人工作区内容不进入基线清单。草稿文档、个人分支上的实验代码、尚未评审通过的需求，都缺少“正式批准”这一前提。

这条边界的作用是防止清单无限扩张。如果所有资产都往清单里放，清单就退化成资产台账，失去“冻结切片”的意义。反过来，清单条目过少、遗漏关键受控对象，又会让回溯出现断点。实践中可以先用纳入标准筛一遍，再检查五类对象是否都有覆盖。

在协作工具中承载这套边界时，工作项和文档的版本状态需要能被记录和查询。ONES 当前方案覆盖需求、基线、版本、变更、测试与发布，围绕需求、基线、版本和变更建立统一管理对象，支撑需求变更影响分析、过程状态追踪和交付结果回溯。这类方案层面的能力可以作为基线清单落地时的承载参考，具体字段和操作方式仍需结合团队实际配置确认。

基线清单应聚焦的五类受控对象

研发基线清单的对象范围通常收敛到五类。每类对象在清单中的呈现方式不同，但都遵循“对象标识 + 版本 + 批准状态”的基本结构。

需求类：已批准的需求条目

需求基线的组成单位是已批准的需求条目及其版本。清单中一行对应一个需求条目，记录需求编号、当前批准版本和批准状态。需求条目的粒度建议与需求管理中的拆分粒度保持一致，避免一条清单行对应多个需求导致回溯时无法定位。

设计类：架构与接口文档版本

设计基线覆盖架构文档、接口定义、数据模型等设计文档的版本。这类对象的版本变化往往影响多个下游对象，清单中除版本号外，可补充文档所属模块或系统，便于变更影响分析时快速圈定范围。

代码类：分支、标签与提交标识

代码基线的锚点通常是代码分支、标签或提交标识。清单中记录标签名称或提交哈希，而不是罗列每个源文件。标签命名建议与发布版本对应，使代码基线能与其他四类对象在同一版本口径下对齐。

构建与发布类：构建产物与部署配置

构建与发布基线记录构建产物标识、发布包版本和部署配置。构建产物标识应能唯一指向某次构建结果，部署配置则记录该版本对应的环境参数。这类条目把代码基线与实际交付物连接起来，是回溯“这个版本到底部署了什么”的关键。

测试类：测试用例版本与测试记录

测试类对象包括测试用例版本和对应的测试记录，作用是支撑基线可验证。清单中记录用例集版本和执行记录标识，使基线不仅说明“批准了什么”，还能说明“用什么验证过”。

五类对象的清单条目可以统一为一张表，字段建议如下：

对象类型	对象标识示例	版本字段示例	批准状态
需求	REQ-1024 登录鉴权改造	V2.1	已批准
设计	接口文档-用户中心 API	V1.3	已批准
代码	标签 release-2.4.0	commit a1b2c3	已打标
构建与发布	构建产物 build-2.4.0-118	发布包 2.4.0	已批准
测试	用例集-登录模块回归	V1.0 + 执行记录 R-88	已通过

基线清单、配置项清单与版本清单的区别

这三个概念容易混用，原因在于它们都围绕“配置项”展开，但回答的问题不同。配置项清单回答“有哪些受控资产”，版本清单回答“某个资产经历了哪些版本”，基线清单回答“在某一时点，哪些资产的哪些版本被批准冻结”。三者是底库、历史与切片的关系，互相配合而非互相替代。

对比维度	配置项清单	版本清单	基线清单
回答的问题	有哪些受控资产	某个资产有哪些版本	某时点哪些版本被批准冻结
范围	最大，全量登记	单一配置项的演进记录	从全量中选取的特定版本组合
时间属性	持续维护	按版本累积	某一时点的快照
是否含批准状态	通常不含	通常不含	必须含
主要用途	资产登记与分类	追溯单个对象的历史	整体回溯、比对与审计

三者的关系可以这样理解：配置项清单是底库，提供可选对象的全集；版本清单是历史，记录每个对象的演进轨迹；基线清单是冻结切片，从底库中按版本挑出一组对象并赋予批准状态。建立基线时，先从配置项清单确认对象范围，再从版本清单确认具体版本，最后形成基线清单。缺少前两者，基线清单的条目就缺少可核对的来源。

一个具体例子：发布前的基线清单长什么样

以下为演示性示例，用于说明清单的填写形态，不代表真实客户案例。某团队准备发布 2.4.0 版本，在发布前建立发布基线，清单条目按五类对象各列一行：

• 需求：REQ-1024 登录鉴权改造，版本 V2.1，状态已批准，批准时间 3 月 12 日，责任人产品负责人。
• 设计：接口文档-用户中心 API，版本 V1.3，状态已批准，批准时间 3 月 14 日，责任人架构师。
• 代码：标签 release-2.4.0，指向提交 a1b2c3，状态已打标，打标时间 3 月 20 日，责任人开发负责人。
• 构建与发布：构建产物 build-2.4.0-118，发布包版本 2.4.0，状态已批准，批准时间 3 月 21 日，责任人发布经理。
• 测试：用例集-登录模块回归 V1.0，关联执行记录 R-88，状态已通过，通过时间 3 月 19 日，责任人测试负责人。

这份清单形成后，团队可以据此回答“2.4.0 版本批准了哪些需求、对应哪份设计、哪段代码、哪个构建产物、用什么测试验证过”。发布后若发现缺陷需要回溯，清单提供了完整的对象与版本对应关系。

实际使用中有两个常见误解需要纠正。第一个误解是把基线清单当成全量资产台账，把所有文档、所有代码分支都列进去。这样做的结果是清单体积膨胀、批准状态难以维护，回溯时反而找不到关键条目。清单应只保留被正式批准并需要整体冻结的对象。第二个误解是基线建立后仍随意改动被冻结对象而不走变更流程。基线一旦批准，其中的版本组合就应保持稳定；需要修改时，应通过变更流程评估影响、重新批准并形成新的基线版本，而不是直接覆盖原条目。ONES 瀑布项目管理方案支持设置项目计划和里程碑基线，实时对比计划与执行的偏差，并可通过对比版本细节追溯变更细节，这类机制可以作为基线冻结后比对与追溯的参考，具体适用范围以实际产品为准。

常见问题

基线清单里的条目粒度应该多细，需求要拆到子任务级别吗？

条目粒度建议与需求管理中的拆分粒度保持一致，一条清单行对应一个可独立批准和回溯的需求条目。拆到子任务级别会让清单体积膨胀，批准状态难以维护；粒度过粗则一条行对应多个需求，回溯时无法定位到具体对象。判断标准是：该对象能否独立被批准、独立被替换版本。设计文档、代码标签、构建产物同理，按可独立受控的最小单位登记即可。

基线批准之后发现需求要改，是直接改清单还是新建一个基线？

应通过变更流程处理，而不是直接覆盖原条目。基线一旦批准，其中的版本组合就应保持稳定，这样后续回溯才有意义。正确做法是评估变更影响范围，确认受影响的条目，重新批准后形成新的基线版本，原基线保留作为历史记录。直接改动被冻结对象会让“当时批准的是什么”失去可查性，审计和问题回溯时会出现断点。

小团队项目不多，还需要单独维护配置项清单和版本清单吗？

三个清单承担不同职责，是否单独成文可以按团队规模调整，但信息不能缺失。配置项清单提供可选对象的全集，版本清单记录每个对象的演进轨迹，基线清单从中挑出特定版本并赋予批准状态。小团队可以把前两者合并到工具的工作项和文档版本记录中，由工具自动承载，人工只维护基线清单。关键是建立基线时能核对对象范围和具体版本来源，避免条目凭空出现。

代码和构建产物这类对象，基线清单里到底记标签还是记每个文件？

记标签或提交标识，不罗列每个源文件。代码基线的锚点通常是分支、标签或提交哈希，清单中一行记录标签名称或提交标识即可。构建与发布类同理，记录能唯一指向某次构建结果的产物标识和发布包版本。这样清单保持精简，同时通过标签与提交标识仍能精确还原当时的代码状态。标签命名建议与发布版本对应，使代码基线与其他四类对象在同一版本口径下对齐。

基线清单需要包含测试记录吗，还是只列测试用例？

建议同时记录用例集版本和执行记录标识。只列用例版本能说明“用什么验证”，加上执行记录才能说明“验证结果如何”，基线因此具备可验证性。清单中一行可记录用例集版本加关联的执行记录编号，状态填已通过或对应结论。这样发布后回溯时，能回答这个版本批准了哪些需求、用什么用例验证、执行结果是什么。