翻看这个博客过往的历史，你会发现有许多关于用 AI 编程的文章，其中几篇可以追溯到 2024 年 1 月（比如这篇：https://antirez.com/news/140）。毕竟，我算是一位相当受认可的程序员。我并不需要像一个渴求存在感的老人那样硬要留在“圈子”里，我最近重新加入了 Redis，现在还在开发一款用于本地 LLM 推理的新开源软件，它在社区中也得到了很好的反响。那我为什么还要坚持做这件事，去说那些人们不想听的话？为什么还要不断宣告未来编程的默认形态会是什么样？因为我有一种紧迫感，想为那些比我更没做好准备去迎接变化的人减轻冲击，他们往往比我年轻，而且不像我，没有预见到许多事情的到来（早在 ChatGPT 出现之前的 2022 年，我就出版了一本书，预告了现在已经发生的许多事，以及我相信*将会*发生的其他一些事，所以我觉得这么说并不算自负）。

所以我的做法其实是个策略。人们越来越感觉到编程已经被 AI 彻底改变，却不知道自己该怎么做，是否真的可以开始以一种完全不同的方式写代码，而不再把代码本身当作主要产出来仔细审视。他们觉得自己好像背叛了自己的领域。所以我的意图就是站出来说：“看看我，你们知道，我是会写代码的，我不是躲在 AI 背后：但事情已经变了，这不是你的软弱，也不是因为你被 AI 洗脑了。只是我们的领域正在朝着一个不可思议*而又*痛苦（但也充满快乐）的方向演进”。

这就是为什么昨天我在 X 上说，我认为此刻许多程序员之所以没有发挥出本可以发挥的影响力，是因为他们还在盯着代码看。我真心这么认为。请注意，这并不是说要用 vibe code(氛围编程)的方式直接向 AI 索要最终成品。重点在于：如果你掌控了软件的思想，那么盯着代码本身去看就是次优的，而且常常是毫无意义的。原因如下：

1. 你现在可以生成大量的代码，即便*不*考虑 LLM 代码的冗长（这在很大程度上也是因为大多数人还不懂得如何很好地指令它们）。你怎么可能每天去审查 5000 行代码？
2. LLM 非常擅长编写局部最优的代码，而在大的构想上则要差一些（不过正在进步）。逐函数、逐行地去扫描有什么意义？相反，你应该用提示词来表达你心中的设计，有时问一句“那部分的设计究竟是怎样的？它是如何工作的？”，然后评估它是否是正确的模型。这样要快得多。
3. 工作日只有 8 小时。如果你去读代码，这就是一种权衡。你会做更少如今工作中最重要的部分，也就是问自己：我用这个软件到底在做什么？我想朝哪些新方向前进？还有，去思考新的想法、功能、优化技巧。以及去做大量的 QA。

掌控思想。你还记得 Mythical Man Month（《人月神话》）中的这种说法吗？一本 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 有序集合节省 50% 内存的优化我也正在做类似的事，一个我很快会提交的 PR。但我已经不觉得这还有用了。以后不该再有人去看这些代码，而应该只看代码中所包含的思想。出于对用户的尊重，我才继续这么做。Redis 到今天已经是一个被广泛使用的工具，许多程序员会打开文件并手动修改一些东西。但如果让我放开手脚，你知道我会怎么做吗？把花在审查上的所有时间，用来做更多的 QA，去思考下一个优化点子并将其实现，以及用 LLM 来写一份 DESIGN.md 文件，用人类语言描述每一种数据结构，讲清楚它包含的思想、实现技巧和设计。那在未来会要有用得多。你想修改有序集合？打开文件，读懂设计，然后你就掌握了思想。你可以打开你的 agent，带着正确的心智模型去问它该怎么做。这比审查代码要有用得多。

对有序集合节省内存的审查，Fable 和 GPT 5.6 将会比我的审查发现多得多的错误和微妙的竞态条件。但我还是会去做。不过对于绝大多数软件项目来说，这一切已经没有意义了。转而去掌控思想吧。去关注质量、测试，以及对你想交付的软件有一个清晰的构想。世界已经变了，这很痛苦，但也充满了改进那个早已彻底腐烂的软件世界的机会。

我唯一的疑虑是关于年轻程序员，他们还没有足够的经验，无法建立起心智模型。我们还不知道，他们是否需要非常透彻地理解某一段代码是如何工作的，但我认为他们应该学习如何编写程序。然而，我不确定检查 LLM 的输出是否是他们应该做的事。如果他们学一门编程语言，去实现一个小型的解释器、一个小型的数据库、一张哈希表等等，可能会要有用得多。去审查某个客户网站的那些 JavaScript 代码？见鬼，别在那种破事上浪费时间了。