同一批合同，上周分类正确，这周却把几份补充协议放错组。大家先问模型是不是升级了，但清洗脚本和分类标签也刚改过。只保存最终答案，连“同一个处理方法”都无法确认，更谈不上知道哪一步出了问题。
单一服务先把版本写进日志，用已有模型评估和数据版本工具就够。多个助手调用不同提供方时，需要把这些运行事实和具体请求关联；EasyNet 的能力身份与调用记录可以提供索引，却不会自动保存所有依赖。
提供方应在分类结果里附上实际模型标识、规则版本、数据快照及必要配置摘要。声明来自真正执行程序，不能由客户端根据今天的默认配置推断昨天用了什么。输入材料保留合法可复测的版本，敏感原件不必进入公共目录。
排查函数可以接受两次运行标识，返回已记录的差异与缺失项。它只是整理证据，不因为模型字段变了就宣判根因。要确认原因，还需在隔离环境固定输入，一次换一个因素做对照。
维护者要说明哪些旧依赖仍可获得、哪些外部服务无法回退。接口版本相同也可能有非确定性输出，不能承诺逐字重现。回退发布与重新处理客户材料是两个需要分别决定的动作。
把那几份出错合同做成获准的回归样本，检查不同规则下差异能否稳定出现。发布清单和对照工具补齐后，团队面对结果变化时可以先找运行事实，而不是靠模型名称、时间巧合或一次重试猜原因。
- 01
取两次运行事实
模型、规则与数据版本
- 02
列差异与缺项
没有记录的字段不猜
- 03
固定输入复测
一次替换一个因素
同一模型也可能用了不同规则
本地运行记录比较器，只找差异不判根因；这里没有实际模型调用。
本地示例 · python
before = {"model": "classifier-A", "rules": "v3", "data": "snapshot-17"}
after = {"model": "classifier-A", "rules": "v4", "data": "snapshot-17"}
changes = {key: (before[key], after[key])
for key in before if before[key] != after[key]}
assert changes == {"rules": ("v3", "v4")}
print(changes)
print("Next: compare v3 and v4 on the same approved input.")预期结果：只指出 rules 从 v3 变为 v4；还要对照试验，不能直接宣布 v4 是错误根因。
接入时的检查项
- 能否定位两次调用各自的能力和依赖版本。
- 固定输入的差异是否可重复观察。
- 报告中的根因是否有单变量对照支持。