百万行代码两周迁完，账单是 16.5 万美元

一百万行代码，两周，16.5 万美元。

这三个数字凑在一起，出自 Anthropic 昨天发的一篇官方博客。Bun 的联合创始人 Jarred Sumner，现在人在 Anthropic，用 Claude Code 把 Bun 整个从 Zig 迁到了 Rust。不到两周产出一百万行代码，合并前现有测试套件在 CI 里全绿，Rust 版 6 月就随 Claude Code 上线了，你现在用的 Claude Code 里面就跑着它。

好家伙，百万行，两周。这个量级放在两年前，是那种要开誓师大会、立四年军令状的项目。

朋友圈里传的版本基本到这就结束了，两周，百万行，AI 牛逼。但我把原文从头到尾读完，发现真正值钱的部分根本不在标题里。标题是给围观群众看的，正文里藏着的那几个数字和几条前提，才是给真想干这事的团队看的。

我平时的工作就是给大模型搭让它真正能干活的那层工程，agent 的工具链、评测、调度这些，天天看模型在生产环境里怎么跑、怎么翻车。所以读这种文章的时候，我的眼睛会自动跳过「多快多好」，直奔「花了多少、坏了几次、凭什么成」。

今天就带你把这笔账摊开算算。

先把账摊开

第一个数字，钱。

Bun 这次迁移烧掉了 59 亿未缓存输入 token，6.9 亿输出 token，按 API 定价折算约 16.5 万美元。人民币一百二十万左右。

你的第一反应可能是，好贵。我的第一反应是，好便宜。

因为原文给了参照系。这种百万行级的语言迁移，以前的行情是 300 到 400 万美元的工程资源，工期四年。现在是 16.5 万美元，两周。钱缩到二十分之一，时间缩到百分之一。

而且以前那种迁移还有一个没法写进预算表的成本，工程师的职业风险。并行维护两套代码库好几个季度甚至几年，最后如果只做到 90% 对等，你的处境比没开始还惨。多少重构项目就是这么烂尾的，新版永远差最后 10%，旧版永远删不掉，团队里最资深的几个人被钉在两边来回缝。

现在最坏的情况变成了什么？删掉分支，重来一次。

这句话在原文里很轻描淡写，但我觉得它比「两周百万行」更重磅。它改的不是迁移的速度，是迁移这件事的风险结构。失败从「烂尾两年」降级成「浪费一个分支」，立项的心理门槛完全是另一回事了。

原文里另一个例子更接地气。Anthropic Labs 的负责人 Mike Krieger，就是当年 Instagram 那位联合创始人，用一个周末把一个 Python 代码库迁成了 16.5 万行 TypeScript。动机特别朴素，他团队的内部工具要打成单一二进制发布，Python 工具链下每个平台编译 8 分钟，一次发版全平台等 30 分钟。迁完之后，编译 2 秒。

8 分钟到 2 秒。就为这个，一个周末，值了。

所以原文有句话我很认同，迁移的理由不再需要「生死存亡」级别。changelog 里攒了一年的内存 bug 补丁，或者一个每天恶心你一次的慢性瓶颈，现在就够立项了。

19 个回归，和一个没人细说的前提

第二个数字，19。

合并前测试 100% 通过，合并后依然浮出了 19 个回归，后来全修掉了。原文没有藏这个数字，就大大方方写在第二段。

我跟你说，这个数字比 100% 那个数字诚实多了，也有用多了。它告诉你测试套件的覆盖边界之外永远有东西，AI 迁移不豁免这条定律。百万行的手工迁移合并后只冒 19 个回归，你敢信？大概率冒的是 190 个。但它不是零，你的发布计划里得给这 19 个留出位置。

还有个小注脚，新代码库里约 4% 的 Rust 代码在 unsafe 块里，多是 C/C++ 边界上的单行指针操作。迁移不是魔法，该付的代价换了个形式还在。

但真正容易被忽略的是那个前提。

Bun 的测试套件，本来就是用 TypeScript 写的。

这事看着是个冷知识，其实是整个故事的地基。测试和被测代码不同语言，所以 Zig 版能跑这套测试，Rust 版也能跑同一套，天生就有一个对两边一视同仁的裁判。AI 可以对着这个裁判没日没夜地磨，磨到全绿为止，不需要人类坐在旁边当质检。

你的项目多半没这个条件。你的测试大概率和业务代码同一门语言，还依赖一堆内部函数，旧代码一迁移，测试自己先碎了。

原文对这种情况给的方案是 Mike 的路子。他的 Python 项目就没有现成裁判，于是让 Claude 写了个小脚本，挑 7 个真实使用场景，对新旧两版各跑一遍，diff 输出，任何行为差异都算 bug。每个失败场景配一个专属修复 agent，循环到 7 个全过。

再往后一步更有意思。Claude 自己设计了一套端到端测试，连续 4 个晚上自主通宵跑，坏了就修，修完再跑，抓出一堆任何场景清单都预测不到的细碎问题。

所以没有测试套件不是拦路石，裁判继承不到就现造一个，反正旧代码库就是标准答案。但注意原文里造裁判的纪律，造完要先拿原代码验证它能通过，再拿故意改坏的代码验证它会失败。抓不住坏代码的裁判不是裁判，是橡皮图章。

你修的不是代码，是产出代码的那个循环

原文把方法论浓缩成一句话，你不修代码，你修产出这些代码的流程。

这句话我反复读了几遍。怎么说呢，它跟我日常工作里体感最强的一条经验完全对上了，带 agent 干活，盯单个产出是最没效率的姿势，要盯的是那条生产线。

具体到迁移，生产线长这样。

先跟 Claude 一起写一本翻译规则手册，把两门语言之间的类型对照、惯用法、歧义点政策全部沉淀成文字。然后做一次小规模试航，Jarred 的做法有点子牛逼，一个 agent 按规则手册翻译 3 个文件，另一个 agent 抛开手册「像资深 Rust 工程师那样」翻译同样 3 个文件，第三个 agent 对比两版 diff，从分歧里提炼新规则。

就这一步，他抓到了 2 个致命问题。当时全量是 1448 个文件，这俩问题要是直接扇出出去，后面就是 1448 份灾难。

试航完了，翻译出来的文件全部扔掉。

对，扔掉。这一步的产出是规则，不是进度。舍不得扔试航产物的人，后面会为此加倍还债。Mike 更狠，他是整条流水线端到端跑完，看结果改规则，再从头重跑，前两轮的全部产出都扔了，第三轮才收货。

全量翻译阶段的分工也值得抄。实现类的活扇出给小模型，Mike 扇出 12 个子 agent 用的是 Claude Sonnet，审查留给大模型。token 的钱要花在刀刃上，而刀刃是审查者，以及任何产出「会被其他 agent 遵循的规则」的环节。

审查本身是对抗式的，两个审查 agent 在互相隔离的上下文里独立评估，意见打架就交给第三个仲裁。当审查者在一堆文件里反复抓到同一类错，正确动作不是挨个改文件，是往规则手册里加一句话，然后重新生成受影响的整批。规则手册在整个过程中一直在长大，代码永远不做违背手册的手工补丁。

还有一个我特别喜欢的细节，工作队列必须是机械的。什么算完成？翻译后的文件存在于磁盘上，就算完成。批处理脚本每次从磁盘重建队列，所以整个迁移天生可以断点续跑，中间断电、断网、断预算，回来接着跑就是。

连编译器放哪都是一个被认真做过的决策。Mike 把 TypeScript 编译器放进每个循环里，因为 tsc 检查一个单元只要几秒。Jarred 把编译器彻底赶出循环，攒到后面统一跑，因为 cargo 一跑就是几分钟，放循环里 agent 全在排队等编译。同一个问题，两个相反的答案，都对，因为约束不同。

到收尾阶段，测试失败清单成了自动写自己的待办列表，修复 agent 并行烧，一个叫 build daemon 的进程独占重建二进制的权力，攒一批补丁重建一次，把最贵的操作串行化。人在这个阶段干嘛？看模式。单个失败是循环自己的事，人的注意力只留给「同一类错在反复出现」这种信号，因为那说明规则错了，而规则错了要改上游。

什么能交给 AI，什么会翻车

拆到这，可以回答标题外的那个问题了。这套东西对不在 Anthropic 上班的普通团队，到底哪些能用？

我自己的感受是，先看四个条件。

你的迁移工作能不能拆成几千个互相独立的小单元，文件、模块、crate，拆得开才有并行，拆不开 agent 就在互相等。旧代码是不是新代码的完整 spec，语言迁移天然满足这条，但如果你想「顺便重新设计一下架构」，spec 就没了，难度直接换档，那是 Mike 那条路，规则手册变成设计文档，试航变成对设计文档的对抗式攻击，人力投入完全不同。有没有一个机械的裁判，测试套件、编译器、diff 脚本都行，验证必须客观到不需要人类在旁边拍板，这是四条里最硬的一条。最后，有没有人愿意在前期投入真正的人类工时，规则手册和试航是全流程里最吃人时间的部分，这部分省了，后面的队列烧的全是垃圾。

反过来，翻车的姿势也基本能预测。没有裁判就开跑的，会得到一百万行没人敢合并的代码。验证靠人眼 review 的，人会先崩溃。指望 AI 迁移「顺便」把技术债也还了的，两个目标互相打架，一个都达不成。还有把 16.5 万美元当成天花板的，那是 Bun 的账单，你的代码库越缠绕、裁判越弱，token 就烧得越多，预算得自己试航完再估。

顺手贴一下工具，Anthropic 把整套流程泛化成了一个迁移 starter kit，规则手册模板、依赖图 prompt、试航 prompt 都在里面。注意他们自己标注了，这是泛化模板，不是 Bun 那次实际用的。另有一个偏框架升级场景的代码现代化插件，以及支撑这些多 agent 编排的 dynamic workflows。想看一手细节的直接读 Jarred 的博客，比官方博客更多血泪。

最后

说实话，读完我想起的是忒修斯之船，木板一块块换掉，船还是那条船吗。Bun 用两周把一百万行木板全换了，测试说是同一条船，19 个回归说换的过程里还是掉了几颗钉子。

但真正的变化不在船上，在船坞里。以前换船要四年和四百万美元，所以大家宁可开着漏水的船继续跑。现在换船要两周和一次试航的耐心，于是「要不要换」第一次变成了一道可以坐下来认真算的数学题，而不是一个用来吓退提案人的天文数字。

新代码库的收益是实打实的，某个 2000 次重复构建的基准测试，内存占用从 6745 MB 降到 609 MB，二进制小了 19%，真实负载快了 2 到 5 个百分点，能检测到的内存泄漏清零。

你团队里那个提了三年、每次都被「等不忙了再说」挡回去的迁移，或者那个 changelog 里攒了一年补丁的老模块，也许值得重新拿出来算算账了。

反正现在，算错的代价也就是删个分支。