面试官不屑：“用 Claude Code 迁移百万行代码？少吹牛 *！” 我镇定：“让我入职，教你怎么做！”

大家好，我是程序员鱼皮。

前几天 Anthropic 官方发了 一篇博文，讲的是他们内部如何用 Claude Code 跑大规模代码迁移。

这篇文章的含金量非常高，因为里面的两个案例实在太炸裂了！

第一个案例，前端圈很火的工具 Bun 的创始人 Jarred Sumner（目前也是 Anthropic 的技术员工），用 Claude Code 把 Bun 从 Zig 语言重写到 Rust。整整 53 万行代码，只用 11 天就完成了，而且 100% 测试通过后合并上线。

第二个案例，Anthropic Labs 的联合负责人 Mike Krieger 只用了一个周末，把一个 Python 项目迁移成了 16.5 万行 TypeScript，全平台构建时间从 30 分钟降到了约 2 秒。

一个周末，重构 16.5 万行代码，什么概念？

以前这种量级的工程，再牛的团队也得干上一两年，还不一定能做到 100% 兼容。现在一个人加一个 AI，几天就搞定了。

大家肯定很好奇，他们是怎么做到的，这背后有什么方法和技巧吗？

下面我会结合官方博文的内容，加上 Bun 官方的技术博客、以及我自己使用 AI 编程的经验，给大家做一个完整的中文深度解读。

学会这套方法之后，几万行代码的项目重构、技术栈升级、老项目翻新，你都可以用同样的思路高效完成。

AI 迁移代码的核心思路

用 AI 迁移代码时，你的工作不是修改代码，是在设置「产出代码的流程」。

传统的代码迁移思路是一个文件一个文件地翻译，翻译完了逐个检查，发现问题逐个修复。

这种方式在几十个文件的规模还可行，但如果文件数量成百上千，基本就不可能了。

正确的思路是 把注意力放在流程上。

当你发现 AI 在某类翻译上反复犯同样的错，不要一个一个去修那些错误的代码，而是去修复规则手册，让所有后续翻译都不再犯这个错。随着规则越来越完善，你需要人工干预的次数会越来越少。

我刚开始用 AI 编程的时候，经常是一个个修复 Bug。AI 犯了一个错，我纠正一次，下次又犯同样的错，我再纠正一次。反反复复，非常低效。

后来我开始把踩过的坑写进 CLAUDE.md / AGENTS.md 或者 Rules 文件里，每次纠正 AI 的错误都顺手沉淀成规则。

随便举个例子，比如我发现 AI 生成 Spring Boot 接口时总是忘记加参数校验注解，我就加了一条规则：

所有 Controller 层的请求参数必须使用 @Valid + DTO 校验，禁止在 Service 层手动 if 判空

从此再也没出现过这个问题。

所以无论是百万行代码迁移，还是你平时 Vibe Coding 项目，都应该有这个意识：出了问题不要只盯着问题本身，要修复产出问题的源头。

六步迁移法

Anthropic 总结了一套完整的大规模代码迁移流程，总共六步。

开局一张图，你就知道这套方法论大概有多 NB 了。

六步迁移流程总览 0、搞定验证机制

在动手迁移之前，你必须有一个可靠的验证机制。没有验证机制，你都不知道什么时候可以收工。

最理想的情况是像 Bun 一样，已经有一套完整的测试套件，而且测试是用第三方语言写的（Bun 的测试用的是 TypeScript），不依赖被迁移的语言本身。

但如果你的测试跟源代码是同一种语言写的呢？

建议是先把测试分类。哪些测试是通过外部接口验证行为的？哪些是依赖内部实现细节的？

外部接口的测试可以直接复用，内部实现的测试需要重写成跟语言无关的形式。

开头提到的例子中，Mike 的项目没有现成的测试套件，他的做法是让 Claude 创建了一个 对比脚本，跑 7 个真实场景，把 Python 版本和 TypeScript 版本的输出做 diff，任何行为差异都算 Bug。

这个思路对小项目也完全适用。哪怕你只是把一个 Python 脚本迁移到 TypeScript，也可以让 AI 帮你准备几组真实的输入输出样本，迁移完了跑一遍，看看结果一不一样。

1、制定规则手册和依赖图

这一步是整个流程里人工投入最多的阶段。

Bun 创始人 Jarred 光是跟 Claude 讨论怎么把 Zig 的模式映射到 Rust 就花了 3 个小时，最终产出了一份 576 行的规则手册，里面详细规定了每种类型怎么映射、每种惯用法怎么转换。

规则手册的内容取决于一个关键策略：新代码是保持原有架构逐行翻译，还是完全重新设计？

Jarred 选择的是保持架构不变的机械翻译，所以他的规则手册主要是一个对照表。他还让 Claude 跑了一个工作流，分析代码库里每个 struct 字段的生命周期，输出成一个 LIFETIMES.tsv 文件给后续翻译参考。

而 Mike 选择的是重新设计架构，所以他的规则手册更像是一份设计文档，描述新系统应该长什么样。

除了规则手册，依赖图也很重要。你得知道哪些文件依赖哪些文件，这样才能决定迁移的顺序、哪些文件可以放在同一批处理。

对于像 Python 这种依赖关系不显式声明的语言，可以让 Claude 写一个脚本去分析和生成依赖图。Anthropic 还开源了一个 代码迁移工具包，里面就包含了现成的依赖分析脚本，拿来直接用就行。

此外，还要做一份「差异清单」，列出源语言和目标语言之间那些不能简单翻译的地方。

比如 Zig 到 Rust 的核心差异是手动内存管理变成了所有权系统，Python 到 TypeScript 的核心差异是动态类型变成了需要显式声明接口。这些差异点是 AI 最容易犯错的地方，必须在规则手册里重点标注。

2、小范围试跑

规则手册写好之后，不要急着全量执行，先拿 3 个文件试试水。

我觉得 Bun 创始人 Jarred 的做法很机智。他让一个 Claude 实例按照规则手册翻译 3 个文件，同时让另一个 Claude 实例以「高级 Rust 工程师」的身份翻译同样的 3 个文件。然后再开一个全新的 Claude 对话，专门用来对比两个版本的差异，从差异中提取新的翻译规则。

这一步他发现了 2 个关键问题，如果直接铺开到全部 1448 个文件，后果不堪设想。

对于重新设计架构的项目，做法不太一样。Mike 是让多个 Claude 实例从不同角度挑设计文档的毛病，看有没有逻辑漏洞或考虑不周的地方。然后跑一次完整的端到端翻译，看看设计在实际执行中有没有问题，发现了问题就改规则、重跑。

有趣的是，他实际上跑了三次完整迁移，前两次都丢弃产出，只保留对规则的改进，直到第三次才正式保留结果。

我看到这里，第一反应是：前两次直接丢弃，这不是浪费 Tokens 么？

但其实，对于复杂的项目来说，这么做是合理的。试跑阶段的目标就是打磨规则，试跑出来的代码未必正确可用，如果直接应用这些代码，搞不好会影响整个项目迁移。

这点对普通开发者也很有启发。很多人用 AI 做项目的时候，总想着一步到位。其实不妨先让 AI 做一个粗糙的版本，看看哪里不对，完善好提示词和规则之后再正式开始，磨刀不误砍柴工。

3、全量翻译

规则经过试跑验证之后，就可以全量执行了。

这一步的核心架构可以理解为一个流水线，分为 3 个角色：负责翻译的 Agent、负责找茬的 Agent、负责修复的 Agent。

每个翻译好的文件由 2 个独立的「找茬 Agent」来检查，它们的唯一任务就是挑毛病。发现问题后交给「修复 Agent」来处理。

三角色 Agent 流水线

这里的找茬 Agent 就是前面提到的「对抗性审查」。

为什么叫对抗性呢？

因为审查者被明确要求「假设这段代码是有 Bug 的，你的任务是找出 Bug 在哪」。

这种心态跟人做代码审查是一个道理，审查者不能先入为主觉得「他写的应该没问题吧」？而是要带着怀疑的态度去看，才能发现问题。

对抗性审查

听起来很简单，但是要注意几个实操细节。

1）工作队列要机械化。比如什么文件翻译了、什么文件没翻译，可以通过检查磁盘上有没有目标文件来判断。这样整个流程天然可恢复，中断了重启就行，不需要维护什么状态。

2）翻译 Agent 和审查 Agent 的对话必须隔离。写代码的 AI 总是倾向于认为自己的代码没问题，所以审查者必须在一个全新的独立对话里工作，只看翻译结果，不看翻译过程中的推理。

3）模型要分层使用，不需要所有步骤都用最强的。实现翻译这种高并发的工作可以用相对便宜的模型（比如 Claude Sonnet），而审查和规则制定用最强的模型（比如 Claude Fable、Claude Opus）。Mike 在全量翻译阶段就是用 12 个 Sonnet 子代理并行工作的。

翻译时如果有拿不准的地方，直接标上 // TODO(port): <原因>，不要在这一步纠结，后面编译器和测试会告诉你到底对不对。

4 ~ 6、编译 + 运行 + 对齐行为

接下来的 3 步套路都一样：先跑一遍得到错误列表，然后让一批修复 Agent 并行处理这些错误，修完了再跑一遍，循环往复直到没有错误为止。人工介入的程度越来越低。

错误驱动修复循环

1）编译阶段，把编译器报出的所有错误整理成一份待修复清单，然后让 AI 按照这份清单逐个修复。

Jarred 的做法是让编排脚本对整个工作区跑一次编译器，把错误按模块分组输出到文件，然后 64 个「修复 Agent」并行处理错误列表。每个修复 Agent 有 2 个对抗性审查者盯着。修复完再编译，反复循环。

这一步他遇到了一个大问题。

原来的 Zig 代码是一整坨放在一起编译的，他想把 Rust 代码拆成 100 个独立模块来加快编译速度，但这引入了大量循环依赖问题。

于是，他跑了一个专门的工作流来分类哪些代码该挪到哪里，修复循环依赖之后暴露出约 16000 个编译错误。16000 个错误对人来说是天文数字，但对 64 个并行的 Claude 来说，也就是几个小时的事。

2）冒烟测试阶段，把所有崩溃信息整理成待修复清单。

编译通过之后，先让各个子命令跑起来，把每个崩溃的报错信息和对应的子命令保存到文件，用同样的「修复 + 审查」循环处理。

3）行为对齐阶段，把所有失败的测试整理成待修复清单。

把测试套件分片跑，每个失败的测试交给一个修复 Agent，修复之后由对抗性审查者检查。

Jarred 还有一个巧妙的设计，只允许一个专门的构建守护进程来编译整个项目。修复 Agent 只提交代码，守护进程定期把所有补丁批量编译、跑受影响的测试、把结果反馈回去。这样避免了多个 Agent 各自触发编译导致的资源冲突和重复工作。

整个过程中，Bun 的 CI 从 972 个测试文件失败到全部通过，花了大约 4 天。Linux 最先变绿，Windows 是最后一个。合并之后一共出现了 19 个回归 Bug，全部已修复。

其实 Airbnb 之前也做过类似的事情。他们用 AI 把 3500 个 React 组件测试从 Enzyme 迁移到 React Testing Library，原本估计要一年半，最终 6 周就完成了，用的也是类似的方法。

我的感受

看完 Anthropic 这套六步迁移法，说几个我自己比较有感触的点。

首先是对抗性审查这件事，大家日常用 AI 编程时完全可以做。比如让一个 Agent 写完代码之后，开一个新的对话让另一个 Agent 做 code review。在 Claude Code 里面可以直接用内置的 /code-review 命令，或者用 Subagent 来做审查。哪怕不做代码迁移，这个习惯也值得养成。

然后是 AI 的成本问题。你敢信？Bun 的迁移花了 16.5 万美元的 API 费用！

这个数字乍一听很吓人，但对比 3 个高级工程师干一年的薪资加机会成本，便宜太多了。

对于个人开发者来说，一个几万行的项目迁移用 Pro 或者 Max 的订阅额度基本就够了。至于这个钱花的值不值，自己用人力成本算一笔账就好。

不过不要盲目跟风迁移。如果现有代码跑得好好的、也不难维护，就没必要折腾了。

迁移的前提是你确实有一个持续的痛点需要解决。

像我之前在 Claude Fable 5 限时可用的那几天里，疯狂优化自己的工作流，结果纯粹是为了优化而优化，也没什么效果，主要是之前 Opus 做的已经很好了。

还有很关键的一点，人的判断力仍然不可替代。

Jarred 在整个迁移过程中，每天都在监控工作流的输出、手动检查 AI 的行为、发现系统性问题后调整流程。

虽然 AI 执行力很强，但决策权还是在人这边。

AI 能节省成本，但不代表完全不需要人。

最后哔哔

最后帮大家总结一下本文提到的方法，你立刻就能用起来：

1）做任何稍大的重构或迁移之前，先跟 AI 聊出一份规则文档，把「什么该怎么改」定义清楚，别上来就动手。

2）先拿 3 个文件试跑一轮，看看 AI 会犯什么错。发现的问题不要逐个修代码，而是补到规则文档里，然后重新生成。

3）写代码的 AI 和审查代码的 AI 一定要分开。可以用 Claude Code 的 /code-review 命令，或者开一个新对话做独立审查。

4）善用「错误即清单」的思路。编译报错、测试失败、Lint 警告，这些都是天然的任务列表，让 AI 按清单逐个修复就好。

想想看，连几十万行、上百万行代码都能用 AI 完成迁移了，我们平时几千行、几万行的项目重构，还有什么不敢动的呢？

关键不在于 AI 有多聪明，现在模型的能力已经足够了，更多的要看你给 AI 设计的流程够不够好。

希望这篇文章能帮你建立起这个信心，学好如何驾驭 AI！

本文已收录到我免费开源的 ，上千张图、几十万字，带你从 0 开始快速学会 AI 编程，做出自己的产品、跑通变现全流程，一次拿捏。

开源指路：https://github.com/liyupi/ai-guide

我是鱼皮，持续分享 AI 编程干货。觉得有用的话记得点赞收藏和关注~

也欢迎在评论区聊聊：你现在最常用的是什么 AI 模型？用 AI 做过的最复杂的工作是什么？