# LLM时代程序员的懒惰美德正在消亡

### 引言

你是否也有过这样的经历：用 LLM 写代码，一天下来产出了几千行，回头看却发现——真正有价值的可能不到几百行？

听起来离谱但这其实是很正常的现象。Oxide 公司 CTO、DTrace 的联合创始人 Bryan Cantrill 最近写了一篇文章 [The Peril of Laziness Lost](https://bcantrill.dtrace.org/2026/04/12/the-peril-of-laziness-lost/)，直指这个问题的心脏：**LLM 正在杀死程序员最重要的美德——懒惰。**

这篇文章不长，但观点犀利，值得每个使用 LLM 写代码的人认真读一读。

---

### 一、程序员的三大美德，你真的理解"懒惰"吗？

Larry Wall 在经典著作《Programming Perl》（被一代技术人员亲切地称为"骆驼书"）中提出了程序员的三大美德：

> **懒惰（Laziness）、急躁（Impatience）、傲慢（Hubris）**

这三个词看起来都是贬义，但 Larry Wall 用的是反讽式的表达。其中，Cantrill 认为**懒惰是最深刻的那个**。

为什么？因为这里的"懒惰"不是表面意义上的偷懒，反而它是一个褒义词，代表了一种**驱动力**。

真正的懒惰驱动程序员去构建优雅的抽象。当你不想重复写同样的代码，你就会封装一个函数；当你不想重复处理同类的逻辑，你就会设计一个通用的框架。用 Cantrill 的话说：

> **懒惰驱使我们让系统尽可能简单（但不能更简单！），开发出强大的抽象，从而让我们能更轻松地做更多的事。**

但这有一个隐含的矛盾：**要真正"懒"，你得先很"勤快"。**

![程序员三大美德](https://leafw-blog-pic.oss-cn-hangzhou.aliyuncs.com/posts/laziness-lost/01-infographic-three-virtues.png)

想想你自己最满意的代码——是不是那些花了大量时间思考、反复推敲，最终写出来却极其简洁的方案？Cantrill 提到了"吊床驱动开发"（hammock-driven development）的概念。你以为程序员躺在吊床上是在摸鱼？不，那是在脑子里反复翻转问题，寻找最优雅的解法。

**懒惰的本质是：用当下的深度思考，换取未来的轻松。**

---

### 二、虚假勤奋的崛起

Cantrill 接着指出一个趋势：过去二十年，软件开发者群体急剧膨胀，越来越多的人并不把自己叫做"程序员"。这本身不是问题，但它带来了一个副作用——**虚假勤奋**（false industriousness）的崛起。

具体表现是什么？就是所谓的 **brogrammer** 文化。

Brogrammer 是 brother + programmer 的合成词，指的是一种程序员亚文化：用代码行数衡量产出，用加班时长证明努力，在社交媒体上晒"crushing code"（疯狂写代码）。在这种文化中，**量大于质**，**忙碌大于思考**。

而懒惰——那种驱动你停下来思考、寻找更好方案的懒惰——被边缘化了。

![美德式懒惰 vs 虚假勤奋](https://leafw-blog-pic.oss-cn-hangzhou.aliyuncs.com/posts/laziness-lost/02-comparison-virtuous-laziness-vs-false-industriousness.png)

Cantrill 把这种文化比作**干柴**（dry tinder），只差一颗火星就会点燃。

---

### 三、LLM：虚假勤奋的类固醇

那颗火星就是 LLM。

> **无论你对软件创作的态度如何，LLM 都能让这种态度以（大得多的）更大的力量施加。**

这句话是整篇文章的关键洞察之一。LLM 本身是中性的工具，但它会**放大**使用者已有的倾向。如果你本来就追求简洁和优雅，LLM 能帮你更快达到目标；但如果你本来就追求"多就是好"，LLM 就会让你在这个方向上越走越远。

![LLM 放大效应](https://leafw-blog-pic.oss-cn-hangzhou.aliyuncs.com/posts/laziness-lost/03-infographic-llm-amplifier.png)

Cantrill 举了一个极具代表性的例子：Garry Tan。

Garry Tan（Y Combinator 现任 CEO）一直在社交媒体上炫耀自己用 LLM 写代码的"效率"，甚至声称自己**每天写 37,000 行代码**，而且"还在加速"。

37,000 行。一天。你品品这个数字。

如果懒惰是程序员的美德，那这种思维方式显然是恶习。就像用重量来衡量文学价值一样荒谬——一个刚学编程的新手都能看出其中的问题。

---

### 四、拆解一个"高效"的产物

更有意思的是，有人真的去拆解了 Garry Tan 用 LLM 高速搭建的"newsletter-blog"项目。波兰软件工程师 Gregorein 做了这个工作，结果既在意料之中，又令人哭笑不得：

- 多个**测试工具**（test harnesses）被塞进了项目
- 一个完整的 **Hello World Rails 应用**
- 一个**搭便车的文本编辑器**——跟项目毫无关系
- **八个不同版本的同一个 logo**——其中一个文件大小是零字节

!["高效"产物拆解](https://leafw-blog-pic.oss-cn-hangzhou.aliyuncs.com/posts/laziness-lost/04-infographic-code-bloat-breakdown.png)

你可能觉得这些只是小问题，都可以修。Cantrill 的回应是：**问题不在于这些 bug 本身。**

> **问题在于，LLM 天生缺乏懒惰的美德。**

---

### 五、核心论点：没有约束，就没有优雅

这是整篇文章最核心的段落，值得逐句品味：

> **工作对 LLM 来说没有任何成本。LLM 不会觉得需要为自己（或任何人）的未来时间做优化，它们会愉快地把越来越多的垃圾堆叠在一起。如果不加约束，LLM 会让系统变得更大，而不是更好——也许能满足扭曲的虚荣指标，但代价是一切真正重要的东西。**

Cantrill 进一步阐述了约束与优雅之间的关系：

> **我们有限的时间迫使我们开发出清晰的抽象，部分原因是我不想在糟糕抽象的后果上浪费自己的（人类的！）时间。最好的工程总是诞生于约束之中。**

这句话让我深有感触。回忆一下你自己的经历：

- **当你时间充裕**时，是不是倾向于写"先跑起来再说"的代码？
- **当你面临严格的交付压力**时，反而更容易逼出简洁的设计——因为你知道，复杂的方案后续维护会让你崩溃？

这正好反映出**约束塑造了设计**。人类时间的有限性，恰恰是推动我们追求简洁和优雅的根本动力。

![约束塑造设计](https://leafw-blog-pic.oss-cn-hangzhou.aliyuncs.com/posts/laziness-lost/05-infographic-constraint-breeds-elegance.png)

Cantrill 还引用了他自己的演讲《The Complexity of Simplicity》（简洁的复杂性），强调追求简洁本身就是一项艰巨的工作——我们不能期望不受时间或认知负载约束的 LLM 自主完成这项工作。

---

### 六、Cantrill 的立场：不是反 LLM，而是反误用

值得注意的是，Cantrill **并不是在反对 LLM**。

他明确表示：

> **LLM 在我们的未来中将扮演重要角色：它们是软件工程的非凡工具，但——正如我们在 Oxide 的 LLM 使用指南中所概述的——它们只是工具。**

关键在于：**LLM 必须服务于人类的"美德式懒惰"。**

具体来说，Cantrill 认为 LLM 应该被用来：

- **攻克技术债**——那些我们知道该修但一直拖延的问题
- **提升工程严谨性**——帮助我们做到自己没时间做到的细致
- **最终目标是产出一个更简洁、更强大的系统**

而不是：

- 追求代码行数
- 用膨胀的功能清单来证明"效率"
- 把"能跑"当成唯一标准

![正确使用 LLM vs 误用](https://leafw-blog-pic.oss-cn-hangzhou.aliyuncs.com/posts/laziness-lost/06-comparison-correct-vs-wrong-llm-usage.png)

---

### 七、我的思考

读完这篇文章，我最深的感受是：**约束恰恰是推动我们追求优雅的根本动力。**

这让我想到用胶片相机或者拍立得这类相机拍照的体验，一卷胶片可能只有二三十张，每按一次快门就少一张。正因为这个限制，你会更认真地构图、更谨慎地选择光线和时机。而当你珍视每一次按下快门的机会时，拍出的照片往往比想象中更好。

软件工程也是如此。**代码行数是最差的衡量指标之一**，因为它衡量的是付出的努力，甚至某种程度上存在一些无效努力。一个花了三天思考、最终写了 50 行优雅代码的程序员，比一个一天写了 5000 行但充满重复和冗余的程序员，创造了更多的价值。

LLM 是一个强大的工具，这一点毫无疑问。我自己也大量使用 LLM 辅助编程。但 Cantrill 的文章提醒我们：**在使用 LLM 时，不要放弃你作为人类的"懒惰"——停下来思考，这个抽象是不是足够好？这段代码是不是足够简洁？这个设计是不是足够优雅？**

LLM 可以帮你更快地到达目的地，但**目的地本身必须由你来选择**。

---

### 总结

| 观点 | 说明 |
|------|------|
| 懒惰是程序员的核心美德 | 懒惰驱动构建优雅抽象的力量 |
| LLM 天生缺乏懒惰 | 对 LLM 来说工作没有成本，不会主动优化 |
| 约束塑造设计 | 人类时间的有限性逼出简洁的设计 |
| LLM 放大已有倾向 | 追求质量的人会更好，追求数量的人会更糟 |
| LLM 只是工具 | 应服务于人类的"美德式懒惰" |

**一句话总结：** 人类时间的有限性是逼出优雅设计的根本动力。LLM 没有这种约束，所以它会让系统变得更大而非更好——除非我们人类用自己的"懒惰"来驾驭它。

---

> **参考链接：** [The Peril of Laziness Lost — Bryan Cantrill](https://bcantrill.dtrace.org/2026/04/12/the-peril-of-laziness-lost/)
>
> **相关视频：** [The Complexity of Simplicity — Bryan Cantrill](https://www.youtube.com/watch?v=Cum5uN2634o)