本地推理迁移上线一个月后，我们才发现漏掉的三行配置

上个月我们把线上推理从云 API 切到了本地 router，流量数字很体面：P95 延迟从 1400ms 掉到 220ms，月底账单省了大概七成。我们是按计划切完、观察一周、报告结果的。

一周后，一位用户报告说，他最近几次长对话里被引用了自己三天前的另一段话，而且引错了对象。不是幻觉，是检索库撞了记录。我们复现三次才命中一次，定位花了一天：云 API 时代，网关里有一段请求日志的脱敏逻辑，顺手把用户自定义 ID 的分隔符统一改成了下划线。本地 router 没这段逻辑，ID 原样进库。旧库里两个互不相干的用户 ID，撞了。

迁移时我们做了全链路回归，spec 也写了「自定义 ID 唯一性校验」这条，执行时用的是测试数据——测试数据的 ID 从来没撞过，所以 spec 全绿，我们上线了。

没有人做错事，但机制缺了一块：迁移类工作没有强制环节去检查旧系统里的隐性副作用。

现在我们的做法变了，很笨，但有效：

第一，迁移前把上一代网关的配置、中间件、路由规则逐条列成清单，每条只允许标三种状态：显式迁移、确认不需要、没有确认。第三类没有清零就不许开工。第一版清单 47 条，有 9 条停在「没有确认」，事故来源就是其中之一。

第二，测试数据不能是干净的。ID 库里必须故意放一组已知会撞的 ID，目的不是检验检索正常工作，是检验撞库时有没有报警。以前测试库是手工造的，从没撞过，所以从没发现过报警路径根本不存在。

第三，切流不走瞬时开关。新旧两套先并行一小段真实流量，两边收同一请求，比对输出差异，超阈值不许切。第一版并行时差异率 0.3%，阈值当时定的是 0.5%，我们上线了。0.1% 的话这事会在上线前暴露。

成本是实打实的：清单一次整理大概两个人日，比对脚本两晚。我们用这笔时间换掉了一次「用户先发现」，三个月内同类问题没再出现。样本太小，不构成结论，但对我们自己来说，比 spec 全绿可信一点。