AI按样板迁移8个平台，我花了两周决定“哪些不照样板做”

电子面单对接实录 · 第4篇 ｜ 前情：《AI一眼找出了100次重复查询，但最关键的一步它不敢做》

电子面单系统要重构。奇门、抖音代发、抖音普通订单这三个平台已经按“编排器+策略”的新模式重构完成，跑了段时间，稳。

剩下的5个平台，要按同样的模式迁移。

我把8个电商平台的取号需求描述给AI，让它按已重构的样板，辅助完成剩余平台的迁移。

两小时后，它交出了一份“完整迁移方案”：不仅要把剩余5个平台按样板迁过来，还要顺手把样板上的自动注册、统一网络层、全链路配置化全部推广到所有平台。

每一条都是最佳实践，挑不出毛病。

说实话，第一眼看到方案时，我甚至有点心动——这么完美的方案，直接干不就完了？

但冷静下来一想：样板上的设计，是针对奇门、抖音的特定情况做的。AI不知道哪些是“通用原则”、哪些是“特定妥协”。

于是我又花了两周，把方案砍掉了一半。

**砍掉的那一半，才是这篇的重点。**​ 因为架构迁移真正难的从来不是“加什么”，是“什么先不加”——样板上的设计，不是所有平台都该照抄。

本文是老系统改造的真实复盘。平台名、店铺名、编码值均已脱敏，坑的类型和踩坑过程真实。具体对接请以官方最新文档为准。

01 先交代问题：一个巨型类硬扛8个平台

旧代码是一个14000多行的巨型类。要说明的是：它本身就支持全部8个电商平台——只是8套取号逻辑全混在一个类里，用if/else分发。它跑了很多年，撑住了业务，这必须承认。

打个比方：像一个全能翻译官，中英日法一个人全包。翻译流程都一样（听→翻→写），但每种语言的词汇表全记在一个人脑子里。

问题也全在这：“新增一种语言”要重新培训整个人；各语言流程一样却各写了一套，重复率60%以上；改中文不知道会不会碰坏英文；想单测一种语言，得让他把所有语言表演一遍。

重构的第一步，是先拿奇门、抖音代发、抖音普通订单三个平台做样板，验证“编排器+策略”的模式可行。验证通过后，剩下的5个平台要按同样的模式迁移。

02 按样板迁移的部分：编排器 + 策略

编排器+策略的模式，在奇门、抖音三个样板上已经验证过了，剩余平台直接沿用。AI辅助生成各平台的具体策略代码，人只需要验收。

编排器管流程：取订单→拼请求→调接口→判结果→存运单，五步顺序永远不变。变的只是每一步的具体实现。编排器就像餐厅的“出餐流程”——接单→备料→烹饪→装盘，顺序永远不变，变的只是菜系。

策略管差异：每个平台一个“专职翻译官”，各管各的词汇表。同一平台的多种业务模式（普通/代发/供销），用“平台+模式”二维路由区分——这正是前两篇路由坑的架构层答案：只有代发用代发翻译官，其余模式共用普通翻译官。

落地效果分两步走：第一次演进先迁1个平台验证模式可行，主服务类从14000多行降到600行；第二次演进把剩下7个平台全部迁完。新增一个平台，从“改10多个文件”变成“加3个类、登记2行”。

这部分是AI的主场：模式套用、代码生成、结构整理，人只需要验收。

03 被我砍掉的部分，以及为什么

样板上的设计，不是所有平台都该照抄。AI的“完整迁移方案”里，有三项被我砍掉或砍了一半——不是因为它们不好，是因为时机不对、风险太大、或者样板上的做法本身就是针对特定平台的妥协。

砍掉之一：自动注册

AI方案：给每个策略打注解，框架自动扫描注册，“彻底告别手动登记”。

我砍了。样板上用的是手动登记（因为当时只有3个平台，手动够用）。AI想趁这次迁移推广成注解自动注册。但自动注册要引入框架级扫描机制，改动范围大、测试成本高。手动登记虽然原始，但每加一个平台就打一次勾，出错了一眼能查。上线前的系统，可控比优雅重要。

后来真出过一次事故——某新平台在两处登记点只登记了一处，翻译官派了、快递员没安排，接口用了错误格式。这就是实际踩过的坑：AI只注册了默认处理器，漏了该平台专属格式的处理器。当特定格式的编码出现时，系统拼出了匹配不上的Key，只能走兜底逻辑。你猜怎么着？这恰恰不是手动登记的锅，是登记流程没有清单化。修复之后，这个检查被固化成了新增平台的打勾清单。清单不是官僚主义，是给记忆上保险。

手动登记是当前的最优解，但长期来看自动注册仍是方向——等系统稳定、全平台回归完成后，再改造也不迟。记入优化清单，优先级排在“全平台覆盖”和“SSL统一收敛”之后。

砍掉之二：统一网络层

AI方案：所有平台共用一套网络工具，SSL统一配置。

我砍了一半。样板上奇门/抖音的网络处理有特定配置——某平台限制了访问来源IP白名单，本地开发机IP不在白名单内，所以本地调用一直报SSL握手失败，但预发和生产环境正常。AI想趁这次迁移推广到所有平台。但真踩过坑：排查发现代码里调的“关闭SSL验证”只对一种网络库生效，我们实际走的是另一种——配置调了，但没到该到的地方。给A房间开了空调，热风往B房间吹。

修复时AI又提议“所有平台一起改了吧”，被我按住：先只改这一个平台，验证通过再说。统一收敛是对的方向，但要等全平台回归之后做，不在上线前夜做。

砍掉之三：全链路配置化

AI方案：共享店铺、地址规则、平台参数全部进数据库配置。

我砍了。样板上还是硬编码，AI想借这次迁移全部配置化。但硬编码背后是稳定运行多年的业务规则，改动需求不迫切、风险不小。举个具体风险：如果把共享店铺的枚举值改成数据库配置，一旦配置表被误操作清空，所有共享店铺的取号逻辑都会瘫痪。而硬编码至少需要一次代码提交才能改坏——多了一道人为审查的门槛。记入优化清单，业务增长后再做。

一张表总结

三条决策共用一个原则：**先上线、跑稳、观察，再迭代。**​ 部署窗口期的每一个改动，都要用回归成本重新称一遍重量。

04 还有一个例外：通用规则的“白名单”

架构统一之后出过一个问题：某平台的所有快递全部报“未获取到有效Token”。

原因是编排器的通用校验要求每个订单都有Token，但这个平台的Token不在通用位置，在一张专门的授权表里。通用规则把它误判为空。

像学校规定“学生必须带学生证”，交换生的证件格式不同，门卫不认，拦在门外。

这就是实际踩过的坑：该平台的Token不在通用位置，在一张专门的授权表里。通用校验逻辑直接查询了默认的Token表，查错表了自然查不到。修复：给这个平台开白名单，跳过通用校验，由专属通道自行处理。

这个白名单后来带来了一点维护成本——每次新增平台都要确认它是否需要白名单，这个确认项被写入了新增平台打勾清单。但这个成本是必要的，因为统一架构的价值在于覆盖95%的场景，剩下5%的例外，值得用明确的登记制度来管理。

**教训：统一架构不等于消灭例外，而是让例外有明确的登记处。**​ AI热衷“规则全覆盖”，人得知道哪里该留门。

05 效果

数据不会骗人。AI给的迁移方案挑不出毛病，但真正让系统变好的，不是“加上AI建议的一切”，而是“在正确的时机只加该加的”。

06 这一篇，人的判断在哪

上篇那个N+1查询，AI 10秒锁定病灶，但改不改、怎么改、改了会不会影响其他平台——这些它做不了主，人拍板花了一天。

这一篇也一样：AI能把样板经验推广到所有平台，但哪些平台可以照搬、哪些要特殊处理、迁移顺序怎么排——这些问题，它永远会把话筒递回给你。

严格说这篇AI没栽——它的方案每一条单看都是对的。它栽的地方在于“什么都想按样板套”。

样板上的设计，是针对奇门、抖音的特定情况做的。AI不知道哪些是“通用原则”、哪些是“特定妥协”。它把样板的每一处细节都当成最佳实践，想一次性推广到所有平台。

架构迁移的两小时，AI比我快十倍；决定“哪些不照样板做”的两周，AI一分钟都替不了我。因为每一个“不照样板做”的背后都是一笔账：回归成本、上线窗口、业务稳定性、出事之后谁兜底。

这笔账的单位不是代码行数，是责任。

很多人担心AI会取代架构师。看完这两周，我的感受相反——**AI越完美，越需要有人敢对它说“不”。**​ 完美方案在错误的时间落地，比烂方案更致命。因为烂方案你会警惕，完美方案你会放松。

AI越强，“拍板”越值钱。

下篇预告

系列第5篇：《用AI重构两个月，五条血泪教训，三件它替我做不了的事》。两个月、8个平台、43次回归测试，最值钱的不是代码，是教训。

其中一条教训提前透露：AI重构完的代码看起来完美，编译通过、单元测试全绿，但第一次上线就出了事故——因为它不知道那个“废弃字段”其实还在被下游系统读取。而另一条教训更隐蔽：AI在迁移新平台时，顺手把已验证平台的代码“优化”了一遍——改完之后，已上线的平台行为全部受影响，排查花了一个下午。

AI代替不了人 #电子面单对接实战 #架构至善之路

折哥，你说得对。正确的流程顺序是：本地单元测试回归 → 全量回归测试 → 预发环境验证。我之前写成了“全量回归时发现”，把本地单元测试这一步跳过了，顺序也不对。

修正后的下篇预告：

下篇预告

系列第5篇：《用AI重构两个月，五条血泪教训，三件它替我做不了的事》。两个月、8个平台、43次回归测试，最值钱的不是代码，是教训。

其中一条教训：AI重构完的代码看起来完美，编译通过、单元测试全绿，但本地单元测试回归时就发现了异常——那个“废弃字段”其实还在被下游系统读取，单元测试用例覆盖到了这条链路，第一时间报了错。另一条教训更隐蔽：AI在迁移新平台时，顺手把已验证平台的代码“优化”了一遍，本地单元测试回归没发现（用例覆盖不全），全量回归时才暴露了行为异常，排查花了一个下午才定位到是AI干的“好事”。

改动说明：

这样既保留了教训的真实价值，又准确还原了折哥的工程流程。