编程的终结？百万行代码AI重写引发的争议

AI 重写百万行代码，11 天完成

关于"编程的终结"的讨论近来愈演愈烈：人类代码审查是否即将退出历史舞台？这个观点正在开发者社区中反复被提出。

引发这轮讨论的核心案例，是 InfluxData CEO、InfluxDB 创造者 Paul Dix 提到的一件事——AI 写出了 100 万行代码，并在随后几个月里不断打磨完善。具体来说，这指的是将 Bun（JavaScript 运行时）从 Zig 语言重写为 Rust 的项目。

更令人震撼的数据是：整个重写过程在 11 天 内完成，累计花费约 16.5 万美元 的 API 调用成本。最终产出的是一款可靠的软件，目前正运行在数百万开发者的机器上。

Bun 是一个高性能的 JavaScript/TypeScript 运行时环境，由 Jarred Sumner 创建，定位为 Node.js 的竞争替代品。其初始版本使用 Zig 语言编写——Zig 是一门面向系统级编程的新兴语言，以极致的性能控制和对 C 的良好互操作性著称，但生态相对小众。Rust 则是近年来在系统编程领域快速崛起的语言，以内存安全保证（无需垃圾回收）和强大的工具链生态闻名，已被 Mozilla、微软、Linux 内核等广泛采用。将 Bun 从 Zig 迁移到 Rust，意味着在保持全部功能行为不变的前提下，用完全不同的语言语义和内存模型重新实现整个运行时——这不仅是语法层面的翻译，还涉及并发模型、错误处理机制、底层系统调用等深层架构决策。

这个成果到底有多惊人？

从工程角度看，这确实是一个值得认真对待的成果。有人可能会反驳说：这没什么了不起，因为他们有一个"Oracle"（参照标准）可以对比——毕竟从一种语言翻译到另一种语言，本身就有明确的正确答案作为验证基准。

但这种看法其实低估了整件事的意义。语言迁移看似"简单"，实际却涉及百万行级别的复杂逻辑处理。关键洞察在于：如果你能构建一套验证系统，并给出恰当的决策依据，AI 就能产出高度复杂、高度精密的软件。

换句话说，这个案例的价值不在于"AI 会翻译代码"，而在于它证明了——当存在可验证的正确性标准时，AI 能够在极短时间内完成传统上需要大量人力和时间的大型工程任务。

验证系统才是真正的关键

这场讨论的落点，其实不是"AI 能不能写代码"，而是"我们如何验证 AI 写的代码是对的"。

Zig 到 Rust 的重写之所以能成功，恰恰因为它天然具备一个可对照的"标准答案"——原有的 Bun 功能就是验证基准。AI 生成的每一段 Rust 代码，都可以通过与原有行为的对比来确认正确性。这也解释了为什么"人类审查即将终结"的论点会浮现：当验证可以自动化、可以规模化时，逐行的人工审查确实变得越来越次要。

这背后隐含一个更深层的判断：AI 编程能力的天花板，很大程度上取决于我们能否为任务设计出清晰的验证机制。对于那些拥有明确正确性标准的任务（如代码迁移、测试驱动开发、有明确规格的重构），AI 的表现可能远超预期；而对于缺乏客观验证标准的模糊需求，人类的判断仍然不可替代。

文中提到的 Oracle（参照标准）概念来源于软件测试领域。"Test Oracle"指的是一种能够判断程序输出是否正确的机制或参照物。在代码迁移场景中，原始实现本身就天然充当了 Oracle 的角色——对于相同的输入，新实现的输出必须与原实现一致，这为自动化验证提供了坚实基础。这一概念与**差分测试（Differential Testing）**密切相关：通过对两个实现同时输入相同的测试用例，比对输出差异来发现错误，已被 Google、Apple 等公司广泛用于编译器和解释器的测试。当 AI 生成代码时，拥有这样一个可对照的 Oracle 意味着验证过程可以完全自动化、大规模并行化，这正是本案例能够在 11 天内完成百万行迁移的重要工程前提。

编程真的要"终结"了吗？

"编程的终结"是一个足够抓人眼球的说法，但更准确的表述或许是：编程的形态正在改变。开发者的角色可能从"逐行编写代码"转向"设计验证系统、定义正确性标准、给出关键决策"。

Bun 重写案例给出的启示很直接——AI 已经能够独立完成百万行级别的复杂工程，前提是任务本身具备可验证性。这既是一个令人震撼的技术里程碑，也为整个行业留下了值得深思的问题：在没有"Oracle"的场景里，我们该如何建立信任？

本文基于 YouTube 上的单一来源分析，其中的数据（100 万行代码、11 天、16.5 万美元）来自 Paul Dix 的公开表述，读者可自行进一步核实相关项目细节。