11天、16.5万美元、100万行AI代码——Bun重写事件暴露的，不是语言之争，是信任危机

AI资讯

11天、16.5万美元、100万行AI代码——Bun重写事件暴露的，不是语言之争，是信任危机

11天。16.5万美元的API费用。50万行Zig代码被重写为100万行Rust。

Bun创始人Jarred Sumner公布这个数字时，科技圈的反应几乎是统一的震惊——AI终于能重写一个大型生产项目了，而且只用了不到两周。

但紧接着，Zig创始人Andrew Kelley的万字长文让事情变得复杂。他直指Jarred的工程习惯是"黑客式补丁摞补丁"，Bun的代码库让Zig团队感到"极其恐惧"，而用AI重写只是把烂代码从一种语言翻译成了另一种。

技术圈迅速分裂成两个阵营：一方认为这是AI编程的里程碑，另一方认为这是工程责任的灾难。但双方都在回避真正的问题——不是Zig好还是Rust好，不是AI能不能写代码，而是：当AI写的代码量超过人类审查能力时，软件工程的信任模型应该怎么重建？

一、拆解叙事：双方都在回避真正的问题

先看Jarred的叙事。他在Bun官方博客中描绘了一个清晰的因果链：Bun用Zig写的代码存在大量内存安全问题（use-after-free、double-free、内存泄漏）→ Zig语言本身不提供内存安全保障，只能靠编码规范 → 团队已经在用ASAN、fuzzing等手段，但bug仍然层出不穷 → Rust的借用检查器能从编译器层面解决这些问题 → 用Claude Fable 5在11天内完成重写。

这个叙事逻辑自洽，而且有数据支撑——Bun v1.3.14的bug修复列表确实触目惊心。Jarred甚至坦承"我厌倦了带着对崩溃的担忧入睡"。这是一个被技术债务折磨到极限的创始人做出的理性决策。

但Andrew Kelley的回应揭开了另一层真相。

他指出，Zig社区早就对Bun的代码质量感到"越来越恐惧"。问题不在于Zig语言——其他Zig项目并没有Bun这么多bug——而在于Jarred的工程习惯：为了快速上线新功能，几乎从不花时间消除bug和技术债。"Jarred在AI出现之前就已经在写垃圾代码了。"

Kelley还抛出了一个尖锐的反问：Bun声称测试套件足够完备，所以100万行未经人工审查的AI代码是安全的——那为什么同样的测试套件没能抓住Zig版本的那些bug？

这个反问直击要害。如果测试覆盖率真的足够，Zig版本的bug就不该存在。如果测试覆盖率不够，凭什么相信它能兜住AI生成的100万行代码？

Jarred的回应策略也很聪明——他把问题从"管理失败"转移到了"语言缺陷"。一个创始人的工程习惯问题，被包装成了Zig vs Rust的技术选型问题。这让人想起那句老话：当手里只有锤子的时候，看什么都像钉子。而当你的锤子是AI时，看什么都像需要重写的代码。

二、建框架：软件工程的"信任三角"正在瓦解

传统软件工程有一个隐形的信任三角：

开发者写代码 → 编译器检查 → 测试验证 → 代码审查 → 上线

在这个链条中，最关键的一环是"代码审查"。它不是发现所有bug——事实上，代码审查的bug发现率远低于测试——它的核心作用是建立理解。团队中至少有一个人（通常是资深工程师）通读了每一行代码，理解了它的逻辑，判断了它的正确性。这个人对代码负责。

AI时代，这个链条变成了：

AI写代码 → 编译器检查 → 测试验证 → 上线

代码审查被跳过了。不是"省略了"，是"不可能执行了"。100万行代码，11天写完，意味着每天近10万行的产出。即使一个团队有10个资深工程师，每人每天审查1万行代码，也是不可能完成的任务——而且这还是理想情况，现实中没人能连续11天每天审查1万行代码还能保持判断力。

信任从"人类审查"转移到了"测试覆盖率"。但测试本身也是人写的，而且测试的质量取决于人对代码逻辑的理解——这正是被跳过的环节。

这就是Bun事件暴露的核心矛盾：AI将代码生产的边际成本压到了接近零，但"理解代码"的成本并没有降低。

更准确地说，AI降低了"写"的成本，但"读"的成本——理解、审查、维护、排错——反而因为代码量的暴增而上升了。这是一个不对称的成本转移。

三、推演：框架的跨场景验证

这个"信任三角瓦解"的框架，能解释近期多个看似不相关的事件。

场景一：开源社区的"AI slop"危机。Andrew Kelley在博文中提到，Anthropic收购Bun后，Zig社区涌入大量"AI爱好者"，他们用LLM生成代码提交PR，被拒绝后还在论坛里抱怨。这不是Bun独有的问题。GitHub上已经有大量项目在讨论如何应对AI生成的垃圾PR——这些PR看起来格式规范、注释完整，但逻辑是错的。审查者需要花更多时间去判断代码是否正确，因为AI生成的代码"看起来太像真的了"。

场景二：Claude Code的Dynamic Workflows。Anthropic把Bun重写作为Dynamic Workflows的标杆案例宣传。但仔细看Bun的实践：他们用的是"机械翻译"策略——把Zig代码逐行翻译成Rust，而不是重新设计架构。这意味着新代码库保留了原Zig版本的所有架构缺陷，只是换了一种语言。新代码中残留的2.7万行unsafe Rust代码就是证据——这些是AI无法自动安全化的部分，需要人类工程师逐行审查。但谁去审查？

场景三：测试的"自我指涉"困境。Bun的测试套件是用TypeScript写的，不依赖运行时语言。这听起来很聪明——测试可以跨语言复用。但Kelley的反问依然有效：如果测试真的够好，为什么Zig版本的bug没被抓住？答案是：测试覆盖的是"已知行为"，而内存安全问题往往出现在"未知路径"。AI生成的代码可能通过了所有现有测试，但引入了新的、测试未覆盖的bug路径。测试套件只能证明"没有已知问题"，不能证明"没有问题"。

四、落到行动：三组人各自该做什么

如果你是技术决策者：停止问"AI能不能帮我重写这个项目"，开始问"重写之后谁来维护"。Bun的案例证明AI重写在技术上是可行的，但可行性不等于可持续性。在决定用AI重写之前，先回答三个问题：1）新代码的架构和旧代码一致吗？2）团队有能力审查AI生成的每一行关键代码吗？3）如果AI生成的代码出了问题，谁负责修？

如果你是开发者："读代码"的能力正在变得比"写代码"更重要。AI可以帮你写，但AI不能帮你理解——至少目前不能。花时间训练自己阅读和审查AI生成代码的能力，这可能是未来几年最有价值的技能投资。学会问"这段代码为什么这么写"而不是"这段代码能不能跑"。

如果你是工具厂商：测试基础设施是AI时代的护城河。Bun之所以敢用AI重写，核心前提是他们有一个跨语言的TypeScript测试套件。如果你的测试套件不够好，AI生成的代码就是定时炸弹。投资测试工具、形式化验证、模糊测试——这些在"人写代码"时代是加分项，在"AI写代码"时代是必需品。

来源：

滚动至顶部