研发基线建立，是把一组已通过评审、处于受控状态的研发资产固定为可识别、可追溯、可复现的组合，并规定其变更必须经过审批。落地时按“定对象—定规则—齐套核对—评审批准—冻结发布—变更再基线”推进，本文给出每一步的输入、动作、输出，配套角色分工表、一个迭代版本基线的完整示例和一份可逐项判断的完成检查清单。
要点总览（TL;DR）
- 研发基线建立是把已通过评审的研发资产固定为可识别、可追溯、可复现的组合，并规定其变更必须审批；主线为定对象、定规则、齐套核对、评审批准、冻结发布、变更再基线。
- 建立前先定两件事：按功能基线、分配基线、产品基线圈定纳入清单与排除项；用类型、版本序列和日期构成基线标识，并写明递增条件与审批人。
- 角色分工要保证核对与审批的独立性：配置管理员组织齐套与冻结，项目经理确认范围，开发与测试负责人提交资产并处理不一致，评审组给出结论。
- 基线可用与否看四类检查：资产完整一致、记录可还原快照、冻结后修改需审批、变更后形成新基线且旧记录可查。
- 出现核对表长期“待确认”、通知无人确认、冻结后直接改资产、变更不形成新基线等信号时，按受影响资产范围返工。
研发基线建立的核心步骤
基线建立的主线可以概括为六个动作：确定基线对象与颗粒度、定义命名与版本规则、资产齐套与一致性核对、基线评审与批准、冻结入库并发布通知、基线变更的申请评估与再基线。前两步是规则准备，中间三步是本次基线的建立过程，最后一步是基线生效后的持续控制。下表按执行顺序列出每步的输入、动作、输出与完成标志，可直接作为团队的操作底稿。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 确定基线对象与颗粒度 | 项目阶段计划、资产分类清单、合同或内部质量要求 | 按基线类型圈定纳入范围，明确哪些需求、设计、接口、构建配置进入本次基线，哪些作为排除项并写明理由 | 基线对象清单（含纳入项与排除项） | 清单经项目经理与配置管理员确认，无“待定”条目 |
| 2. 定义命名、版本号与存放位置规则 | 组织级配置管理规范、已有基线命名习惯 | 确定基线标识编码规则、版本号递增规则、基线记录与资产在配置库中的存放路径 | 基线命名与版本规则说明 | 规则可被他人按说明独立命名出下一个基线，不产生歧义 |
| 3. 资产齐套与一致性核对 | 基线对象清单、各资产当前版本 | 逐项核对资产是否存在、版本是否为评审通过的版本、需求与设计、设计与接口之间是否对应一致 | 齐套核对记录（缺项、版本不符项、不一致项） | 缺项与不一致项全部关闭或经批准转为排除项 |
| 4. 基线评审与批准 | 齐套后的资产包、核对记录 | 组织评审组对基线内容进行评审，记录评审意见与结论，由授权人签署批准 | 基线评审记录、批准结论 | 评审结论为通过，批准人签字或系统审批完成 |
| 5. 冻结入库并发布基线通知 | 批准的资产包、命名规则 | 将资产按规则冻结为基线快照，登记基线记录，向相关角色发布基线通知 | 基线记录、基线通知 | 基线可被独立检索到，通知已送达需求、开发、测试等接收方 |
| 6. 基线变更的申请、评估与再基线 | 变更申请、受影响资产分析 | 受理变更申请，评估影响范围与工作量，审批通过后修改资产，按规则形成新的基线版本 | 变更记录、新基线记录 | 变更全程留痕，旧基线仍可追溯，新基线完成发布 |
执行时有两个容易出问题的节点。其一是第3步，齐套核对常被简化为“文件都在”，实际要核对版本是否为评审通过的版本，以及需求、设计、接口之间的对应关系是否成立。其二是第5步，冻结之后资产仍被随意修改，基线就失去意义，因此冻结动作要与权限控制同时落地。在资产齐套核对和评审环节，团队可以用ONES的工作项与文档状态管理承载资产清单、评审记录和审批流转，让“哪些资产已评审、哪些还缺”在同一个视图里可见，减少线下表格反复对账。
基线对象与版本标识怎么定
基线对象决定“纳入什么”，版本标识决定“怎么叫得清楚”，这两件事在建立前定不下来，后续核对和追溯都会返工。
基线类型与适用场景
常见的三类基线对应研发过程的不同节点。功能基线通常在需求评审通过后建立，固定系统对外承诺的功能范围；分配基线在系统设计确定后建立，把功能分配到各子系统或模块，固定接口与模块职责；产品基线在版本发布前建立，固定可交付的构建配置与配套文档。团队规模较小、阶段划分不细时，可以只建功能基线和产品基线，但要在规范中写明取舍，避免同一资产在不同类型基线中重复登记却版本不一致。
纳入清单与排除项
纳入基线的资产应满足两个条件：已通过对应评审，且后续变更需要被控制。典型纳入项包括需求文档与需求条目、系统与详细设计、接口定义、构建配置与依赖清单、测试用例与测试计划。排除项也要显式写出，例如过程性的会议纪要、临时验证脚本、尚未评审通过的草案。排除不等于不重要，而是说明它们不进入本次受控组合，避免基线包被无关内容稀释。
版本号与基线标识规则
基线标识建议包含类型、版本序列和日期三个要素，例如“产品基线 V1.2.0-20240630”，其中主版本号对应不兼容的范围调整，次版本号对应功能增补，修订号对应缺陷修正类变更。规则要写清楚递增条件和审批人，使任何人按规则都能推出下一个基线该叫什么。资产自身的版本号与基线标识分开管理：基线标识标识“这一组资产的组合状态”，资产版本号标识单个文件的演进，两者通过基线记录关联。
基线快照与配置库的对应关系
基线快照是资产在某一时刻的组合状态，配置库是资产的实际存放位置。基线记录中应写明每个资产在配置库中的路径与版本，使快照可以被还原。这样做的价值在复现：当需要回查某个已发布版本用了哪版需求、哪版接口时，从基线记录即可定位，而不必依赖个人记忆。
角色分工与各环节交付物
基线建立涉及多个角色，单人包办会导致核对失去独立性、审批流于形式。下表按角色列出主要动作与交付物，团队可据此分配职责。
| 角色 | 主要动作 | 输入 | 输出交付物 |
|---|---|---|---|
| 配置管理员 | 维护命名与版本规则、组织齐套核对、执行冻结入库、登记基线记录、发布通知 | 基线对象清单、各资产版本信息 | 基线记录、基线通知、齐套核对记录 |
| 项目经理 | 确认基线范围与时间点、协调评审资源、批准排除项 | 阶段计划、质量要求 | 基线对象清单确认、排除项批准记录 |
| 开发负责人 | 提交设计与接口资产、确认构建配置、处理核对中发现的不一致 | 设计文档、接口定义、构建配置 | 提交的资产版本、不一致项处理结论 |
| 测试负责人 | 提交测试用例与计划、核对需求与用例的覆盖对应 | 需求条目、测试资产 | 测试资产版本、覆盖核对结论 |
| 评审组 | 评审基线内容的完整性与一致性、给出通过或不通过结论 | 齐套后的资产包、核对记录 | 评审记录与评审结论 |
审批权限要与基线类型匹配：功能基线和分配基线通常由项目经理或技术负责人批准，产品基线由更高一级的发布负责人批准。升级路径要提前写明，例如评审出现重大分歧时提交给项目管理层裁决，避免评审卡住后无人推进。基线管理与相邻工作的边界也要划清：需求变更走需求变更流程，基线只负责记录变更后形成的新组合状态；交付制品的打包与发布由制品管理负责，基线提供的是可追溯的资产组合依据。在评审与审批环节，ONES的审批流转和状态记录可以把评审意见、批准结论与基线记录关联在同一工作项下，便于后续追溯谁在何时批准了哪一版基线。
示例：一个迭代版本基线的建立过程
以下为演示情景，用于说明步骤、角色与产物如何串联，不代表特定团队的真实数据。
示例背景与基线范围
某研发团队准备发布订单模块的迭代版本，计划建立一次产品基线。基线范围包括：本期新增和修改的需求条目共18条、订单模块详细设计文档、对外接口定义5个、构建配置与依赖清单、对应测试用例。排除项为过程会议纪要和一份尚未评审通过的优化方案草案，排除理由经项目经理批准并记录。
从资产齐套到评审通过
配置管理员按规则将本次基线命名为“订单模块产品基线 V1.3.0-20240630”，并建立核对表。开发负责人提交设计与接口资产，测试负责人提交测试用例。核对中发现两个问题：一条需求条目对应的设计章节缺失，一个接口定义存在两个版本且未标注哪个为评审通过版本。开发负责人补充设计章节并确认接口版本，配置管理员更新核对表后关闭两项。随后评审组评审，结论为通过，项目经理签署批准。
基线记录与通知内容示例
基线记录包含：基线标识、建立日期、基线类型、纳入资产清单及各自版本与存放路径、排除项及理由、评审记录编号、批准人。基线通知写明基线标识、生效时间、接收角色、变更申请入口，并提示“自生效时间起，纳入资产的修改须走变更申请”。通知发送给需求、开发、测试和发布相关角色。
建立后发生变更时的处理示例
基线生效两周后，业务方提出一条需求调整。变更申请提交后，配置管理员评估受影响资产：1条需求条目、1个接口定义、2条测试用例。审批通过后，开发与测试分别修改资产，配置管理员按规则形成“订单模块产品基线 V1.3.1-20240715”，旧基线记录保留可查。整个过程留下变更申请、影响评估、审批结论和新基线记录四类凭据。
完成检查：基线是否真的可用
流程走完不等于基线可用。以下清单按四类检查项组织，每项给出可判断的通过标准，全部通过才建议宣布基线建立完成。
| 检查类别 | 检查项 | 通过标准 |
|---|---|---|
| 资产完整性与一致性 | 纳入清单中的资产是否全部存在 | 无缺项，缺项均已关闭或经批准转为排除项 |
| 资产完整性与一致性 | 资产版本是否为评审通过的版本 | 每个资产版本与评审记录一致，无多版本并存未标注的情况 |
| 资产完整性与一致性 | 需求、设计、接口、用例之间是否对应 | 抽查关键需求可沿设计、接口、用例逐层找到对应项 |
| 可追溯性与可复现性 | 基线记录是否写明每个资产的路径与版本 | 按记录可独立定位并还原基线快照 |
| 可追溯性与可复现性 | 基线标识是否符合命名规则 | 标识可被他人按规则复现出下一个版本号 |
| 变更受控与通知 | 冻结后资产修改是否需审批 | 未审批的修改无法直接进入基线资产 |
| 变更受控与通知 | 基线通知是否送达相关角色 | 需求、开发、测试、发布角色均确认收到 |
| 变更受控与通知 | 变更后是否形成新基线并保留旧记录 | 新旧基线均可检索，变更全程留痕 |
常见失败信号包括：核对表长期存在“待确认”条目却已宣布基线建立；基线通知发出后无人确认接收；冻结后仍出现直接修改资产的情况；变更后只更新资产、不形成新基线记录。出现上述任一信号，应回到对应步骤返工，返工范围以受影响资产为限，不必推翻整个基线。基线建立的价值最终体现在两件事上：需要回查时能准确还原当时的资产组合，需要变更时能清楚知道改了哪些、谁批准的、形成了哪个新版本。
常见问题
团队规模小、阶段划分不细，能不能只建功能基线和产品基线？
可以，前提是把取舍写进团队规范。功能基线在需求评审通过后固定对外承诺的功能范围，产品基线在版本发布前固定构建配置与配套文档，两者已能覆盖“做什么”和“交付什么组合”两个关键节点。分配基线主要用于系统设计确定后把功能分配到子系统、固定接口与模块职责，如果团队模块划分简单、接口变动不频繁，可以暂不单独建立。需要注意的是，取舍一旦确定就要在规范中写明，避免同一资产在不同类型基线中重复登记却版本不一致。
基线冻结后，紧急缺陷修复也必须走变更申请吗？
建议走，但可以按影响范围设置简化路径。冻结的意义在于“未审批的修改无法直接进入基线资产”，紧急修复同样需要留下申请、影响评估和审批结论，只是评估范围可以限定在受影响的资产上，审批人可以预先指定为值班负责人。修复完成后按规则形成新的修订版本基线，旧基线记录保留可查。如果允许紧急修复绕过流程直接改资产，基线记录与实际资产就会脱节，后续回查某个已发布版本用了哪版接口时便无法还原。
基线记录里要写到什么程度，才算“可还原”？
判断标准是：换一个人只凭基线记录，能独立定位到每个资产并还原出当时的组合状态。因此记录中至少要写明基线标识、建立日期、基线类型、纳入资产清单及各自版本与存放路径、排除项及理由、评审记录编号和批准人。资产自身的版本号与基线标识要分开记录，通过基线记录关联起来。如果记录只写了“某版本已发布”而没有逐项路径与版本，回查时仍需依赖个人记忆或翻找聊天记录，就不算可还原。
齐套核对时发现需求与设计对不上，应该先改资产还是先调整基线范围？
先判断不一致的性质。如果是设计章节缺失或版本未更新，属于资产本身的问题，由开发负责人补充或更新后重新核对；如果是该需求本就不属于本期范围，则走排除项批准，由项目经理确认后从基线对象清单中移出并记录理由。两种处理都要在核对表中留下关闭记录，避免“待确认”条目被带入评审。评审组只对齐套后的资产包给出结论，把未关闭的不一致项带进评审，会让评审结论失去意义。
基线建立完成后，怎么和需求变更、交付制品管理衔接？
边界按“谁负责改变、谁负责记录组合状态”划分。需求变更由需求变更流程受理和审批，基线负责在变更完成后记录形成的新组合状态，并保留旧基线；交付制品的打包、发布与制品库管理由制品管理负责，基线提供的是可追溯的资产组合依据，供发布时引用。衔接动作有两个：变更审批通过后通知配置管理员评估受影响资产并形成新基线；发布前核对发布内容引用的基线标识是否为最新有效版本。这样三件事各归其位，又通过基线标识串起来。
