配置项清单是一张受控台账，每行记录一个配置项，核心信息可以归为四组：标识（编号、名称、类型、所属产品/项目）、版本与状态（当前版本、基线归属、状态）、责任与位置（责任人、存放位置、关联文档）、变更与审计（变更记录、入库时间、备注）。一张可用的清单至少要能回答“这是什么、现在哪个版本、谁负责、放在哪、改过什么”。下面给出一张可直接复制到表格工具中的空白模板，并逐字段说明填写口径、必填取舍、完整示例与维护方法。
要点总览（TL;DR）
- 配置项清单的核心信息分四组：标识、版本与状态、责任与位置、变更与审计，每行记录一个配置项。
- 小团队起步可用八项最小字段集：编号、名称、类型、所属项目、当前版本、状态、责任人、存放位置。
- 基线名称、关联需求、变更单号等字段在进入多团队协作或对外交付阶段再补充，避免登记负担过重。
- 清单更新应与评审、基线建立、变更审批等流程节点绑定，每季度或每个版本节点核查一次存放位置与状态。
可复制空白配置项清单模板
将下表复制到 Excel、在线表格或文档表格中即可使用。第一行是列名，第二行是填写提示，第三行起为数据行。建议保留提示行作为表头注释，或在正式使用前将其删除，避免与真实记录混淆。
| 配置项编号 | 配置项名称 | 类型 | 所属产品/项目 | 当前版本 | 基线名称 | 状态 | 责任人 | 存放位置 | 关联需求/文档 | 变更单号 | 最近变更时间 | 入库时间 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 提示：按规则唯一编号 | 提示：可识别的正式名称 | 提示：文档/代码/配置/环境等 | 提示：归属项目或产品线 | 提示：如 V1.2 | 提示：所属基线或“未基线” | 提示：草稿/受控/基线化/失效 | 提示：唯一负责人 | 提示：库路径或文档链接 | 提示：需求编号或文档编号 | 提示：触发本次变更的单号 | 提示：YYYY-MM-DD | 提示：首次登记日期 | 提示：补充说明 |
列顺序按“先识别、再定位、后追溯”排列：前四列回答“这是什么”，中间三列回答“现在哪个版本、处于什么受控状态”，随后三列回答“谁负责、放在哪、对应什么需求”，最后四列用于变更追溯。团队如果已有编号习惯，可以调整列顺序，但同一项目内应保持稳定，避免不同人维护出不同结构。
每个字段记录什么：字段说明与取值口径
字段能否填得一致，取决于取值来源是否明确。下表逐列说明含义、示例写法和数据从哪里来，填写时优先从已有系统或文档中取值，减少手工判断。
| 字段 | 含义 | 取值示例 | 填写来源 |
|---|---|---|---|
| 配置项编号 | 配置项的唯一标识，一经分配不再复用 | PRJ-A-DOC-0012 | 按团队编号规则生成，项目代号+类型码+流水号 |
| 配置项名称 | 可被人识别的正式名称，与文档标题或文件名称保持一致 | 订单服务接口设计说明书 | 文档标题、代码仓库名称或制品名称 |
| 类型 | 配置项的类别，决定后续受控方式 | 设计文档、源代码、配置文件、环境参数、测试用例 | 团队预先定义的类别清单 |
| 所属产品/项目 | 配置项归属的产品线或项目 | 订单中心项目 | 项目立项信息 |
| 当前版本 | 当前受控的版本标识 | V1.2 | 文档版本记录、代码标签或制品版本号 |
| 基线名称 | 该配置项所属的基线，未纳入基线时填“未基线” | 订单中心 V1.0 需求基线 | 基线建立记录 |
| 状态 | 配置项当前的受控状态 | 草稿、受控、基线化、失效 | 按团队状态定义更新，随评审和基线动作变化 |
| 责任人 | 对该配置项内容和更新负责的人 | 张明 | 项目角色分配表 |
| 存放位置 | 配置项的实际存放路径或链接 | 文档库/订单中心/设计/接口设计 V1.2 | 文档库路径、代码仓库地址或配置管理库位置 |
| 关联需求/文档 | 该配置项对应的需求、任务或上游文档 | REQ-0231 | 需求管理系统中的需求编号 |
| 变更单号 | 触发最近一次变更的变更申请或评审单 | CR-0087 | 变更管理记录 |
| 最近变更时间 | 最近一次内容或版本变化发生的日期 | 2025-03-14 | 变更单审批完成日期 |
| 入库时间 | 配置项首次登记进入受控库的日期 | 2025-01-08 | 首次登记记录 |
| 备注 | 需要说明的特殊情况 | 依赖外部接口，待联调确认 | 责任人填写 |
编号规则建议在项目启动时一次定好，例如“项目代号-类型码-四位流水号”，类型码用 DOC、SRC、CFG、ENV 等短码区分。名称与存放位置要保持可对应，避免清单里写“接口设计文档”，库里却找不到同名文件。状态取值不宜过多，四到五个即可覆盖大多数研发场景；状态变化应与评审或基线动作绑定，由动作触发更新，减少凭印象修改。
必填与选填：最小可用清单怎么定
清单字段并非越多越好。字段过多会增加登记负担，导致更新滞后；字段过少则无法支撑追溯。建议先确定最小可用字段集，再按项目受控等级逐步扩展。
| 字段 | 建议属性 | 理由与适用场景 |
|---|---|---|
| 配置项编号 | 必填 | 唯一标识是检索、引用和变更追溯的基础 |
| 配置项名称 | 必填 | 人可读的识别入口 |
| 类型 | 必填 | 决定受控方式和评审要求 |
| 所属产品/项目 | 必填 | 多项目并行时用于隔离和统计 |
| 当前版本 | 必填 | 回答“现在用的是哪个版本” |
| 状态 | 必填 | 区分草稿与受控，防止误用未评审内容 |
| 责任人 | 必填 | 明确更新与答疑的对接人 |
| 存放位置 | 必填 | 保证清单能指向实际资产 |
| 基线名称 | 选填 | 纳入基线管理后填写；小团队初期可先留空 |
| 关联需求/文档 | 选填 | 需要做需求追溯或影响分析时填写 |
| 变更单号 | 选填 | 有正式变更流程时填写，支撑审计 |
| 最近变更时间 | 选填 | 与变更单号配套使用 |
| 入库时间 | 选填 | 需要统计配置项存续时间时填写 |
| 备注 | 选填 | 记录例外情况 |
小团队起步可采用八项最小字段集：编号、名称、类型、所属项目、当前版本、状态、责任人、存放位置。这八项已经能回答“这是什么、哪个版本、谁负责、放在哪”。当项目进入需要对外交付、多团队协作或通过质量审核的阶段，再补充基线名称、关联需求和变更单号，使清单具备追溯能力。受控等级较高的项目，可以把变更单号和最近变更时间也设为必填，并要求每次变更同步更新。
填写示例：一条配置项从登记到变更的完整记录
以下为演示情景，展示一条配置项首次登记与一次版本变更后的记录差异。示例数据仅用于说明填写方式，不代表真实项目记录。
| 字段 | 首次登记（V1.0） | 变更后（V1.1） |
|---|---|---|
| 配置项编号 | PRJ-A-DOC-0012 | PRJ-A-DOC-0012 |
| 配置项名称 | 订单服务接口设计说明书 | 订单服务接口设计说明书 |
| 类型 | 设计文档 | 设计文档 |
| 所属产品/项目 | 订单中心项目 | 订单中心项目 |
| 当前版本 | V1.0 | V1.1 |
| 基线名称 | 未基线 | 订单中心 V1.0 需求基线 |
| 状态 | 草稿 | 基线化 |
| 责任人 | 张明 | 张明 |
| 存放位置 | 文档库/订单中心/设计/接口设计 V1.0 | 文档库/订单中心/设计/接口设计 V1.1 |
| 关联需求/文档 | REQ-0231 | REQ-0231、REQ-0245 |
| 变更单号 | — | CR-0087 |
| 最近变更时间 | — | 2025-03-14 |
| 入库时间 | 2025-01-08 | 2025-01-08 |
| 备注 | 初稿待评审 | 新增退款接口说明，已通过评审 |
变更发生时，清单中变化的是版本、基线归属、状态、存放位置、关联需求、变更单号和变更时间，编号、名称、类型、责任人和入库时间保持不变。这种“一行一条配置项、变更只更新字段”的方式，便于对比历史记录。如果团队需要保留每次变更的完整快照，可以在清单之外保留变更记录表，或在版本管理工具中保留历史版本，清单本身只维护当前有效状态。
清单的调整与维护方法
清单建好后，能否持续可用取决于更新责任和更新时点是否明确。建议指定一名配置管理员负责清单结构和整体一致性，各配置项责任人负责自己名下条目的内容更新。下表给出常见动作与对应的更新要求。
| 触发动作 | 更新内容 | 责任人 | 完成标志 |
|---|---|---|---|
| 新增配置项 | 分配编号，填写名称、类型、版本、状态、责任人、存放位置 | 配置项责任人 | 清单出现新行且存放位置可访问 |
| 内容变更 | 更新版本、存放位置、变更单号、变更时间、备注 | 配置项责任人 | 变更单审批完成，清单字段同步 |
| 建立基线 | 填写基线名称，状态改为基线化 | 配置管理员 | 基线记录与清单条目对应一致 |
| 配置项失效 | 状态改为失效，备注写明替代项或失效原因 | 配置管理员 | 清单中不再作为有效资产引用 |
| 定期核查 | 核对存放位置有效性、责任人在岗情况、状态准确性 | 配置管理员 | 核查记录留存，异常条目完成修正 |
更新时点应与研发流程节点绑定：配置项首次提交评审时登记，评审通过后状态改为受控，纳入基线时填写基线名称，变更审批完成后更新版本和变更信息。这样清单反映的是流程结果，而非事后补录。建议每季度或每个版本节点做一次核查，重点检查三类问题：存放位置打不开、责任人已转岗、状态长期停留在草稿。失效配置项保留记录并标注失效，便于追溯历史交付内容。
当配置项数量增多、跨项目协作频繁时，手工表格容易出现更新不同步。ONES 当前方案覆盖需求、基线、版本、变更、测试与发布，围绕需求、基线、版本和变更建立统一管理对象，可支撑需求变更影响分析和交付结果回溯；标准流程、评审节点和交付物模板也可以沉淀为可复用资产。对于清单中的文档类配置项，ONES Wiki 支持文档关联项目任务，页面组可关联项目，需求与文档互相对应，文档实时同步并记录页面版本，支持查看与回滚。团队可以把清单登记、基线建立和变更评审放在同一套协作流程中，减少表格与实际情况脱节。是否引入工具承载，取决于项目规模、协作人数和受控要求；小团队用共享表格配合固定更新节奏同样可以运行。
常见问题
配置项清单和需求列表有什么区别，能不能共用一张表？
两者记录对象不同。配置项清单记录的是受控的研发资产，包括设计文档、源代码、配置文件、环境参数、测试用例等，关注版本、状态、存放位置和变更追溯；需求列表记录的是需求条目及其优先级、验收状态。需求本身可以作为配置项登记进清单，但清单还需要覆盖需求之外的资产。共用一张表容易让字段含义混杂，建议分开维护，通过关联需求字段建立对应关系。
配置项数量很少的项目，还需要单独建清单吗？
需要，但可以简化。即使只有十几个配置项，清单也能回答“当前版本是哪个、文件放在哪、谁负责更新”这类问题，避免交付时找错版本。项目初期用共享表格维护八项最小字段集即可，等配置项数量增加或需要对外交付时，再补充基线和变更追溯字段。清单的价值在于持续更新，字段多少是次要的。
配置项状态应该设几个取值，怎么避免长期停留在草稿？
四到五个状态通常够用，例如草稿、受控、基线化、失效。状态变化应由流程动作触发：评审通过后从草稿改为受控，纳入基线后改为基线化，被替代后改为失效。为避免长期停留草稿，可在定期核查时把超过约定时间仍未评审的条目列出来，由责任人确认是继续推进还是关闭。状态定义过多会增加判断成本，反而不利于执行。
变更后清单只更新当前行，历史版本怎么追溯？
清单维护当前有效状态，历史追溯交给版本记录。常见做法有两种：一是在文档库或代码仓库中保留每次变更的版本，清单的存放位置指向最新版本；二是在清单之外保留一张变更记录表，记录每次变更的单号、时间、变更内容和操作人。两种方式可以并用。关键是变更单号与清单条目能对应上，审计时能从清单找到变更依据。
清单由谁维护，配置管理员和配置项责任人怎么分工？
配置管理员负责清单结构、编号规则和整体一致性，组织定期核查；配置项责任人负责自己名下条目的内容更新，在新增、变更、失效时及时修改字段。分工明确后，更新时点可以绑定到流程节点：提交评审时登记，评审通过后改状态，变更审批完成后更新版本和变更信息。人数较少的团队可以由一人兼任两个角色，但仍要区分“结构维护”和“内容维护”两类动作。
