Bun 1.4 11天重写100万行代码、烧掉16.5万美元Token：当AI批量迁移代码库，Java工程师怎么守住审查关

2026年9月初，Bun 1.4正式发布。GitHub合并记录显示，这次更新把大量底层代码从Zig重写成Rust，一次提交达到+1,009,257行、-4,024行，累计6,778次提交。更令人震惊的是，核心开发者Jarred Sumner没有亲手敲出这100万行——他先搭了一套Agent工作框架，让多个Agent并行推进，11天主体重构完成，全程烧掉约16.5万美元Token。InfluxDB创始人Paul Dix看后发文《The end of programming》，称传统编程正在终结。当AI开始批量改写整个代码库，Java工程师最该担心什么？

一、100万行代码事件：AI开始批量改代码库

Bun是一个JavaScript运行时，以性能著称。1.4版本最大的变化不是新功能，而是底层代码的大规模语言迁移：从Zig转到Rust。

GitHub上的合并记录触目惊心：+1,009,257行新增代码，-4,024行删除代码，6,778次提交。这个数字放在任何项目里都堪称巨兽。更惊人的是，主导者Jarred Sumner后来在复盘中说，这100万行不是几百个程序员一点点敲出来的。

他搭了一套Agent工作框架，定义好「应该怎么迁移、什么结果算正确」，然后把多个Agent并行放进去推进。第一版出来后没有结束，而是让Agent继续跑、继续测、继续修，几个月后才跟着Bun 1.4正式发布，跑在数百万开发者的电脑上。

全程Token烧掉约16.5万美元。这不是小成本实验，而是一次工业化级别的AI代码生产。

二、为什么Bun能成：迁移任务有明确验证标准

很多人第一反应是：这不就是把Zig翻译成Rust吗？翻译确实不稀奇，稀奇的是把100万行代码一路修到稳定发布。

Bun这次迁移有几个前提条件，让AI特别适合参与。第一，目标明确：把Zig代码改成Rust代码，输入和输出的语义基本一致。第二，验证标准清晰：原来的测试用例、性能基准、兼容性测试都可以直接复用。第三，边界相对封闭：底层运行时有自己的抽象层，不需要理解千变万化的业务逻辑。

换句话说，Bun给AI的是一个「有明确答案的重复工程问题」。Agent可以大胆尝试，因为每次尝试都有测试告诉它对不对。错了就修，修完再测，循环往复。

Paul Dix在《The end of programming》里说的不是AI会取代程序员，而是传统的「一个人写代码、另一个人逐行Review」的模式已经走不通了。当AI一周能交几十个PR，人类根本看不过来。新的工作方式是：写Prompt、搭Harness、做测试、设验证条件，然后把Agent放进去循环。代码让机器自己产，人盯结果。

三、Java代码库迁移的特殊难点

Bun的成功让很多人兴奋：那我的Java项目是不是也能让AI批量重构？现实要复杂得多。

Java企业级代码库有几个特点，让AI迁移远没有Bun那么顺手。第一是业务逻辑密集。Bun迁移的是底层运行时，语义映射相对固定；而Java业务代码里充斥着领域模型、业务规则、状态机，很多逻辑只有熟悉业务的人才能判断等价性。

第二是依赖生态复杂。一个Spring Boot项目可能依赖几百个Maven/Gradle包，版本冲突、传递依赖、兼容性断点层出不穷。AI改了代码，编译可能过了，运行时某个依赖行为变了，bug会在生产环境才暴露。

第三是隐性约定多。Java项目里常常有约定俗成的设计模式：Service层怎么分、事务边界怎么划、异常怎么转、日志怎么打。这些约定很多没有写在文档里，而是存在于老工程师的脑子里。AI看不懂这些，生成的代码容易「形似神不似」。

一位在某城商行做了8年Java开发的老张说：「我们核心系统有200多万行Java代码，让我用AI整体迁移？我宁可用AI辅助我一点点迁。不是不信AI，是不信它懂我们那些历史包袱。」

四、审查关：人看不过来的代码怎么办

Bun事件暴露的最大问题，不是AI能不能写代码，而是人怎么审查AI写的代码。

100万行代码，如果靠人工逐行Review，按一个人一天能认真看1000行算，需要1000人天，约4个人年。这在实际项目中不可能发生。Bun的做法是用测试和验证回路代替人工逐行审查：Agent生成代码，测试套件验证正确性，性能基准验证效率，长期运行验证稳定性。

但测试只能验证「已知问题」，不能发现「未知问题」。AI生成的代码可能通过了所有测试，但引入了新的架构债务、安全漏洞或可维护性问题。这些问题的代价不会立刻显现，而是在未来几倍、十几倍地还回来。

对企业Java团队来说，更现实的策略是「分区分级」：对工具类、样板类、迁移类代码，可以大胆交给AI；对核心业务逻辑、资金相关、安全敏感模块，必须保留人工深度审查。同时，建立可复现的验证 harness，让AI每次改动都有明确的通过标准。

五、飞算JavaAI的代码语义索引：让AI先看懂再动手

飞算JavaAI解决的核心问题，正是「让AI先看懂Java代码，再动手改」。

全量代码语义索引把项目的分层架构、依赖关系、注解使用、接口契约都结构化地建立起来。AI不是把代码当纯文本处理，而是知道Controller负责接收请求、Service负责业务逻辑、Mapper负责数据访问、@Transactional控制事务边界。

这种理解能力是批量改动的前提。比如要把一个单体模块拆成微服务，AI需要先知道哪些类被哪些模块引用、哪些接口是内部调用、哪些是外部暴露、哪些数据需要同步迁移。没有语义索引，AI只能盲目拆分，拆完一堆编译错误。

智能路由模式进一步保证经济可行性：简单迁移任务走轻量模型，复杂架构重构上Java专属专家模式，日均Token消耗从850万降到260万，降幅69.4%。

Bun 1.4证明了一件事：AI已经能处理超大规模的代码迁移。但Bun的成功经验不能简单复制到Java企业项目。Java团队需要的不是「能写100万行代码的AI」，而是「看得懂200万行历史包袱、改完能过审、上线不翻车」的AI。飞算JavaAI想做的，是后者。