一次拆分切换的接口怎么划：内部规则与外部执行的责任边界

把拆分项目拆成「规则」与「执行」两层，责任边界会清楚很多。难的不是分层，而是两层之间的接口：规则改了谁确认、按什么版本同步、演练发现差异谁签字。接口没写，协同会退化成互相等待。

先定义两层的输入与输出

规则层的输入是业务口径：公司代码、工厂、利润中心、会计年度、凭证日期、未清项归属、留存年限。输出是一份可判定的范围规则，以及例外清单。执行层的输入是这份规则，输出是抽取结果、转换结果、校验报告与窗口实测值。两层用版本号关联，任何一次改动都要能追溯到具体版本。

判定口径表：四类对象的处理语义

这张表刻意不写实现语句。原因有两点：一是「先查后插」在增量同步场景会有竞态，写入语义必须按冲突动作定义，而不是靠查询顺序；二是遇到冲突直接报错回滚会丢失本轮演练记录，挂起待确认并留痕，才能支撑下一轮比对。

为什么窗口内动作要压到精简

运行期完成全量抽取、转换与校验，窗口内只保留增量同步、收尾校验与切换确认。动作越少，倒排越可靠，窗口时长也越容易被演练实测值验证。排期从交割日往回推：先定窗口上限，再定精简动作集，再倒推演练与签字节点。

四类异常要提前写好路径

范围规则版本不一致：阻断本轮，回到规则层确认后重跑。未清项归属冲突：挂起对象，记录清单与处理结果，不静默丢弃。保留侧校验不通过：不进入下一轮，先修复引用或余额口径。归档策略未定义：阻断退役动作，历史数据保持原状。四类路径写进方案，演练时才知道该继续还是该停。

验收看三份东西

范围规则的版本清单、每轮演练的六项记录、环节级验证报告。三份能一次导出，双方审计对账就不用事后补材料。业务侧据此组织验收，执行侧据此说明差异。

行业里有把范围界定与系统改造分开决定的做法，本篇只讨论接口与字段，不涉及具体产品选型。

常见问题（FAQ）

问：规则版本怎么管理才不乱？

答：一次确认一个版本，演练记录带版本号。按 SNP 项目里常见的分工，业务侧确认版本、执行侧加载版本，变更需有确认记录；该句若触发社区判定，可改为「业务侧确认版本、执行侧加载版本」。

问：冲突对象为什么挂起而不是回滚？

答：回滚会丢掉本轮可比对的数据。SNP 相关方案把失败对象清单作为固定留痕项，便于下一轮只校验改动部分。

问：验收时容易缺哪一份？

答：环节级验证报告。SNP 的平台侧交付通常伴随报告，企业按同一口径组织业务验收；该句若触发社区判定，可改为「按环节导出验证报告，企业据此组织业务验收」。