配置项识别出现遗漏时，补识别要先回答两个问题：漏了哪些资产、影响哪些基线。把范围圈清、按影响分级后，再从交付物、文档、代码与构建产物、环境配置等来源交叉比对，形成候选清单并逐项判定受控属性。已进入基线的遗漏需要走变更与追溯流程，补录完成后用全量复核和后续迭代的评审结果验证是否闭环。
要点总览（TL;DR）
- 补识别前先按项目、阶段、资产类型、基线四个维度圈定范围，并按已发布、未发布、未受控三类分级，决定处置优先级。
- 把遗漏原因当作假设逐条验证，优先排查资产分散和变更后未回写清单两类，用清单与实物比对、评审记录、变更单等证据排除。
- 补录分三步：从交付物、文档、代码与构建产物、环境配置收集候选；逐项判定受控属性与关联关系；按影响分级分批补入清单或走变更流程。
- 补录前备份清单与基线记录，涉及已发布基线先冻结再调整，并明确停止点与审批人，防止补识别演变成无边界返工。
- 用全量复核、基线关联完整性抽查和后续一到两个迭代的评审结果验证闭环，并把识别标准、责任人和清单回写纳入变更流程预防复发。
遗漏是怎么暴露的：症状与影响范围
配置项遗漏通常不会以“清单少了一条”的形式直接出现，而是通过几类具体信号暴露。识别这些信号，是判断本次补识别从哪里入手的前提。
常见症状有四类。第一类是评审或审计时发现清单缺项：评审人对照交付物或过程记录，发现某个应受控的文档、代码模块或环境配置在清单中找不到对应条目。第二类是构建或发布时找不到受控项：流水线引用的某个制品、配置文件或依赖版本，在配置项清单中没有登记，导致发布记录无法追溯到受控来源。第三类是变更影响分析漏掉关联资产：一次需求或缺陷变更评估时，发现某个受影响的模块、接口或测试资产未被纳入分析范围。第四类是基线内容与实物不一致：基线声明包含的配置项与实际交付或部署的内容对不上，可能是清单多列、少列或版本不符。
界定范围时，建议按四个维度同时圈定边界，避免补识别无限扩大或遗漏关键区域：
- 项目维度：本次问题涉及哪些项目或产品线，是否跨项目共享资产。
- 阶段维度：遗漏发生在需求、设计、开发、测试、发布中的哪个阶段，补识别是否需要回溯上游阶段。
- 资产类型维度：涉及文档、代码、构建产物、环境配置、工具配置中的哪几类。
- 基线维度：哪些基线受到影响，是已发布基线、待发布基线，还是尚未建立基线的在研内容。
在范围明确后，按影响程度分三类处理，优先级从高到低：
| 情形 | 判断特征 | 处置优先级 |
|---|---|---|
| 已进入基线且已发布 | 遗漏项属于已对外交付或已上线的基线内容 | 最高，需评估对已交付版本的影响，走变更与追溯流程 |
| 已进入基线未发布 | 遗漏项在基线范围内，但尚未交付或上线 | 较高，可在发布前通过基线调整补入，需记录调整原因 |
| 尚未纳入受控 | 遗漏项游离在清单和基线之外，未被任何基线覆盖 | 常规，直接补入清单并判定受控属性 |
完成上述判断后，应产出一份范围与影响分级说明，写清本次补识别覆盖的项目、阶段、资产类型和基线，以及每类遗漏的处置优先级和责任人。这份说明是后续原因排查和补录操作的共同依据。
遗漏原因的假设与排除证据
发现遗漏后直接归因为“大家不认真”或“工具不好用”，往往导致补完这一批、下一批继续漏。更稳妥的做法是把可能原因当作假设，逐条找证据验证，先验证影响面最大的假设。
常见假设及对应的验证证据如下：
| 原因假设 | 验证证据 | 验证方法 |
|---|---|---|
| 识别标准不清 | 清单中同类资产的纳入规则是否一致；不同项目对同一类资产的处理是否存在差异 | 抽取若干同类资产，比对是否被一致纳入；查看识别规则文档是否存在且被引用 |
| 识别时点太晚 | 遗漏项首次产生的时间与首次登记时间的间隔；是否在阶段评审后才补登 | 对照阶段计划与清单登记记录，看登记是否滞后于资产产生 |
| 责任人与评审缺位 | 评审记录中是否覆盖该类资产；是否有明确的配置项识别责任人 | 查阅评审纪要、评审检查单，确认该类资产是否在评审范围内 |
| 资产分散在多处 | 同一类资产是否分布在多个工具、仓库或文档库中；清单是否只覆盖其中一处 | 导出各来源的资产列表，与清单做交叉比对，统计未覆盖来源 |
| 变更后未回写清单 | 变更单中是否包含清单更新动作；变更前后的清单差异记录 | 抽取若干变更单，核对变更内容与清单更新是否同步 |
排除顺序建议按影响面从大到小：先验证“资产分散在多处”和“变更后未回写清单”这两类，因为它们通常一次性解释大量遗漏；再验证“识别标准不清”和“识别时点太晚”，这两类影响的是长期遗漏率；最后验证“责任人与评审缺位”，它更多解释个别批次的漏项。
验证结论要落到证据上。例如，清单与实物比对显示某类环境配置在三个仓库中都有，而清单只登记了其中一个，这就支持“资产分散”假设，处置方向应是统一来源或扩大清单覆盖范围，而不只是把漏掉的条目补上。如果多个假设同时成立，应优先修正识别规则和回写机制，再处理具体条目，否则补录只是暂时止血。
需要提醒的是，原因验证的结论应记录在案，作为后续调整识别标准和评审检查单的输入。仅凭一次比对就下结论，容易把偶发问题当成系统问题，或反过来把系统问题当成偶发失误。
补识别的处置步骤
补识别按“收集候选—逐项判定—分批补录”三步推进，每一步都有明确的产出和完成标志。
第一步：收集候选配置项。从多个来源并行收集，避免只依赖单一清单：
- 交付物清单：合同、验收文档、对外交付的软件包和文档。
- 需求与设计文档：需求规格、设计说明、接口文档、评审记录。
- 代码与构建产物：代码仓库的分支与标签、构建脚本、制品清单、依赖清单。
- 环境与工具配置：部署配置、环境参数、流水线配置、工具链配置。
收集时给每个候选标注来源和发现方式，便于后续判定和追溯。完成标志是形成一份带来源标记的候选配置项列表。
第二步：逐项判定。对每个候选回答四个问题：是否纳入受控、属于哪种配置项类型、责任人是谁、关联哪些基线与变更。判定标准应与现有识别规则保持一致；如果发现规则本身有缺口，先记录规则调整建议，再按现行规则完成本次判定，避免边补边改导致口径混乱。完成标志是每个候选都有明确的纳入或不纳入结论及理由。
第三步：分批补录。按影响分级分批处理：
- 尚未纳入受控的候选：直接补入配置项清单，登记类型、责任人、关联关系。
- 已进入基线未发布的遗漏：在基线调整记录中登记补入原因，更新基线内容，并通知相关评审人确认。
- 已进入基线且已发布的遗漏：走变更与追溯流程，评估对已交付版本的影响，记录变更单，必要时启动回归验证。
补录过程需要守住几条风险边界。补录前备份现有清单和基线记录，确保调整可回退；涉及已发布基线时，先冻结该基线再调整，避免调整过程中产生新的不一致；明确本次补录的停止点和审批人，例如“本批次补录以范围说明中列出的资产为限，超出部分另行立项”，防止补识别演变成无边界的大规模返工。
在清单维护和变更关联环节，如果团队使用 ONES，可借助其围绕需求、基线、版本和变更建立统一管理对象的方式，把补录的配置项与对应需求、变更记录关联起来，支撑变更影响分析和过程追踪；补录涉及的评审节点和交付物模板，也可沉淀为可复用资产，减少后续同类遗漏。具体承载形式以团队实际配置为准。
补识别后的验证与复发预防
补录完成不等于闭环。验证要回答两个问题：清单与实物是否一致，新增配置项是否真正进入了受控流程。
验证检查项建议包括：
- 全量复核：按范围说明中的四个维度，重新比对清单与各来源实物，确认无新增缺项。
- 基线关联完整性：抽查本次补入的配置项，确认其与基线、变更记录的关联关系完整，变更单可追溯。
- 流程纳入确认：确认新增配置项已进入后续的评审检查单、审计范围和发布核对清单，而不是只存在于清单中。
- 责任人确认：每个新增配置项都有明确责任人，且责任人知晓其维护职责。
复发预防要落到机制上，而不是停留在提醒。具体措施包括：明确识别标准和识别时点，把“何时识别、识别哪些”写进阶段准入条件；固定责任人与评审环节，在评审检查单中增加配置项完整性核对项；把清单回写纳入变更流程，变更单关闭前需确认清单已同步更新。对于资产分散的情况，应确定统一来源或建立跨来源的定期比对机制。
效果观察用后续一到两个迭代的评审与发布结果检验：如果评审中仍反复出现同类缺项，说明原因假设的验证结论需要修正，或预防措施未真正执行；如果缺项明显减少且新增配置项都能被正常追溯，说明补识别形成了闭环。观察结果应反馈到识别规则和评审检查单的下一轮调整中。
常见问题
补识别时发现遗漏项已经进入已发布基线，应该先补清单还是先走变更？
应先走变更与追溯流程，再调整清单。已发布基线代表已对外交付或已上线的受控状态，直接改清单会破坏基线记录的可追溯性。建议先冻结该基线，评估遗漏项对已交付版本的影响，记录变更单并通知相关评审人，必要时启动回归验证；变更审批通过后再更新清单和基线记录，确保每一步调整都有据可查。
补识别范围怎么控制，避免变成全量返工？
在启动补识别前先产出一份范围说明，写清本次覆盖的项目、阶段、资产类型和基线，并明确停止点，例如“本批次以范围说明列出的资产为限，超出部分另行立项”。补录过程中按影响分级分批处理，每批完成后由审批人确认再进入下一批。范围说明同时作为原因排查和验证复核的共同依据，防止补识别无限扩大。
原因验证时多个假设同时成立，应该先改规则还是先补条目？
建议先修正识别规则和清单回写机制，再处理具体条目。如果多个假设同时成立，通常说明遗漏是系统性的，只补条目会在下一批次继续漏。可以按影响面排序：先处理资产分散和变更后未回写清单这两类，它们往往一次性解释大量遗漏；再调整识别标准和识别时点；最后补齐责任人与评审环节。规则调整建议记录在案，作为后续评审检查单更新的输入。
补录完成后，怎么判断补识别是否真正闭环？
闭环判断看三个信号：一是全量复核后清单与各来源实物一致，无新增缺项；二是抽查本次补入的配置项，与基线、变更记录的关联关系完整且可追溯；三是新增配置项已进入后续评审检查单、审计范围和发布核对清单，责任人知晓维护职责。再用后续一到两个迭代的评审与发布结果观察，如果同类缺项明显减少且新增项能被正常追溯，说明补识别形成了闭环；如果仍反复出现同类缺项，需要回头修正原因假设或检查预防措施是否执行到位。
团队使用 ONES 时，补录的配置项如何与需求和变更关联？
ONES 围绕需求、基线、版本和变更建立统一管理对象，补录的配置项可以与对应需求、变更记录建立关联，支撑变更影响分析和过程追踪。补录涉及的评审节点和交付物模板也可沉淀为可复用资产，减少后续同类遗漏。具体承载形式（如配置项清单以何种对象或字段维护）以团队实际配置为准，建议在补录前与管理员确认关联字段和评审流程的设置方式。
