AI 时代，程序员的“懒惰”为什么仍然重要

优秀程序员的三种美德是懒惰、急躁和傲慢。这些听起来像糟糕的品质，但玩笑背后有认真道理：急躁让你想解决反复出现的问题，自信让你相信自己能做到，懒惰则促使你一次解决，免得不断重复劳动。

随着写代码的方式改变，懒惰的含义也在变化。程序员现在可以通过不断向模型输入提示产出大量内容，但这不一定是这些美德所说的省力设计。Bryan Cantrill 的文章《The Peril of Laziness Lost》让我想重新讨论其中的区别。

这个说法来自 Larry Wall 的《Programming Perl》。书中以幽默方式把懒惰与构建省力工具和编写文档联系起来，把急躁与让软件预判需求联系起来，把傲慢与推动人们编写并维护值得尊重的软件联系起来。这些是思考软件的视角，不是字面的招聘标准。

抽象可以用循环、函数或其他可复用的思路替代反复复制粘贴，但不断堆高抽象层也可能是错误。难点在于减少不必要的劳动和复杂度，同时避免为问题引入超出需要的机制。

Cantrill 认为，有意义的懒惰需要付出努力：反复思考问题，在当下投入精力，找到能在未来节省时间的简单抽象。当设计成功时，收益不只属于原作者，也会惠及后来在系统上构建的人。简洁需要设计，不能成为不思考的借口。

这也是我喜欢做 T3 Stack 的原因。我希望计算机能告诉我前端和后端边界上出现的错误。我觉得某些现有方案设置起来太重，因此想用更少的抽象，让全栈类型安全更容易使用。

它的起源故事也符合这三种美德。我希望一次讲清这个技术栈，而不是反复回答相同问题。社区成员 Nexile 最初创建了 create T3 app，让配置更快捷；后来其他贡献者也加入了，包括深度参与我们项目的 Julius。

看到其他开发者使用这些成果很令人满足，因为好的抽象能让更多人更轻松地构建东西。Cantrill 希望受益于抽象的人也能继续改善自己的系统。但随着更多人参与软件创建，程序员懒惰一词原本带有反讽意味的含义可能逐渐流失。

Cantrill 将这种态度与追求忙碌感、炫耀代码产量的文化作对比。语言模型可能放大使用者原本的倾向。如果目标变成获得生产力的感觉，快速增长的代码行数就可能被误认为软件的改进。

文章引用 Garry Tan 一条帖子，其中称五个项目每天产出 3.7 万行代码，并将其与 DTrace 的粗略代码行数比较。我同意，把写了多少行当作主要成就不是评价工程的好方法。这些数字来自不同情境，单凭它们不能判断任何一个项目的质量。

我记得曾用 T3 Stack 把朋友的一个全栈示例应用从数千行缩减到不到 500 行。我想说明的是，更好的抽象可以减少人们需要维护的代码。代码更少并不能自动证明其正确，也不能免除适当测试。

Cantrill 引用另一位工程师对某个简报网站的检查，称页面加载了不必要的内容，包括测试工具和多个标志版本。他把这些可修复的问题当作更广泛风险的例子：不加约束的生成可能不断堆积内容，却不考虑是否让系统更简单。这是他引用的案例，并非我独立完成的审计。

我担心模型可能让难以维护的代码库更容易长期存在：它们可以不断向人类团队难以维护的系统添加改动。这是对激励机制和后果的担忧，并不能证明每个由 AI 协助维护的项目都会变得无法维护。人工审查和有意识的清理仍然重要。

Cantrill 认为，人类有限的时间和注意力会促使我们追求清晰的抽象。模型不会像人一样在意未来维护生成内容的成本；团队必须设定目标并评估结果。运行模型会消耗资源，但它不会像人类一样体验维护工作的负担。

这并不是反对使用大语言模型。Cantrill 将它们视为可以帮助处理技术债务、提高工程严谨性的工具。我同意：可以让模型承担困难工作，但要引导它构建更简单、更有力、让未来维护者能够理解的系统。

我很高兴看到一种中间立场：既重视代码质量，也愿意使用 AI，而不是仅仅庆祝大量生成代码。被称为 Uncle Bob 的 Robert C. Martin 认为，减少对语法的关注，可以让我们有精力思考更重要的问题。

我过去批评过一些整洁代码模式过度抽象，现在仍认为这是实际风险。平衡点是尽可能简化系统，同时不掩盖必要的复杂性。即便 AI 处理更多语法细节，我们仍要关心不必要的膨胀和整个系统的设计。

Theo 播放了一段 Bryan Cantrill 讨论 Oracle 和 OpenSolaris 的演讲片段。Cantrill 用刻意尖锐的割草机比喻，反对把人的感情或关切归因于公司的行为。这是他对那段历史的修辞性评价，不是对任何人内心动机的事实陈述。

我把这个比喻带回大语言模型：我们不能依赖工具替我们关心软件质量。人必须决定什么重要、指导工作并检查结果。否则，输出可能看起来能运行，却积累复杂性，随着时间侵蚀系统。

目标是保持有建设性的懒惰：用自动化和经过思考的抽象节省未来的劳动，同时对所构建软件的质量负责。继续使用提示词，也继续努力让软件变得更好。