百万行代码，两周搞定！Anthropic揭秘AI代码迁移六步法：秘诀不是改代码，是改流程
内容提要
Anthropic工程师使用Claude Code在一个月内迁移了10个代码包，包括将Bun的百万行Zig代码迁移到Rust（两周完成，内存占用降低91%）以及将Python迁移到TypeScript（一个周末完成16.5万行）。核心方法论是“修流程而非代码”，通过六步迁移法：规则手册、压力测试、全量翻译、编译、运行、行为对齐，并配合对抗式审查和机械化验证，显著降低了迁移成本和时间。
延伸解读
成本账本已变：迁移不再是“生死攸关”的决定
过去，百万行代码的语言迁移动辄需要数百万美元和数年时间，团队往往因风险过高而搁置。如今，Anthropic的案例显示，Bun迁移消耗约59亿输入token和6.9亿输出token，按API定价约16.5万美元，Mike的迁移仅2700万token。成本大幅下降，使得迁移的触发条件从“生死攸关”变为“长期内存bug或性能瓶颈”。但商业理由仍需成立，成本虽低，仍需数万至数十万美元投入。
核心方法论：修流程而非修代码
Anthropic强调，AI代码迁移的本质不是让模型逐文件翻译，而是工程师构建迁移规则和验证循环，让智能体在循环中不断翻译、编译、测试，直到行为对齐。六步法包括规则手册、压力测试、全量翻译、编译、运行、行为对齐。关键原则包括：让审查对抗化、验证机械化、任务队列机械化且可断点续跑，以及把人力前置到规则手册和压力测试阶段。
没有现成测试套件？让AI自己造一个裁判
迁移前必须有一套能公平评判新旧代码的裁判系统。如果原语言测试套件依赖内部函数，需先分类、重写为可移植断言，并验证裁判本身能抓“坏代码”。Mike在Python到TypeScript迁移中，没有现成测试套件，便让Claude写脚本用7个真实场景对比新旧版本，还让Claude自主设计端到端测试套件，连续四晚自动运行修复，抓到了场景清单无法预见的细节问题。
模型分工与token优化：小模型干活，大模型审查
大规模迁移中，token消耗集中在循环里，需有意识设计。实现类工作可交给较小模型（如Mike用Claude Sonnet铺开12个子智能体），审查类工作留给更大模型（如Fable和Opus 4.8）。对抗式审查者独立评估实现成果，意见不一致时由第三个智能体裁决。当审查者反复抓到同类错误时，不是逐文件修补，而是修改规则手册并重新生成受影响文件，避免手动打补丁。
Q&A
Anthropic的工程师如何在一个月内迁移10个代码包？
Anthropic的工程师使用Claude Code（包括Claude Fable 5和Claude Opus 4.8）以及动态工作流，在一个月内迁移了10个代码包，规模从数万行到数十万行不等。他们采用了一套六步迁移法，并配合对抗式审查和机械化验证，显著降低了迁移成本和时间。
Bun项目从Zig迁移到Rust的具体成果是什么？
Bun项目从Zig迁移到Rust，在不到两周内完成，合并前原有测试套件100%通过CI。迁移后内存占用从6745MB降至609MB，暴降91%；二进制体积减小19%；性能提升2%至5%。
Mike Krieger如何在一个周末将Python代码库迁移为16.5万行TypeScript？
Mike Krieger动用了数百个智能体、8个阶段关卡、3轮对抗式审查，并最后进行一致性核查，将Python代码库迁移为16.5万行TypeScript，只花了一个周末。
Anthropic的六步迁移法具体是哪六步？
六步迁移法包括：1. 规则手册、依赖地图、差距清单；2. 压力测试规则；3. 全量翻译；4. 编译；5. 运行；6. 行为对齐。
为什么AI特别适合大规模代码迁移？
AI特别适合大规模代码迁移的原因有：工作本身是并行的，可以拆分到成千上万个独立单元；上下文清晰完整，旧代码是需求文档；有天然的裁判，测试套件可以验证；任务队列会自己生成；具备一致性和边界情况处理能力。
在开始迁移之前，如何构建一个有效的裁判系统？
构建裁判系统需要：给现有测试分类，识别哪些测试可以外部调用；为可移植性重写测试，使它们能同时跑在原代码和迁移后代码上；验证裁判本身，确保它能抓住坏代码。
在代码迁移过程中，如何有效管理token消耗？
token消耗集中在循环中，因此要有意识地设计：较小的模型足以胜任大批量的实现工作，把最强的模型留给审查者以及制定规则的关键节点。例如，Mike在主体迁移阶段用Claude Sonnet铺开12个子智能体，而审查工作交给更大的模型。
代码迁移后，Bun项目在内存和性能上有哪些改进？
Bun项目迁移后，内存占用从6745MB降至609MB，暴降91%；二进制体积减小19%；性能提升2%至5%，覆盖HTTP服务和next build、tsc等真实工作负载。
