数百万行遗留代码如何被AI安全重构：搜推在线架构升级的完整方法论拆解

大型在线系统演进到一定阶段，几乎都会积累出一个“能跑但不敢动”的遗留体系：多套框架并存、几十个分支各自演进、数百万行代码牵一发动全身。某头部电商直播搜推团队就面临这样的局面。他们没有选择让AI直接改写代码的激进路线，而是先重构应用的生产方式，再把迁移经验沉淀为可复用的Skill交给AI执行，最终实现性能平稳过渡、迁移周期从20人日压缩到3天。这条路径对任何想用AI改造存量系统的团队都有参考价值。

从人工基线到Skill复用的三阶段演进

早期为让算法策略快速上线，算法同学直接编写Java UDF、维护图配置并独立开分支，这在当时是务实选择。但当业务进入多场景长期维护阶段，问题开始爆发：同一套公共能力被复制到不同分支后因场景需求独立演进，同名逻辑图行为已各不相同，一次公共能力升级需要先逐一确认各版本差异，再分别修改、发布和回归验证。维护成本随分支和场景持续增长，无法通过增加人员根本解决。

很多团队把AI Friendly理解为“模型能快速生成代码”，这是误读。代码生成效果取决于模型版本和提示词，只能证明模型能力，不能证明架构适合AI长期参与。真正的判断标准是：AI能否只读取与任务相关的局部上下文，能否在有限且稳定的工程语法内做选择，生成结果能否被确定性工具检查，运行后能否留下足以定位问题的证据。AI Friendly本质是一组架构属性，而非一项功能。

从多年产业实践经验来看，这套升级的关键不在于换了某个框架，而在于三项核心机制的系统配合。其一是统一物料与声明式差异：把粗粒度UDF拆为职责可用一句话说明、输入输出可稳定声明的细粒度节点，稳定能力进入代码主干，场景差异通过节点组合、参数连接、条件与配置在编排层显式表达，新场景不再默认复制完整分支。其二是受约束的流程语义：放弃自由图的表达上限，换取按Plan到Stage到执行组的层级自上而下可读的稳定范式，参数依赖从隐藏在方法调用中的约定变为可枚举、可静态校验的显式契约，公共前后置逻辑成为统一生命周期的一等能力。其三是结构化执行诊断：每次执行生成与真实任务树一致的证据树，日志、监控、排查工具消费同一份执行事实。这三者共同把散落在人脑中的隐式知识变成机器也能使用的工程契约，为AI参与工程任务提供了有限、显式且可验证的空间。

迁移策略同样值得深挖。第一阶段选择图结构简单、输出稳定的场景做人工迁移，约20人日，目的不是证明人比AI可靠，而是建立三类基线：哪些旧行为必须保留、旧概念如何映射到新体系、什么证据能证明迁移正确。第二阶段让AI参与一个完整场景迁移，同时把失败沉淀为能力：需要业务理解的错误补充进Skill知识，可确定性判断的错误沉淀为解析器、生成器和校验脚本，例如增加图血缘提取、跨产物契约对账等工具。第三阶段直接复用Skill执行标准流程：还原事实、生成任务、按依赖拓扑迁移、确定性校验、修复重跑，人工只负责审核语义与授权灰度，单场景周期压缩到约3天。验证上采用三层机制：静态契约校验前置拦截结构问题；录制旧链路外部调用回放给新链路，隔离实时数据噪音后按召回、打分、重排逐层比对；最后经预发、灰度与生产观察。已上线场景的平均RT、P99、P999均未劣化，部分长尾耗时反而改善。

这次实践给出的核心判断是：面对复杂历史系统，AI迁移的起点不是更长的提示词或更激进的自动生成，而是先把系统改造成可理解、可约束、可验证的形态。工程基础决定了AI能够安全走多远，而人工迁移建立的事实与验收基线，恰恰是后续一切自动化的前提。