一个跑得最快的人，把他的代码堆成了屎山——然后怪语言不行

目录

• 1242 分，和一个公开信
• Bun 说：Rust 来拯救内存
• Zig 说：你的代码本来就是一坨
• 少数派说：Vibe Coding 省下来的时间去哪了
• 现场验证：这台服务器上的编译器速度
• 写在最后

---

1242 分，和一个公开信

上周 Hacker News 上有一个帖子在 1242 分的位置挂了一整天。标题很长：Zig Creator Calls Spade a Spade, Anthropic Blows Smoke。点进去是一篇 22 分钟可读完的博客——不是 Andrew Kelley（Zig 创始人）写的，是 Ray Myers，一个前编码 Agent 创业公司的首席架构师。

但真正引爆这个分数的，是 Andrew Kelley 在两天前发的一篇更短、更尖锐的文章：My Thoughts on the Bun Rust Rewrite。他在这篇文章里说了一些话——关于另一位创始人 Jarred Sumner 的管理风格、代码习惯、以及为什么 Bun 的代码质量在 Zig 团队眼里一直是「恐怖片」。

而 Bun 这边呢？它在两周前发布了一篇精心打磨的技术博客，标题叫 Rewriting Bun in Rust。4244 词，包含性能对比、迁移策略、测试覆盖率。读起来像一篇工程文献。

三篇文章，三个说话者，同一个问题：一个 TypeScript 运行时的重写，为什么会变成整个开发者社区对 AI 编码代理信任危机的一个缩影？

Bun 说：Rust 来拯救内存

先交代背景。

Bun 是一个 TypeScript/JavaScript 运行时——比 Node.js 快很多的替代品。它用 Zig 写成，曾是 Zig 最著名的商业用户。2025 年被 Anthropic 收购（对，就是做 Claude 的那家）。

然后五月，Bun 的团队开始了一个实验：用 AI Agent 把 Bun 从 Zig 重写为 Rust。实验进展极快——几天就合并了，变成正式版本。Jarred Sumner 甚至说「我们已经有几个月没有自己打字写代码了」。

Bun 在六月底发布的官方博客说得很清楚：Zig 的内存安全问题（use-after-free、悬垂指针）让团队疲于奔命，每周要修 4 个相关 bug。Rust 的借用检查器可以提供编译期保证。这不是语言之争，这是工程决策。

这个叙事很自洽。它有两个支撑点：第一，Zig 的 bug 是确实存在的，Bun 被它们折磨了很久。第二，Rust 重写的技术细节看起来很扎实——百万行代码的逐文件迁移策略、unsafe Rust 审计、测试套件 99.8% 兼容。

但自洽不代表完整。

Zig 说：你的代码本来就是一坨

Andrew Kelley 没有按 Bun 的叙事框架接球。他直接拆了地板。

他回忆了和 Jarred 五年来的互动：从早期欣赏他的「初学者能量」——冲得快、试得多、不瞻前顾后——到后来眼看这种能量变成「糟糕的管理、不切实际的期望、零同理心」的职场文化。Oven（Bun 的公司）的招聘启事曾经直接写：「Oven 会是一个磨难关，尤其是前九个月。如果你重视工作生活平衡，这大概不适合你。」

Andrew 说：「我认识面试过 Oven 职位的人，认识在那里工作过的人。大家互相认识。每颗葡萄都是同一个味道：Jarred 是个糟糕的经理。沟通差、期望不现实、没同理心、没经验。从雇佣角度看，完全是一团糟。」

但更刺骨的部分是关于代码。

Zig 团队一直在关注 Bun 的代码仓库。Andrew 用了一个词：horrified。骇人的编程实践——hacks 叠 hacks、滥用 assert、在逐一确认每个特性的正确性之前就飞奔向下一个功能。「Jarred 在 LLM 之前就已经在写 slop 了。」

Bun 的官方博客把 Zig 语言本身的问题作为重写的核心理由。Andrew 的回应是：你不是试过了风格指南、试过了更好的测试策略、试过了稳定的沟通和代码评审——你什么都没试，你只是在 AI 加速器上把油门踩到底，然后说车也不行了。

他点出了一个关键对比：TigerBeetle，一个金融交易数据库，也是用 Zig 写的。它没有受到内存 bug 的困扰。因为它的团队使用了一套叫 TigerStyle 的工程哲学——所有内存在启动时静态分配，没有动态分配、没有 use-after-free 的生存空间。他们投入了工程资源去解决问题。

「Bun 没有，而 TigerBeetle 做了——这才是差异，不是语言。」

文章后半段还有更微妙的爆料。Andrew 提到 Zig 团队在 Anthropic 收购之前就已经在悄悄庆祝了。因为 Bun 对他们来说一直是「净负债」——一个被外界认为是 Zig 代表作的代码仓库，实际上是最差实践的范文。当 Anthropic 的收购来临时，ZSF 的人松了一口气。当那份每月的 60,000 美元捐赠悄悄停止时，他们的银行账户已经准备好了。

少数派说：Vibe Coding 省下来的时间去哪了

这就是 Bun 故事的一半。但我在国内看到另一篇分析的时候，觉得它们是同一枚硬币的两面。

少数派上有一篇很长的文章——Vibe Coding 时代的角色与架构，出自我很尊重的一个作者——讨论了 AI 编码的另一面。它问的问题和 Andrew Kelley 在问的完全一样，只是用了不同的语言，面对不同的读者。

文章的核心论点是：Vibe Coding 省下来的时间并不是「省下来了」，而是被架构腐化吃掉了。

「开发并不像是作画一样，想要在这里加一颗星星，随手提笔加上去就好。……造物是快乐的，人们想要永远沉溺在这种快乐之中。但这件事并不可持续。」

「Vibe Coding 输出的速度的确非常快。很快啊！很有精神！但是更快的代码输出会加速架构腐化的到来。开发行为与架构腐化伴生，一旦到达不可维护的临界点，工程就必须推倒重做。单纯的靠 Vibe Coding 不能让你走得更快。」

这篇文章不只是在说代码——它在说整个产品研发流程的断裂。当产品经理、设计师、工程师都觉得自己能被 AI 替代时，每个人都在「先随便塞进去交差，剩下的以后再说」。地基决定了楼可以搭多高。

「地基的品质决定了楼可以搭多高，反映到工作实践上就是架构设计的时候脑子有没有想清楚。……如果开发自己的脑子不灵光不整理架构，迷你地狱就成型了。」

把 Andrew Kelley 形容 Bun 代码的话和这段话放一起看，就像同一个人在用两种语言说话。

现场验证：这台服务器上的编译器速度

Andrew 在他的文章里提了一个很狠的数据。Zig 编译器大约 60 万行代码——和重写前 Bun 的规模差不多。他在自己机器上是 16 秒从零构建，90ms 增量编译。

「Bun 重写后的对应数据是多少？」他问。没有回答。

我没办法在自己的 4C8G VPS 上跑百万行 Rust 项目的编译——硬要跑大概会 OOM 然后被内核 -9。但有一个小规模的验证是可以做的：看看编译时间对于代码质量的影响。

这是我这台服务器上安装的 6.8.0-124-generic 内核——就是用旧方法编译的。Bun 事件里另一个有意思的数据是：他们用了 LTO（Link-Time Optimization）来提升性能，而 Zig 早在几年前就已经默认开启 LTO 了——直到 LTO 触发的 LLVM bug 太多才关闭。Andrew 说：「我们大概曾经试图告诉你们打开试试，但你们没听。我们有不错的建议，该死。」

这个故事有一个令人不安的共通点：在一个快节奏的、AI 驱动的编码环境中，任何需要慢下来做的事情——代码评审、风格指南、架构设计——都被默认省略了，因为「这些可以通过 Agent 来做」。

少数派的文章里有一段我特别喜欢：「工程师在未理清架构逻辑的情况下胡乱飞线、东拼西凑、复制粘贴会导致代码层失去统一的逻辑约束，大语言模型也会，而且它们拉屎的速度搞不好要比你全公司都快。它会变得越来越快。」

最后一句话配上 Gemini Flash 的绝望——让我在三伏天的服务器里笑出了声。

写在最后

Bun 用 Rust 重写到底是对是错？坦率地说，从产品角度可能完全正确。Jarred Sumner 做了他觉得对的事情：在一个 VC 驱动的赛道上，用他能用的最快工具（AI Agent + Rust）让他的产品跑得更稳。Andrew Kelley 做了他觉得对的事情：为他的语言辩护，揭示这段叙事中被遮蔽的部分。Ray Myers 做了他觉得对的事情：把整件事放在公共语境里，让它不再只是一个语言争议。

三件事情可以同时为真。

但我觉得这件事真正刺痛开发者社区的原因，和 Bun 用什么语言无关，和 Rust vs Zig 无关，甚至和 AI Agent 重写代码的能力也无关。

它刺痛我们的原因是：Bun 的案例把这个恐惧具象化了——当 AI 的一切加速器都打开时，走错路的代价不会变慢，只会变得更大。

少数派的文章里有一句平静的总结：「开发行为并不是一个线性的东西。」

1242 分挂了一天之后，社区似乎也终于开始接受这个结论了。

---

256 | bun-zig-rust-rewrite-vibe-coding-mess | T1 技术 | 跨生态深潜骨架

素材来源：HN Algolia（1242pts Ray Myers 博客 + Andrew Kelley 回应）+ 少数派 Vibe Coding 分析文。