# 用 Claude Code 重构百万行代码？官方教程终于来了！
**作者**: 程序员鱼皮
**日期**: 2026-07-21T05:23:59.000Z
**来源**: [https://x.com/yupi996/status/2079437208633954420](https://x.com/yupi996/status/2079437208633954420)
---
大家好，我是程序员鱼皮。
前几天 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 就是前面提到的「对抗性审查」。
为什么叫对抗性呢？
因为审查者被明确要求「假设这段代码是有 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！
本文已收录到我免费开源的 《AI 编程零基础入门教程》，上千张图、几十万字，带你从 0 开始快速学会 AI 编程，做出自己的产品、跑通变现全流程，一次拿捏。
> 开源指路：https://github.com/liyupi/ai-guide
我是鱼皮，持续分享 AI 编程干货。觉得有用的话记得点赞收藏和关注~
也欢迎在评论区聊聊：你现在最常用的是什么 AI 模型？用 AI 做过的最复杂的工作是什么？
## 相关链接
- [程序员鱼皮](https://x.com/yupi996)
- [@yupi996](https://x.com/yupi996)
- [611](https://x.com/yupi996/status/2079437208633954420/analytics)
- [一篇博文](https://claude.com/blog/ai-code-migration)
- [代码迁移工具包](https://github.com/anthropics/code-migration-kit-with-claude-code)
- [《AI 编程零基础入门教程》](https://ai.codefather.cn/vibe)
- [https://github.com/liyupi/ai-guide](https://github.com/liyupi/ai-guide)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [1:23 PM · Jul 21, 2026](https://x.com/yupi996/status/2079437208633954420)
- [611 Views](https://x.com/yupi996/status/2079437208633954420/analytics)
---
*导出时间: 2026/7/21 14:24:37*