上周末，AI 圈最热闹的事，不是哪个公司又发了新模型，而是一场”嘴仗”。
主角是 Zig 语言创始人 Andrew Kelley，和被他点名的 Anthropic/Bun 团队。导火索是 Bun（那个被 Anthropic 收购的 TypeScript 运行时）把代码从 Zig 迁移到了 Rust，而 Anthropic 把这次迁移定性为”Zig 语言不行”的胜利。
Andrew Kelley 发了一篇博客，直接反驳了这个叙事。
这场争论的本质，不是语言之争，而是一次关于”AI 到底能不能写出好代码”的公开检验。
发生了什么
Bun 是近年来最受关注的 JavaScript 运行时之一，最初用 Zig 编写，代码贡献者声称 100% 是 AI 完成的工作。Anthropic 收购 Bun 之后，启动了一次大规模重构——用 AI agent 把整个代码库从 Zig 迁移到”unsafe Rust”。
迁移完成后，Anthropic 官方博客写了一篇文章，核心论调是：我们遇到了无法解决的内存安全问题，所以不得不换语言，言下之意是 Zig 不够格。
这个叙事被 The Register 这样的媒体放大，标题是”Anthropic’s Bun Rust rewrite merged at speed of AI”——AI 快速重写代码，听起来很震撼。
Andrew Kelley 的回应很直接： 真正的问题不是 Zig 语言本身，而是 Bun 的代码质量和工程管理。他引用了”消息来源”的说法，称 Bun 团队内部是”Poor communication, unrealistic expectations, low empathy, no experience. Just a total shit show.”
这不是技术争论，是管理问题的锅。
真正的问题：AI 写的代码，到底能不能用？
Ray Myers 写了一篇更长的分析，读下来比两边的”声明”都有价值。他提出了一个关键问题：
当 Anthropic 用 AI agent 重写 Bun 的时候，AI 没有能力发现并修复一个 use-after-free 漏洞——但 Anthropic 却用这次”成功”来营销自己的 AI 编程能力。
这个矛盾点非常有意思。
Ray Myers 的分析框架把各方叙事拆开了看：
- Anthropic/Bun 的说法： 我们尝试了所有合理方法，还是被内存 bug 淹没，所以切换到 Rust
- Andrew Kelley 的说法： 代码本来就是一团糟，是因为过度使用 AI 写代码和审查代码导致的工程问题
- Ray Myers 的说法： 这是一次管理决策——选择 Rust 能展示 Anthropic 的 Fable 模型，能复用 Anthropic 内部已有的 Rust 技术栈，同时 Zig 本身对 Anthropic 产品持批评态度
这三个解读，哪个更接近真相？Ray Myers 说他更倾向于第三种。
几个硬事实
1. Bun 的代码质量确实有问题
Ray Myers 引用了 Bun 2022 年发布时的招聘警告，原话是：
“Oven is going to be a grind, especially the first nine months or so. If work-life balance means a lot of time spent not working, it’s probably not a good fit.”
Ray Myers 的评价是：”我看到这种声明，会觉得这个人不知道自己在做什么。长期加班对健康和生产力的损害，是有大量实证研究支持的。”
2. AI agent 编程的现实：可以快速产出，但质量难以保证
Ray Myers 在文章里提到一个关键观察：
“Zig allows 0% AI contributions. Bun claims near 100% AI contributions.”
这两句话放在一起，讽刺意味很足。Zig 社区对 AI 生成代码持警惕态度，而 Bun 则把 AI 编程当作核心卖点。现实是：AI 确实能快速生成大量代码，但当代码库规模上去之后，维护成本和技术债务积累的速度也很快。
3. 这次迁移的”宣传”和”实质”对不上
Anthropic/Bun 的官方博客给出了：
– ✅ 动机
– ❌ 考虑过哪些其他方案
– ❌ 各种方案的优缺点对比
Ray Myers 引用了 Richard Feldman 把 Roc 编译器从 Rust 迁移到 Zig 的博客作为正面例子——那个案例详细列出了所有选项和权衡。而 Bun 的解释，晚了两个月，却缺少最关键的分析框架。
为什么这个事件比看起来更重要
因为这是 AI 编程工具第一次在聚光灯下完整展示了一次失败案例的全程——从”AI 重写代码”到”官方叙事”到”行业反驳”。
过去一年，我们看到的都是 AI 编程工具的成功叙事：Cursor 能做什么、Claude Code 有多强、GitHub Copilot 提升了几个百分点的效率。但失败案例很少被公开讨论，尤其是当失败和 AI 编程直接相关的时候。
Bun 事件让几个问题无法再回避：
- AI 编程的边界在哪里？ 100% AI 贡献的代码库，是否比人工维护的代码质量更差？
- 大厂叙事 vs 技术真相： 当 Anthropic 这样的公司用营销语言包装技术决策，开发者社区如何做出正确判断？
- 语言护城河还存在吗？ 如果 AI 能快速在不同语言之间做翻译，语言本身的选择逻辑是不是正在改变？
观点
Andrew Kelley 的文章被一些人称为”meltdown”，Ray Myers 的回应是：不是，这是有人在说出真相。
这个事件最值得关注的不是谁骂了谁，而是AI 编程工具正在经历第一次真正意义上的”复盘”——不是厂商自己的复盘，而是社区主导的、有具体技术细节的公开复盘。
Bun 的故事告诉我们：AI 可以帮你写代码，但它不能帮你做好的工程决策。当一家公司把”AI 重写整个代码库”当成营销事件的时候，它实际上在掩盖一个更深层的问题——代码质量问题的根源，从来不只是语言的选择。
真正的问题永远是：是谁在用 AI，用 AI 做什么，以及为什么。
话题关联：Bun / Zig / Rust / AI 编程 / Anthropic / 编程语言之争