在编程语言迁移领域，过去企业往往谈之色变，因为这如同立下“军令状”，不仅工程师压力巨大，预算委员会也忧心忡忡，代码库却常常因各种顾虑而停滞不前。然而，Anthropic公司近期的一系列操作，彻底打破了这一局面。该公司内部开发者借助Claude Fable5、Opus4.8和动态工作流，在一个月内成功将10个规模达数万到数十万行的代码包迁移至新语言，让曾经遥不可及的设想成为现实。
Bun联合创始人Jarred Sumner和Anthropic Labs联合负责人Mike Krieger的案例尤为引人注目。Jarred利用Claude Code，在不到两周的时间里，将整个Bun从Zig迁移到Rust，产出百万行代码。合并进主干前，整条CI测试链100%通过，合并后虽出现19个回归问题，但已全部修复，Rust版本还随Claude Code发布。Mike则在一个周末，把一套Python代码库迁移为16.5万行Typescript，代码中包含数百个代理、8道阶段闸门和3轮对抗审查，最后通过奇偶校验，逐字比对每条命令的输出与Python原版。
Anthropic总结出“修流程而非代码”的理念，认为想通这一点，那些被搁置的迁移项目就不再是禁区。团队启动迁移，通常是因为项目诞生时的技术环境与当下已不匹配，可能是当初的权衡出现问题，可能是出现了更好的技术路径，也可能是原有生态萎缩。以Jarred为例，当初选择Zig，是看中其C级别的性能和极致的简单，适合在资源有限的情况下快速开发Bun。但随着Bun的发展，Zig的代价逐渐显现。
到了2026年，Bun的命令行工具月下载量突破一千万，在Claude Code内部也被大规模使用。然而，迁移语言虽能带来更小、更快、更安全的系统，但工程师们担心职业风险，因为可能要并行维护两套代码多年，最终只换来90%的等价，且迁移成本高昂。不过，如今情况已不同，最坏结果不过是删掉分支重来。当然，商业成本仍需考量，百万行级别的迁移虽不像以往那样耗费巨大，但仍需数万到数十万美元。Bun迁移消耗了59亿个未缓存的输入token和6.9亿个输出token，按API定价约合16.5万美元；Mike的迁移也消耗了2700万token。Mike下决心迁移，是因为编译问题，其团队内部工具用Python工具链编译耗时过长，迁移后编译时间大幅缩短，还淘汰了一条独立部署管线。
AI之所以能解决大规模代码迁移难题，是因为这一场景天然适合高级模型。代码迁移工作可并行进行，文件、crate等独立单元可让代理同时作业。旧代码为模型提供了清晰的上下文和完整的规格说明书，大型代码库的测试套件可作为代理自我评分的工具。队列可自动生成，编译器或测试出现问题时，下一个修复任务会自动排列。流程的严谨性让偏差无处藏身，审查员的发现会转化为待办项，代理遇到边缘情况时的修复方法会成为后续规则。
Anthropic从成功案例中总结出可复用的六步法。开工前需准备一个公正的裁判，即能同时评判原代码和目标代码的标准。原语言测试套件可能依赖目标代码不存在的内部函数，需对测试进行分类和改写，并通过验证确保裁判的有效性。第一步是立规矩、画依赖图、列缺口清单。规则手册的制定顺序有讲究，缺口清单由规则手册未覆盖的地方定义，两者需联合审计。规则手册的形式取决于核心架构决定，沿用结构时是翻译查表，彻底重做时是设计文档。依赖图可明确文件间依赖关系，缺口清单记录新旧语言的硬差距。第二步是进行迷你迁移试航，通过翻译少量文件提炼新规则，及时发现致命问题。这一步对结构保持型迁移有效，重设计时则用对抗审查员炮轰设计文档。
第三步是翻译一切，采用多代理循环，包括实现、审查、修复。小模型负责实现，大模型负责审查。任务队列根据文件状态分配任务，实现断点续跑。代理遇到难题时，通过指令提醒其下一步编译器会抓错。翻译器不确定的活儿标记留待后续处理。从这一步开始，待办清单自动生成，审查员意见相左时交由第三个代理处理，规则手册不断更新，代码不手动修改。编译器放置位置根据语言和规模决定。第四、五、六步共用同一套循环。第四步编译，可融入第三步，通过修复代理并行处理错误清单。第五步处理冒烟测试的崩溃，按根因归类修复。第六步逐项比对两套代码库行为，用测试套件检测失败并修复，构建守护进程负责重建二进制。Mike还让Claude设计端到端测试套件，自主运行修复问题。
Anthropic提醒，这份指南并非万能，每场迁移都有其独特性，应先与Claude制定具体方案再动手。关注规律而非单点失败，让审查保持对抗、验证保持机械，合理分配模型资源，将人的工时前置在规则手册和压力测试上，确保任务队列机械且可续跑。Jarred的Bun迁移已上线生产，新代码库有明显优势，内存泄漏得到修复，内存占用大幅降低，二进制体积缩小，在真实负载上速度也有提升。那些一直被容忍的代码库，或许到了重新评估迁移成本的时候。
