“Migration fatigue”迁移疲劳。这个词听起来像管理咨询报告里的术语但经历过一次系统迁移的研发应该都认得它。它不是加班后的疲惫不是项目验收前的焦虑而是你面对一个老系统明知道新方案更合理却要在一堆旧接口、旧表结构和历史数据里反复确认“这里为什么这么写”然后被这种无休止的解释和判断耗干。LLM 被讨论最多的是它能不能写代码但我更想聊一个更实际的问题它有没有可能改变迁移这种最磨人的工作。我的判断是能但前提是你不要把它当成自动化迁移机器而要把它当成一个能降低“不确定性”的辅助层。1. 迁移疲劳不是工作量问题而是“不确定性问题”1.1 迁移时真正消耗人的是大量低价值判断普通开发任务通常是创造性的需求清楚边界相对明确你写代码、调试、联调最后交付。迁移不一样。迁移更像“考古加翻译加重写”的三重叠加。你面对一个已经运行了很久的旧系统首先要搞清楚旧代码为什么这么写其次是设计新版本怎么写最后还要证明新老行为是一致的。最累的就是最后这一步。很多旧系统的文档早就过时字段名含义依赖于“老员工口头解释”有些甚至存在“没人知道为什么存在但删掉就会出问题”的历史逻辑。你需要在极短的时间里对几十个、上百个这样的问题做判断。这种判断本身并不难难的是数量太多而且每一条都需要找到依据。连续几周每天处理“这个字段要不要保留”“这个接口到底是同步还是异步”“这条 SQL 里的隐式类型转换是不是历史包袱”这类问题大脑会持续处于高负荷状态。这时候你会发现你并不是被某一次巨大的技术难题击垮的而是被大量琐碎、重复、需要反复确认的小问题磨到失去耐心。迁移疲劳的本质就是这种“持续判断”带来的认知透支。1.2 为什么单点效率提升救不了迁移疲劳很多人会直觉地想既然 LLM 能写代码那迁移是不是可以交给它自动完成听起来很合理但如果你只是让 LLM 把旧代码“翻译”成新代码生成结果之后你仍然需要理解、审核、测试、回归。生成速度越快需要审查的候选物反而越多。迁移疲劳的核心不是“代码生成慢”而是“不知道哪里会出问题”。在这个状态下真正有效的做法是用 LLM 把不确定性拆散先解释旧逻辑再标出差异再生成初稿最后用测试用例验证。每一步都让做决策的人掌握更充分的信息而不是在黑暗中猜。所以这篇文章的主线是LLM 不能替你完成迁移但它可以显著降低“做判断所需的成本”。迁移疲劳不会消失但可以变成可控、可排期、可复盘的大任务。2. LLM 在迁移流程里到底能做什么2.1 现状普查让 LLM 当旧系统的“讲解员”迁移动手前你首先要回答一个问题旧系统里到底有什么最笨的办法是逐个文件读代码读不懂就去问老员工。更高效的办法是拿一段旧代码问 LLM“这段逻辑做了什么有哪些依赖返回什么有哪些特殊边界。”它会给你一份解释虽然不是百分之百准确但足够帮你快速建立理解框架。比如你可以输入这是旧系统里的一个用户查询接口。请解释它的职责、入参出参、异常路径和外部依赖。并列出迁移前需要确认的问题清单。LLM 会输出一段结构化的解释包括你没想到过的历史兼容逻辑、配置项和调用方假设。你不需要完全相信它但你可以把这份解释当成一份“预读材料”然后回到代码里逐条核实。这一步真正解决的问题是以前新人对老系统的理解完全依赖“老人讲”现在可以先让 LLM 做一次快速预演再去问专家更有针对性的问题。2.2 差异分析快速生成不同层级的行为对照迁移中另一个高频动作是“对照”旧接口和新接口的字段怎么对应返回结构有什么差异异常处理是否一致。你可以把新旧两边的接口定义一起交给 LLM让它输出字段映射表。更好的做法是要求它把映射关系分成几类请把新旧接口的字段映射关系分为四类 1. 直接对应 2. 改名对应 3. 拆分或合并 4. 需要人工确认 并对每一类给出理由。这种输出比你自己对着文档逐行看要快得多。差异表最怕遗漏而 LLM 在“列出候选差异”这件事上有天然优势。但你要记住它只是给出候选真正决定“这个字段是否真的语义一致”的仍然是熟悉业务的人。2.3 转换与生成把 LLM 输出当“初稿”不是“成品”很多人喜欢让 LLM 直接生成最终的 adapter、DTO 映射或 SQL 脚本。我不是反对这样用而是提醒一句生成结果只能当初稿。原因是 LLM 的生成依据是你喂给它的上下文而旧系统里真正影响线上行为的历史逻辑经常不在代码片段里。它可能来自配置文件、消息队列、定时任务甚至来自一个你从未注意过的数据库视图。初稿的价值在于减少“空白页焦虑”。你不需要从零写起但也绝不能复制粘贴就上线。2.4 测试与回归让 LLM 帮忙构造验证清单迁移前后最怕的就是“不知道测什么”。没有 LLM 时测试样例经常依赖老员工的经验漏一个边界可能就是线上事故。LLM 可以用来生成测试清单根据新旧接口的差异生成 15 个测试用例。包括正常输入、空值、非法格式、超长参数、用户不存在、手机号脱敏等情况。对每个用例给出旧系统预期行为和新系统预期行为。它不一定能列出所有业务独有的边界但它能覆盖常见的、容易遗漏的边界条件。这一步能显著缓解迁移过程中“心里没底”的焦虑。3. 一个可落地的示例迁移一个老接口的完整操作流3.1 第一步准备一份“最小迁移样本”不要一上来就把整个服务丢给 LLM先挑一个独立、可验证的小接口。这里用一个常见示例来说明流程。假设旧系统有这样一个接口// 旧接口示例结构 public UserProfile getUserProfile(String userId) { // 返回用户基本信息、部门编码、手机号掩码等 }新系统变成了// 新接口示例结构 public QueryUserResult queryUser(QueryUserRequest request) { // 需要设置 includeProfile、includeDepartment 等布尔参数 }这一步的重点不是功能复杂而是边界清楚你有明确的旧接口定义、新接口定义、调用方式和返回结构。有了这些你才能验证 LLM 的输出是否准确。注意这里只是示例结构不是具体某个 SDK 的完整代码。落地前必须确认目标语言版本和依赖。3.2 第二步让 LLM 解释旧接口建立问题清单直接把旧接口片段交给 LLM然后附上一段提示请解释 getUserProfile 这个接口的内部行为。输出 1. 它返回哪些字段 2. 哪些字段可能为 null 或有特殊格式 3. 调用方通常如何处理返回值 4. 你发现了哪些需要确认的历史兼容逻辑。你会得到一份解释。接下来要做的是回到代码里核实。如果 LLM 说“手机号字段可能已经做过脱敏”你需要去看脱敏逻辑到底在哪里、是接口内部做还是调用方做。这一步能帮你建立自己的问题清单。问题清单是迁移最宝贵的中间产物它会成为后续所有工作的锚点。3.3 第三步生成新旧差异表和迁移初稿把新旧接口定义一起交给 LLM要求请输出新旧接口字段映射表把映射关系分成直接对应、改名对应、拆分对应、缺失、需要人工确认。 然后基于该表生成一个 Adapter 的 Java 代码初稿保持旧接口的入参和返回结构不变。LLM 会产出一张差异表以及一段看起来像模像样的 adapter 代码。你的任务有两件把差异表中“需要人工确认”的行提取出来去找业务负责人或老系统代码确认。把 adapter 初稿里的边界处理补上空值判断、异常透传、字段缺失时的默认值。3.4 第四步用测试样例和人工检查点收口最后让 LLM 生成测试用例并人工设置检查点。一个典型的检查点清单可以包括空值行为是否一致userId 为空时旧系统返回什么新系统返回什么。敏感字段格式是否一致手机号掩码位数、身份证脱敏规则。异常类型是否一致用户不存在时是返回空对象、返回 null还是抛出异常日志和 traceId 是否保留旧系统是否依赖日志做问题排查。隐式转换是否被显式处理比如数据库中的字符串数字在新接口里是否需要强转。这些检查点就是迁移的“验收标准”。它们不应该拍脑袋定而应该来自差异表里被标记为“需要人工确认”的部分。4. 只靠 Prompt 不够要为 LLM 建立“验证闭环”4.1 四层检查输入、转换、行为、回归把 LLM 接入迁移流程最重要的一步不是调 prompt而是建立一套验证闭环。我建议至少做四层检查检查层检查内容常用方法输入检查LLM 是否拿到了真实、完整的旧接口定义和依赖人工核对代码片段、配置项转换检查差异表是否覆盖所有字段有没有误映射逐字段审阅差异表行为一致性新代码是否保留旧代码边界行为代码走查、异常路径梳理回归测试新旧系统在相同输入下输出是否一致测试环境跑样例、对比结果这四层不是可选项而是迁移流程的基本盘。4.2 如何设计 Prompt让 LLM 减少胡思乱想Prompt 设计能直接影响输出质量但这不是玄学是有规律可循的。尽量提供“被迁移代码片段”而不是只提供“描述性需求”。要求输出“理由加结论”。比如“请解释为什么你认为这两个字段对应”。指定“不要修改什么”。比如“不要改变异常类型”“不要移除日志”。给出少量输出样例当你想让它按表格输出时先给一个期望格式。限制任务边界。不要让它写完整迁移方案而是让它只完成其中一个小步骤。允许它回答“信息不足”。你可以在 prompt 里明确写“如果缺少必要信息请列出需要补充的问题清单”。一个好的 prompt 不是“让 LLM 更聪明”而是“让 LLM 知道自己不知道什么”。4.3 最容易翻车的几个失败模式即使你做好了验证闭环LLM 在迁移任务里仍然有几种典型翻车方式。第一是相似映射陷阱。两个字段名字很像但语义完全不同。旧系统里的createTime可能是订单创建时间新系统里的createTime可能是记录创建时间不能直接对应。第二是理想化重写。LLM 在不知道历史原因时会默认把看起来“冗余”的逻辑清掉而这些逻辑可能正是线上依赖的兼容逻辑。第三是忽略外部契约。新接口可能要求先申请 token或者返回结构自带分页包装LLM 生成的 adapter 里不一定包含。第四是边界条件缺失。null、空字符串、超长数字、并发请求、时区、编码这些都是 LLM 在“看起来正常”的代码里容易漏掉的部分。第五是过度自信。模型会输出一个完整但未经验证的方案而且语气非常确定容易让人放松警惕。理解这些失败模式不是为了否定 LLM而是为了知道哪里需要人工兜底。4.4 排查链路LLM 结果不对劲时按什么顺序查当迁移结果不理想不要先怀疑“LLM 不行”按这个顺序排查先看输入你给的旧代码和目标接口定义是否完整关键配置有没有带上。再看上下文有没有把真正影响行为的历史逻辑写进提示。再看输出约束是否要求 LLM 区分“推测”和“确定”。再看人工检查差异表里“需要人工确认”的字段有没有被认真处理。最后看回归测试生成的代码能否编译能否在测试环境跑通行为是否一致。如果都做对了还是不对再考虑这个任务本身是否不适合用 LLM 生成完整方案。提示很多时候问题不出在 LLM而出在上下文准备、任务拆解和结果验证上。5. 从“一次帮忙”到“团队迁移工作流”5.1 把常用提示沉淀成模板和脚本一个人会写 prompt解决不了团队的问题。真正能让迁移流程变轻松的是把提示模板沉淀下来。你可以在项目仓库里新建一个migration-prompts/目录把“解释旧代码”“生成差异表”“生成适配层”“生成测试样例”等提示写成 markdown 文件。每个模板都标注清楚输入需要什么。输出格式是什么。使用者需要检查什么。这样团队里其他人也能复用而不是只有一个人会写提示。5.2 把代码库切成合适上下文或做检索增强LLM 能接受的上下文有限而且代码库越大越容易遗漏。常见的做法是先让 LLM 生成文件依赖清单再按依赖关系切片把与迁移目标相关的代码抽出来。如果团队有检索增强能力可以把代码索引起来让 LLM 只参考相关函数和配置。这一步的意义在于避免 LLM 在“不知道某个配置项来自哪里”时强行推断从而降低幻觉概率。5.3 哪些迁移适合 LLM哪些不应该用并不是所有迁移都适合用 LLM。这里有一个粗略的判断表适合的迁移场景原因人工仍需承担的工作语言或框架升级的局部代码模式相对标准编译、测试、行为核对旧 API 换新 API参数结构可对比差异表审查、上游兼容性验证DTO、VO 字段更新重复度高、边界清晰名称对照、敏感字段脱敏规则SQL 或存储过程改写语法差异相对明确数据量、索引、事务行为验证生成测试用例不直接改动生产逻辑样本筛选、期望值核对不适合直接用 LLM 的场景原因高安全、强审计系统需要严格的痕迹和审批管理旧代码完全无法理解输入本身不可靠输出也没法验证业务规则无法从代码中推测LLM 只能猜容易错得离谱迁移结果必须精确到每一步操作需要精确控制和审计不依赖概率生成5.4 团队角色变化以前迁移往往依赖极少数懂老系统的人他们是瓶颈也是最容易疲劳的人。有了 LLM 辅助之后新成员可以更快产出一版解释和差异表再由专家审核。专家的时间从“解释旧逻辑”“写转换层”转向“验收”“定策略”。这个变化才是缓解迁移疲劳的长期力量它没有去掉专家而是让专家不用再做大量重复的解释和初稿工作。6. 迁移疲劳不会消失但可以降维成可控流程6.1 先小范围试点不要把整个迁移一次交给 LLM迁移疲劳不是靠一次“大工程”解决的恰恰相反越大的迁移越容易疲劳。所以更建议先选一个边界清楚、风险可控的单接口或单表跑一遍“讲解、差异分析、生成初稿、测试验证”的完整流程。成功之后再逐步扩大范围。这既是对 LLM 能力的验证也是团队工作方式的磨合。6.2 把迁移中产生的知识版本化迁移过程会产生大量有价值的中间产物差异表、测试样例、问题清单、adapter 初稿。不要只放在聊天记录里应该放进代码仓库。这样即使迁移中断几个月之后有人接手也能从这些资产里快速恢复上下文。迁移疲劳很多时候来自“前一拨人离开后一拨人又要重新考古”版本化能缓解这种断裂。6.3 下一个值得关注的方向迁移生产线一个成熟的迁移流程应该是可以重复的导入代码、讲解、差异分析、生成初稿、测试样例、人工验收、回归。当这套流程被固化LLM 就不再是一个聊天工具而是团队内部的“迁移生产力”。迁移疲劳不会彻底消失但它会从“拖垮整个团队的慢性病”变成“可预期、可排期、可复盘的一个大任务”。对个体开发者来说最重要的不是掌握最新模型而是掌握“如何把 LLM 输出变成可靠工程结果”的方法。如果下一次你所在的团队又要迁移不要把问题定义成“怎么让 LLM 把代码全部改写”。先找一个还没人解释清楚的老接口让 LLM 讲给你听再回到代码里核实。你可能会发现最消耗人的不是迁移本身而是“每一步都要在信息不足的情况下做判断”。LLM 不能替你做判断但它能让这些判断有据可依。迁移疲劳不会凭空消失但只要你把解释、对照、生成、验证串成一套闭环它就会从“压倒性的风暴”变成一个可以按清单推进的工程。这大概才是 LLM 在迁移这件事上真正的长期价值。