我知道，一个自我介绍写着“我解决软件系统中的难题”的人说这话，口气不小。但我们不妨退后一步，看看其中的经济账。

定制代码过去很贵。一个大型项目，可能要耗费相当于好几个人一辈子的集体劳动才能建成。这周，我用 David Wheeler 的 SLOCCount 测了一遍当前的 Linux 内核，采用的是他推荐用于内核项目的模型：2,880 万行源代码，估算工作量为 38,218 人年——849 个完整的职业生涯。

当你手里握着一件不可替代的东西，无论是实体的还是数字的，其价值超过你一生的全部产出时，你的本能就是爱护、保管、维护。

刚开始让 AI 生成代码时，我估计自己的效率提高到了原来的十倍。后来，我更懂得怎样使用 AI、怎样把问题说明白。与此同时，AI 本身也在进步，我花在那些把显而易见的事再说一遍的模板式规格说明上的时间越来越少。现在，我估计这个倍数更接近 50。

就连难的部分也变快了。为 Loongson 做优化时，模型会套用 AVX2 的习惯，而这些习惯在 LASX 上并不成立，我得解释两者的区别。这没什么。我花十分钟用英语描述算法和向量通道的规则，机器花三分钟生成内建函数调用，一天的活就干完了。这番解释也没有白费。过去，它存在于我的脑子里和我敲下的代码中。现在，它存在于规格说明里，下次构建时就能找到。这对我们与知识打交道的方式所带来的改变，比印刷术还大。

然后，我就听到网上那套老生常谈：“AI 生成的代码无法维护。你的项目可能会发展到连 AI 自己都照料不了的地步。最后还是得回到人来写代码。”

胡扯。

我们所谓的代码，已经不再是代码了。C++、Python、Rust：这些全都是机器生成的实现。它们就是二进制产物。

如果某些值得保留的东西只存在于代码中，那代码就是规格说明。你用 C++ 而不是英语写下它，又把它和如今相当于二进制产物的东西混在一起，这只说明你面对的是遗留代码。你有一份规格说明需要还原。那些知识依然重要。至于你碰巧把它埋在哪种语言里，倒不必那么重要。

没人会把构建产物提交到版本库。你提交的是编译器的输入，再让构建过程重现输出。自从我干这行以来，规矩就是这样——仓库里放一个 .o 文件，就是代码异味；要是把二进制文件签入进去，代码审查时就会收到你不想看到的评论。

现在看看你的仓库里到底有什么。里面没有规格说明。直到不久前，第一道编译器还是人：规格说明在你脑子里运行，你输出 C++，GCC 再输出二进制文件。没人提交第一阶段的输入，因为那个输入是某个人对问题的理解。这也正是你需要还原规格说明的原因。如今，第一阶段已经是程序了。我们只是还没注意到，自己仍然在提交它的输出——中间表示——而不是输入。

规格说明应该放在 Git 里。旁边的 C++ 是缓存下来的构建产物——之所以留着，是因为在今天，从一份规格说明走到加上改动的新规格说明，磁盘上有上一版实现，仍然比从零重新生成更快。这不叫维护。这叫带着提交说明的构建缓存。

而构建缓存也不一定要放在你的仓库里。ccache、sccache、Bazel 的远程缓存：我们早就在不同机器、不同团队之间共享编译器输出，因为大家构建的东西大部分都一样。高一层也会发生同样的事。缓存的 C++ 会从你的仓库搬到模型层面的共享缓存里，大家也就不必再烧算力，反复推导同一份实现。

我们早就不再琢磨怎么维护二进制文件了。没人会拿十六进制编辑器看着可执行文件，抱怨 GCC 没有生成可维护的机器码。但过去可不是这样。当重新构建要占用一整夜的机器时间时，人们就直接给二进制文件打补丁。IBM 把修复做成 SuperZap 补丁，直接应用到装入模块上，因为重新编译才是昂贵的那一步。二进制补丁并不是因为难看才消失的，而是因为重新构建变便宜了。

人们说，模型具有非确定性，所以不能信任。但 GCC 本身也塞满了人为选定的阈值——总得有人拍板定下那些数字。从规格说明的角度看，它们跟编译时随机选出来的数字没什么区别。我们早就接受了让编译器替我们选择实现方式。

我们也曾不信任早期的编译器。1957 年 Fortran 发布时，写汇编的程序员说的，正是今天网上对 AI 说的那套话：机器的输出臃肿，没人看得懂，没人维护得了，出了问题还得回去手写。Backus 的团队一开始就知道会这样。他们在优化器上花了好几年，因为没人会接受比人手写还慢的输出；即便如此，程序员还是会翻看汇编清单，检查编译器的工作。

现在没人看那些清单了。信任不是靠辩论灌输给谁的。它随着一次次构建逐渐积累，直到检查编译器输出成了专家的业余爱好。你不信任模型，这个问题我解决不了。Backus 也解决不了。我能告诉你的是，这种反对意见有个日期，而那个日期是 1957 年。

模型就是这么回事。不是结对编程的搭档，也不是实习生：它是编译器。输入一份规格说明——可以是普通英语，也可以是满载问题所属领域术语的英语——输出一份实现。今年这份实现是 C++ 而不是机器码，只是工具链的一个细节。

所以，没错，维护你的规格说明。跟踪文件格式、约束、业务规则的变化——这些可能非常复杂，尤其当你处理的是技术含量很高的问题时。但请放下对代码的执念。到了 2026 年，你仍然需要那些缓存的代码片段，帮助 AI 从一份规格说明走到下一份，但已经不必再担心可维护性，因为替换这些片段的成本正一天比一天低。