推荐这篇文章：未来的程序员，要控制思想，而不是盯着代码

昨天，我在 X 上说了一句话：

很多程序员之所以没有产生本可以产生的影响，是因为他们仍然把大量时间花在阅读代码上。

这句话听起来很冒犯。

程序员不看代码，还能叫程序员吗？

但我真正想表达的，不是让大家放弃工程质量，也不是鼓励那种只说一句“帮我做个产品”，然后等 AI 交付最终结果的 Vibe Coding。

我的观点是：

当代码可以被大量、快速生成以后，程序员真正需要控制的，已经不再是每一行代码，而是代码背后的思想。

你必须知道软件要解决什么问题，采用什么设计，数据如何流动，边界条件在哪里，系统为什么能够正确运行。

至于这些思想最终被翻译成多少行代码，正在变得没那么重要。

01 为什么我一直在谈 AI 编程

回看这个博客，关于 AI 编程的文章已经写了很多。有些可以追溯到 2024 年 1 月。

我并不是因为担心自己被时代抛下，才拼命讨论 AI。

我重新加入了 Redis，也在开发一款用于本地大模型推理的新开源软件 DwarfStar。至少到现在，我仍然能够亲手写代码，也没有躲在 AI 后面假装自己是程序员。

我反复谈论这件事，是因为很多人已经感受到变化，却不敢承认。

他们发现，自己可以用一种完全不同的方式编程。他们不再把代码本身视为最重要的产出，甚至不再逐行检查代码。

可这又让他们产生了一种背叛感。

仿佛只要没有亲手写下每一行代码，就背叛了自己的职业。

所以我想告诉他们：

这不是你的软弱，也不是你被 AI 洗脑了。

只是软件开发正在发生一次剧烈、痛苦，同时也令人兴奋的变化。

02 逐行阅读代码，正在成为低效选择

过去，代码是稀缺产能。

一个工程师一天只能写有限的代码，所以阅读、审查和维护这些代码，是一种合理的工作方式。

现在，这个前提变了。

2.1 代码数量已经超出人工审查能力

借助大模型，一个程序员每天可以生成几千行代码。

这还没有考虑大模型普遍存在的代码冗长问题。

面对每天新增的 5000 行代码，你准备怎么审查？

逐个函数读，逐个分支检查，再追踪每个变量的生命周期？

一天只有八个小时。

当代码生成速度远远超过阅读速度时，继续依赖人工逐行审查，已经不是严谨，而是一种无法扩展的工作方式。

2.2 大模型擅长局部实现，真正容易出错的是整体设计

大模型已经很擅长生成局部正确的代码。

一个函数怎么写，一种数据结构怎么实现，某个接口如何调用，这些任务通常不是最危险的部分。

真正容易出问题的，是更大的东西：

系统采用了什么模型？

组件之间如何协作？

数据如何存储和流动？

性能瓶颈在哪里？

并发和故障场景如何处理？

与其扫描每一行代码，不如直接询问 Agent：

“这一部分的设计是什么？”

“数据从哪里进入，又从哪里离开？”

“这里为什么使用这种数据结构？”

“发生并发修改时，系统如何保证正确性？”

程序员需要判断的，是这个模型是否成立。

这通常比逐行阅读快得多，也更接近问题的本质。

2.3 阅读代码存在机会成本

一天只有八个小时。

你把两个小时花在阅读代码上，就意味着少了两个小时去思考：

• 这个软件究竟应该做什么？
• 下一步应该往哪里走？
• 还有哪些功能值得实现？
• 能不能找到新的优化方法？
• 如何设计更严格的测试？

过去，程序员的主要工作是把想法变成代码。

现在，代码已经不再是最稀缺的部分。

真正稀缺的是好的问题、好的设计、好的判断，以及足够严密的质量验证。

03 控制思想，不等于放弃工程

“控制思想”这句话，来自《人月神话》。

有意思的是，一本 20 世纪 70 年代的软件工程著作，可能比 2000 年到 2020 年之间的许多讨论，更接近今天的软件开发。

所谓控制思想，是指你必须真正拥有软件的心智模型。

你知道它为什么这样设计，知道每一种选择的代价，也知道哪些部分绝对不能出错。

这和一句话生成整个产品完全不同。

以 DwarfStar 为例。

我曾经借助 AI，几乎自动完成了两个大模型的推理实现。但实际过程并不是对 AI 说一句“实现这个模型”，然后等待程序自动运行。

你仍然需要理解模型的推理图，寻找合适的设计，分析性能瓶颈，还要通过其他实现交叉验证结果。

在这个过程中，我发现一些现有的本地推理系统同样存在错误。

有些错误出现在注意力机制的实现中。当上下文超过一定长度后，索引注意力会执行不必要的计算，性能随之下降。

这类问题非常隐蔽。

本地推理本身就是一个复杂、快速变化的领域。不同模型的推理图存在细微差异，新的模型又在不断发布。

对开发者来说，这是一场很不公平的游戏。

AI 在这里非常有价值。

因为在许多复杂领域，严谨地设计系统、理解算法、建立测试，比亲手写一个 GPU Kernel，或者逐行阅读它，更能保证最终质量。

04 真正应该增加的，是测试而不是阅读

有人问我：

你不是说过，Redis 中由 AI 生成的代码，你都会亲自检查吗？

是的，我现在仍然会这样做。

但我越来越怀疑，这件事是否值得。

在检查过程中，我确实会发现一些自己不喜欢的写法，也会把代码改得更符合个人审美。

可如果打开其他 Redis 贡献者编写的文件，同样能找到很多我不喜欢的实现。

这并不意味着他们不是优秀的程序员。

很多时候，只是编码风格和个人偏好的差异。

我喜欢把代码写得非常干净，因为我希望它容易阅读。

因此，在开发 Redis Arrays，以及优化 Redis 有序集合的内存占用时，我仍然会调整 AI 生成的代码。

但这些调整的实际价值正在下降。

如果可以自由分配时间，我宁愿把代码审查的时间用于三件事：

• 做更多质量测试。
• 寻找下一项优化。
• 把软件的核心设计写成清晰的文档。

未来，对一个项目更有价值的文件，也许不是某个源代码文件，而是 DESIGN.md。

它应该用人类语言解释每一种数据结构的设计、关键技巧、约束条件和实现思路。

当你需要修改 Redis 有序集合时，你先阅读设计文档，理解其中的思想，建立正确的心智模型。

然后再让 Agent 完成修改。

这比从第一行代码开始阅读，更有效。

05 代码审查也会逐渐交给模型

随着模型能力提高，大模型在代码审查上的表现，也会超过多数人工审查。

它们可以同时检查大量文件，追踪跨模块依赖，寻找细微的竞态条件，并反复执行静态分析和测试。

人类当然仍然要对结果负责。

但负责不等于亲自完成每一步。

飞行员要对飞机负责，却不需要亲自计算每一次姿态调整。建筑师要对建筑负责，也不需要亲手砌每一块砖。

程序员未来承担的责任，是控制软件的目标、架构和质量标准。

代码只是这些思想的一种表达形式。

在大多数软件项目里，把主要精力继续投入逐行阅读，已经很难获得最高回报。

更合理的做法是：

理解设计，控制方向，构建测试，验证结果。

06 年轻程序员仍然需要学习编程

我唯一无法确定的，是缺乏经验的年轻程序员该如何进入这个行业。

一个没有写过足够多代码的人，可能还没有能力建立完整的心智模型。

他不知道什么设计是合理的，也不知道哪些地方容易出错。

所以，年轻程序员仍然应该学习编程语言，也应该亲手实现一些基础系统。

写一个小型解释器。

写一个简单数据库。

实现一个哈希表。

做一个网络服务器。

这些练习能够帮助你理解程序如何运行，数据结构如何影响性能，抽象为什么会泄漏，错误为什么会出现。

但我不确定，逐行审查大模型生成的普通业务代码，是否是最好的学习方式。

检查某个客户网站里的一堆 JavaScript，并不会自动让你成为更好的程序员。

真正重要的是，通过完整的小项目，建立对计算机系统的理解。

07 软件开发的中心正在上移

过去，程序员通过代码控制软件。

未来，程序员会通过思想控制软件。

你需要定义目标，设计系统，建立约束，选择取舍，构造测试，并对最终结果负责。

代码生成会越来越便宜。

判断力不会。

软件行业已经发生变化。这种变化当然令人痛苦，因为它正在削弱许多程序员最熟悉、也最引以为傲的能力。

但它也带来了一个机会。

我们终于可以少花一点时间搬运语法，多花一点时间思考软件真正应该是什么。

不要只控制代码。

控制代码背后的思想。