花 12 万美元让 AI 重写 43 万行代码：微软那篇长文里最值钱的不是倍数

花 12 万美元让 AI 重写 43 万行代码微软那篇长文里最值钱的不是倍数TL;DR 速览规模43 万行 TypeScript → 80 万行 Rust跨135 个 release、14.5 周平均每天1.3 个迁移 PR成本token 约12 万美元 人工3 周官方对纯手工工作量的估计是「几年、几百万美元」收益单轮会话生命周期吞吐7.55/秒 → 120/秒同时挂 10 个客户端 agents 时内存1383MB → 126MB最难的一个文件session.ts3 万多行迁移花25 小时其中读文档 56 分钟、122 次工具调用澄清需求随后 spawn15 个子会话各带独立 worktree最有价值的一句官方原话——如果编译通过就等于正确那这话只能当个笑话用微软杰出工程师 Stephen Toub 发布的长文记录了 Copilot 运行时从 TypeScript 重写到 Rust 的全过程43 万行 TS 变成 80 万行 Rust跨135 个 release、14.5 周完成平均每天1.3 个迁移 PR。token 成本约12 万美元另外投入 3 周人工官方对纯手工完成同样工作的估计是「几年、几百万美元」。这段时间里跨模型分工也在用主力是 GPT-5.6 Sol 与 Claude Opus 4.8。这件事被大量转述成AI 编码能力的又一枚里程碑但长文里真正能复用的东西不是那些倍数而是验收环节被推翻的一个默认假设把编译通过当成迁移正确。这篇文章拆它的成本结构、收益口径以及那套验收方法。一、先拆成本12 万美元到底买了什么12 万美元这个数字最容易被误读成AI 干完活的价钱。实际结构是两块成本项量级说明token约12 万美元覆盖跨 135 个 release 的全部模型调用按当前主流编码模型定价折算人工3 周不是监工性质——是设计迁移顺序、审每一批 diff、定位回归纯手工对照「几年、几百万美元」官方给出的估计值与上两项做对比折算下来真正值得盯的是这三个比率每行成本12 万美元 / 43 万行 ≈0.28 美元/行。这个数只有当每行代码的语义复杂度可控时才成立。每 release 成本12 万 / 135 ≈890 美元/release。也就是说这批钱不是一次性押注是分 135 次小步支付的。人工与模型的比例模型跑 14.5 周人工只跟 3 周。人工被压缩到了设计 验收两个环节中间的执行几乎全自动化。这里有一条容易被忽略的前提本次迁移只做逐模块替换没有重构结构。TS 里是什么形状Rust 里就是什么形状。这个约束把任务从重新设计降级成等价翻译才有了 0.28 美元/行这个量级。一旦允许顺手重构成本立刻不可控——因为等价这个判据消失了。二、session.ts那 25 小时AI 是怎么被喂饱需求的长文里最硬的一段是单个文件session.ts3 万多行的迁移过程。它值得逐步看清因为流程暴露了一个反直觉的事实最贵的不是写代码是澄清需求。阶段耗时 / 动作关键点读文档56 分钟迁移前先把模块间约定读进去不是直接改代码提问澄清122 次工具调用用工具调用去验证假设不是问人实际改写剩下一大半时间分组作业每组独立并行拆分spawn15 个子会话每个子会话带自己的worktree彼此可通信122 次工具调用这个数字最值得琢磨。它说明模型不是读一遍代码就动手而是把这个函数在别处怎么被调用“这个类型有没有等价物”这个边界条件在测试里怎么覆盖逐条查证。工具调用次数在这里等价于需求澄清轮次——它花的是 token省的是返工。15 个子会话各带 worktree 的设计也值得抄。3 万行的文件不可能一个会话从头改到尾但简单拆成 15 个会话会互相踩。给每个子会话一份独立的 git worktree等于给每个执行体一个私有工作区冲突推迟到合并时才暴露——把写时的冲突换成合并时的冲突后者可回滚、可仲裁前者只能靠人盯。这条经验可以直接搬到自己的项目上要迁移一个大文件先问这个文件能不能按职责切成 5–15 段、每段有没有独立的调用方如果答案是切不开那它就不适合交给并行迁移。三、收益侧两个数字但含金量不同指标迁移前迁移后口径单轮会话生命周期吞吐7.55 /秒120 /秒约15.9×10 个客户端 agents 的内存占用1383 MB126 MB约91% 降幅这两个数字的性质完全不一样别混着用吞吐那 15.9 倍主要来自语言与运行时特性的重写——Rust 没有 JS 的 GC 停顿和事件循环争抢单机并发上去了。内存那 91%真正的原因是架构改了全程进程内不再拉后台子进程。也就是说这部分收益不是Rust 比 TS 省内存而是顺手把进程模型改了。把这两件事归到换语言名下下次照做会失望。这也是评估任何AI 重写项目的通用判据收益里有多少来自语言有多少来自顺手改掉的架构前者可预期后者是意外收获不能写进预算。我评估迁移收益时有个固定习惯把语言带来的和顺手改架构带来的分成两栏记因为后者不可复现——换个技术负责人架构未必会一起改。我的分栏模板和判断清单攒在 墨衍 里跟选题素材放一起下次做迁移预算直接调出来对。四、验收账编译通过为什么不能等于正确这是全文最该被记住的部分。迁移过程中出现了数十个回归官方给出的总结是那句广为流传的话——如果编译通过就等于正确那这话只能当个笑话用。编译器检查不了的东西恰好是这类迁移最容易出错的地方函数调用顺序类型全对、编译全过但两个函数的调用先后错了行为就变了。并发假设TS 里靠事件循环隐式串行的部分搬到 Rust 里如果换成真线程编译不报错但共享状态不再安全。错误传播路径异常改Result之后出错时谁来兜这条链路肉眼看不出来。单次任务成本可不可接受这个最容易被跳过——功能对、性能对但每次调用的成本模型变了。所以一套能用的迁移验收至少要有三层编译——只当入场券不当结论。行为对照——同一批输入跑新旧两版逐项比对输出。这也是为什么先有测试再迁移是硬前提。顺序与并发假设清单——把谁必须先于谁哪些状态原本靠单线程隐式保护逐条写下来人工过一遍编译器不会替你做。对照案例把这条讲得更清楚。同期 Bun 把53.5 万行 Zig 移植到 Rusttoken 花销16.5 万美元通过现有测试的比例是99.8%——看起来比 43 万行那批更漂亮。但 Zig 作者仍然称其结果是「没人审过的垃圾」。99.8% 通过意味着 0.2% 没通过而那 0.2% 里藏的是什么只有人去看了才知道。这两个案例合起来给出的结论是一致的AI 能把翻译这一步的边际成本压到接近零但不能把确认翻译正确这一步也压下去。五、什么规模的重构适合交给 AI把上面的账综合成一张可操作的判据表判据适合交给 AI不适合目标形状等价翻译一进一出顺手重构边迁边重新设计语义可判据有能跑的测试集或输出可逐项比对只有看起来对模块边界能按职责切成 5–15 个独立段高度耦合、切不开失败代价可回滚、可回退到旧实现不可逆或涉及数据迁移验收预算留出人工审 diff 的时间本例是 3 周打算编译过了就发最该注意的取舍是逐模块替换 vs 顺手重构。前者牺牲的是代码质量Rust 里写的还是 TS 的结构换来的是可控性后者看着更划算但会让等价这个验证判据失效回归无处可查。本次选择的路线是先等价、后优化把结构优化留到下一步单独做——这是一个非常克制、也非常工程化的取舍。六、这件事真正的边界三个容易被忽略的限制第一12 万美元是一次性的但维护不是。80 万行 Rust 之后要有人读、有人改。代码产出速度提升之后承接它的团队容量会成为新的瓶颈——这也是为什么原文强调了那 3 周人工投入。第二AI 写的代码在组织里有隐性成本。审 diff 的人需要能看懂 Rust 而不是只懂 TS否则人工审是假的。第三这套方法高度依赖任务可翻译这个前提。TS→Rust 有类型系统互相对应是最理想的一类迁移换成老 Java 单体拆微服务这种语义与架构同时变化的任务同一套流程的成本会成倍上浮。所以把这件事读成AI 能替代工程师和读成AI 只是又一个编译期工具都是误读。它准确的定位是把大工程的执行边际成本压到接近零同时把风险全部前移到了定义什么叫正确和验收这两个环节。这两个环节上的能力才是团队真正需要提前备好的东西。而准备的第一步是先承认编译器不会替你判断函数顺序对不对。