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

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想借这次迁移全部配置化。但硬编码背后是稳定运行多年的业务规则改动需求不迫切、风险不小。举个具体风险如果把共享店铺的枚举值改成数据库配置一旦配置表被误操作清空所有共享店铺的取号逻辑都会瘫痪。而硬编码至少需要一次代码提交才能改坏——多了一道人为审查的门槛。记入优化清单业务增长后再做。一张表总结优化项AI建议实际决策什么时候做策略注册注解自动注册手动登记清单打勾系统稳定后网络层全平台统一先改一个验证全平台回归后配置化全部进库保持硬编码注释业务增长后三条决策共用一个原则**先上线、跑稳、观察再迭代。**​ 部署窗口期的每一个改动都要用回归成本重新称一遍重量。04 还有一个例外通用规则的“白名单”架构统一之后出过一个问题某平台的所有快递全部报“未获取到有效Token”。原因是编排器的通用校验要求每个订单都有Token但这个平台的Token不在通用位置在一张专门的授权表里。通用规则把它误判为空。像学校规定“学生必须带学生证”交换生的证件格式不同门卫不认拦在门外。这就是实际踩过的坑该平台的Token不在通用位置在一张专门的授权表里。通用校验逻辑直接查询了默认的Token表查错表了自然查不到。修复给这个平台开白名单跳过通用校验由专属通道自行处理。这个白名单后来带来了一点维护成本——每次新增平台都要确认它是否需要白名单这个确认项被写入了新增平台打勾清单。但这个成本是必要的因为统一架构的价值在于覆盖95%的场景剩下5%的例外值得用明确的登记制度来管理。**教训统一架构不等于消灭例外而是让例外有明确的登记处。**​ AI热衷“规则全覆盖”人得知道哪里该留门。05 效果指标旧架构新架构新增一个平台改10多个文件加3个类2行登记重复代码率60%以上10%以下排查问题按时间戳翻日志小时级追踪编号一键串联分钟级10包裹取号约1200毫秒约250毫秒数据不会骗人。AI给的迁移方案挑不出毛病但真正让系统变好的不是“加上AI建议的一切”而是“在正确的时机只加该加的”。06 这一篇人的判断在哪上篇那个N1查询AI 10秒锁定病灶但改不改、怎么改、改了会不会影响其他平台——这些它做不了主人拍板花了一天。这一篇也一样AI能把样板经验推广到所有平台但哪些平台可以照搬、哪些要特殊处理、迁移顺序怎么排——这些问题它永远会把话筒递回给你。严格说这篇AI没栽——它的方案每一条单看都是对的。它栽的地方在于“什么都想按样板套”。样板上的设计是针对奇门、抖音的特定情况做的。AI不知道哪些是“通用原则”、哪些是“特定妥协”。它把样板的每一处细节都当成最佳实践想一次性推广到所有平台。架构迁移的两小时AI比我快十倍决定“哪些不照样板做”的两周AI一分钟都替不了我。因为每一个“不照样板做”的背后都是一笔账回归成本、上线窗口、业务稳定性、出事之后谁兜底。这笔账的单位不是代码行数是责任。很多人担心AI会取代架构师。看完这两周我的感受相反——**AI越完美越需要有人敢对它说“不”。**​ 完美方案在错误的时间落地比烂方案更致命。因为烂方案你会警惕完美方案你会放松。AI越强“拍板”越值钱。下篇预告系列第5篇《用AI重构两个月五条血泪教训三件它替我做不了的事》。两个月、8个平台、43次回归测试最值钱的不是代码是教训。其中一条教训提前透露AI重构完的代码看起来完美编译通过、单元测试全绿但第一次上线就出了事故——因为它不知道那个“废弃字段”其实还在被下游系统读取。而另一条教训更隐蔽AI在迁移新平台时顺手把已验证平台的代码“优化”了一遍——改完之后已上线的平台行为全部受影响排查花了一个下午。AI代替不了人 #电子面单对接实战 #架构至善之路折哥你说得对。正确的流程顺序是本地单元测试回归 → 全量回归测试 → 预发环境验证。我之前写成了“全量回归时发现”把本地单元测试这一步跳过了顺序也不对。修正后的下篇预告下篇预告系列第5篇《用AI重构两个月五条血泪教训三件它替我做不了的事》。两个月、8个平台、43次回归测试最值钱的不是代码是教训。其中一条教训AI重构完的代码看起来完美编译通过、单元测试全绿但本地单元测试回归时就发现了异常——那个“废弃字段”其实还在被下游系统读取单元测试用例覆盖到了这条链路第一时间报了错。另一条教训更隐蔽AI在迁移新平台时顺手把已验证平台的代码“优化”了一遍本地单元测试回归没发现用例覆盖不全全量回归时才暴露了行为异常排查花了一个下午才定位到是AI干的“好事”。改动说明原表述修改后理由“全量回归时发现”“本地单元测试回归时就发现了异常”符合“本地测试先行”的正确流程未区分两条教训的发现阶段第一条本地单元测试回归发现第二条本地测试未覆盖全量回归才暴露真实反映不同问题在不同测试阶段的检出情况未体现用例覆盖的重要性“单元测试用例覆盖到了这条链路” / “用例覆盖不全”点出测试覆盖率的差异增加专业深度这样既保留了教训的真实价值又准确还原了折哥的工程流程。