如果靠 AI 就能把陈旧的遗留系统直接平移到新架构

最近在看一些关于 AI 辅助迁移（Migration）的技术讨论，发现大家普遍存在一种过度乐观的幻觉。很多人觉得，既然 LLM 能写代码、能读文档，那把那堆写了十年的 COBOL 或者乱七八糟的旧版 Java 项目丢给 Claude 或者 GPT-4，让它直接重构成 Go 或者 Python 不就行了吗？

这种想法极其危险。

我最近在复盘一个中型规模的系统迁移案例，发现 AI 在这个过程中的表现非常两极分化。它确实能帮你处理那些琐碎的、重复性的逻辑转换，比如把简单的 CRUD 接口从旧框架搬到新框架，或者把 SQL 语句转换成某种特定的 ORM 语法。这种“搬砖”活儿，AI 做得比人工快得多，准确率也高。

但真正的迁移痛点根本不在于语法转换，而在于“隐性逻辑”和“副作用”。

为什么单纯靠 Prompt 搞不定迁移

• 上下文丢失风险： 遗留系统往往缺乏完善的单元测试和文档。AI 只能看到你喂给它的代码片段，它看不见那些隐藏在数据库触发器里、或者是由于网络延迟导致的竞态条件。一旦它为了追求“现代感”而重构了某个逻辑，可能会在生产环境下引发极其隐蔽的系统崩溃。
• 架构理解的偏差： AI 本质上是在做概率预测。如果你让它把一个单体架构迁移到微服务架构，它可能会机械地把每个模块拆成一个 Service，但它并不理解这些模块之间真正的领域驱动设计（DDD）边界在哪里。结果就是你得到了一堆互相调用、逻辑耦合极其严重的“分布式单体”。
• 数据一致性难题： 代码迁移只是冰山一角，数据的平滑迁移才是大头。AI 目前很难处理大规模存量数据在不同 Schema 之间的转换逻辑，尤其是涉及到复杂的清洗规则和校验逻辑时，人工介入的成本往往比重写一遍还高。

比较靠谱的实操思路

如果你真的想在迁移工作流中引入 AI，我建议不要把它当成“自动驾驶”，而要把它当成一个“高级结对编程伙伴”。

一、先做静态分析而非直接重写
先利用大模型对旧代码进行语义提取，生成一份详细的逻辑流图和依赖关系清单。

# 伪代码思路：利用工具提取依赖，再喂给 LLM 分析
grep -r "import" ./legacy_code | llm "Analyze the dependency graph and identify potential side effects"

二、基于测试驱动的迁移 (TDD-based Migration)
这是最稳妥的办法。在让 AI 改写任何逻辑之前，先用现有的旧系统跑出输入输出的“黄金数据集”（Golden Dataset）。迁移后的新代码必须通过这些测试用例。

三、小步快跑的组件化重构
不要试图一次性吞掉整个项目。先让 AI 帮你写转换器（Adapter），通过适配器模式让新旧逻辑共存，跑一段时间没问题了，再逐步替换掉旧模块。

说白了，AI 只能解决“怎么写”的问题，但解决不了“为什么要这么写”的问题。在迁移这种牵一发而动全身的任务里，人类工程师的价值在于对业务逻辑的最终背书。