掌控思想，而非代码

背景

本文作者是 Redis 的创始人 antirez（Salvatore Sanfilippo）。他是一位在编程社区中备受尊重的资深程序员，最近重新加入 Redis 公司，并正在开发一个用于本地 LLM 推理的开源软件（DwarfStar），该项目已获得社区良好反响。antirez 在 2022 年（ChatGPT 出现之前）就出版了一本书，提前预测了许多当前已发生以及他认为 将会 发生的事情。他认为自己有责任说出许多人不愿意听的观点，帮助那些比他更年轻、对变化准备不足的程序员应对 AI 带来的行业剧变。

核心内容

antirez 认为，如今许多程序员仍在过度关注代码本身，这反而限制了他们的影响力。他主张程序员应该 控制软件背后的思想（ideas），而不是控制代码。以下是他的完整论述：

1. 时代已经改变：AI 正在彻底改变编程方式。程序员不必再以代码为主要产出，而是应该将更多精力放在设计、测试、方向思考和质量保障上。查看代码本身往往是次优且无意义的做法。

2. 为什么看代码是低效的？

   • 现在 LLM 可以生成大量代码（甚至不考虑其冗余性），你不可能每天审查 5000 行代码。
   • LLM 非常擅长编写局部最优的代码，但在处理大型架构思路方面较弱（尽管在改进）。逐函数、逐行扫描代码意义不大，更好的方式是：描述你脑海中的设计，询问 LLM “这部分的具体设计是什么？它是如何工作的？”，然后评估模型是否正确。这快得多。
   • 工作日只有 8 小时。如果花时间读代码，就是在牺牲当前工作中最重要的部分：问自己“这个软件到底要实现什么？下一步想往哪个方向发展？”以及思考新想法、新功能、优化技巧，并进行大量 QA。这本质上是控制思想。

3. 《人月神话》的智慧：这本 1970 年代的书对当前软件时代的洞察，比 2000 年到 2020 年间许多言论更有价值。antirez 质问：那些现在抗议 AI 的人，为何在过去十年对软件的“垃圾”状态（slop）毫不震惊？在 AI 出现之前，软件行业的低质量水平已经令人难以置信。

4. 以 DwarfStar 项目为例：antirez 用 DwarfStar 实现了两个 LLM（DeepSeek v4 和 GLM 5.2）的完全自动化推理。但他发现，你不能简单地说“实现 XYZ”就能直接工作。你必须理解事物如何运作、什么是最好的设计、如何达到特定性能。他对比了其他实现，发现其中常包含更多错误。本地推理领域充满了微妙的错误（例如注意力实现中的问题导致上下文超过某个限制后性能下降）。这是一个极其复杂、快速变化的领域，开发者面临不公平的游戏。AI 在此类领域大有帮助：严格的设计工程和测试远胜于手写 GPU 内核（或阅读它）。所以，许多抵制是否只是意识形态上的？

5. 回应 Matteo Collina 的问题：对方曾问 antirez：“你不是说你会检查 Redis 中所有 AI 生成的代码吗？” antirez 承认他确实这么做，但这只是出于对用户的尊重，他认为这大部分已经毫无意义。即使在他发现某些代码风格不符合他喜好时，但如果打开其他 Redis 贡献者写的文件，情况“糟糕得多”——这并非因为他们能力差，而是品味问题。antirez 追求整洁可读的代码，因此他在实现 Redis Arrays 时进行了改动，现在又在做 Redis 有序集合节省 50% 内存的优化 PR。但他觉得这种做法不再有用——没有人应该再看这些代码，而应该看代码背后的思想。如果有自由，他会把审查时间全部用于做更多 QA、思考下一个优化想法并用 LLM 编写一个 DESIGN.md 文件，用人类语言描述每个数据结构的设计、实现技巧和原因。这比审查代码有用得多。未来，要修改有序集合只需阅读设计，掌握思想，然后代理就能在正确心智模型下操作。

6. AI 审查更可靠：Fable 和 GPT 5.6（指代 AI 工具）对有序集合内存节省的审查会发现比他的审查多得多的错误和微妙竞态条件。

7. 对年轻程序员的建议：对于经验不足、无法构建心智模型的年轻程序员，antirez 不确定他们是否需要深入理解某段代码的工作原理。他认为他们应该学会如何编写程序，但检查 LLM 输出可能不是正确做法。更有用的是学习某种编程语言并实现一个小型解释器、一个小型数据库、一个哈希表等。审查某个客户的网站的 JavaScript 代码？“不，别在那些垃圾上浪费时间。”

关键要点

• 核心主张：程序员应从审查代码转向控制软件的思想（ideas），即专注于设计、方向、QA 和创新，而非逐行检查 AI 生成的代码。
• 理由一：LLM 能生成海量代码，手动审查不切实际；LLM 擅长局部优化但弱于全局设计，因此应聚焦于评估设计而非代码细节。
• 理由二：工作时间有限，读代码挤占了思考软件本质、新方向、新功能的时间，这些才是程序员当下最重要的职责。
• 理由三：AI 本身已经足够可靠，能发现比人类更多的错误（如 Fable、GPT 5.6 等），特别是复杂领域的微妙问题（如注意力实现缺陷）。
• 对“代码审查”的反思：即使是 Redis 这样要求高质量的项目，antirez 认为自己审查 AI 生成的代码更多是出于对用户的尊重，实际价值已很低；更好的做法是编写高质量的 DESIGN.md 文档。
• 对软件行业现状的批判：AI 出现之前，软件业已存在大量低质量代码（slop），现在许多抗议 AI 的人当时并未同样震惊。
• 对年轻程序员的启示：不应花时间审查 web 项目的琐碎代码，而应通过学习底层实现（如解释器、数据库、哈希表）来建立扎实的心智模型。检查 AI 输出不是学习编程的最佳方式。

意义与影响

这篇文章反映了 AI 时代资深程序员对编程范式转变的深刻思考。antirez 作为 Redis 官方维护者和行业标杆，其观点具有重要影响力：

• 重新定义编程核心技能：传统“写代码”的价值正被 AI 削弱，而“控制思想”——即设计、架构、测试和方向决策——成为更稀缺的能力。这可能会推动软件工程教育和工作流程的变革。
• 挑战“代码审查”教条：长期以来，代码审查被视为保证质量的关键。antirez 认为在 AI 生成代码足够可靠的情况下，它已变成低价值活动。未来可能会更多依赖 AI 辅助审查和设计文档驱动的开发模式。
• 对反 AI 情绪提供新视角：他点明许多抵制可能源于意识形态而非实际问题。AI 不仅没有降低软件质量（实际在修复许多隐性错误），反而帮助开发者应对复杂领域。
• 警示年轻程序员：不要被 AI 的“黑箱”输出麻痹，应通过亲手实现基础数据结构来打下牢固根基，同时避免在低价值任务上消耗精力。
• 对开源生态的启发：antirez 提出用 DESIGN.md 替代代码审查，意味着开源项目可能转向“思想文档+AI 审查”的新协作模式，这有望提升项目可维护性和新人上手效率。

总体而言，文章倡导一种更主动、更聚焦于本质的编程哲学：不要做 AI 的校对员，要做软件思想的架构师。