How Anthropic Runs Large-Scale Code Migrations with Claude Code（Anthropic 如何用 Claude Code 做大规模代码迁移）

代码迁移（把生产代码库转换到新语言）已从「多年、百万美元级」的项目变成「数周可完成」的工作。核心洞察是：

「你要修的不是代码，而是产出代码的那个流程（循环）。」

两个真实案例

Bun 迁移（Zig → Rust）

• 规模： 一百万行代码，不到两周
• 质量： 合并前 100% 通过既有测试套件；合并后出现 19 个回归，均已修复
• 消耗： 59 亿输入 token、6.9 亿输出 token，约 $165,000
• 收益： Linux/Windows 二进制体积减少 19%；基准测试中内存占用从 6,745 MB 降到 609 MB；性能提升 2-5%
• 已在生产部署；代码中约 4% 是 unsafe 块（多为 C/C++ 边界的指针操作）

内部 Python → TypeScript 项目

• 规模： 16.5 万行，一个周末
• 配置： 12 个子 Agent、8 道阶段闸门、3 轮对抗式审查
• 收益： 编译时间从约 30 分钟降到每平台约 2 秒；二进制启动快 6 倍；退役了一条独立的部署流水线

六步迁移架构

第 1 步：打地基（三条并行工作流）

• 规则手册（Rulebook）： 记录两种语言间的翻译政策——惯用法、类型、架构决策
• 依赖图（Dependency Map）： 用脚本识别文件关系，据此切分可并行的工作流
• 缺口清单（Gap Inventory）： 编目那些需要重构而非直译的架构差异（如 Rust 的所有权模型 vs Zig 的手动分配）

第 2 步：压力测试

在代表性样本上用不同翻译方式跑小规模迁移。Bun 的作者在这一阶段抓出了两个影响 1,448 个文件的关键问题。产出全部丢弃，只保留精化后的规则。

第 3 步：并行翻译

• 跨批次部署实现者 Agent，高并发工作用较小模型（Sonnet）
• 未解决的项用 // TODO(port): 注释标记
• 用双重对抗式审查者；分歧升级给仲裁者
• 发现模式时更新规则手册，而不是逐个修文件

第 4-6 步：编译 → 冒烟测试 → 行为对齐

• 编译： 全工作区跑编译器，并行修错并配对抗式审查
• 冒烟测试： 自动化测试找崩溃，按根因分组做系统性修复
• 行为对齐： 对新旧两套代码库跑完整测试套件；用构建守护进程串行化昂贵的重建操作
• 没有测试套件时的替代方案： 建对等性测试台（parity harness）对比真实场景，或让 Claude 自主设计并通宵运行端到端测试

为什么 AI 改变了迁移的经济账

• 工作天然可并行： 数千个独立文件单元支持并发执行
• 规格明确： 原代码库本身就是参考规格
• 验证客观： 测试套件提供无需人工仲裁的基准真值
• 工作队列自动生成： 编译错误和测试失败自动填充待办队列
• 模式可检测： 系统性问题在审查循环中浮现，防止悄然偏移

六条关键实践

1. 把人力前置到规则手册和压力测试上；后续阶段基本是「烧队列」
2. 关注失败的模式而非单个失败——人的注意力应该放在模式上
3. 设计 token 高效的循环： 最大的模型留给审查者和写规则，实现工作用小模型
4. 让工作队列机械化： 「完成」= 输出文件存在；迁移在构造上就是可恢复的
5. 坚持对抗式审查——长任务中它值那个 token 成本
6. 别照搬本文： 每次迁移都不同，先和 Claude 一起做针对性规划

结论

语言迁移不再需要「关乎存亡」的理由来立项——长期存在的瓶颈或维护负担现在就足以证明投资合理。通过把迁移围绕系统性验证循环（而非人工代码审查）来组织，并策略性地搭配不同档位的模型，历史上需要「多年工程」的项目可以压缩到几周，迁移的算术从根本上变了。