基线说明用于把“哪些研发资产在什么时点被固定为受控组合”记录清楚，建议包含基线标识、范围与内容、状态与审批、关联与追溯四类字段，并按“表头信息区＋受控资产清单表＋审批与变更规则区＋附件索引”四段式组织。下面给出一份可直接复制填写的空白模板，再逐字段说明填写口径、区分必填与选填，并用一份完整示例演示填写结果，最后补齐配套的建立检查清单与发布记录模板。
要点总览（TL;DR）
- 基线说明建议包含四类字段：基线标识（名称、编号、类型、版本）、范围与内容（受控资产清单及各自版本）、状态与审批（建立原因、生效时间、审批人、变更规则）、关联与追溯（上游需求来源、下游交付衔接、关联变更单）。
- 模板结构采用四段式：表头信息区、受控资产清单表、审批与变更规则区、附件索引区，空白表可直接复制填写。
- 必填字段覆盖标识、范围、审批与变更入口；最小可用版本可省略附件索引、关联需求编号等选填项，适合小型项目或首次推行基线管理的团队。
- 配套的基线建立检查清单与基线发布记录共用基线编号、名称、版本三个关键字段，三份文档按同一口径互相引用。
- 模板调整遵循字段增减有依据、版本变更可追溯的原则；需求版本演进归需求变更与版本管理，交付制品归研发交付物与制品管理，基线说明通过关联字段衔接。
可复制空白模板：基线说明表
以下模板可直接复制到文档工具中填写。表格中的空白行按实际资产数量增删，字段名称保持不变，便于不同项目之间横向比对。
表头信息区
| 字段 | 填写内容 |
|---|---|
| 基线名称 | |
| 基线编号 | |
| 基线类型 | |
| 基线版本 | |
| 所属项目／产品 | |
| 建立原因 | |
| 生效时间 | |
| 编制人／编制日期 | |
| 审批人／审批日期 | |
| 基线状态 |
受控资产清单表
| 序号 | 资产类别 | 资产名称／编号 | 版本号 | 存放位置 | 责任人 | 备注 |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 2 | ||||||
| 3 |
审批与变更规则区
| 字段 | 填写内容 |
|---|---|
| 审批结论 | |
| 审批意见 | |
| 变更申请方式 | |
| 变更审批权限 | |
| 变更后版本规则 | |
| 基线冻结范围说明 |
附件索引区
| 序号 | 附件名称 | 附件类型 | 存放位置 | 关联资产序号 |
|---|---|---|---|---|
| 1 | ||||
| 2 |
字段说明：每个字段填什么、怎么填
模板中的每个字段都对应一个明确的填写口径。下表按四类字段分组说明，填写时以“可被他人独立读懂”为标准，避免只写内部简称。
| 字段 | 含义 | 填写口径 |
|---|---|---|
| 基线名称 | 基线的业务称呼 | 采用“项目＋阶段＋基线类型”的写法，如“订单系统V2.0需求基线” |
| 基线编号 | 基线的唯一标识 | 按团队编号规则生成，建立后不再复用 |
| 基线类型 | 基线固定的资产侧重 | 常见取值：需求基线、设计基线、代码基线、配置基线、交付基线 |
| 基线版本 | 该基线自身的版本 | 首次建立为V1.0，变更后按规则递增 |
| 所属项目／产品 | 基线的归属范围 | 写到可独立交付的项目或产品层级 |
| 建立原因 | 为什么在此刻建立基线 | 写明触发事件，如阶段评审通过、对外交付前冻结 |
| 生效时间 | 基线开始受控的时点 | 精确到日期，必要时到时刻 |
| 编制人／审批人 | 文档责任人与批准人 | 填写实名，审批人应为有权批准该基线类型的角色 |
| 基线状态 | 基线当前所处阶段 | 常见取值：草稿、待审批、已生效、已变更、已关闭 |
| 资产类别 | 受控资产的种类 | 与基线类型呼应，如需求文档、设计文档、代码分支、配置项 |
| 资产名称／编号 | 资产的唯一指称 | 使用系统中的正式名称或编号，便于检索 |
| 版本号 | 资产被固定时的版本 | 填写纳入基线那一刻的版本，不写“最新版” |
| 存放位置 | 资产的实际所在 | 写到仓库、目录或文档空间层级，保证可定位 |
| 责任人 | 资产的对口负责人 | 填写实名，便于变更时联系 |
| 审批结论 | 基线是否获准生效 | 通过、有条件通过、退回，附简要理由 |
| 变更申请方式 | 基线生效后如何提出变更 | 写明提交渠道与所需材料，如变更单＋影响分析 |
| 变更审批权限 | 谁有权批准变更 | 按变更影响范围分级写明角色 |
| 变更后版本规则 | 变更后基线版本如何递增 | 如小范围修正升次版本号，范围调整升主版本号 |
| 附件名称／类型 | 随基线归档的材料 | 如评审记录、测试报告、签字页，注明类型便于分类 |
| 关联资产序号 | 附件与清单行的对应关系 | 填写受控资产清单中的序号，建立索引 |
关联与追溯类信息有两种承载方式：一是在表头增加“上游需求来源”“下游交付衔接”“关联变更单”三个字段，适合基线数量少、追溯关系简单的项目；二是在受控资产清单中增加“关联需求编号”列，适合一条基线覆盖大量需求条目的场景。两种方式选其一即可，避免同一信息在两处重复维护。
必填与选填：哪些字段不能空
基线说明的价值在于可追溯和可审批，因此标识、范围、审批三类信息属于必填。选填字段用于提升检索和协作效率，可按项目复杂度取舍。
| 字段 | 必填／选填 | 理由或适用场景 |
|---|---|---|
| 基线名称、编号、类型、版本 | 必填 | 缺少任一项，基线无法被唯一识别和引用 |
| 所属项目／产品 | 必填 | 确定归属范围，避免跨项目混淆 |
| 建立原因、生效时间 | 必填 | 说明基线的时间边界和建立依据 |
| 受控资产清单（名称、版本、位置） | 必填 | 基线说明的核心内容，缺此项文档失去意义 |
| 编制人、审批人、审批结论 | 必填 | 受控文档需要明确责任与批准状态 |
| 变更申请方式、变更审批权限 | 必填 | 基线生效后必须有变更入口，否则冻结无法执行 |
| 资产责任人 | 选填 | 团队规模较大、资产分散时建议填写 |
| 变更后版本规则 | 选填 | 基线变更频繁的项目建议填写，一次性基线可简化 |
| 基线冻结范围说明 | 选填 | 需要区分“冻结”与“仍可迭代”部分时填写 |
| 附件索引 | 选填 | 有评审记录、测试报告等归档材料时填写 |
| 关联需求编号、关联变更单 | 选填 | 需要与需求管理和变更管理打通时填写 |
最小可用版本的字段组合为：基线名称、编号、类型、版本、所属项目、建立原因、生效时间、受控资产清单（名称、版本、位置）、编制人、审批人、审批结论、变更申请方式、变更审批权限。这一组合可以支撑一次完整的基线建立与后续变更受理，适合小型项目或首次推行基线管理的团队。
填写示例：一份完整的基线说明
以下示例为演示情景，用于说明字段如何组合成可读文档，不代表真实项目数据。
示例背景与基线类型
某订单系统进入V2.0版本开发，需求评审通过后需要冻结本阶段需求范围，建立一条需求基线，供开发和测试按固定范围推进。
表头与资产清单填写示范
| 字段 | 填写内容 |
|---|---|
| 基线名称 | 订单系统V2.0需求基线 |
| 基线编号 | BL-ORD-2024-003 |
| 基线类型 | 需求基线 |
| 基线版本 | V1.0 |
| 所属项目／产品 | 订单系统 |
| 建立原因 | V2.0需求评审通过，开发启动前冻结需求范围 |
| 生效时间 | 2024-06-15 |
| 编制人／编制日期 | 张明／2024-06-14 |
| 审批人／审批日期 | 李华／2024-06-15 |
| 基线状态 | 已生效 |
| 序号 | 资产类别 | 资产名称／编号 | 版本号 | 存放位置 | 责任人 | 备注 |
|---|---|---|---|---|---|---|
| 1 | 需求文档 | 订单创建与支付需求说明 REQ-101 | V2.3 | 需求库／订单系统／V2.0 | 王芳 | 含评审意见修订版 |
| 2 | 需求文档 | 订单履约与售后需求说明 REQ-102 | V1.8 | 需求库／订单系统／V2.0 | 王芳 | |
| 3 | 原型文件 | 订单中心交互原型 PRO-201 | V1.2 | 设计库／订单系统 | 陈磊 | 与REQ-101对应 |
审批与变更规则填写示范
| 字段 | 填写内容 |
|---|---|
| 审批结论 | 通过 |
| 审批意见 | 需求范围清晰，同意冻结；后续新增需求走变更流程 |
| 变更申请方式 | 在变更管理流程中提交变更单，附影响分析说明 |
| 变更审批权限 | 影响单个需求条目由产品负责人批准；影响范围或交付时间由项目经理批准 |
| 变更后版本规则 | 条目级修正升次版本号，范围调整升主版本号 |
| 基线冻结范围说明 | 冻结REQ-101、REQ-102及对应原型；性能优化类需求不纳入本基线 |
示例与字段说明的一致性
示例中的每个字段都能在字段说明表中找到对应口径：基线编号遵循唯一标识规则，资产版本填写的是纳入基线时的具体版本而非“最新版”，变更审批权限按影响范围分级。读者可对照字段说明表逐项核对，确认示例没有引入模板之外的字段。
配套模板：建立检查清单与基线发布记录
基线说明是主文档，建立检查清单用于确认建立前条件是否齐备，发布记录用于留痕发布动作。三份文档共用基线编号、基线名称、基线版本三个关键字段，保证可以互相引用。
基线建立检查清单空白项
| 序号 | 检查项 | 检查结果 | 检查人 | 备注 |
|---|---|---|---|---|
| 1 | 基线编号已按规则分配且未重复 | |||
| 2 | 受控资产清单完整，每项均有版本号和存放位置 | |||
| 3 | 资产版本与系统中当前版本一致 | |||
| 4 | 建立原因与生效时间已填写 | |||
| 5 | 审批人具备对应审批权限 | |||
| 6 | 变更申请方式与审批权限已明确 | |||
| 7 | 附件索引与资产清单对应无误 | |||
| 8 | 基线说明已归档至指定位置 |
基线发布记录空白字段
| 字段 | 填写内容 |
|---|---|
| 基线编号 | |
| 基线名称 | |
| 基线版本 | |
| 发布日期 | |
| 发布人 | |
| 通知范围 | |
| 发布渠道 | |
| 关联基线说明文档位置 | |
| 接收确认情况 | |
| 备注 |
三份文档字段口径一致性
基线编号、基线名称、基线版本在三份文档中使用完全相同的写法，检查清单的检查结果与基线说明的基线状态对应，发布记录的发布日期不早于基线说明的生效时间。字段口径统一后，审计或复盘时可以按基线编号把三份文档串成一条完整记录。
当团队使用研发管理工具承载基线时，受控资产清单和审批状态可以放到系统中维护，文档模板作为归档和对外说明的载体。ONES 围绕需求、基线、版本和变更建立统一管理对象，支撑需求变更影响分析、过程状态追踪和交付结果回溯；ONES Wiki 提供页面模板库，可将基线说明、检查清单和发布记录维护为制式化文档模板，并记录页面版本、按角色配置读写权限。模板字段与系统字段的对应关系需要在团队内约定一次，避免文档与系统两套口径。
调整与维护方法：模板如何随团队演进
模板需要随项目规模和流程成熟度调整，调整的原则是字段增减有依据、版本变更可追溯。以下规则可作为团队维护模板时的参考。
按项目规模裁剪字段
小型项目可采用最小可用字段组合，省略附件索引和关联需求编号；中大型项目保留完整字段，并在受控资产清单中增加关联需求编号列；涉及对外交付或合规审查的项目，建议增加基线冻结范围说明和接收确认字段。裁剪时保持必填字段不变，只调整选填部分。
新增字段的准入判断
新增字段前先回答三个问题：该信息是否已有其他字段承载；缺少它是否会导致基线无法识别、审批或追溯；填写成本是否低于它带来的检索和审计收益。三个问题都指向“需要”时再新增，并在模板变更记录中写明新增原因和生效版本。
模板版本与变更记录维护
模板本身应有版本号，如“基线说明模板V1.2”，并在文末维护变更记录表，记录变更日期、变更内容、变更人和影响范围。模板版本变更后，新建立的基线使用新模板，已生效的基线说明保持原样，避免历史记录被追溯修改。
与需求版本、交付制品的边界划分
基线说明只回答“哪些资产在何时被固定为受控组合”。需求条目本身的版本演进和变更审批归需求变更与版本管理；构建产物、安装包等交付制品的管理归研发交付物与制品管理。基线说明通过关联字段引用这两类信息，不重复记录其详细内容，保持文档职责清晰。
常见问题
基线说明和基线发布记录能否合并成一份文档？
可以合并，但建议保留两个独立区块。基线说明回答“哪些资产在什么时点被固定”，发布记录回答“这份基线何时通知了谁、接收情况如何”。合并时把发布记录作为基线说明的附页，共用基线编号、名称、版本三个字段；分开维护时按基线编号互相引用。团队规模小、发布动作简单时合并更省事；涉及多方接收确认或对外交付时分开维护，便于单独归档和审计。
基线生效后资产又发生了修改，基线说明要不要改？
已生效的基线说明保持原样，不追溯修改。资产修改通过变更流程处理：提交变更单、完成影响分析、按变更审批权限批准后，形成新的基线版本，并新建或更新对应版本的基线说明。原版本作为历史记录保留，便于回溯当时冻结的具体内容。若团队在研发管理工具中维护基线，变更后的状态与版本可在系统中同步更新，文档侧保留归档版本。
受控资产清单里的版本号，填资产当前版本还是纳入基线时的版本？
填写纳入基线那一刻的具体版本号，不写“最新版”或“当前版本”。基线说明的意义在于固定一个可复现的组合，写“最新版”会让后来者无法判断当时冻结的到底是哪一版。填写前建议核对系统中该资产的实际版本，确保清单版本与系统记录一致；检查清单中“资产版本与系统中当前版本一致”一项就是为此设置的核对点。
模板字段和研发管理工具里的字段对不上怎么办？
先在团队内约定一次映射关系，明确哪些文档字段由系统字段自动带出、哪些需要人工补充。常见做法是基线编号、名称、版本、状态、审批人直接对应系统对象字段，受控资产清单从系统资产列表导出后归档，附件索引指向系统内的评审记录或测试报告。映射关系确定后写入模板变更记录，后续调整时同步更新，避免文档与系统两套口径并行。
需求条目本身的版本变化，要不要写进基线说明？
基线说明只记录被纳入基线的需求条目及其固定版本，需求条目后续的版本演进和变更审批归需求变更与版本管理。基线说明通过“关联需求编号”或表头“上游需求来源”字段引用需求，不重复记录需求变更的详细过程。这样划分后，基线说明保持稳定，需求侧的变化在需求管理流程中完整留痕，两边按需求编号可以互相追溯。
