编程时代的终结？AI重写代码背后的真相与分水岭

当AI在11天内重写100万行代码

一个被反复讨论的话题正在席卷开发者社区：我们所熟知的编程是否正在走向终结？这场讨论的导火索，是 Bun 从 Zig 语言用 AI 重写为 Rust 的项目。

InfluxData 的 CEO、同时也是 InfluxDB 创造者的保罗·迪克斯（Paul Dix）给出了一个颇具冲击力的论点：AI 写出了约 100 万行代码，并在接下来几个月里不断完善它。整个重写项目在 11 天内完成，花费了约 16.5 万美元的 API 费用，最终产出一款可靠的软件，如今运行在数百万开发者的机器上。

这个结果确实令人震惊，但 PrimeTime 并不感到意外。他的看法很直接：如果你能建立一套完善的验证系统，并给出正确的方向，AI 就能处理高度复杂、高度精密的软件，并持续打磨。

成功的前提：被低估的验证系统

有人会说，Bun 的重写没那么了不起，因为它有一个现成的参照物——从一种语言转换到另一种语言本来就简单。但 PrimeTime 认为这种说法恰恰把关键看低了。

真正让 AI 重写成为可能的，是那套来之不易的验证基础。Bun 不仅有一套惊人的测试套件，还有一份类似形式化规范的文档，明确说明代码应该如何运作。

类似的案例并非孤例。Anthropic 此前就曾用一组并行的 Claude 实例构建过一个 C 编译器，而那同样建立在完美的验证基准之上——GCC 拥有 30 年积累的测试、深思熟虑来之不易的代码，以及被反复纳入训练权重的编译器实现。换句话说，AI 能够有效复述并重建它，靠的是方向引导和测试工具不断重定向流程。

这里藏着一个容易被忽视的悖论：要构建出真正那么可靠的东西，你所依赖的验证系统本身，正是多年艰苦奋斗积累下来的工程知识。AI 的能力建立在人类工程资产之上，而非凭空取代它。

形式化规范（Formal Specification）是指用数学或严格逻辑语言描述软件预期行为的文档，与普通注释或设计文档不同，它能被工具直接验证。测试套件则是一组自动化测试用例的集合，覆盖从边界条件到复杂集成场景的各类输入输出。两者共同构成「验证基础设施」——这套基础设施的价值在于，它让「代码是否正确」这个问题从主观判断变成可自动执行的客观检查。对AI重写项目而言，验证基础设施扮演的角色类似于建筑工程中的图纸和质检标准：AI每生成一段代码，就能立即跑测试、对照规范，发现偏差后自动修正。没有这套机制，AI输出的代码无论看起来多么合理，都缺乏可信的正确性保障。这也解释了为什么Bun的重写能够成功——其价值不仅在于「有一个参照实现可以翻译」，更在于每一步翻译的结果都能被立即、自动地验证。

EVE 的谨慎迁移：为什么不一键搞定

另一个被拿来对照的案例是经典网游《星战前夜》（EVE Online）。令许多人震惊的是，这款游戏居然是用 Python 编写的，而它从 Python 2 到 Python 3 的迁移从 2023 年 2 月就一直在进行。

迁移中最棘手的问题之一，是同一段代码在 Python 2 和 Python 3 中都能编译，运行结果却不一样。一个经典例子就是除法：在 Python 2 里 1/2 等于 0（整数除法），而在 Python 3 里结果是 0.5。

看起来似乎只要「确保所有运算行为一致，两万行代码一次搞定」就行，但 EVE 团队却选择把过程大幅放慢，一步步推进。原因并不是他们排斥 AI——事实上，面对一个有 30 年历史、很多部分无人了解、文档缺失的代码库，他们相当频繁地使用生成式 AI 智能体。

真正的差异在于：对 EVE 来说，建立一套可靠的自动化验证系统可能极其困难，甚至不在同一个数量级上，因此他们不得不更多依赖人工验证。这恰恰印证了前面的论点——没有可靠验证系统的地方，AI 的激进重写就会失去安全网。

Python 2 到 Python 3 的迁移在整个行业曾是一场持续超过十年的「慢性阵痛」。Python 3 于2008年发布，直到2020年Python 2才正式停止维护，期间无数大型项目因迁移成本过高而长期搁置。核心挑战并非语法差异（这部分有自动化工具2to3可以处理），而是「语义静默变化」——代码在两个版本下都能运行，但行为不同，例如整数除法、字符串默认编码（ASCII vs UTF-8）、dict迭代顺序等。这类问题无法通过静态分析完全捕获，必须依赖运行时测试覆盖每一条逻辑路径。对EVE这样一个拥有数百万活跃玩家、任何线上bug都可能影响经济系统和玩家资产的游戏而言，漏掉一处语义变化的代价可能远超迁移本身的收益，这使得「快速全量迁移」的风险收益比极不划算。

林纳斯的硬骨头：AI 说「这个 bug 无法解决」

最有说服力的例子来自 Linux 之父林纳斯·托瓦兹。他最近开始大量采用 AI 编程，刚搞定了一个显卡驱动，用他自己的话说，那是「一场来自地狱的调试过程」。

离谱的地方在于：那个大模型居然对他说，这其实是一个「不可能也无法解决的 bug」，建议他写一份报告然后继续往前走。但林纳斯没有听。他打了 24 个调试补丁，启动了 18 次内核，最终找到了问题所在——而问题仅仅是一行代码。

这个故事点出了核心：如果连林纳斯都需要靠自己的专业判断去推翻 AI 的「放弃」结论，那么技术专长在新时代不但没有贬值，反而更加关键。AI 智能体对所有人都是同样的工具，但「谁在使用它」会决定结果的天差地别。

真正的分水岭：专业能力，而非智能体

PrimeTime 对一个流行词汇颇有微词——「人肉代理」（human proxy）。他认为用这个词形容开发者，是在极大贬低人和人性，也多少把人放到了和大模型同等的位置上。

他的警告很尖锐：如果你所做的一切，只是指挥 AI 去搞定所有事情、充当 AI 的传声筒，那么你会是第一个被扫地出门的人。这类人和当年那些只会从 Stack Overflow 复制粘贴、从不真正理解系统的人是同一类——区别只在于，现在你用的是一台更快的复制机器。

结论因此也更清晰：你掌握的代码知识越多，就越能真正引导 AI 走向好的模式，一个人能取得的进展也会大得多。编程智能体确实已经变得非常强，这一点没跑了；但在这个新时代，技术专长将成为一个巨大的分水岭。

阅读优秀的手册、学习如何保持好奇心、提出大量问题——这些投入现在带来的回报不再只是「3% 的股息」，而会是「大约 10% 的股息」。要说有什么变化，那就是：比以往任何时候都更值得去学习。

「人肉代理」（human proxy）这一概念来自AI工作流领域，原本描述在全自动化流程中负责处理AI无法独立完成的边缘案例的人工角色。其核心含义是：人的参与方式被简化为「当AI卡住时的备用输入源」，而非真正的决策者或设计者。这种工作模式的危险在于，它并不需要操作者理解系统——只需转述问题、确认输出。历史上类似的角色反复出现过：工业革命中只会搬运但不理解机器的工人，互联网时代只会拼接Stack Overflow代码但不理解架构的程序员。每一次技术跃迁后，这类「无理解的执行者」都是最先被自动化替代的群体。PrimeTime的判断延续的正是这一规律：工具变得更强，理解系统的人受益更大，而不理解系统的人则加速失去稀缺性。

这是终结，还是一次升级？

回到最初的问题：这是我们所熟知的编程的终结吗？从几个案例来看，答案更接近「它实际上只是有那么一点不一样」。

AI 能在拥有完美验证系统的场景中创造奇迹（Bun、C 编译器），在验证困难的场景中仍需人类主导（EVE），在遇到真正硬骨头时还会误判放弃（林纳斯的驱动）。软件工程的开展方式确实会改变，但「人类亲手写代码的日子已经不多了」这种断言，显然过于简化了现实。

编程没有终结，终结的是「不理解系统、只会复制粘贴」的工作方式。能否驾驭前沿模型，会放大而不是抹平开发者之间的能力差距。