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

AI沉思录 · 2026-07-31

昨天，我在 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 软件开发的中心正在上移过去，程序员通过代码控制软件。未来，程序员会通过思想控制软件。你需要定义目标，设计系统，建立约束，选择取舍，构造测试，并对最终结果负责。代码生成会越来越便宜。判断力不会。软件行业已经发生变化。这种变化当然令人痛苦，因为它正在削弱许多程序员最熟悉、也最引以为傲的能力。但它也带来了一个机会。我们终于可以少花一点时间搬运语法，多花一点时间思考软件真正应该是什么。不要只控制代码。控制代码背后的思想。