配置状态记录用来回答三个问题：项目里有哪些受控配置项、每个配置项当前处于什么状态、每条基线包含哪些版本。本文给出一份已填写的记录表（演示情景，非真实项目数据），并逐项解释字段取值规则，帮助读者把它改造成适合自己团队的记录表。
要点总览（TL;DR）
- 配置状态记录围绕三类信息展开：配置项清单、当前状态、基线归属，示例覆盖需求文档、设计文档、代码版本、构建产物四类资产。
- 示例表头固定为编号、名称、类型、当前版本、状态、所属基线、变更单号、责任人、更新时间，状态取值约定为新建、修改中、已审核、已入基线、已废弃。
- 版本递增与状态流转同步发生：变更单触发修改即升版本，审核通过转已审核，纳入基线转已入基线，历史版本通过变更单号追溯。
- 改造成自己团队的表时，按配置项类型裁剪字段，把状态变化绑定评审节点，基线快照在评审通过时生成并保存，责任人更新、配置管理员定期核对。
- 示例为演示情景，小团队可精简字段，配置项多或合规要求高的项目需增加审核记录与完整状态历史，交付制品管理需另行约定规则。
示例要解决什么问题：记录哪些配置状态
配置状态记录的核心任务，是让项目成员和评审人员能够随时查到受控资产的当前状态与历史轨迹。它需要回答三个问题：有哪些配置项、各处于什么状态、基线包含哪些版本。这三个问题对应记录表的三类信息：配置项清单、状态字段、基线归属字段。
本示例覆盖的受控对象是研发过程中的常见资产：需求文档、设计文档、代码版本、构建产物。每类资产的记录粒度不同，需求文档和设计文档以文档版本为单位，代码以分支或标签版本为单位，构建产物以构建号为单位。示例只记录这些资产在受控组合中的状态，不展开需求变更的审批流程，也不涉及交付制品的发布与分发管理。
记录范围需要提前约定，否则表格会不断膨胀。一个实用的做法是：只把需要评审、需要追溯、需要随基线交付的资产纳入记录，临时脚本、个人草稿、实验性分支不进入记录表。这样记录表保持可维护，状态统计才有意义。
完整示例：一份配置状态记录表
下表是一份已填写的配置状态记录（演示情景）。表头字段固定，数据行覆盖新建、修改中、已审核、已入基线、已废弃等状态，便于对照填写。
| 配置项编号 | 名称 | 类型 | 当前版本 | 状态 | 所属基线 | 变更单号 | 责任人 | 更新时间 |
|---|---|---|---|---|---|---|---|---|
| REQ-001 | 用户登录需求说明 | 需求文档 | V1.2 | 已入基线 | BL-2024-03 | CR-011 | 张岚 | 2024-03-12 |
| REQ-002 | 订单查询需求说明 | 需求文档 | V0.3 | 修改中 | — | CR-014 | 张岚 | 2024-03-15 |
| DES-001 | 登录模块设计说明 | 设计文档 | V1.0 | 已审核 | — | CR-012 | 陈默 | 2024-03-13 |
| DES-002 | 订单模块设计说明 | 设计文档 | V0.1 | 新建 | — | — | 陈默 | 2024-03-15 |
| CODE-001 | 登录服务代码 | 代码版本 | release-1.4 | 已入基线 | BL-2024-03 | CR-011 | 王启 | 2024-03-12 |
| CODE-002 | 订单服务代码 | 代码版本 | feature-order-2 | 修改中 | — | CR-014 | 王启 | 2024-03-15 |
| BUILD-001 | 登录服务构建包 | 构建产物 | build-20240312-07 | 已入基线 | BL-2024-03 | CR-011 | 王启 | 2024-03-12 |
| BUILD-002 | 订单服务构建包 | 构建产物 | build-20240310-03 | 已废弃 | — | CR-009 | 王启 | 2024-03-10 |
与记录表配套的基线快照如下，用于核对基线内各配置项的版本组合：
| 基线编号 | 基线名称 | 包含配置项及版本 | 建立时间 | 审核人 |
|---|---|---|---|---|
| BL-2024-03 | 登录功能首个受控版本 | REQ-001 V1.2；CODE-001 release-1.4；BUILD-001 build-20240312-07 | 2024-03-12 | 李衡 |
状态统计按类型汇总，便于快速判断项目进展：需求文档共 2 项，其中已入基线 1 项、修改中 1 项；设计文档共 2 项，其中已审核 1 项、新建 1 项；代码版本共 2 项，其中已入基线 1 项、修改中 1 项；构建产物共 2 项，其中已入基线 1 项、已废弃 1 项。统计口径与记录表状态字段保持一致，避免出现表内状态与统计结果对不上的情况。
逐项解释：每个字段为什么这样填
版本号与状态的关系是填写时最容易出错的地方。约定规则是：配置项进入受控状态时分配初始版本，之后每次因变更单引起的修改都递增版本，状态随之变化。以 REQ-001 为例，初始版本 V1.0 对应新建状态，经 CR-011 修改后升为 V1.2，审核通过后状态变为已审核，纳入基线后状态变为已入基线。版本递增与状态流转同步发生，记录表只保留当前版本，历史版本通过变更单号追溯。
所属基线与变更单号的对应关系需要成对填写。已入基线的配置项必须填写基线编号，且该基线快照中要能找到对应版本；处于修改中或新建状态的配置项，所属基线留空，变更单号填写触发本次修改的单据。这样从记录表可以反查：某条基线包含哪些版本，某个变更单影响了哪些配置项。
责任人与更新时间记录的是最近一次状态变化的责任人和时间，不记录创建人。这样做的目的是让读者知道当前状态由谁维护、何时更新，便于交接和核查。更新时间精确到日即可满足多数研发项目，合规要求较高的项目可精确到时分。
状态取值集合需要团队提前约定并固定下来，示例采用新建、修改中、已审核、已入基线、已废弃五个取值。取值集合一旦确定，记录表只允许使用这些值，避免出现“进行中”“处理中”“待审核”等含义重叠的写法，否则状态统计无法汇总。
可迁移规律：把示例改成自己的记录表
把示例改造成自己的记录表，可以从字段裁剪、状态流转、基线快照、维护分工四个方面入手。
- 按配置项类型裁剪字段。文档类配置项可增加“文档链接”字段，代码类可增加“分支或标签”字段，构建产物可增加“构建来源”字段。公共字段保留编号、名称、类型、版本、状态、基线、变更单号、责任人、更新时间。
- 状态流转与评审节点对应。每个状态变化都应绑定一个评审或审核动作，例如“修改中”到“已审核”对应设计评审通过，“已审核”到“已入基线”对应基线评审通过。状态字段因此成为评审结果的记录，而不只是进度标记。
- 基线快照在基线评审通过时生成并保存。快照内容为基线编号、包含的配置项及版本、建立时间、审核人，保存后不再修改，后续变更通过新基线体现。
- 维护频率与责任人分工。配置项责任人负责在自己负责的资产状态变化时更新记录，配置管理员负责每周核对状态统计与基线快照的一致性，发现版本与状态不匹配时退回责任人修正。
当记录表需要多人协作维护时，表格本身容易产生版本冲突和更新遗漏。此时可以把配置项作为工作项管理，状态字段对应工作项状态，文档版本与代码版本挂在对应工作项下，基线快照通过评审记录固化。ONES 支持在工作项中维护状态与版本信息，并通过评审和基线记录保留快照，适合把上述记录规则落到日常协作中；具体字段配置需按团队约定设置。
适用边界：示例不能直接照搬的情况
本文示例为演示情景，不代表任何真实项目或客户，表中的编号、名称、日期均为示意数据。直接照搬前需要确认几个假设条件是否成立。
团队规模和工具链不同，记录方式需要调整。小团队可以只保留编号、名称、版本、状态、基线五个字段，用共享表格维护；配置项数量多、变更频繁的团队需要借助工具自动记录状态变化，减少手工更新遗漏。合规要求较高的项目，例如需要审计追踪的行业，应增加审核记录、变更原因、生效时间等字段，并保留每次状态变化的完整历史，而非只记录当前状态。
本文的记录范围限定在研发资产的受控组合，需求版本变更的完整流程设计和交付制品的发布与分发管理不在本文范围内。如果团队需要把交付制品也纳入配置状态记录，需要另行约定制品编号规则和发布状态取值，不能直接套用本文的状态集合。
常见问题
配置项处于“修改中”时，所属基线字段应该留空还是填原基线？
建议留空，并在变更单号中填写触发本次修改的单据。原因是记录表只保留当前版本，而原基线快照中保存的是修改前的版本；如果此时仍填原基线，读者会误以为当前版本已在该基线内。修改完成并纳入新基线后，再填写新基线编号，基线快照同步记录新版本组合。
同一配置项在一个月内多次变更，记录表需要保留每次的状态变化吗？
记录表本身只保留当前状态和当前版本，历史轨迹通过变更单号追溯。如果项目有审计或追溯要求，需要额外维护状态变更历史，记录每次变化的版本、状态、变更单号、责任人和时间。是否保留完整历史取决于合规要求，普通研发项目依靠变更单即可满足回溯需要。
基线建立后发现问题需要修改，应该怎么记录？
已入基线的配置项需要修改时，先提交变更单，状态从已入基线转为修改中，版本递增，所属基线暂时留空。修改完成并通过评审后，纳入新基线，新基线快照记录更新后的版本组合。原基线快照保持不动，这样两条基线分别对应修改前后的受控状态，便于对比和追溯。
用共享表格维护记录表，多人同时编辑时如何避免状态统计出错？
可以约定单一更新入口：配置项责任人只更新自己负责的行，配置管理员负责汇总统计，其他人只读。统计结果按固定周期生成并附上生成时间，避免读者把过期统计当成当前状态。当配置项数量和变更频率上升到手工维护容易遗漏时，可考虑把配置项作为工作项管理，让状态变化随工作项流转自动留痕。
构建产物作为配置项记录时，版本号用什么形式？
示例使用构建号形式，例如 build-20240312-07，包含构建日期和当日序号，便于识别生成时点并保证唯一。团队也可以采用“版本号+构建序号”的组合。关键是同一构建产物在记录表和基线快照中使用完全相同的标识，避免出现同一产物两种写法导致核对困难。
