程序员最熟悉的疲惫不是加班到凌晨三点而是接到一个看似简单实则无底洞的任务把一套运行了五六年的老系统从一个技术栈迁移到另一个技术栈。依赖冲突、语法差异、隐式约定、文档缺失、环境不一致……每一项单独拎出来都不难叠在一起就变成了“迁移疲劳”。你很难说清楚到底哪一步最累但整个项目做完所有人都像被抽空了一样。更可怕的是这种疲劳会在团队里沉淀成一种潜意识能不迁就不迁能不动就不动。而 LLM 的出现正在改变这件事。这篇文章不是要告诉你“LLM 能自动迁移一切代码”——这是不现实的。我想聊的是LLM 如何从理解、转换、审查、验证这四个环节把迁移从“靠人肉硬扛”变成“半自动重构”以及在实际项目里该怎么一步步接入这套流程。1. 迁移疲劳到底是什么“迁移疲劳”不是一个严谨的技术术语但它描述的现象几乎所有后端开发者都见过。一个典型的 Java 老项目准备升级到 Spring Boot 3 / Jakarta EE或者一个 Python 2 项目终于决定迁到 Python 3又或者 PostgreSQL 要迁移到国产数据库。刚开始大家觉得“工作量不大两周搞定”。真正动手后才发现依赖之间的版本冲突比想象中复杂得多很多写法在新框架里已经废弃但旧文档根本没提线上有很多隐蔽分支逻辑测试覆盖不到迁移完以后行为变得不一样但没人说得清是哪里变了。于是项目从两周拖到两个月从“顺手升级”变成“专项攻坚”。中途不断有人接手又不断有人离开知识在交接中流失文档和代码越来越对不上。这就是迁移疲劳的本质它不是某一次技术难点而是高密度、低创造性、持续消耗认知资源的重复劳动。人脑天然不擅长这种任务。读旧代码要维持大量上下文改代码要时刻警惕边界差异验证结果又高度依赖经验。LLM 恰好在这种场景下最有优势——它的上下文窗口足够大能够一次读入大量文件它不厌烦重复更重要的是它可以基于大规模代码语料快速识别那些“看起来没用、实际上有用”的隐式约定。2. 对抗迁移疲劳的传统方案为什么总差一步在 LLM 成熟之前业界也有很多迁移工具大致分三类第一类是语言/框架官方迁移工具。比如 Python 的2to3、Java 的OpenRewrite、Angular 的ng update。它们对标准语法的覆盖很好但处理不了业务语义。第二类是静态分析工具。比如 SonarQube、SpotBugs、ESLint 迁移规则能扫出一批“不兼容写法”但它只能告诉你“这里有风险”不能帮你理解“为什么这里要这么写”。第三类是手工重构。最可靠也最慢。它要求团队里至少有一个对新旧技术栈都非常熟的人由他充当“人肉编译器”。这三种方案各解决了一部分问题但都没有解决一个核心矛盾迁移过程中最大的成本不是改代码而是理解旧代码“为什么要这么写”。传统工具擅长机械替换但面对那些历史遗留的兼容逻辑、性能优化技巧、防御性判断它们无能为力。老程序员靠经验能看出来“这里为什么要 catch 这个异常然后又吞掉”新人看不出来工具更看不出来。于是要么误删逻辑要么不敢动最后迁移就变成了“全部重写”。LLM 的价值恰恰在于它可以成为一个会读代码、能解释语义、能提出建议的“虚拟老同事”。它不一定每次都对但能极大降低理解门槛让你把有限的精力放在真正需要判断的地方。3. LLM 真正改变的是迁移全流程很多人对 LLM 辅助开发的想象停留在“你说需求它写代码”。但在迁移场景里LLM 最大的帮助不在“写”而在“读”。一次完整的迁移可以拆成四个阶段3.1 理解阶段LLM 是代码讲解员拿到一个老旧模块第一件事不是改而是搞懂它。传统方式人肉读源码顺着调用链一个个跳遇到不懂的再搜文档。一个 5000 行的老模块经验丰富的人也要读一两天。LLM 方式把整个模块的关键文件丢给它直接提问这个模块的核心流程是什么这个类有哪些外部依赖这段逻辑里有哪些边界条件如果迁移到新框架哪些部分风险最高它给你的回答不一定 100% 准确但能给你一张带猜测标记的地图。你可以拿着地图去看代码比自己从头摸索快得多。3.2 转换阶段LLM 是初步改写器这是大家最熟悉的部分让 LLM 把旧 API 调用改成新 API把旧语法改成新语法。要注意这个阶段 LLM 的输出只能当草稿不能当成品。因为 LLM 没有运行环境它不知道一个方法是否有副作用也不知道一个配置项在运行时是否真的被加载。正确的用法是让 LLM 批量完成“机械性大于判断性”的转换比如 Java EE 的javax.*到jakarta.*、Python 2 的print语句、Spring 的WebSecurityConfigurerAdapter废弃替换。这些转换规则清晰、重复性高LLM 做得又快又好。3.3 审查阶段LLM 是差异分析器代码改完了最大的问题是行为是否发生了变化传统方式靠 code review 测试。但测试覆盖不全的话很多差异会漏到线上。LLM 方式把迁移前后的代码对拍diff让 LLM 重点分析“行为差异”而不是“语法差异”。你可以这样提问这两个版本的代码在功能上有没有差异有没有哪个异常处理、边界条件、默认值发生了变化LLM 能识别出很多肉眼容易忽略的细节比如Integer.valueOf和parseInt的区别、getOrDefault和先get再判空的区别、异常被吞掉后逻辑走向的变化。3.4 验证阶段LLM 是测试生成器迁移最怕的是“没有回归测试”。但老项目往往测试覆盖极低不能指望重构前先补一套完整测试——这不现实。LLM 可以基于旧代码行为快速生成一批冒烟测试 特征测试把那些容易在迁移中出问题的逻辑先钉死。等代码迁移完成后跑一遍这套测试能挡住大部分低级回归。这四个阶段串联起来才能真正达到“LLM 缓解迁移疲劳”的效果。反过来如果只停留在“让 LLM 写转换代码”那迁移还是照样累——因为最累的理解和验证环节没有被解决。4. LLM 辅助迁移的典型工作流下面用一个贴近实战的工作流来说明从接到任务到迁移完成每一步 LLM 应该承担什么角色。假设场景一个老的 Spring Boot 2.x JDK 8 项目要迁移到 Spring Boot 3.x JDK 17。项目规模大概 200 个 Java 文件混杂着 XML 配置、JSP 页面、自定义 Starter。4.1 第一步摸清现状不要上来就让 LLM 改代码先让它做“项目体检”。你可以写一个脚本把项目里的关键信息汇总出来然后交给 LLM 分析。需要汇总的信息包括Java 文件列表、每个文件的代码行数所有 import 的第三方包所有javax.*的引用所有application.properties里的配置项自定义注解和反射调用的位置。# 1. 统计 javax 引用 grep -rl javax\. --include*.java . | wc -l # 2. 列出所有 import javax 的文件 grep -rh import javax\. --include*.java . | sort | uniq -c | sort -rn | head -30 # 3. 查看 Spring Boot 版本 grep -E spring-boot|spring-cloud pom.xml把这些命令的输出塞给 LLM让它帮你评估分析这个项目的迁移风险。哪些模块依赖 javax哪些依赖 Spring Boot 2.x 特有的 API哪些地方可能有反射调用需要手工确认LLM 的回答会给你一个迁移优先级建议而不是让你盲目地从第一个文件开始改。4.2 第二步确定批次200 个文件不能一次性迁移得拆批次。判断依据是依赖关系没有内部依赖的公共类、工具类先迁然后迁服务层最后迁入口和配置。这个批次计划可以让 LLM 帮你制定。你只需要把包结构贴给它让它按“依赖关系 风险等级”排序。4.3 第三步批次内迁移对每个批次内的文件用一套固定的提示词模板操作。推荐模板你是 Java 迁移专家。请将以下 Spring Boot 2.x 代码迁移到 Spring Boot 3.x。 要求 1. 替换 javax.* 为 jakarta.* 2. 替换已废弃的 Spring Security API 3. 保持业务逻辑变量名和注释不变 4. 如果遇到不确定的 API在代码注释中标记 TODO_MIGRATION_CHECK 5. 输出完整文件内容不要省略 原代码 [粘贴代码]这里的关键点是要求 LLM 不要自作主张重构逻辑。迁移和重构是两件事混在一起会让问题定位变得困难。4.4 第四步对拍审查迁移完成后运行git diff把 diff 结果发给 LLM请审查以下 diff重点检查1、行为和语义是否发生变化2、异常处理是否正确3、空指针风险是否增加4、是否有遗漏的 javax 引用。这一步能过滤掉很多低级错误。4.5 第五步测试生成对每个迁移完的 Service 类让 LLM 生成“迁移回归测试”基于以下 Service 的原始逻辑生成 JUnit 5 测试用例。测试应该覆盖正常路径、边界路径、异常路径。只用 Mockito不用真实数据库。这些测试拿到项目里跑能尽早暴露行为差异。整个流程里LLM 承担的是“增强理解、批量转换、辅助审查、生成测试”四个角色而人的精力应该集中在决策和判断上迁移顺序怎么安排、行为差异是否可接受、老逻辑是否要借机修改。5. 一个最小可复用的 LLM 辅助迁移示例为了让你能快速跑通这套流程我给你写一个最小示例。假设我们要把一个 Python 2 风格的脚本迁移到 Python 3。原始代码legacy.py# -*- coding: utf-8 -*- import urllib2 import ConfigParser class LegacyHandler(object): def __init__(self, config_path): self.config ConfigParser.ConfigParser() self.config.read(config_path) def fetch_data(self, url): req urllib2.Request(url) response urllib2.urlopen(req, timeout10) data response.read() return data def get_config(self, section, key): try: return self.config.get(section, key) except Exception, e: # Python 2 语法 return None第一步让 LLM 解释这个脚本的作用。请解释这个 Python 脚本的功能重点说明 1. ConfigParser 在这里承担什么职责 2. 这个类的异常处理有什么问题 3. 迁移到 Python 3 时哪些地方容易出错第二步让 LLM 生成迁移后的代码migrated.py# -*- coding: utf-8 -*- import urllib.request import urllib.error import configparser class LegacyHandler(object): def __init__(self, config_path): self.config configparser.ConfigParser() self.config.read(config_path) def fetch_data(self, url): req urllib.request.Request(url) try: response urllib.request.urlopen(req, timeout10) data response.read() return data except urllib.error.URLError as e: raise RuntimeError(Failed to fetch data from {}.format(url)) from e def get_config(self, section, key): try: return self.config.get(section, key) except (configparser.NoSectionError, configparser.NoOptionError) as e: return None第三步让 LLM 对比差异。对比 legacy.py 和 migrated.py列出所有行为差异。 特别注意异常处理的变化原来的 except Exception 在新代码里改成了什么这个修改是否有风险。第四步生成测试。为 migrated.py 的 LegacyHandler 生成 pytest 测试覆盖 1. 配置文件存在且 key 存在 2. 配置文件存在但 key 不存在 3. 配置文件不存在 4. fetch_data 成功和失败场景这个最小示例看起来简单但它的流程和 200 个文件的大型迁移完全一致先理解再转换再对比再测试。你把示例跑通了再放大到真实项目里就顺理成章。在项目里你一定会遇到的实际情况是迁移前后的行为差异不会在 diff 里自动标红但会让线上的某条数据链路突然异常。LLM 能帮你减少这类事件但没法替你根除——因为根除需要完整的行为验证体系那已经是另一个工程问题。6. LLM 辅助迁移的关键边界与风险控制LLM 不是银弹。在迁移项目里它有非常明确的边界。6.1 LLM 不能做什么第一不能做运行时验证。LLM 没有编译器和执行环境它不知道一段代码在真实 JVM / Python 解释器里会不会炸。第二不能做架构决策。微服务要不要改成模块化单体、数据库要不要换、缓存策略要不要调整这些必须由人基于业务判断。第三不能完全依赖它对隐藏语义的理解。老代码里经常有“这个字段虽然是 String但其实是序列化后的 JSON”“这个看似死代码的 if 分支其实在线上触发过 bug”。LLM 读不出来这些。6.2 LLM 输出幻觉的处理LLM 生成迁移代码时最常见的幻觉是使用了不存在的 API记错了方法签名把旧的依赖关系理解错生成错误 import为了“看起来合理”擅自加了一些逻辑。应对方法只有一条所有 LLM 生成的代码必须有编译和测试兜底。在 Java 项目里就是mvn compile必须通过在 Python 项目里就是pytest必须通过。通过的代码才进入人工 review 环节通不过的直接丢弃或修改。6.3 人工与 LLM 的分工我把这个分工总结成一句话LLM 负责理解辅助和转译人负责判断和决策。LLM 说“这个 API 在新版本里被替换成了 XX”——可以信但要自己核实。LLM 说“这段逻辑在迁移后行为一致”——不能信必须跑测试。LLM 说“建议重新设计这个模块”——听听就好架构决策自己拍板。7. LLM 辅助迁移的坑与排查思路下面整理了一些实际接入 LLM 做迁移时会遇到的问题按“现象-原因-排查-解决”给你一份参考表问题现象可能原因排查方式解决方案LLM 生成的代码编译不过使用了不存在的 API 或错误的 import查看编译错误信息检查 API 是否存在把错误信息重新喂给 LLM要求修正或人工修正后继续LLM 生成的代码通过编译但运行时报错对旧代码行为理解有误对比运行时日志和迁移前行为用测试用例锁定行为差异逐项修复LLM 在迁移时擅自重构代码提示词里没有明确限制检查 diff 中超出迁移范围的改动重新生成强调“只做迁移不做重构”LLM 生成的测试全部通过但线上仍出问题测试覆盖不足或 LLM 按照被迁移后代码“自我验证”用人肉 review 补充关键路径测试基于旧代码行为手写关键测试不让 LLM 自问自答大型项目一次喂给 LLM上下文不够一次性粘贴太多代码按模块拆分分批生成用“先列目录 → 再选关键文件 → 逐步深入”的策略LLM 对框架新版本理解滞后训练数据截止时间早于框架版本在提示词中补充官方迁移文档关键片段把官方迁移指南喂给 LLM 充当参考再让它生成代码迁移后隐藏的反射调用失败反射字符串没有被修改grep 检查旧包名/类名让 LLM 扫描所有反射调用相关字符串重点排查配置文件中仍引用旧配置项只迁移了 Java 代码没迁移配置检查 application.yml/properties 中的类名和包名用脚本统一替换配置中的旧包名并让 LLM 核对LLM 生成代码引入了新依赖为了让代码“好写”而擅自添加第三方库检查 pom.xml 或 requirements.txt 的 diff约束 LLM 不得添加新依赖除非用户明确要求迁移后性能下降API 调用方式和底层实现不同对比迁移前后的响应时间和 GC 日志对热点方法做针对性性能测试定位差异8. 工程落地建议与渐进式采纳路径看完前面的流程你大概想知道这个方案应该怎么在团队里落地我的建议是不要一开始就搞“全量 LLM 辅助迁移”先找一个 200 行左右的中等模块练手。8.1 推荐的渐进式路径第一阶段单人试用。找一个对 LLM 工具感兴趣的同事在一个小模块上跑完整流程记录耗时、准确率和踩坑点。第二阶段小团队试点。选一个低风险的服务做真实迁移要求所有 LLM 生成的代码必须经过人工 review 测试通过。第三阶段沉淀模板。把好用的提示词、流程文档、风险清单沉淀到团队 Wiki 里形成可复用的“迁移手册”。第四阶段规模化应用。把 LLM 辅助迁移融入日常升级流程例如每次技术栈升级都按“体检 → 分批 → 生成 → 审查 → 测试”的固定路径执行。8.2 几个直接可用的工程建议建议一给 LLM 一个“知识包”在开始迁移前把以下材料放进提示词上下文里官方迁移指南的要点项目现有依赖清单项目目录结构一条“禁止事项”清单。LLM 有了这些参考生成质量会显著提升。建议二使用统一的 TODO 标记要求 LLM 在无法确定的地方标注统一标记方便人工排查。// TODO_MIGRATION_CHECK: 请确认 Spring Security 6 中此写法是否仍然适用这样你可以用一行命令找出所有需要人工复核的位置grep -rn TODO_MIGRATION_CHECK --include*.java .建议三把代码库索引交给 LLM大型项目没法一次全量喂给 LLM。你可以先用工具把项目索引生成出来再用查询方式让 LLM “按需阅读”。# 生成项目文件清单 find . -name *.java file_list.txt # 统计每个文件的依赖关系简化版 grep -r ^import --include*.java . | awk -Fimport {print $2} | sort | uniq -c | sort -rn | head -50把这些输出给 LLM它就能对项目全貌有个基本认知。建议四重视“迁移说明书”的沉淀迁移过程中LLM 会发现很多有趣的细节比如“这个类里有个逻辑是专门兼容某个旧版本的 bug”。这类发现如果不记录下一个人接手还是要重新踩坑。建议在迁移文档中专门留一个“发现与决策”章节把 LLM 分析的结果、人工确认后的结论都写下来。这份文档的价值往往比迁移代码本身还高。9. 总结与后续学习方向迁移疲劳不是一个被广泛讨论的技术概念但它真实存在于每一个维护过老系统的人身上。LLM 没办法替你做架构决策也没办法替你承担线上风险但它确实能帮你把迁移过程中最耗神的“读代码、改语法、找差异、补测试”这四个环节压缩到原来的几分之一。回到开头那个判断LLM 对迁移带来的最大变化不是“自动化”而是“降低理解门槛”。在代码迁移这件事上真正决定成败的从来不是某个工具而是你是否能快速准确地理解旧系统的真实意图。LLM 恰好补上了这个短板。如果你接下来想深入实践可以考虑以下几个方向第一把本文提到的工作流做成一个团队的内部工具脚本把“体检 → 分批 → 转换 → 审查 → 测试”的流程固化下来减少对个人经验的依赖。第二研究一下开源社区的迁移工具与 LLM 的结合。比如 OpenRewrite 这类工具擅长规则化转换LLM 擅长语义理解两者结合往往比单用任何一方效果更好。第三在提示词工程上多花时间。迁移场景的提示词和通用编程场景完全不同你需要把你的约束写清楚把参考文档放进去把“不确定就标 TODO”这样的要求固化在模板里。迁移的脚步不会停。技术栈永远在迭代老系统永远存在但以后面对迁移时你至少可以不用一个人扛着所有疲劳往前走了。
