Anthropic 在 2026 年 7 月 16 日公开了一件事：他们自己在用 Claude Code 做大规模代码迁移，而且真的跑通了。
两个案例摆在那里：Bun 的联合创始人 Jarred Sumner 用 Claude Code 把 96 万行 Zig 改成了 Rust，历时 11 天，合并前 CI 里 Bun 的全套测试全绿。Mike Krieger（Anthropic Labs 的联合负责人）用一个周末把一个 Python 代码库改写成了 16.5 万行 TypeScript，过程中跑了数百个 agent、八道阶段门、三轮对抗性审查，最后用逐命令 diff 做了完整的行为一致性验证。
这篇文章把 Anthropic 总结出来的六步方法论梳理一遍，以及背后一个核心理念：不是去修代码，而是去修产生代码的流程。
为什么大规模迁移过去那么难
传统的代码迁移几乎都是人肉的。工程师要读懂几十万行的历史代码，理解语言之间细微的语义差别，保证重构后行为等价——这些事同时做，精力很快就到了极限。
AI 改变的不是"理解代码"这件事有多难，而是改变了谁在做这件事：不再是一个工程师面对几十万行代码发愁，而是几百个并行运行的 agent，每个只处理一块，同时进行。
但并行不是免费的。并行多了，出错的机会也多了，出错了还难以追踪。Bun 的迁移消耗了 59 亿个未缓存的输入 token 和 6.9 亿个输出 token，按 API 定价大约是 16.5 万美元。这个数字听起来大，但用来替代一个需要若干工程师花数月时间完成的人肉迁移，也有另一种算法。
关键在于：规模越大，前期的结构化准备就越重要。乱打一通 agent 不会出好结果，需要一套可复用的流程。
六步方法论
第一步：建 Rulebook（翻译规则手册）
Rulebook 是整套方法论的起点。在开始任何代码翻译之前，先要明确源语言的模式和目标语言里对应的写法。
Rulebook 的具体形态取决于迁移策略：
- 结构保留型迁移（比如 Python → TypeScript）：Rulebook 主要是类型映射表、惯用法对照，以及指向"难翻译点清单（Gap Inventory）“的指针
- 结构重设计型迁移（比如 Zig → Rust）：Rulebook 需要更多架构层面的决策，包括哪些模式在目标语言里没有对应物、应该怎么重设计
一个重要的顺序约束：Rulebook 要先于 Gap Inventory 存在，因为 Gap Inventory 的定义本身依赖 Rulebook 的默认规则——不知道"规则是什么”，就不知道哪些地方是规则的例外。
第二步：建 Gap Inventory（难点清单）
Gap Inventory 列出的是 Rulebook 默认规则无法覆盖的那些地方——需要人工判断或额外处理的代码区域。
比如：
- 某个库在目标语言里没有直接对应的包
- 某段代码依赖源语言特有的内存模型或并发原语
- 某个接口的行为语义在两种语言里有细微差异
Gap Inventory 不是一次性的，它在迁移过程中会随着发现新问题而不断更新。建立 Gap Inventory 的过程，本质上也是在让 Claude Code 对整个代码库做一次预扫描。
第三步：建依赖图（Dependency Map）
代码之间有依赖关系，如果 A 依赖 B，就不能在 B 还没迁移的情况下去迁移 A。
Claude Code 可以部署 agent 去运行确定性的脚本，产出一张依赖图。这张图有两个用途：
- 确定迁移顺序：从叶子节点开始，逐步向上
- 划分并行工作流：哪些模块之间没有依赖关系，可以并行推进
Bun 的迁移能在 11 天内完成，依赖图是关键——它让数百个 agent 能够安全地并行运行而不互相踩脚。
第四步：联合压力测试（Joint Audit）
在开始大规模翻译之前，先用 Rulebook 和 Gap Inventory 对一小块有代表性的代码做翻译，看两份文档能不能配合产出正确的结果。
这一步发现的问题，比在大规模翻译之后再发现，处理成本要低几个数量级。Anthropic 的经验是：好的联合压力测试会让 Rulebook 变得更厚、Gap Inventory 变得更精确。
第五步：阶段门 + 对抗性审查
Mike Krieger 的 Python → TypeScript 迁移里有八道阶段门（Phase Gate）和三轮对抗性审查（Adversarial Review）。这两件事的逻辑是一样的：在翻译出的代码大规模堆积之前，先拦住问题。
阶段门：每完成一个阶段，必须满足预定的通过标准（测试通过率、lint 通过、特定类型的错误数量）才能进入下一阶段。
对抗性审查：专门设一个 agent，目标不是翻译代码，而是尽力找翻译出来的代码的问题。这个 agent 和做翻译的 agent 是对立的——让模型扮演怀疑者，比让它自我审查要有效得多。
第六步：行为一致性验证（Parity Check）
迁移完成后，要验证新代码和旧代码的行为是否等价。Mike Krieger 的迁移里用的方法是：对每一个命令，把新版和旧版的输出 diff 一遍。
这个步骤在传统迁移里往往是最难的——测试覆盖不够、行为规格不清楚、边界情况多。Claude Code 可以帮助生成更全面的测试矩阵，以及自动运行对比。
Bun 的验证标准更直接：CI 里 Bun 的全套现有测试，必须全绿。这个条件在合并前就达到了。
一个核心理念
Anthropic 在文章里反复强调的一句话值得单独拿出来：
你不是在修代码。你是在修产生代码的那个流程（循环）。
这句话的意思是：当翻译结果出问题的时候，第一反应不应该是"让 Claude 重写这段代码"，而应该是"Rulebook 里是不是缺了一条规则？““Gap Inventory 是不是漏掉了这种模式？““阶段门的标准是不是设得太低了？”
把问题往上游推，修好流程，让流程重新产生正确的代码——这是 AI agent 在大规模任务里能发挥最大价值的方式。
局限与争议
值得一提的是：Bun 的迁移本身也引发了一定的争议。Zig 的创始人 Andrew Kelley 把这次 AI 驱动的改写称为"unreviewed slop”（未经审查的垃圾），认为 AI 生成的代码大量堆积而没有经过真正的人工审查，是一种质量风险。
这个争议本身揭示了一个真实的张力：AI agent 能快速产出大量代码，但人类审查者能理解和负责的代码量并没有同步增长。GitHub 工程博客同期发了一篇文章《The Cost of Saying Yes Has Changed》，讲的也是同一个问题：写代码的成本降了，但拥有代码的成本没有降。
大规模 AI 迁移是一个强大的工具，但它把"验证和所有权"的问题放大了，而不是消除了。
原文：How Anthropic runs large-scale code migrations with Claude Code，发布于 Claude by Anthropic 官方博客，2026 年 7 月 16 日。
关于
关注我获取更多资讯
