AI 迁移能力的真正起点：把历史系统改造成可理解、可约束、可验证的架构

在算法策略高速迭代的年代，很多大型在线系统的第一优先级是让实验快速上线。策略团队直接编写 UDF、维护流程图配置、各自拉分支，单次试验的路径确实很短。但当业务进入多场景长期维护阶段，这份「速度红利」开始反噬：数百万行代码、多套框架并存、同名逻辑在各分支独立演化，一次公共能力升级要逐一确认行为、评估影响、分别发布验证。维护责任最终落到规模更精简的工程团队手中，问题从「写得快」变成了「接不住」。这篇文章要讲的，正是一个团队如何从生产方式层面重构这套系统，并让 AI 真正参与到复杂历史应用的迁移中。

复杂度藏在复制后的独立演化里

梳理线上版本后会发现，真正的维护成本并不来自图的数量或代码行数，而来自「复制后的独立演化」。同一套流程被复制到不同分支后，因场景需求、参数配置和兼容逻辑各自生长，同名逻辑图可能早已行为不同，代码分支的最新提交也未必对应线上部署版本。叠加三类问题——分支副本化与多框架并存、执行模型缺少稳定语义与统一生命周期、诊断与监控能力分散——维护成本随分支和场景持续增长，无法被公共能力和历史经验摊薄。团队由此得出关键判断：要重构的不是某段代码，而是整个应用生产方式。

AI Friendly 不是让 AI 更容易写代码

很多团队把 AI Friendly 理解为「模型能快速生成代码」，这个判断并不牢靠：代码生成效果随模型版本、提示词和样例数量波动，只能说明模型能力，不能证明架构适合 AI 长期参与。真正的检验标准是：AI 能否只读取与任务相关的局部上下文，能否在有限且稳定的工程语法内做选择，能否通过显式契约理解数据流，生成结果能否被确定性工具检查，运行后能否留下足以定位问题的证据。换言之，AI Friendly 是架构设计产生的工程属性——为 AI 提供有限、显式且可验证的工程空间，而不是替 AI 保证结果正确。

从多年产业实践经验来看

从多年产业实践经验来看，这类重构的关键是把「稳定能力」和「场景差异」彻底分开。新体系由轻量执行框架与配套编排平台组成，分为四层：物料层用细粒度节点承载独立业务计算与链式调用，节点通过明确的输入、输出和配置契约参与编排；编排层用 Plan、Stage、执行组等层级声明式描述流程，顺序优先、显式并行，公共前后置逻辑由框架统一拼接；运行时层负责条件判断、参数传递、并发调度与异常处理；诊断层则让每次执行生成与真实任务树一致的结构化执行记录——日志、监控、排查工具消费同一份执行事实。选择自研而非改造现有图框架，是因为团队要统一应用模型、流程语义、生命周期和结构化诊断，并配套组件发现、可视化编排与发布治理，这些核心抽象在既有框架上仍需重建，还要受制于底层模型的演进节奏。值得强调的是，统一框架本身不会自动回收历史分支，主干开发约束和长尾分支治理仍需工程制度保证——架构提供的是让治理动作可以发生的技术基础。

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

新体系建立后，历史应用不会自动迁移，团队走出了一条值得借鉴的三阶段路径。第一阶段是人工迁移建立基线：选一个结构相对简单的真实场景，人工还原旧图、节点职责与数据依赖，投入约 20 人日，留下第一批可复用资产——概念映射、节点拆分规则、编排样例、新旧链路对比方法。没有这一步，AI 面对的只是一组散乱代码和抽象目标。第二阶段让 AI 参与迁移并打磨 Skill：把框架知识、迁移步骤和样例写入 Skill，迁移中暴露的错误分两类处理——需要理解业务语义的补充知识与样例，可确定性判断的沉淀为解析器、生成器和校验脚本。每发现一种可重复错误，都思考如何让下一次更早发现、自动定位、可重跑。第三阶段直接复用 Skill：读取旧应用事实、按依赖拓扑划分阶段、生成代码与配置、执行确定性校验、人工审核语义与灰度决策，单场景迁移周期压缩到约 3 天。验证同样分三层：静态结构与契约校验在部署前拦截问题；录制旧链路外部输入、回放给新链路，逐层比较召回、打分、重排差异；最后经预发、灰度与生产观察收尾。结果显示已迁移场景的平均 RT、P99 均未劣化，部分长尾甚至改善，且性能提升主要来自迁移中重新梳理的并行关系。

这次实践给出的最终判断很清晰：面对复杂历史系统，AI 迁移的起点不是更长的提示词或更激进的自动生成，而是先把系统改造成可理解、可约束、可验证的形态。人工基线、显式契约、确定性工具与职责分离，共同决定了 AI 能安全走多远——工程基础有多扎实，AI 的自动化能力就能复制多远。