研发基线清单把一次基线所包含的受控资产逐项登记下来，让评审、发布和后续变更都能找到同一份依据。本文交付一张可直接复制到表格工具的空白模板，并说明每个字段的填写口径、必填与选填的划分、一份完整的版本发布基线示例，以及模板拿到后如何裁剪和长期维护。
要点总览（TL;DR）
- 模板由基线基本信息区、条目明细表和签署确认区三部分组成，复制到表格工具即可使用。
- 必填项按“可定位、可追溯、可追责”划分：基本信息区与签署区全部必填，条目明细表除备注外均必填。
- 需求、设计、代码、发布四类基线在条目明细表上各有需要加强的字段，发布基线覆盖全部必填项。
- 填写示例演示了订单服务 2.4 版本发布基线，清单可在评审过程中从待评审逐步收敛为已纳入。
- 模板裁剪需守住三条底线，基线变更后清单要升版留痕，并与发布节奏对齐定期复核。
可复制空白研发基线清单模板
模板分为三个区域：基线基本信息区、条目明细表和签署确认区。使用时把三张表复制到同一个工作表或同一个文档中，基本信息区填一次，条目明细表按资产逐行填写，签署区在评审通过后填写。
基线基本信息区
| 字段 | 填写内容 |
|---|---|
| 基线名称 | |
| 基线类型 | |
| 基线编号 | |
| 建立日期 | |
| 基线负责人 | |
| 配置管理员 | |
| 适用项目或产品 |
基线条目明细表
| 序号 | 资产名称 | 资产类型 | 唯一标识 | 版本或修订号 | 存放位置 | 责任人 | 纳入依据 | 状态 | 备注 |
|---|---|---|---|---|---|---|---|---|---|
| 1 | |||||||||
| 2 | |||||||||
| 3 | |||||||||
| 4 | |||||||||
| 5 |
签署确认区
| 角色 | 姓名 | 签署日期 |
|---|---|---|
| 编制人 | ||
| 评审人 | ||
| 批准人 | ||
| 批准日期 |
每个字段记录什么：字段说明
字段说明的目的是让不同项目、不同配置管理员填出的清单可以互相比对。下面按模板顺序逐项解释，重点放在容易填得含糊的唯一标识、版本或修订号和纳入依据三项。
基线基本信息字段
| 字段 | 含义与填写口径 |
|---|---|
| 基线名称 | 用一句话说明这次基线覆盖的范围，例如“订单服务 2.4 版本发布基线”，名称中体现对象和版本，避免只写“发布基线”。 |
| 基线类型 | 标明基线属于需求基线、设计基线、代码基线还是发布基线，决定后续必填项的取舍。 |
| 基线编号 | 团队内唯一的编号，建议包含项目代号、基线类型缩写和顺序号，便于在变更单和评审记录中引用。 |
| 建立日期 | 基线正式冻结的日期，与签署区的批准日期区分开：建立日期是清单生效日，批准日期是审批动作完成日。 |
| 基线负责人 | 对基线内容完整性负责的人，通常是产品负责人或技术负责人，负责确认纳入范围。 |
| 配置管理员 | 负责登记条目、核对版本号和保管清单的人，是清单日常维护的执行角色。 |
| 适用项目或产品 | 写明基线服务的项目、产品或客户交付批次，跨项目共用资产时注明主要归属。 |
条目明细表字段
| 字段 | 含义与填写口径 |
|---|---|
| 序号 | 清单内顺序号，仅用于定位行，不作为资产标识。 |
| 资产名称 | 资产的正式名称，与文档标题、代码仓库名或需求条目名称保持一致。 |
| 资产类型 | 需求文档、设计文档、接口定义、源代码、配置文件、测试用例、脚本等，按团队既有分类填写。 |
| 唯一标识 | 资产在管理工具或仓库中的稳定标识，如需求编号、文档编号、仓库路径加分支名。同一资产在不同清单中应使用同一标识。 |
| 版本或修订号 | 被纳入基线的那个具体版本，如文档修订号、代码提交号或标签名。填写时锁定到具体版本，避免只写“最新版”。 |
| 存放位置 | 资产所在的位置，如文档库目录、代码仓库地址、共享盘路径，保证他人能按此找到。 |
| 责任人 | 对该资产内容和后续变更负责的人，变更时由此人确认影响。 |
| 纳入依据 | 说明该资产为什么进入这次基线，如“发布范围清单第 3 项”“接口评审结论”“客户合同附件”，让纳入动作可追溯。 |
| 状态 | 建议取值：待评审、已纳入、已变更、已作废。新建条目先填待评审，评审通过后改为已纳入。 |
| 备注 | 记录例外情况，如资产存在已知缺陷、版本待补测、与其他条目的依赖关系。 |
必填与选填怎么划分
划分标准可以归纳为三条：能定位到资产、能追溯到具体版本、能找到责任人。满足这三条的字段设为必填，其余按项目需要选填。缺了必填项，清单就无法作为受控依据，评审时也难以判断基线是否完整。
必填与选填对照
| 区域 | 必填字段 | 选填字段 | 划分理由 |
|---|---|---|---|
| 基本信息区 | 基线名称、基线类型、基线编号、建立日期、基线负责人、配置管理员、适用项目或产品 | 无 | 基本信息区字段数量少，全部填写才能保证清单可被引用和追责。 |
| 条目明细表 | 序号、资产名称、资产类型、唯一标识、版本或修订号、存放位置、责任人、纳入依据、状态 | 备注 | 前九项分别解决定位、追溯和追责；备注用于记录例外，不影响清单成立。 |
| 签署区 | 编制人、评审人、批准人、批准日期 | 无 | 签署是基线生效的标志，缺少任一角色，清单只能算草稿。 |
不同基线类型的必填差异
基线类型影响条目明细表中部分字段的填写要求，基本信息区和签署区的要求保持一致。
| 基线类型 | 需要加强的字段 | 说明 |
|---|---|---|
| 需求基线 | 唯一标识、纳入依据 | 需求条目通常已有编号，纳入依据应指向需求评审结论或版本范围说明，便于后续变更时比对。 |
| 设计基线 | 版本或修订号、存放位置 | 设计文档修订频繁，必须锁定评审通过的修订号，存放位置指向文档库中的定稿目录。 |
| 代码基线 | 唯一标识、版本或修订号 | 以仓库路径加分支或标签作为唯一标识，版本号填提交号或标签名，确保能还原出当时的代码状态。 |
| 发布基线 | 全部必填项，备注建议填写 | 发布基线通常组合需求、设计、代码和配置，条目多、依赖多，备注用于记录已知问题和上线注意事项。 |
填写示例：一次版本发布基线
以下示例为演示情景：某订单服务准备发布 2.4 版本，发布前建立一次发布基线，把该版本涉及的需求、设计、代码和配置登记在同一张清单中。
基本信息区填写结果
| 字段 | 填写内容 |
|---|---|
| 基线名称 | 订单服务 2.4 版本发布基线 |
| 基线类型 | 发布基线 |
| 基线编号 | ORD-REL-2.4-BL01 |
| 建立日期 | 2025-03-10 |
| 基线负责人 | 张明（产品负责人） |
| 配置管理员 | 李倩 |
| 适用项目或产品 | 订单服务，2.4 版本客户交付批次 |
条目明细表填写结果
| 序号 | 资产名称 | 资产类型 | 唯一标识 | 版本或修订号 | 存放位置 | 责任人 | 纳入依据 | 状态 | 备注 |
|---|---|---|---|---|---|---|---|---|---|
| 1 | 订单服务需求说明书 | 需求文档 | REQ-ORD-021 | V1.3 | 文档库/订单服务/需求 | 王芳 | 2.4 版本范围评审结论 | 已纳入 | |
| 2 | 订单查询接口设计 | 设计文档 | DES-ORD-018 | V2.0 | 文档库/订单服务/设计 | 陈磊 | 接口评审记录 2025-02-28 | 已纳入 | 含分页参数调整说明 |
| 3 | 订单服务代码仓库 | 源代码 | repo/order-service，分支 release/2.4 | 标签 v2.4.0 | 代码仓库/order-service | 陈磊 | 发布范围清单第 1 项 | 已纳入 | |
| 4 | 订单服务生产配置 | 配置文件 | CFG-ORD-PROD | R7 | 配置库/order-service/prod | 李倩 | 发布检查单配置项 | 已纳入 | 数据库连接数已按容量评估调整 |
| 5 | 订单查询回归用例集 | 测试用例 | TC-ORD-105 | V1.1 | 测试管理/订单服务/回归 | 赵宇 | 测试计划 2.4 回归范围 | 待评审 | 补充用例待测试负责人确认 |
签署区填写结果
| 角色 | 姓名 | 签署日期 |
|---|---|---|
| 编制人 | 李倩 | 2025-03-10 |
| 评审人 | 张明 | 2025-03-11 |
| 批准人 | 刘涛（研发经理） | 2025-03-11 |
| 批准日期 | 2025-03-11 |
示例中第 5 行仍为待评审，说明清单可以在评审过程中逐步收敛：先登记全部候选资产，评审通过后逐行改为已纳入，全部条目确认后再完成签署。这种填写顺序比等所有资产定稿后一次性填表更容易发现遗漏。
模板的调整与维护方法
模板需要按团队规模和合规要求裁剪，但裁剪应保持“可定位、可追溯、可追责”三条底线。基线发生变更后，清单本身也要版本化，否则清单会与实际受控资产脱节。
按项目情况裁剪字段
- 小型项目或内部工具：条目明细表可保留全部必填项，备注按需填写；签署区可由编制人和批准人两人完成，评审人由批准人兼任时在备注中说明。
- 有外部合规或客户审计要求的项目：在基本信息区增加合同编号或审计批次字段，在条目明细表增加“密级”或“交付物类别”，并在备注中记录审计关注点。
- 资产数量多、跨团队协作的项目：增加“所属团队”字段，便于按团队汇总核对；唯一标识建议统一采用管理工具中的编号，减少手工命名差异。
- 裁剪原则：删除字段前确认该字段不承担定位、追溯或追责功能；新增字段时同步更新字段说明，避免同一模板在不同项目中出现两种口径。
基线变更时的更新与留痕
- 变更提出：由资产责任人提交变更说明，写明涉及的条目序号、原版本号和新版本号。
- 影响核对：配置管理员按清单逐项核对受影响的条目，把状态改为已变更，并在备注中记录变更单编号。
- 清单升版：变更确认后生成新版本清单，保留原版本，版本号按 V1.0、V1.1 递增，旧版本标记为已作废。
- 重新签署：涉及基线范围变化的变更，需要重新完成评审和批准；仅修正笔误的变更可由配置管理员记录后更新。
存放、权限与复核
清单存放在团队统一的文档库或研发管理工具中，与它所登记的资产处于同一项目空间，避免清单和资产分散在两处。访问权限按角色设置：项目成员可查看，配置管理员可编辑，基线负责人和批准人拥有审批权限。复核节奏建议与发布节奏对齐，每个版本发布前复核一次；长期不发布的项目至少每季度复核一次，重点检查条目状态是否仍为已纳入、版本号是否与实际资产一致。
当清单条目增多、变更频繁时，可以把登记、状态流转和评审签署放到研发管理工具中承载。以 ONES 为例，基线条目可以作为工作项登记唯一标识、版本号和责任人，状态在待评审、已纳入、已变更之间流转并保留操作记录，评审和批准通过工作流完成，清单版本与资产版本在同一项目空间内对应，减少手工表格与实际情况脱节的情况。工具承载的是登记和留痕动作，字段口径和必填规则仍按本文模板执行。
常见问题
基线清单里的“建立日期”和签署区的“批准日期”有什么区别，能不能填同一天？
两者记录的动作不同。建立日期是基线正式冻结、清单开始生效的日期；批准日期是评审和批准动作完成的日期。实际工作中两者常常是同一天，尤其在小团队里，但建议分别填写：如果评审跨天，建立日期在前、批准日期在后，能清楚看出清单在审批期间的状态。示例中建立日期为 2025-03-10，批准日期为 2025-03-11，就是这种情形。
条目还没评审完，清单可以先发出去用吗？
可以，但要明确标注状态。建议先把候选资产全部登记，状态填“待评审”，评审通过后逐行改为“已纳入”。在签署区完成之前，这份清单只能作为草稿使用，不能作为发布或变更的受控依据。示例中第 5 行测试用例集仍为待评审，其余条目已纳入，说明清单允许在评审过程中逐步收敛。
小团队人手少，评审人和批准人由同一人兼任，清单还成立吗？
可以成立，但要在清单中留下说明。签署区仍分别填写评审人和批准人，若为同一人，在备注或签署说明中注明兼任情况，避免后续审计时被误认为缺少评审环节。更稳妥的做法是至少保留一名独立评审人，由其对条目完整性和版本号准确性做核对。
基线变更后，原清单是直接改还是另存新版本？
另存新版本。变更确认后生成新版本清单，版本号按 V1.0、V1.1 递增，原版本保留并标记为已作废，同时在备注中记录变更单编号。涉及基线范围变化的变更需要重新完成评审和批准；仅修正笔误的变更可由配置管理员记录后更新。这样在追溯某次发布用了哪些资产时，能找回当时生效的那一版清单。
清单放在共享盘还是放进研发管理工具，怎么选？
看条目数量和变更频率。条目少、变更不频繁的项目，共享盘或文档库中的表格足够用，关键是设置好编辑权限和复核节奏。条目多、状态流转频繁、需要保留操作记录的项目，把登记、状态流转和评审签署放到研发管理工具中更省事，清单版本与资产版本在同一项目空间内对应，减少手工表格与实际脱节。无论放在哪里，字段口径和必填规则都按本文模板执行。
