掌控思想，而非代码：AI 时代的编程新范式

看看这个博客的过往历史吧。关于用人工智能进行编程的博文数不胜数，其中不乏早在2024年1月就发表的帖子——比如这篇：antirez.com/news/140。 毕竟，我可是个相当受人尊敬的程序员。 我并不需要像一位老者那样，依然徘徊在“循环”之中，苦苦追寻那些所谓的“相关性”。 最近，我重新加入了Redis团队，如今还致力于开发一款用于本地LLM推理的新开源软件， 这款软件在社区中受到了热烈欢迎。为什么我还要不断做这些事、说出那些人们不愿听的话？ 为什么我总是大肆宣扬未来编程将默认采用何种模式？ 因为我内心深处有一种强烈的冲动：希望为那些尚未做好迎接变革准备的人们——尤其是比我年轻得多、 却往往缺乏足够经验的人——降低变革带来的冲击。 而我本人，也从未真正预料到这些变化会如此迅速地到来。 （早在2022年，也就是ChatGPT问世之前，我就出版了一本书，提前预言了许多如今已然发生的事， 以及许多我坚信未来还会发生的种种变化。 因此，我觉得自己完全有资格坦然地说出这些话，而不必显得过于自恋。 ）

所以，我的做法其实是一种“小技巧”。 如今，越来越多的人觉得，编程已经彻底被人工智能所重塑，他们甚至不知道自己究竟该怎么做——如果真的想以一种全新的方式来编写代码， 又该如何着手呢？在这样的情况下，他们往往不再把目光过多地聚焦于代码本身， 而是更倾向于将其视为自己的主要输出成果。 他们觉得自己仿佛背叛了自己所从事的领域。 因此，我的初衷就是站出来，大声说一句：“看好了！ 我也可以写代码，你知道的，我并没有躲在AI的背后； 事实上，时代已经变了，这并不是你的弱点，也不是因为你被‘AI化’了。 只是我们的行业正以一种令人惊叹、却又充满痛苦（但同时也无比喜悦）的方式不断演进。 ”

正因为如此，昨天我在X平台上曾说过：我相信，如今的许多程序员，其影响力其实远不如自己本可以发挥的水平——因为他们总是盯着代码看。 这一点，我真心相信。而且，请注意，这绝不是在提倡“盲目地迎合代码”，更不是在要求大家一味地追求最终的产品。 关键在于：如果你能够掌控自己软件的设计理念，那么仅仅盯着代码本身，往往适得其反， 甚至毫无意义。原因如下：

1. 如今，我们已经能够生成大量代码，甚至在不考虑LLM代码冗长程度的情况下也是如此——而这恰恰是因为我们无法对它们进行充分的指令引导， 尤其是在大部分环节上。你又怎么可能每天仔细审阅5000行代码呢？

2. LLM在编写局部最优代码方面表现得非常出色，但在面对宏大的设计思路时，却往往力不从心， 甚至有所退步。那么，你何必一个函数一个函数、一行一行地去逐一扫描呢？ 相反，你应该先明确自己心中构想的设计方案，有时还可以这样提问：“那部分的设计究竟是怎样的？ 它是如何运作的？”然后，再根据实际情况评估是否选择了最合适的模型。 这样做，效率要高得多。

3. 一天的工作时间是8小时。如果你花时间阅读代码，那其实是在权衡取舍：你实际上减少了那些当下工作中最为重要的部分——也就是反复思考： “我究竟在用这个软件做什么？我想要探索哪些新的发展方向？ ”同时，你还需要不断萌发新想法、开发新功能、优化现有技术。 此外，你还要投入大量时间进行质量保证和测试工作。

掌控思想。你还记得《神话般的项目管理》里那句经典表述吗？ 其实，一本诞生于上世纪70年代的著作，比我们在2000年至2020年间听到的许多观点， 都更加深刻地揭示了当今软件行业的现状。 为什么那些如今对AI持反对态度的人，竟然对过去十年间软件行业的状况毫不感到惊恐？ 在AI出现之前，我们所经历的种种低劣与粗糙，其程度之深、之多，简直令人难以置信。 再补充一点：什么是“低劣”？借助DwarfStar，我以完全自动化的方式实现了两款LLM（DeepSeek v4和GLM 5.2）的推理功能。不过，不妨亲自试一试——你会发现，你根本不可能简单地只说一句“实现XYZ”， 就能让系统顺利运行。你必须真正理解这些算法的工作原理，弄清最佳的设计方案， 以及如何将系统性能提升至理想水平。随后，我将这一实现方案与其他系统进行了对比， 结果发现，其他实现方案中往往存在更多的错误。 经过进一步研究，我了解到：在本地推理领域，潜藏的细微错误层出不穷，这些错误会不断累积， 最终损害模型的输出效果；注意力机制的实现问题，也会导致在上下文长度超过一定阈值后， 性能出现明显下滑——因为索引注意力机制本身存在缺陷，明明应该完成更多计算， 却反而耗费了过多资源（例如，原本应该更高效地完成任务，却因某些原因反而增加了不必要的开销）。 这一切，都源于这样一个领域：它既复杂难治，又瞬息万变； 而且，每天都有新的模型在推理图中诞生，彼此之间也存在着细微差异。 对于开发者而言，这无疑是一场不公平的游戏。 不过，AI在这方面确实帮了大忙。在许多领域，严谨的工程设计（尤其是设计层面）和严格的测试， 远比手动编写GPU内核（或仅仅依靠阅读代码）要高效得多。 那么，我们真的能断言，大多数人的抗拒情绪并非出于意识形态的考量吗？

昨天，Matteo Collina在回复我的推文时问道：“你不是说过，你会对Redis生成的所有AI代码进行检查吗？ ”这个问题确实很有道理。没错，我确实会这么做，但此刻，这项工作对我来说虽然有必要， 却在我看来几乎毫无意义——至少在GPT 5.5发布之后，情况更是如此；而如今，随着Fable和GPT 5.6的推出，这种必要性变得更加迫切。 的确，我会识别出一些代码编码方式让我不太满意的地方； 然而，当我翻阅其他Redis贡献者的代码时，却发现情况要糟糕得多——而且， 这并不是因为这些开发者不够擅长编码，而是因为这纯粹是个人品味的问题。 我之所以写得非常干净、清晰，是因为我希望代码易于阅读； 因此，在实现Redis数组时，我也曾对代码进行了诸多调整。 如今，我又一次为Redis有序集合的内存节省优化方案付诸实践——这项PR即将提交。 不过，我已不再觉得这种做法有什么太大意义。 如今，没有人再应该盯着这些代码看，而应该专注于代码所蕴含的理念。 我之所以坚持这么做，只是为了尊重用户。 如今，Redis已经成为一项极为实用的工具，许多程序员都会打开文件，亲手修改其中的内容。 但如果我双手空闲，你知道我会怎么做吗？ 我会把原本用来审查代码的时间，全部用来进行更多的质量保证测试，思考下一个优化方向并付诸实施； 同时，我还愿意利用LLM，撰写一份“DESIGN.md”文档，将每一种数据结构都用人类的语言加以描述， 详细阐述其背后的理念、实现技巧以及设计思路。 在未来，这样的做法将会带来更大的价值。 你想修改有序集合吗？只需打开文件，阅读设计思路，然后你便能掌握其中的精髓。 你可以随时召唤自己的代理，让它根据正确的思维模型，为你做出相应的决策。 相比单纯地查看代码，这种方式要实用得多。

Fable和GPT 5.6针对有序集合内存节省优化的审查，将会发现更多潜在的错误和微妙的竞态条件——而这些正是我以往审查中未曾察觉的。 尽管如此，我仍然会继续进行这样的审查。 不过，对于大多数软件项目而言，这一切早已失去了意义。 与其纠结于“盯着代码看”，不如把重心放在“掌控思想”上； 把精力集中在提升质量、加强测试，以及对即将交付的软件有一个清晰的构想上。 这个世界已经发生了翻天覆地的变化，虽然过程充满阵痛，但也蕴藏着无数机遇， 让我们有机会去改善这个本已腐朽不堪的软件世界。

我唯一担心的是那些缺乏足够经验、尚无法建立起完整思维模型的年轻程序员。目前我们还不知道，他们是否真的需要深入理解某段代码的运行机制；但我相信，他们应当学会如何编写程序。

不过，我也不确定，是否真的应该一味地去检查LLM的输出结果。或许，如果他们能学习一门编程语言，并实现一个小型的解释器、一个小型数据库、一个哈希表等工具，那会更有助于他们的成长。

去审核某个网站上的一些JavaScript代码，为客户提供服务？当然不！别浪费时间在这类事情上。评论