内容
看看这个博客过去的历史。这里有很多关于使用 AI 编程的博文，其中有几篇早在 2024 年 1 月就已经写了（比如这篇：https://antirez.com/news/140）。毕竟，我算是一位相当受认可的程序员。我没必要还像个追求存在感的老年人那样，非得始终“跟上潮流”。我最近重新加入了 Redis，现在还在开发一款用于本地 LLM 推理的新开源软件，并且在社区里获得了不错的欢迎。那我为什么还要继续做这些事，继续说一些人们不想听的话？为什么我总是在宣告未来的编程会默认变成什么样？因为我想尽量降低这种变化对那些比我更没准备好的人所造成的冲击，他们往往比我更年轻，而且不像我那样，早早就预见了不少这些事情（我在 2022 年、也就是 ChatGPT 还不存在之前，就出版了一本书，提前预告了现在发生的许多事情，以及我相信将会发生的其他事情，所以我觉得自己说这些话也不至于显得自大）。
所以，我是在耍一个小花招。人们越来越觉得编程正在被 AI 完全改写，却不知道自己该怎么办，也不知道自己是否真的可以用一种完全不同的方式开始编码，而不再把代码本身当作主要产出。他们觉得自己像是在背叛自己的行业。所以我的意图就是站出来说：“看我，我也能写代码，你知道的，我并没有躲在 AI 背后；不过，事情变了，这不是你的软弱，也不是你被 AI 洗脑了。只是我们的领域正在朝着一个不可思议的、而且痛苦的（但同样也令人愉快的）方向演进。”
这就是为什么昨天我在 X 上说，我相信如今很多程序员之所以影响力变小，是因为他们把注意力放在了代码上。我真的这么认为。注意，这并不意味着只要要求最终产品就去做那种靠感觉写代码（vibe coding）。重点在于：如果你掌控着软件的理念，那么去看代码本身往往是低效的，而且常常毫无意义。原因如下：
-
现在你可以生成大量代码，甚至还没把 LLM 代码啰嗦冗长这一点算进去（而这在很大程度上，也是因为大多数时候我们没法很好地给它们下指令）。你打算怎么每天审查 5000 行代码？
-
LLM 很擅长编写局部最优的代码，但在宏大思路上表现较差（虽然也在进步）。逐个函数、逐行扫代码有什么意义？相反，你应该提示你脑海中的设计，有时问一句：“那部分的设计到底是怎样的？它是怎么工作的？”然后评估它是否是正确的模型。这样快得多。
-
工作日只有 8 小时。如果你去读代码，这就是一种权衡。你会减少今天这份工作里最重要的部分，也就是：反思自己究竟在用这个软件做什么？你想把它带向哪些新方向？同时，还要思考新点子、新功能、优化技巧，并做大量 QA。
控制理念。你还记得《人月神话》里的这个说法吗？一本 70 年代的书，对今天的软件时代的洞见，比 2000 到 2020 年间说过的许多东西都更多。为什么那些如今抗议 AI 的人，对过去十年软件的现状却不感到震惊？我们在最近这些年、也就是 AI 出现之前，所接触到的那种垃圾代码（slop）程度，简直令人难以置信。我要再告诉你一件事。什么是 slop？我在 DwarfStar 里以完全自动化的方式，为两个 LLM（DeepSeek v4 和 GLM 5.2）实现了推理；但是——你自己试试就会发现，你不能只是说“实现 XYZ”，然后就指望它真的能跑起来。你必须理解事情是怎么工作的，什么才是最好的设计，怎样达到某个性能水平。之后我又把实现拿去和其他系统做正确性比较，发现别的实现有时包含更多错误。我继续研究后发现，本地推理领域充满了微妙的错误，这些错误会累积并损害模型输出，比如注意力实现中的问题，会导致当上下文长度超过某个阈值后性能下滑，因为索引式注意力实现坏掉了（比如做了比它应该做的更多的工作），诸如此类。这是一个极其复杂、变化飞快的领域，每天都有在推理图上略有不同的模型发布出来。对开发者来说，这是一场不公平的游戏。好吧：AI 在这方面帮了大忙。有很多领域里，严谨的工程设计和测试，远远比手写一个 GPU kernel（或者去读它）更好。那我们确定，大多数阻力真的不是意识形态问题吗？
昨天，Matteo Collina 在回复我的推文时问我：但你不是说你会检查 Redis 中所有 AI 生成的代码吗？这确实是个好问题。是的，我会检查，但到了现在，这件事我确实还得做，但我认为它大多已经没什么意义了，部分原因是在 GPT 5.5 发布之后，而现在有了 Fable 和 GPT 5.6 Sol，这一点就更明显了。没错：我会发现一些我不喜欢它们的编码方式的地方，但如果我打开其他 Redis 贡献者写的 Redis 文件，那里糟糕得多；这并不是因为他们不是好程序员，而是因为这归根结底是品味问题。我写代码非常干净，因为我希望它可读，所以在实现 Redis Arrays 的过程中我做了一些改动。我现在又在为 Redis 有序集合（sorted sets）节省 50% 内存的优化这么做了，这是我很快就会提交的一个 PR。但我已经不觉得这还有什么用了。现在已经不该再有人去盯着这段代码看，而应该只看代码所承载的理念。我继续这样做，是出于对用户的尊重。Redis 到了这个阶段，已经是一个广泛有用的东西，很多程序员都会打开文件并手工修改内容。但如果我能完全放开手脚，你知道我会做什么吗？我会把审查代码所花的全部时间拿去做更多 QA，去思考下一个优化点子并把它实现出来，再用 LLM 去写一个 DESIGN.md 文件，在那里用自然语言描述每一种数据结构，以及其中包含的思想、实现技巧和设计方案。到了未来，这会有用得多。你想修改有序集合？你打开文件，读设计文档，然后掌握这些理念。你可以打开你的 agent，按照正确的心智模型告诉它该怎么做。这比审查代码有用得多。
Fable 和 GPT 5.6 对有序集合内存优化的审查，会发现比我审查能找出的更多错误和微妙的竞态条件。不过我还是会去做。但对大多数软件项目来说，这一切如今都已经不再有意义了。相反，应当把重点放在掌控理念上。把重点放在质量、测试，以及你想交付的软件愿景上。世界变了，这很痛苦，但也充满了机会，可以改善一个原本就已经彻底腐烂的软件世界。
我唯一的疑问，是那些经验还不够、又无法建立心智模型的年轻程序员。我们还不知道，他们是否需要非常深入地理解某段代码的工作方式，但我认为他们应该学习如何编写程序。不过，我不确定检查 LLM 输出是不是他们该做的事。对他们来说，学一门编程语言，自己实现一个小型解释器、小型数据库、哈希表之类的东西，可能会有用得多。去给客户检查某个网站的一些 Javascript 代码？得了吧，别把时间浪费在那种破事上。