掌控思想，而非代码

掌控思想，而非代码 —— antirez

看看我这个博客的历史，里面有很多关于“用 AI 编程”的文章，其中最早的可以追溯到 2024 年 1 月（比如这篇：https://antirez.com/news/140）。我毕竟还算是个有点名气的程序员，没必要像个老家伙一样硬要赶时髦。我最近重返 Redis，同时还在开发一个新的开源本地 LLM 推理引擎，在社区里反响还不错。

那我为什么还要不停地说这些“大家不想听”的话？为什么还要反复预告未来的编程会是什么样子？因为我有一种强烈的责任感——我想帮那些比我准备不足的人（大多比我年轻，而且不像我那么早就看到趋势）减轻这次剧变带来的冲击。早在 2022 年 ChatGPT 出现之前，我就出版了一本书，提前预言了很多现在已经发生、以及我坚信即将发生的事。所以我说这些，算不上自大。

我的真实用意其实是个“小把戏”。越来越多程序员觉得编程已经被 AI 彻底颠覆了，他们不知道自己该怎么办，不知道还能不能以完全不同的方式写代码，不再把“写代码”当成主要工作。他们觉得自己像是在背叛自己的专业。而我想站出来告诉大家：“看，我还是能亲自写代码的，我没躲在 AI 后面。但时代确实变了，这不是你的无能，也不是你被 AI 洗脑了，只是我们的领域正在经历一场既痛苦又激动人心的进化。”

正因为如此，昨天我在 X（Twitter）上说：现在很多程序员的影响力其实被自己限制住了，因为他们还在死盯着代码看。我是真心这么相信的。但请注意，这不是说你只要随便喊一句“给我生成个成品”就行。核心观点是：如果你真正掌控了软件的思想，那么去一行一行看代码其实是低效、甚至毫无必要的。理由有三点：

代码量已经爆炸。现在随便一生成就是成千上万行（还不算 LLM 常见的啰嗦问题，那主要是提示词写得不够好导致的）。你每天怎么可能审完 5000 行代码？
LLM 擅长局部最优，却不擅长大局观（不过这方面也在快速进步）。逐函数、逐行地看，有什么意义呢？更好的做法是：把你心里的设计告诉它，必要时再问一句“这个模块的具体设计是什么？它是怎么运作的？”，然后判断这个模型对不对。这样效率高多了。
一天只有 8 小时。把时间花在读代码上，就意味着你在减少做真正重要的事：思考“我这个软件到底要解决什么问题？接下来要往哪个方向走？”，去构思新特性、新优化、新的设计技巧，同时做大量测试和验证。

掌控思想——这个说法你应该还记得，它出自《人月神话》。一本 70 年代的书，竟然比 2000–2020 年间大多数讨论都更能解释今天的软件世界。那些现在拼命反对 AI 的人，当年怎么没对软件行业的烂摊子感到愤怒？AI 出现之前那几年，我们制造的垃圾代码（slop）已经多到离谱了。

我再举个例子：我在开发 DwarfStar 时，完全用自动化方式为 DeepSeek v4 和 GLM 5.2 实现了推理。但你自己去试试就知道，绝不是一句“实现 XYZ”就能跑起来的。你必须深刻理解原理、最优设计、性能瓶颈在哪里。然后我对比了其他系统的实现，发现它们有时 bug 更多。我继续深挖后发现，本地 LLM 推理领域到处是细微的、累积性的错误——比如注意力机制实现有问题，导致上下文一长性能就雪崩；索引注意力实现效率低下却还做多余工作……这个领域极度复杂、变化极快，每天都有新模型发布，对开发者来说简直是一场不公平的游戏。

而 AI 在这方面帮了大忙。在很多领域，严谨的设计 + 大量测试，远比自己手写 GPU kernel（或者去读别人写的 kernel）要高效得多。所以，我们真的能确定，大部分对 AI 的抵抗不是出于意识形态吗？

昨天 Matteo Collina 回复我的推文，问我：“你不是说 Redis 里所有 AI 生成的代码你都会检查吗？”这个问题很好。是的，我现在还在检查。但我越来越觉得这事必要却无意义——尤其在 GPT 5.5 之后，现在有了 Fable 和 GPT 5.6 Sol 就更是如此。我确实能挑出一些我不喜欢的写法，但打开其他贡献者写的 Redis 文件，往往更糟糕。那不是因为他们水平差，而是代码风格和品味的问题。

我自己写代码追求极致干净和可读性，所以在实现 Redis Arrays 时改动了很多，现在又在为 sorted sets 的“节省 50% 内存”优化做同样的事（PR 很快就会发出来）。但我已经不觉得这有价值了。未来没人应该再盯着代码看，而应该只看代码背后的思想。

我现在继续检查代码，只是出于对用户的尊重——Redis 是被广泛使用的软件，很多开发者还会手动打开文件改东西。但如果完全由我决定，我会把审查代码的时间省下来：做更多测试、思考下一个优化点、用 LLM 写一份 DESIGN.md，用通俗语言把每个数据结构的思想、实现技巧和设计原理讲清楚。

那样才真正有用。你想改 sorted sets？先打开设计文档，掌握核心思想，然后用正确的 mental model 去指挥你的 AI agent。这比死盯着代码审查强太多了。

Fable 和 GPT 5.6 审查 sorted sets 内存优化时，能发现的错误和竞态条件会比我手动审查多得多。但我还是会做。不过对绝大多数软件项目来说，这种做法已经过时了。

把注意力放在掌控思想上，放在质量、测试和你真正想交付的产品愿景上。这个世界变了，虽然痛苦，但也充满了机会——去修复一个早已千疮百孔的软件生态。

我唯一还有顾虑的是那些经验尚浅的年轻程序员，他们可能还没建立起足够的 mental model。我们还不知道他们是否需要深入理解每段代码的细节，但我坚信他们应该先学会自己写程序。去实现一个小解释器、小数据库、哈希表之类的，会比审查 LLM 生成的代码有用得多。

至于审查某个客户网站的 Javascript 代码？拜托，别把时间浪费在那堆垃圾上了。

原文 https://antirez.com/news/169