AI能重写Bun吗？这场编程变革的真相没那么简单

一个时代的终结？先别急着收拾行李

最近技术圈里流传着一种论调：编程作为一门手艺正走向终结，人类审查代码的日子屈指可数，Agent 将全面接管编码工作。引爆这轮讨论的，是 Bun 从 Zig 到 Rust 的重写工程——由 AI 完成了大量代码生产。类似的信号还有 EVE Online 从 Python 2 迁移到 Python 3，以及 Linus Torvalds 开始认真使用 AI 辅助编码。

这些事件叠加起来，很容易让人产生一种焦虑：我们是否正在进入一个「谁能用上前沿模型和 API，谁就能造出更好软件」的新世界？还是一切照旧？本文认为，真相更可能是第三种——确实变了，但没变成你想象的那样。

Bun 重写背后：AI 真的很强，但有前提

InfluxData CEO、InfluxDB 创造者 Paul Dix 的核心论点是：AI 写出了约 100 万行代码，并在随后几个月里不断打磨。这指的正是 Bun 已公开发布的 Zig 到 Rust 重写。据视频作者转述，这项工作在 11 天内、花费约 16.5 万美元 API 调用 就取得了相当好的进展，而 Bun 目前正运行在数百万开发者的机器上。

有人会说这没什么了不起——因为他们有一个「Oracle」（现成的旧版本）可以对照，从一种语言翻译到另一种语言相对简单。但这种说法低估了整件事。它是一个很好的例子，说明 AI 能够生产出相当复杂的软件，并持续迭代直到「跑通」。

关键在于前提条件。Bun 不仅有出色的测试套件，还有一份形式化规格说明（本质上也是代码），明确规定了「应该如何运作」。有了这样的验证系统和方向指引，AI 确实能做出令人惊叹的事。

Bun 是由 Jarred Sumner 开发的高性能 JavaScript/TypeScript 运行时，最初用 Zig 语言编写，目标是替代 Node.js 并提供更快的启动速度和内置工具链。Zig 是一门注重底层控制和编译期安全的系统级语言，而 Rust 则以内存安全保证和成熟的生态著称。将一个已在生产环境大规模运行的运行时从一种系统语言迁移到另一种，通常需要数年人力——核心挑战不仅是语法转换，还包括内存模型差异、平台行为细节和边缘情况的完整复现。Bun 的测试套件和形式化规格正是让 AI 得以完成这项任务的"地基"：AI 每次生成代码后，可以立即用测试验证正确性，形成一个紧密的反馈循环。这种「写→验→修」的闭环，本质上与 TDD（测试驱动开发）思路相同，只是执行者换成了 AI。没有这套闭环，100 万行代码的输出只会是一堆无法信任的噪音。

不只是一次：Anthropic 用 Opus 造过 C 编译器

重写 Bun 并不是 Anthropic 第一次尝试这类任务。此前它还用一组并行的 Claude 实例配合 Opus 模型，构建过一个 C 编译器。这两件事有着相同的关键条件——一个近乎完美的「Oracle」：

• 30 年积累的测试用例
• 来之不易的代码与领域理解
• 训练权重里本就多次「见过」的 GCC 编译器

换句话说，AI 是在测试的引导和约束下，把已有的知识重新组织、重建出来，最终产出高度复杂的 C 编译器。两个案例的共性非常清晰：都拥有极其强大的构建验证系统。

结论也随之而来：如果你能提供一套形式化的验证体系并给出明确方向，AI 能力惊人。但反过来，那套验证系统本身，往往是多年硬碰硬积累出来的知识——这恰恰不是 AI 凭空能给你的。

EVE Online 的反例：为什么它不用 AI 一把梭？

视频特意提到 EVE Online 从 2023 年 2 月就开始的 Python 2 到 3 迁移。这个迁移的一大难点在于：Python 2 和 3 能编译同一段代码，但行为不同。经典例子就是除法——Python 2 里 1/2 是整数除法得 0，Python 3 里则被强制转为浮点得 0.5。可以想象这会带来多少混乱。

作者的疑问是：这种活儿看起来很适合丢给 LLM——「给你两万行代码，保证所有运算结果一致」。但 EVE 偏偏选择缓慢、逐步推进。原因可能有几层：它运行的业务风险和 Bun 完全不同，预算也不一样，更重要的是——它可能极难构建出可靠的验证系统。这不是同一量级的问题。

说个细节，EVE 团队本身并不排斥 AI，反而大量使用 LLM Agent 来啃这个 30 年的老代码库：文档缺失、原作者离场、逻辑无人知晓。所以问题不是「他们不用 AI」，而是存在某种我们尚未完全理解的约束，让人类验证仍不可替代。

Python 2 与 Python 3 之间的迁移被业界公认为"史上最痛苦的语言版本升级"之一，官方过渡期长达十余年（2008–2020）。除了整数除法，两者在字符串处理（bytes vs str）、print 语句、unicode 支持、迭代器行为等数十处存在语义级差异。对于 EVE Online 这类运行超过 20 年、单个服务端同时承载数万玩家经济交互的系统，任何细微的数值行为变化都可能引发游戏内经济崩溃或安全漏洞。更深层的挑战在于：EVE 的部分核心逻辑依赖 Python 2 的特定错误行为（某些边缘情况下的"错误"输出已被游戏系统当作"正确"输入接受了十年），这类隐式契约几乎不可能用自动化测试完整捕获，必须依赖对业务逻辑有深度理解的人类专家逐段审查。

Linus 的调试地狱：模型说「无解」，人说「再来」

最有意思的案例来自 Linus Torvalds。他最近在图形驱动上打了一场「地狱级」调试战。过程中 LLM 直接告诉他：这是一个不可能解决的 bug，你就写份报告收工吧。

但 Linus 没停。他做了 24 个调试补丁、18 次内核启动，最终找到了问题——而这个问题只有一行代码。

这个故事的分量在于：Linus 拥有几乎不设限的模型访问权限，连他都无法说服 AI「这事能做」，那么单纯充当「AI 传声筒」的人又能走多远？作者由此给出一个尖锐判断：如果你只是给 AI 当代理，那你最好的水平也只能等于「最差的程序员」——因为最差的程序员也能用上同样的 Agent。

这个案例触及了当前 LLM 辅助编程的一个根本性局限：搜索空间爆炸时的推理能力。LLM 在处理有明确上下文、有充足训练先例的问题时表现出色，但面对需要系统性假设排除、跨越多个内核子系统追踪状态变化的调试任务时，它缺乏真正的"坚持"——模型会在上下文窗口用尽或置信度不足时倾向于给出"无法解决"的结论，而不是像 Linus 那样执行 24 次有序实验逐步缩小问题范围。这种差异不只是"经验多少"的问题，而是关乎一种元认知能力：知道自己还不知道什么，并设计实验去填补那个盲区。这正是深度专业能力在 AI 时代仍不可替代的核心原因之一。

至于「人人用 Gemini 3 Flash vibe coding 游戏」

视频开头那句「到年底人人都在用 Gemini 3 Flash vibe coding 电子游戏」其实是个反讽。作者早已知道结果：并没有。做游戏依然很难，demo 大多质量堪忧，真正上手才知道——一个不懂 3D 游戏原理的人，无法凭空变出一个 3D 游戏。这提醒我们别被演示视频的滤镜带偏节奏。

真正的变化：专业能力的红利被放大了

作者最终的态度很明确：他现在站队「AI 编程新时代确实来了」。Agent 已经变得非常强，把它们当白痴是愚蠢的。但同时——专业能力的作用不降反升。

他给出的判断很值得记住：过去认真读文档、保持好奇、多问问题，可能带来 3% 的回报；而在 Agent 时代，这些习惯的回报会变成 10%。你对代码理解越深、越能把 AI 引导进好的模式，能走的距离就越远。

所以，与其焦虑「编程终结」，不如换个视角：这是一个对学习者更友好的时代。技术专长将成为巨大的差异化优势。别只做复制粘贴的人——花时间把自己练好，读文档、提问题、保持好奇。这，才是新时代真正的护城河。