研发平台配置清单和实际配置对不上，通常集中在三类情况：清单里有、平台里已经找不到的过期记录；平台里有、清单没登记的遗漏项；以及同一配置存在多条相似记录的重复项。核对时先以平台当前生效配置为事实来源，划定模块和时间窗口，再按“对象类型+对象标识+关键属性”逐条比对，结合操作日志和变更记录判断成因，最后回写清单并建立变更即登记的节奏。
要点总览（TL;DR）
- 核对口径以平台当前生效配置为事实来源，清单作为待核对象，按“对象类型+对象标识+关键属性”做三向比对。
- 差异分为三类：清单有而平台无记为过期，平台有而清单无记为遗漏，同一对象多条记录记为重复。
- 原因判断需要操作日志、变更单、创建人与创建时间等证据支撑，未取得证据前只列为待验证假设。
- 处置时先导出快照或备份，删除、合并、停用配置前明确停止点与审批人，核对期间冻结相关变更。
- 核对完成后重新比对并抽样复核高风险模块，把清单更新纳入配置变更流程，指定登记责任人与核对周期。
先确认不一致的具体表现和核对范围
“清单和实际配置不一致”是一句笼统描述，直接开始全量比对容易陷入无边界劳动。第一步是把问题拆成可观察的症状，再据此确定本次核对覆盖哪些模块、哪些对象类型、从哪个时间点开始查。
常见症状可以归为三种。第一种是清单条目在平台中找不到对应对象，可能是配置已下线、改名，也可能是当初登记时写错了名称或所属模块。第二种是平台中存在清单未记录的对象，例如有人新建了工作项类型、字段或自动化规则，但没有同步到清单。第三种是同一配置出现多条相似记录，名称接近、属性接近，难以判断哪一条是当前生效版本。把症状先归类，后续比对才有明确的查找方向。
核对范围建议按模块划定边界。研发平台中常见的配置对象包括项目模板、工作项类型、字段、状态流、权限角色、自动化规则和集成配置。不同模块的变更频率和影响面不同，可以优先核对权限角色、状态流和集成配置这类高风险对象，再处理字段、模板等数量较多的模块。范围说明中应写清本次覆盖的模块清单和对象类型，未纳入的模块单独列出，避免核对结束后被误认为已全部核实。
时间窗口以最近一次清单更新时间为起点，锁定这期间发生的配置变更批次。如果清单长期未更新，可以按季度或按重大版本发布节点切分批次，逐批核对。时间窗口的作用是缩小追溯范围，让操作日志和变更单的查询有明确起止点。
同时要明确本次不处理的事项。配置规则本身的业务定义是否合理、旧配置向新平台的搬迁，属于另外的工作，不纳入本次差异核对。把不纳入项写进范围说明，可以避免核对过程中不断扩展议题。
交付物是一份核对范围说明，包含模块清单、对象类型、时间窗口和不纳入项。这份说明既是本次核对的依据，也是后续复核时判断“是否查全”的基准。
差异的常见成因与对应证据
定位差异时，先列出可能的原因假设，再为每个假设找到可验证的证据。没有取得日志、导出记录或变更单之前，假设只作为待验证项，不能直接写成结论。
| 差异类型 | 可能原因假设 | 验证证据 | 排查顺序 |
|---|---|---|---|
| 遗漏（平台有、清单无） | 变更后未登记；由他人代改未通知清单负责人；批量导入绕过清单流程 | 平台操作日志中的创建与修改记录；变更单或需求单；创建人、创建时间 | 先确认对象创建时间是否落在时间窗口内，再查操作人和关联变更单 |
| 过期（清单有、平台无） | 配置已下线或停用但清单未同步；对象改名后清单仍用旧名称；配置被合并到其他对象 | 对象当前状态与停用记录；改名历史；合并操作的日志 | 先按对象标识确认是否真的不存在，再查停用或改名记录 |
| 重复（同一对象多条记录） | 多次创建同类对象；复制模板时残留副本；迁移或导入产生重复条目 | 对象标识、创建时间、创建人；导入批次记录；模板复制来源 | 先比对对象标识和关键属性，再查创建时间先后与创建人 |
排查顺序上，先按对象标识做匹配，确认两侧是否存在同一对象；标识匹配不上的，再核对名称、编码、所属模块等关键属性；属性接近但仍无法判断的，最后追溯变更记录。这个顺序可以把“找不到”与“对不上”分开处理，减少无效查询。
需要特别区分假设与证据。例如看到清单里有一条平台找不到的记录，可以假设是配置已下线，但在查到停用记录或变更单之前，这条只能标记为“疑似过期”，不能直接删除。同样，平台里出现两条名称相同的自动化规则，可以假设是重复创建，但需要看创建时间和创建人，确认哪一条是后来补建的、哪一条是原配置。
证据的取得方式因平台而异。操作日志、变更单、导入记录、对象详情页中的创建人和修改时间，都是常用来源。如果平台对某类配置没有保留变更日志，可以用变更单、审批记录或团队沟通记录作为补充证据，并在差异表中注明证据来源和可信程度。
按步骤完成比对与差异定位
比对阶段的目标是把两侧数据放到同一口径下，分类出过期、遗漏、重复三类差异，并逐条给出处置结论。以下步骤可以按顺序执行。
第一步，导出两侧数据并统一字段。从平台导出当前生效配置，从清单导出登记记录。导出后统一字段命名，至少保留对象类型、对象标识（名称或编码）、所属模块、关键属性、状态、创建人、创建时间、最后修改时间。字段不统一时，先做一次映射表，避免后续比对因列名不同而漏配。
第二步，建立匹配键并做精确匹配。以“对象类型+对象标识+所属模块”作为匹配键，先做精确匹配，得到两侧都存在的对象集合。对匹配上的对象，再逐项比对关键属性，例如状态流中的状态节点、权限角色中的成员范围、自动化规则的触发条件。属性不一致的记录单独列出，作为“同名但内容不同”的待核实项。
第三步，分类差异。精确匹配后剩下的记录分为三类：清单有而平台无，记为过期候选；平台有而清单无，记为遗漏候选；同一匹配键下出现多条记录，记为重复候选。每一类都标注疑似原因，例如“疑似停用未清理”“疑似批量导入未登记”“疑似模板复制残留”。
第四步，逐条核实并定性。对过期候选，查对象是否已停用、改名或被合并；对遗漏候选，查创建时间、创建人和关联变更单，判断是漏登记还是清单流程未覆盖；对重复候选，比对创建时间先后和创建人，确认哪一条是当前生效版本、哪一条是历史残留。核实结果写入差异明细表，每条记录都要有证据来源和结论。
第五步，处置并回写清单。过期项确认后从清单删除，或标注为已停用并保留历史说明；遗漏项补录，并注明来源和补录时间；重复项确认保留哪一条，其余清理或标注为副本。处置动作要逐条记录，形成可追溯的处置日志。
删除、合并、停用配置属于破坏性操作，执行前先导出快照或备份，明确停止点和审批人。例如清理重复的自动化规则前，先导出规则配置和运行日志；停用权限角色前，确认没有成员仍在使用。处置过程中如果发现差异原因超出本次范围，例如涉及规则本身的业务定义，记录后转入后续处理，不在核对中临时扩大改动。
在配置变更和核对记录需要承载时，ONES 可以用工作项记录变更申请与处置任务，用文档保存核对范围说明、差异明细表和处置结论。ONES Project 的自动化规则提供统一的管理平台和运行日志，便于管理员查看规则运行状态，这与核对自动化规则类配置时的追溯需求相对应。具体到配置导出和通用变更日志的覆盖范围，需要在实际环境中核验。
验证核对结果并防止再次不一致
处置完成后，需要验证差异是否真正闭环，再把核对动作固化为日常机制，降低复发概率。
验证的第一种方式是重新执行一次比对。用与首次核对相同的匹配键和字段口径，重新导出平台配置和更新后的清单，确认过期、遗漏、重复三类差异归零，或者每一条剩余差异都有明确的处置结论和责任人。重新比对时保持字段映射不变，否则结果不可比。
第二种方式是抽样复核。对权限角色、状态流、集成配置这类高风险模块，人工抽查若干条记录，确认清单描述与平台实际配置一致，包括成员范围、状态流转条件和集成连接信息。抽样比例可以根据模块变更频率确定，变更频繁的模块提高抽查数量。
复发预防的关键是把清单更新纳入配置变更流程。每次新增、修改、停用配置时，由变更发起人同步更新清单，或由指定的清单责任人确认登记完成后再关闭变更。清单责任人、核对周期和核对范围写入团队约定，例如按季度做一次全量核对，重大版本发布后追加一次专项核对。
记录留痕同样重要。每次核对的差异明细表、处置结论、参与人和核对时间都保留下来，便于后续追溯某条配置是什么时候、因为什么原因从清单中移除或补录。这些记录也可以作为下一次核对的时间窗口起点。
核对期间建议冻结相关配置变更，避免边核边改导致差异无法收敛。如果业务确实需要紧急变更，先记录变更内容和时间，核对时将该批次单独处理，并在结论中说明冻结期的例外情况。
常见问题
平台没有保留某类配置的变更日志，还能核对吗？
可以核对，但证据来源需要调整。没有平台日志时，可以用变更单、审批记录、导入批次记录或团队沟通记录作为补充证据，并在差异明细表中注明证据来源和可信程度。这类差异的结论通常只能定到“疑似过期”或“疑似遗漏”，处置前建议与配置创建人或所属模块负责人确认，再执行删除或补录。
核对过程中发现清单本身写错了对象名称，应该按哪边为准？
以平台当前生效配置为准。清单中的名称写错属于登记质量问题，处理方式是把清单条目修正为平台中的实际对象标识，并在差异表中记录修正原因。如果平台中的对象名称本身不规范，可以另立一条整改项，与本次差异核对分开处理，避免核对范围被扩大。
重复记录确认后，可以直接删除多余的那一条吗？
不建议直接删除。先确认哪一条是当前生效版本，比对创建时间、创建人和引用关系，例如是否有项目、工作流或成员正在使用该配置。确认保留对象后，把其余记录标注为副本或停用，并导出快照留档。涉及自动化规则时，可以结合运行日志确认实际生效的是哪一条规则，再决定清理对象。
核对期间业务方要求紧急修改配置，怎么处理？
先记录变更内容、时间和发起人，把该批次单独标记，核对时按新批次处理，并在核对结论中说明冻结期的例外情况。如果变更影响正在核对的模块，建议先完成该模块的差异定性，再放行变更，避免边核边改导致差异无法收敛。
多久核对一次比较合适，是否每次都要全量比对？
核对周期可以按配置变更频率确定。变更频繁的模块，例如权限角色、状态流和集成配置，可以按季度核对；变更较少的模块可以按版本发布节点核对。全量比对适合清单长期未更新的情况，日常核对可以采用增量方式，只覆盖上次核对之后发生的变更批次，并对高风险模块做抽样复核。
