翻翻这个博客的历史就能看到，有很多篇关于用 AI 编程的文章，有些甚至可以追溯到 2024 年 1 月（比如这篇：https://antirez.com/news/140）。不管怎么说，我也算是个还算受认可的程序员。我没必要像个为了存在感而硬要留在“圈子”里的老人那样，我最近刚回归 Redis，现在还在开发一款用于本地 LLM 推理的新开源软件，在社区里也受到了不错的欢迎。那我为什么还要一直做这种事，说些大家不想听的话？为什么还要不断预告未来编程默认会是什么样子？因为我有一种紧迫感，想为那些比我对这场变化准备更不足的人减轻冲击，他们往往比我年轻，而且和我不同，并没有预见到这些事的发生（2022 年，在 ChatGPT 问世之前，我就出版了一本书，预告了如今已经发生的许多事，以及我相信*未来会*发生的事，所以我觉得这么说并不算自大）。

所以这算是我的一个小花招。越来越多的人感觉编程已经被 AI 彻底改变，却不知道自己该怎么办，不知道是否真的可以换一种完全不同的方式去写代码，不再把代码本身当作主要的产出。他们觉得这样做像是在背叛自己的领域。所以我想站出来说：“看看我，我会写代码，你知道的，我不是躲在 AI 背后：但时代已经变了，这不是你的软弱，也不是你被 AI 洗脑了。只是我们的领域正在朝着一个不可思议*又*痛苦（但也充满乐趣）的方向演进。”

这也是为什么昨天我在 X 上说，我认为现在很多程序员正因为盯着代码，反而没有发挥出本该有的影响力。我真心这么认为。要注意，这并不是说要去 vibe coding，随便让 AI 直接给你一个最终成品。关键在于：如果你掌控了软件背后的思想，那么盯着代码本身去看，往往是低效的，甚至是毫无意义的。原因如下：

1. 你现在可以生成大量的代码，就算*不*算上 LLM 本身代码冗长的问题（这在很大程度上也是因为大多数人还不会好好地指挥它们）。你怎么可能每天去 review 5000 行代码？
2. LLM 很擅长写出局部最优的代码，但在大的构想上则要差一些（不过也在进步）。逐个函数、逐行去扫有什么意义？相反，你应该把你心中的设计用 prompt 表达出来，有时问一句“那部分的设计到底是怎样的？它是怎么工作的？”，然后去判断这个模型是否正确。这样要快得多。
3. 工作日只有 8 小时。如果你把时间花在读代码上，就是一种权衡。你会因此少做当下工作中最重要的部分，那就是问自己：我用这个软件到底要做什么？我想往哪些新方向走？还有，去思考新的点子、功能、优化技巧。以及去做大量的 QA。

掌控思想。还记得《人月神话》里的这句话吗？一本 70 年代的书，对当下软件时代的揭示，反而比 2000 到 2020 年间说的许多东西都要多。为什么那些现在抗议 AI 的人，当初却没有对过去十年软件的状态感到震惊？在 AI 出现之前的几年里，我们所触及的 slop（粗制滥造）的程度简直难以置信。我再跟你说一件事。什么是 slop？用 DwarfStar，我以完全自动化的方式为两个 LLM（DeepSeek v4 和 GLM 5.2）实现了推理，但是：你自己试试就会发现，你不能只是说一句“把 XYZ 实现了”就能看到它跑起来。你必须理解其中的原理、什么是最好的设计、如何达到一定的性能。然后我为了验证正确性，把实现和其他系统做了对比，发现其他实现有时包含更多错误。我进一步研究后发现，本地推理的世界里充满了细微的错误，它们不断累积、损害模型输出，比如 attention 实现中的问题会导致上下文超过一定长度后性能下滑，因为带索引的 attention 实现是有缺陷的（比如做了比实际需要更多的工作），诸如此类。这是领域本身极其复杂、变化飞快、每天都有推理图谱略有不同的新模型发布所导致的结果。对开发者来说，这是一场不公平的游戏。而：AI 在这方面帮了大忙。在许多领域，严谨的工程（在设计层面）和测试，要*远比*手写一个 GPU kernel（或去读它）好得多。所以我们能确定，那些抵触大多不是出于意识形态吗？

昨天 Matteo Collina 回复我的推文问我：但你不是说过你会检查 Redis 里所有 AI 生成的代码吗？这确实是个好问题。是的，我会检查，但到现在，这已经是我*不得不*做、但我认为大多毫无意义的事了，GPT 5.5 发布后就部分如此，现在有了 Fable 和 GPT 5.6 Sol 就更是如此。是的：我会发现一些我不喜欢的写法，但如果我打开其他 Redis 贡献者写的 Redis 文件，里面有*糟得多*的东西，而且不是因为他们不是好程序员，只是因为这是品味问题。我写非常干净的代码，因为我希望它可读，所以在实现 Redis Arrays 时我做了修改。现在为了 Redis 有序集合节省 50% 内存的优化，我又在做同样的事，这是一个我很快会提交的 PR。但我不再觉得这有用了。以后不该再有人去看这些代码本身，而只该看代码所包含的思想。我之所以还继续这么做，是出于对用户的尊重。Redis 到今天已经是一个被广泛使用的东西，很多程序员会打开文件手动修改。但如果我能放开手脚，你知道我会怎么做吗？把花在 review 上的所有时间拿去做更多的 QA，去思考下一个优化点子并把它实现，以及用 LLM 来写一个 DESIGN.md 文件，用人类语言描述每个数据结构，讲清楚它包含的思想、实现技巧和设计。那在未来会要有用得多。想改有序集合？你打开文件，读设计，然后你就掌握了思想。接着你就可以打开你的 agent，带着正确的心智模型去让它做事。这比 review 代码要有用得多。

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

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