研发基线建立检查清单围绕“受控组合”展开：先确认基线范围与纳入对象，再核对每个配置项的版本唯一性、完整性与可追溯性，随后检查冻结状态、基线说明与发布记录字段是否齐全，最后以阻断项全部关闭、证据可查作为通过条件。这份清单适合配置管理员、项目经理在基线建立前准备、建立中核对、发布前评审三个节点逐项使用。
要点总览（TL;DR）
- 清单按三个节点使用：建立前准备核对范围与配置项就绪，建立中核对冻结、标识与追溯，发布前评审确认审批、通知与回执闭环。
- 准备阶段的核心是通过标准是范围书面确认、配置项清单完整、每个配置项版本唯一；命名分类不统一可列为非阻断项限期整改。
- 建立阶段要落到可观察证据：标签已打、冻结后修改被拒绝、追溯链路抽样可查，仅口头确认冻结不足以作为证据。
- 基线说明必填基线名称、标识、范围、纳入配置项及版本、建立依据、责任人、生效时间；发布记录必填发布时间、发布人、审批人、变更对比、通知范围。
- 阻断项包括配置项缺失、版本不唯一、未冻结、审批缺失、追溯断裂，全部关闭且必填字段无空缺、评审结论落实后才算基线建立完成。
谁在什么时点使用这份清单
这份清单解决的是“谁在哪个节点开始逐项核对”的问题。基线建立涉及多个角色，不同角色关注的检查项不同，混在一起核对容易出现遗漏或重复确认。使用前先对照下表确定自己的角色和所处节点，再进入对应章节。
| 角色 | 主要使用时点 | 需要准备的前置输入 | 关注重点 |
|---|---|---|---|
| 配置管理员 | 建立前准备、建立中核对 | 配置项清单、版本记录、配置库权限与目录结构 | 范围完整性、版本唯一性、冻结与标识 |
| 项目经理 | 建立前准备、发布前评审 | 基线范围说明、变更单、评审安排 | 范围确认、待处理项清理、审批闭环 |
| 开发/测试负责人 | 建立中核对 | 本领域配置项及版本、追溯关系 | 配置项内容正确、追溯关系可查 |
| 评审人 | 发布前评审 | 基线说明、发布记录草稿、检查表填写结果 | 字段齐全、阻断项清零、结论记录 |
三个触发时点的划分方式是：建立前准备阶段完成范围与配置项就绪核对；建立中核对阶段确认冻结、标识与追溯已落实；发布前评审阶段确认审批、通知与回执闭环。前置输入不齐时，先补齐输入再开始核对，避免在核对过程中反复回退。
本清单的范围边界是基线受控组合本身。需求版本变更的具体操作归需求变更与版本管理，交付制品的打包、分发与制品库管理归研发交付物与制品管理，这两部分不在本清单内展开。基线中引用的需求版本和制品版本，只核对“是否已纳入、版本是否唯一”，不检查其变更流程或分发流程是否合规。
准备阶段检查项：范围与配置项是否就绪
准备阶段的目的是在进入冻结环节前，确认基线范围和纳入对象已经明确、配置项清单可用。以下检查项全部通过后，才能进入建立阶段。
| 检查项 | 通过标准 | 证据 | 负责人 | 阻断 |
|---|---|---|---|---|
| 基线范围与纳入对象已书面确认 | 基线范围说明中列明纳入的产品、模块或阶段，以及明确排除的对象，经项目经理确认 | 基线范围说明文档及确认记录 | 项目经理 | 是 |
| 配置项清单完整 | 范围内应纳入的需求、设计文档、代码分支或标签、配置文件等均已列入清单，无遗漏项 | 配置项清单 | 配置管理员 | 是 |
| 命名与分类统一 | 配置项命名符合团队约定规则，分类口径一致，同类配置项可批量识别 | 配置项清单中的命名与分类字段 | 配置管理员 | 否 |
| 版本唯一可识别 | 每个配置项有明确的版本号或标识，同一配置项不存在两个并行版本被同时纳入 | 版本记录、配置库版本列表 | 开发/测试负责人 | 是 |
| 配置库权限与目录结构就绪 | 基线相关目录或分支已建立，写入权限已按角色配置，冻结后需要的只读权限可切换 | 权限配置记录、目录结构截图或说明 | 配置管理员 | 是 |
| 变更单与待处理项已清理或标注 | 与纳入配置项相关的变更单已关闭或明确标注处理状态，未决变更不影响本次基线内容 | 变更单列表及状态 | 项目经理 | 是 |
准备阶段最常见的缺口是配置项清单与版本记录对不上：清单里列了某个模块，版本记录里却找不到对应版本，或者同一模块存在多个候选版本未做取舍。遇到这种情况，先由开发负责人确认应纳入的版本并补录版本记录，再回到清单核对，不能带着版本歧义进入冻结。
命名与分类不统一列为非阻断项，原因是它影响后续检索和维护效率，但不改变受控组合的内容本身。处理方式是记录问题、限期在下次基线前整改，本次基线仍可继续。
建立阶段检查项：冻结、标识与追溯是否落实
建立阶段核对的是受控动作是否真正执行到位。准备阶段确认了“纳入什么”，建立阶段确认“纳入后是否被锁住、能否追溯”。
| 检查项 | 通过标准 | 证据 | 负责人 | 阻断 |
|---|---|---|---|---|
| 配置项完成冻结或打标签 | 每个纳入配置项已打基线标签或进入冻结状态，冻结后直接修改通道已关闭 | 标签列表、冻结操作记录 | 配置管理员 | 是 |
| 基线标识与版本号规则统一 | 基线标识按约定规则生成，与配置项版本号可区分，全团队可识别 | 基线标识记录 | 配置管理员 | 是 |
| 追溯关系已建立并可查 | 需求、设计、代码、测试用例之间的关联关系可在工具或文档中查到，从任一配置项可定位上下游 | 追溯关系记录或关联视图 | 开发/测试负责人 | 是 |
| 基线说明文档字段齐全 | 按下一节字段模板填写完整，必填字段无空缺 | 基线说明文档 | 配置管理员 | 是 |
| 异常与例外项已登记 | 未能按常规纳入或冻结的配置项已登记，说明原因、影响和处理方式，并经项目经理确认 | 例外项登记表 | 项目经理 | 否 |
冻结检查要落到可观察的状态上：标签是否已打、冻结后尝试修改是否被拒绝或需要走解冻流程。仅口头确认“已冻结”不足以作为证据。追溯关系检查可以从抽样开始，抽取若干需求，沿设计、代码、测试用例走一遍链路，确认每一跳都能查到对应对象。
异常与例外项登记列为非阻断项，前提是例外项已说明处理方式且不影响基线整体可用性。如果例外项涉及核心配置项缺失或版本不明，则按阻断项处理。
在工具中承载这些动作时，基线冻结、配置项版本与评审记录需要落在同一处可查。ONES 支持将工作项与文档纳入版本化管理和评审流程，基线标签、冻结状态与评审结论可以随工作项记录留存，便于在核对时直接调取证据，减少在多个系统间比对版本的工作。
基线说明与发布记录应包含哪些字段
基线说明回答“这条基线包含什么”，发布记录回答“这条基线何时、经谁、向谁生效”。两张表分别给出字段结构，必填字段缺失即视为未完成。
| 文档 | 字段 | 必填/选填 | 填写要求 | 对应检查项 |
|---|---|---|---|---|
| 基线说明 | 基线名称 | 必填 | 体现产品、模块与阶段，团队内唯一 | 基线范围确认 |
| 基线说明 | 基线标识 | 必填 | 按统一规则生成，与版本号可区分 | 标识规则统一 |
| 基线说明 | 范围 | 必填 | 列明纳入与排除的对象 | 范围书面确认 |
| 基线说明 | 纳入配置项及版本 | 必填 | 逐项列出配置项名称与版本，与配置项清单一致 | 配置项清单完整、版本唯一 |
| 基线说明 | 建立依据 | 必填 | 说明触发基线的事件或阶段，如版本发布、里程碑 | 变更单清理 |
| 基线说明 | 责任人 | 必填 | 指定基线维护责任人 | 角色分工 |
| 基线说明 | 生效时间 | 必填 | 基线正式生效的日期时间 | 发布状态更新 |
| 基线说明 | 例外项说明 | 选填 | 有例外项时填写，无则注明“无” | 异常与例外项登记 |
| 发布记录 | 发布时间 | 必填 | 实际发布的时间 | 发布状态更新 |
| 发布记录 | 发布人 | 必填 | 执行发布操作的人员 | 审批留痕 |
| 发布记录 | 审批人 | 必填 | 完成审批的人员及审批结论 | 审批完成 |
| 发布记录 | 变更对比 | 必填 | 相对上一条基线的增删改配置项及版本变化 | 版本唯一、追溯可查 |
| 发布记录 | 通知范围 | 必填 | 接收发布通知的团队或角色 | 通知覆盖 |
| 发布记录 | 回执 | 选填 | 需要确认的关键相关方回执记录 | 回执回收 |
字段与检查项的对应关系决定了核对顺序：先填基线说明，再据此核对建立阶段检查项；发布记录在评审通过后填写，作为发布闭环的证据。变更对比字段是发布记录中最容易被省略的一项，它直接支撑“相对上一条基线改了什么”的可追溯性，建议保留上一条基线的标识以便对照。
评审与发布检查项：审批、通知与回执是否闭环
评审与发布阶段确认基线对外生效。以下检查项在发布前评审会上逐项确认，发布后补充回执与状态更新记录。
| 检查项 | 通过标准 | 证据 | 负责人 | 阻断 |
|---|---|---|---|---|
| 评审参与角色齐全 | 配置管理员、项目经理、开发/测试负责人及必要评审人到场或书面意见齐全 | 评审签到或意见记录 | 项目经理 | 是 |
| 评审结论已记录 | 评审结论明确为通过、有条件通过或不通过，有条件通过需列明条件 | 评审记录 | 评审人 | 是 |
| 审批完成并留痕 | 审批人已签署或系统审批流已完成，审批意见可查 | 审批记录 | 项目经理 | 是 |
| 发布通知覆盖相关方 | 通知范围覆盖使用该基线的开发、测试及相关团队，渠道为团队约定渠道 | 通知记录 | 配置管理员 | 是 |
| 回执或确认记录回收 | 关键相关方已确认知悉，回执记录可查 | 回执记录 | 配置管理员 | 否 |
| 基线状态更新为生效 | 基线在配置库或管理工具中的状态已更新为生效，旧基线状态同步标注 | 状态变更记录 | 配置管理员 | 是 |
回执回收列为非阻断项，适用于通知已发出但部分相关方尚未确认的情况，处理方式是限期补收并在复查时点核对。如果通知本身未覆盖关键团队，则属于阻断项，需补发通知后再发布。
阻断项与完成条件：哪些缺口必须清零
阻断项是基线建立完成的硬性门槛，任何一项未关闭都不能宣布基线建立完成。以下清单汇总各阶段的阻断项，便于在评审前统一核对。
| 阻断项 | 判定标准 | 关闭方式 |
|---|---|---|
| 配置项缺失 | 范围内应纳入的配置项未列入清单 | 补入清单并确认版本 |
| 版本不唯一 | 同一配置项存在多个候选版本且未取舍 | 确认唯一版本并更新版本记录 |
| 未冻结 | 纳入配置项未打标签或未进入冻结状态 | 完成冻结操作并留存记录 |
| 审批缺失 | 审批人未签署或审批流未完成 | 完成审批并留存记录 |
| 追溯断裂 | 需求、设计、代码、测试用例之间存在无法查到的关联 | 补齐关联关系并抽样验证 |
非阻断项包括命名分类不统一、例外项登记不完整、回执未全部回收等，处理方式是登记问题、指定责任人和整改期限，在下次基线或约定复查时点核对关闭情况。非阻断项不影响本次基线生效，但需要在发布记录中注明遗留问题。
整体通过条件为：全部阻断项关闭，基线说明与发布记录必填字段无空缺，评审结论为通过或有条件通过且条件已落实，基线状态已更新为生效。满足条件后由项目经理与配置管理员共同签署确认，签署记录与各阶段检查表一并留存。
证据留存位置建议与基线本身放在同一管理空间：检查表、基线说明、发布记录、审批与通知记录按基线标识归档，便于复查时按标识一次性调取。复查时点可设在基线生效后一个迭代周期或下一次基线建立前，重点核对非阻断项的整改情况与例外项的实际影响。
常见问题
基线建立过程中发现某个配置项版本还没定，应该先冻结还是先确认版本？
先确认版本，再冻结。版本不唯一属于阻断项，带着两个候选版本进入冻结，会让基线内容本身不确定，后续追溯和变更对比都失去基准。
处理顺序是：由开发负责人确认应纳入的唯一版本，补录版本记录，回到配置项清单核对一致，然后再执行打标签或冻结操作。如果该配置项确实无法在本次基线前定版，应作为例外项登记，说明原因、影响和处理方式，经项目经理确认后决定是排除出本次范围还是延后建立。
回执没有全部收回，基线能不能先发布？
可以发布，前提是发布通知已经覆盖使用该基线的关键团队。回执回收在清单中列为非阻断项，适用于通知已发出、部分相关方尚未确认的情况，处理方式是限期补收并在复查时点核对。
需要区分的是通知本身是否到位：如果通知未覆盖关键开发或测试团队，属于阻断项，需补发通知后再发布。发布记录中应注明回执回收的遗留情况，避免复查时无法判断当时的状态。
基线说明里的“变更对比”字段，第一次建立基线时怎么填？
首次建立基线时没有上一条基线可对比，可以在变更对比字段中注明“首次建立，无上一条基线”，并列出本次纳入的配置项范围作为对照基础。这个字段的作用是支撑“相对上一条基线改了什么”的可追溯性，首次基线把这个起点记录清楚，后续基线才有对照对象。
从第二条基线开始，建议在发布记录中保留上一条基线的标识，逐项列出新增、删除和版本变化的配置项，便于评审人和相关方快速判断影响范围。
非阻断项遗留到下次基线前还没整改完，该怎么处理？
在复查时点核对整改进度，未关闭的继续登记并说明原因，同时评估它对当前基线可用性的实际影响。非阻断项不影响本次基线生效，但需要在发布记录中注明遗留问题，避免问题在多次基线之间被悄悄遗忘。
如果遗留问题的影响扩大，例如命名混乱导致配置项被重复纳入或漏纳，应重新评估是否升级为阻断项处理。复查时点可设在基线生效后一个迭代周期或下一次基线建立前，与证据留存位置一并安排。
小团队也需要按三个节点分别核对吗？
节点划分的目的是让不同角色在不同时点关注不同检查项，团队规模小、角色合并时，可以由同一人依次完成三个节点的核对，但检查项本身不建议省略。范围确认、版本唯一、冻结与追溯、审批与通知这几类动作，与团队规模无关，缺一项都会让基线的受控状态打折扣。
可以简化的是表单形式和评审会议规模，例如把评审意见改为书面确认、把检查表合并为一张带阶段标记的表格，通过标准和阻断项判定保持不变。
