前几天 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 能节省成本但不代表完全不需要人。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】