配置状态记录模板是一张按配置项逐行登记的表，用来回答“这个受控对象现在是什么版本、处于什么状态、由谁负责、依据哪张变更单”。核心字段包括配置项标识、名称、类型、版本或基线号、所属基线、当前状态、变更单号、责任人和登记日期。下面提供一张可直接复制到文档或表格工具中的空白模板，并逐字段说明填写口径、必填取舍，再用一个完整示例演示状态从受控到基线的演进。
要点总览（TL;DR）
- 配置状态记录模板按配置项逐行登记，核心字段包括配置项标识、名称、版本/基线号、当前状态和责任人，其余字段可按项目需要选填。
- 必填字段的判断标准是能定位配置项、判断受控状态并找到负责人；小团队可先用五列精简版，进入交付或合规阶段再补类型、所属基线、变更单号和存放位置。
- 状态取值建议固定为草稿、受控、变更中、已基线、已归档五个，同一配置项状态变化时追加新行、保留旧行，便于追溯。
- 填写时注意两点：变更中的行先确认变更单关闭、修改内容入库后再追加基线行；所属基线只在配置项真正纳入基线后填写。
- 模板落地后要按项目裁剪字段、给模板自身记版本，并在每次基线建立前核对状态表与基线清单、变更单是否一致。
可复制空白配置状态记录表
将下表复制到表格工具中，第一行作为表头保留，从第二行开始一行登记一个配置项。如果团队使用文档工具，可以把表头转成文档表格的首行，后续每新增一次状态变化就追加一行，不覆盖旧行。
| 配置项标识 | 配置项名称 | 类型 | 版本/基线号 | 所属基线 | 当前状态 | 变更单号 | 责任人 | 登记日期 | 存放位置 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|
使用时有四条基本约定。第一，一行只对应一个配置项的一次状态记录，同一配置项出现多次状态变化时追加新行，保留历史行便于追溯。第二，配置项标识在项目内保持唯一，后续所有变更单、评审记录引用同一标识。第三，当前状态只填一个值，取值从团队约定的状态集合中选择，不写自由描述。第四，登记日期填本次状态生效的日期，与变更单的提交或批准日期区分开。
如果团队已有配置管理计划，模板中的字段应与计划里定义的配置项分类、状态集合、基线命名规则保持一致，避免同一对象在两张表里叫法不同。
字段说明：每个字段记录什么
字段说明的作用是让不同人填同一张表时口径一致。下表逐字段给出记录内容、取值来源和填写要点。
| 字段 | 记录什么 | 取值来源 | 填写要点 |
|---|---|---|---|
| 配置项标识 | 配置项在项目内的唯一编号 | 配置管理计划中的编号规则 | 建议采用“项目代号-类型缩写-序号”，如 PRJ-DOC-012；一经分配不再复用 |
| 配置项名称 | 配置项的可读名称 | 文档标题、代码模块名或制品名 | 与受控库中的实际名称一致，便于检索和核对 |
| 类型 | 配置项的类别 | 团队约定的分类，如文档、代码、模型、测试用例、制品 | 分类粒度按项目需要确定，同一项目内保持一致 |
| 版本/基线号 | 当前受控的版本号，或该配置项纳入的基线号 | 版本库标签、文档版本记录、基线清单 | 未纳入基线时填版本号；纳入基线后填基线号，两者可并列填写 |
| 所属基线 | 该配置项当前归属的基线名称 | 基线清单或基线建立记录 | 未纳入任何基线时留空或填“未纳入”，不填预计基线 |
| 当前状态 | 配置项此刻的受控状态 | 团队约定的状态集合 | 常用取值为草稿、受控、变更中、已基线、已归档，只填一个 |
| 变更单号 | 导致本次状态变化的变更单编号 | 变更管理系统或变更记录台账 | 首次受控可填首次入库单号；无变更时留空 |
| 责任人 | 对该配置项内容和状态负责的人 | 项目分工表 | 填具体人名或角色名，团队内统一一种写法 |
| 登记日期 | 本次记录生效的日期 | 状态变更实际发生日 | 使用统一日期格式，如 2025-03-14 |
| 存放位置 | 配置项的受控存放路径 | 配置库目录结构或文档库路径 | 填到可定位的层级，避免只写“服务器上” |
| 备注 | 需要补充说明的信息 | 填写人判断 | 记录例外情况、待办事项或关联评审单号 |
状态取值建议固定为五个：草稿表示内容尚在编写、未纳入受控；受控表示已入库并纳入配置管理；变更中表示已提交变更单、正在修改；已基线表示随基线冻结、对外作为正式版本；已归档表示不再维护但需保留追溯。状态集合一旦确定，模板、变更单和基线清单应使用同一套词，避免“已冻结”“已发布”等混用造成统计口径不一。
必填与选填的划分
必填字段的判断标准是：缺少它就无法定位配置项、无法判断其受控状态或无法找到负责人。按这个标准，配置项标识、名称、版本/基线号、当前状态和责任人属于必填，其余字段按团队规模和流程规范程度选填。
| 字段 | 划分 | 理由 | 适用条件 |
|---|---|---|---|
| 配置项标识 | 必填 | 唯一识别配置项，是变更单和基线清单的引用依据 | 所有团队 |
| 配置项名称 | 必填 | 让人能读懂标识对应什么对象 | 所有团队 |
| 版本/基线号 | 必填 | 判断当前受控的是哪一版 | 所有团队 |
| 当前状态 | 必填 | 状态是这张表的核心信息 | 所有团队 |
| 责任人 | 必填 | 状态变化时需要有人确认和更新 | 所有团队 |
| 类型 | 选填 | 便于分类统计，配置项较少时可由标识规则体现 | 配置项数量多、需要按类别汇总时建议填写 |
| 所属基线 | 选填 | 基线管理成熟后才有稳定取值 | 项目建立正式基线后填写 |
| 变更单号 | 选填 | 首次受控时可能没有变更单 | 有正式变更流程的团队填写，用于追溯 |
| 登记日期 | 选填 | 便于排序和审计，但不影响识别配置项 | 需要按时间回溯或接受审计时建议填写 |
| 存放位置 | 选填 | 配置库结构简单时可省略 | 配置库目录较深、多人协作时建议填写 |
| 备注 | 选填 | 承载例外说明 | 按需填写 |
小团队可以采用精简版，只保留标识、名称、版本/基线号、状态、责任人五列，登记日期由表格工具的创建时间自动记录。当项目进入需要对外交付或接受合规检查的阶段，再补上类型、所属基线、变更单号和存放位置，形成规范版。两种版本的字段名保持一致，便于后续合并。
填写示例：一个配置项从受控到基线
以下为演示情景：某项目的一份模块设计文档，标识为 PRJ-DOC-012，责任人李工。文档完成评审后纳入受控，随后因接口调整发起一次变更，变更完成后随 V1.0 基线冻结。表中四行记录展示同一配置项的状态演进，旧行保留不删除。
| 配置项标识 | 配置项名称 | 类型 | 版本/基线号 | 所属基线 | 当前状态 | 变更单号 | 责任人 | 登记日期 | 存放位置 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|
| PRJ-DOC-012 | 订单模块设计文档 | 文档 | V0.9 | 未纳入 | 草稿 | 李工 | 2025-03-03 | 配置库/设计文档/订单模块 | 评审前初稿 | |
| PRJ-DOC-012 | 订单模块设计文档 | 文档 | V1.0 | 未纳入 | 受控 | CR-021 | 李工 | 2025-03-10 | 配置库/设计文档/订单模块 | 评审通过，首次入库 |
| PRJ-DOC-012 | 订单模块设计文档 | 文档 | V1.1 | 未纳入 | 变更中 | CR-035 | 李工 | 2025-03-18 | 配置库/设计文档/订单模块 | 接口调整，变更审批通过 |
| PRJ-DOC-012 | 订单模块设计文档 | 文档 | V1.1 / BL-2025Q1 | BL-2025Q1 | 已基线 | CR-035 | 李工 | 2025-03-25 | 配置库/基线/BL-2025Q1/设计文档 | 随一季度基线冻结 |
对照字段说明可以看出填写逻辑：第一行草稿阶段尚无变更单，版本为 V0.9，所属基线填“未纳入”；第二行评审通过后状态改为受控，变更单号填首次入库单 CR-021；第三行发起变更，状态改为变更中，版本升到 V1.1，变更单号换成 CR-035；第四行变更完成并随基线冻结，版本/基线号同时记录版本和基线号，所属基线填 BL-2025Q1，存放位置也移到基线目录下。
示例中有两个容易出错的点。一是变更中的行不要直接改成已基线，应先确认变更单已关闭、修改内容已入库，再追加基线行。二是所属基线只在配置项真正纳入基线后填写，变更审批通过但尚未冻结时仍留空或填“未纳入”，避免基线清单与状态表对不上。
模板的调整与维护方法
模板落地后需要随项目阶段调整，否则字段会越填越多、状态越写越乱。以下清单给出裁剪、版本维护、核对节奏和与基线变更衔接的操作方法。
- 按项目裁剪字段。项目启动时先确定配置项清单和状态集合，再决定启用哪些选填字段。对外交付或合规检查要求追溯变更依据时，启用变更单号和登记日期；配置库目录简单时，存放位置可暂不启用。裁剪结果写入配置管理计划，避免不同人使用不同版本。
- 管理模板自身版本。模板文件也应有版本号和变更说明，例如在表头下方标注“模板版本 V1.2，2025-03 增加所属基线字段”。字段增删、状态取值调整都记一条变更说明，旧项目继续用原版本，新项目启用新版本。
- 设定核对节奏。建议在每个迭代结束或每次基线建立前核对一次：检查是否有配置项缺少责任人、状态停留在变更中超过约定时长、版本号与配置库实际标签不一致。核对结果作为基线评审的输入之一。
- 与基线和变更记录衔接。基线冻结时，把纳入基线的配置项统一更新所属基线和状态，并核对基线清单中的条目与状态表中的已基线行数量一致。变更单关闭时，同步更新对应配置项的版本号和状态，确保变更单、状态表、配置库三处信息一致。
当配置项数量增长到几十条以上、变更频繁时，手工维护表格容易出现漏更新。这类团队可以把配置项作为受控对象登记在管理工具中，让状态字段随变更单流转自动更新。ONES 的方案围绕需求、基线、版本和变更建立统一管理对象，支撑过程状态追踪和交付结果回溯；其合规复用场景也支持把交付物模板和过程数据沉淀为可复用资产。对于需要把配置状态记录与基线、变更单放在同一套流程里维护的团队，可以在工具中建立配置项工作项并关联基线与变更记录，减少表格与变更系统之间的手工同步。
常见问题
配置项很少的小团队，用精简版模板会不会漏掉追溯信息？
精简版保留标识、名称、版本/基线号、状态和责任人五列，已经能回答“这是什么、哪一版、什么状态、谁负责”。如果表格工具会自动记录行创建时间，登记日期也可以先不单独设列。需要留意的是，一旦项目进入对外交付、合规检查或变更频繁的阶段，变更单号和所属基线就会成为追溯的关键依据，这时应及时补上这两列，并给已有记录回填历史信息，避免新旧记录口径不一致。
同一配置项在一天内发生两次状态变化，应该怎么记？
按“一行一次状态记录”的约定追加两行，分别填写两次状态生效的日期和对应的变更单号。登记日期填状态实际生效的日期，与变更单的提交或批准日期区分开。如果两次变化确实发生在同一天，日期相同不影响记录有效性，靠变更单号和备注区分即可。关键是保留旧行、不覆盖，这样后续核对时能看清状态演进顺序。
配置状态记录表和基线清单、变更单之间如何核对？
建议在每次基线建立前做一次三方核对：基线清单中的条目数量应与状态表中“已基线”且所属基线为该基线的行数一致；变更单关闭时，对应配置项的版本号和状态应同步更新；配置库中的实际标签应与版本/基线号字段一致。核对中发现状态停留在变更中超过约定时长、缺少责任人或版本号与库中标签不符的条目，先修正再进入基线评审。
模板字段调整后，旧项目的记录要不要跟着改？
不必强制回改。给模板文件本身记版本号和变更说明，例如标注“模板版本 V1.2，增加所属基线字段”，旧项目继续沿用原版本，新项目启用新版本。如果旧项目后续需要与新版本合并统计，可以在核对时统一补齐关键字段，并在备注中说明补录原因。这样既保持历史记录原貌，也避免不同项目之间字段名混用。
配置项数量增长到几十条以上，还适合用表格维护吗？
表格在配置项较少、变更不频繁时足够用。数量增长到几十条以上、变更频繁后，手工维护容易出现漏更新和版本对不上。这类团队可以把配置项作为受控对象登记在管理工具中，让状态随变更单流转更新。ONES 的方案围绕需求、基线、版本和变更建立统一管理对象，支撑过程状态追踪和交付结果回溯，适合需要把配置状态记录与基线、变更单放在同一套流程里维护的团队。
