引言
你是否也有过这样的经历：用 LLM 写代码，一天下来产出了几千行，回头看却发现------真正有价值的可能不到几百行？
听起来离谱但这其实是很正常的现象。Oxide 公司 CTO、DTrace 的联合创始人 Bryan Cantrill 最近写了一篇文章 The Peril of Laziness Lost，直指这个问题的心脏：LLM 正在杀死程序员最重要的美德------懒惰。
这篇文章不长，但观点犀利，值得每个使用 LLM 写代码的人认真读一读。
一、程序员的三大美德，你真的理解"懒惰"吗？
Larry Wall 在经典著作《Programming Perl》（被一代技术人员亲切地称为"骆驼书"）中提出了程序员的三大美德：
懒惰（Laziness）、急躁（Impatience）、傲慢（Hubris）
这三个词看起来都是贬义，但 Larry Wall 用的是反讽式的表达。其中，Cantrill 认为懒惰是最深刻的那个。
为什么？因为这里的"懒惰"不是表面意义上的偷懒，反而它是一个褒义词，代表了一种驱动力。
真正的懒惰驱动程序员去构建优雅的抽象。当你不想重复写同样的代码，你就会封装一个函数；当你不想重复处理同类的逻辑，你就会设计一个通用的框架。用 Cantrill 的话说：
懒惰驱使我们让系统尽可能简单（但不能更简单！），开发出强大的抽象，从而让我们能更轻松地做更多的事。
但这有一个隐含的矛盾：要真正"懒"，你得先很"勤快"。
想想你自己最满意的代码------是不是那些花了大量时间思考、反复推敲，最终写出来却极其简洁的方案？Cantrill 提到了"吊床驱动开发"（hammock-driven development）的概念。你以为程序员躺在吊床上是在摸鱼？不，那是在脑子里反复翻转问题，寻找最优雅的解法。
懒惰的本质是：用当下的深度思考，换取未来的轻松。
二、虚假勤奋的崛起
Cantrill 接着指出一个趋势：过去二十年，软件开发者群体急剧膨胀，越来越多的人并不把自己叫做"程序员"。这本身不是问题，但它带来了一个副作用------虚假勤奋（false industriousness）的崛起。
具体表现是什么？就是所谓的 brogrammer 文化。
Brogrammer 是 brother + programmer 的合成词，指的是一种程序员亚文化：用代码行数衡量产出，用加班时长证明努力，在社交媒体上晒"crushing code"（疯狂写代码）。在这种文化中，量大于质 ，忙碌大于思考。
而懒惰------那种驱动你停下来思考、寻找更好方案的懒惰------被边缘化了。
Cantrill 把这种文化比作干柴（dry tinder），只差一颗火星就会点燃。
三、LLM：虚假勤奋的类固醇
那颗火星就是 LLM。
无论你对软件创作的态度如何，LLM 都能让这种态度以（大得多的）更大的力量施加。
这句话是整篇文章的关键洞察之一。LLM 本身是中性的工具，但它会放大使用者已有的倾向。如果你本来就追求简洁和优雅，LLM 能帮你更快达到目标；但如果你本来就追求"多就是好"，LLM 就会让你在这个方向上越走越远。
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------其中一个文件大小是零字节
你可能觉得这些只是小问题，都可以修。Cantrill 的回应是：问题不在于这些 bug 本身。
问题在于，LLM 天生缺乏懒惰的美德。
五、核心论点：没有约束，就没有优雅
这是整篇文章最核心的段落，值得逐句品味：
工作对 LLM 来说没有任何成本。LLM 不会觉得需要为自己（或任何人）的未来时间做优化，它们会愉快地把越来越多的垃圾堆叠在一起。如果不加约束，LLM 会让系统变得更大，而不是更好------也许能满足扭曲的虚荣指标，但代价是一切真正重要的东西。
Cantrill 进一步阐述了约束与优雅之间的关系：
我们有限的时间迫使我们开发出清晰的抽象，部分原因是我不想在糟糕抽象的后果上浪费自己的（人类的！）时间。最好的工程总是诞生于约束之中。
这句话让我深有感触。回忆一下你自己的经历：
- 当你时间充裕时，是不是倾向于写"先跑起来再说"的代码？
- 当你面临严格的交付压力时，反而更容易逼出简洁的设计------因为你知道，复杂的方案后续维护会让你崩溃？
这正好反映出约束塑造了设计。人类时间的有限性，恰恰是推动我们追求简洁和优雅的根本动力。
Cantrill 还引用了他自己的演讲《The Complexity of Simplicity》（简洁的复杂性），强调追求简洁本身就是一项艰巨的工作------我们不能期望不受时间或认知负载约束的 LLM 自主完成这项工作。
六、Cantrill 的立场：不是反 LLM，而是反误用
值得注意的是，Cantrill 并不是在反对 LLM。
他明确表示：
LLM 在我们的未来中将扮演重要角色：它们是软件工程的非凡工具，但------正如我们在 Oxide 的 LLM 使用指南中所概述的------它们只是工具。
关键在于：LLM 必须服务于人类的"美德式懒惰"。
具体来说，Cantrill 认为 LLM 应该被用来：
- 攻克技术债------那些我们知道该修但一直拖延的问题
- 提升工程严谨性------帮助我们做到自己没时间做到的细致
- 最终目标是产出一个更简洁、更强大的系统
而不是：
- 追求代码行数
- 用膨胀的功能清单来证明"效率"
- 把"能跑"当成唯一标准
七、我的思考
读完这篇文章，我最深的感受是：约束恰恰是推动我们追求优雅的根本动力。
这让我想到用胶片相机或者拍立得这类相机拍照的体验，一卷胶片可能只有二三十张，每按一次快门就少一张。正因为这个限制，你会更认真地构图、更谨慎地选择光线和时机。而当你珍视每一次按下快门的机会时，拍出的照片往往比想象中更好。
软件工程也是如此。代码行数是最差的衡量指标之一，因为它衡量的是付出的努力，甚至某种程度上存在一些无效努力。一个花了三天思考、最终写了 50 行优雅代码的程序员，比一个一天写了 5000 行但充满重复和冗余的程序员，创造了更多的价值。
LLM 是一个强大的工具，这一点毫无疑问。我自己也大量使用 LLM 辅助编程。但 Cantrill 的文章提醒我们：在使用 LLM 时，不要放弃你作为人类的"懒惰"------停下来思考，这个抽象是不是足够好？这段代码是不是足够简洁？这个设计是不是足够优雅？
LLM 可以帮你更快地到达目的地，但目的地本身必须由你来选择。
总结
| 观点 | 说明 |
|---|---|
| 懒惰是程序员的核心美德 | 懒惰驱动构建优雅抽象的力量 |
| LLM 天生缺乏懒惰 | 对 LLM 来说工作没有成本，不会主动优化 |
| 约束塑造设计 | 人类时间的有限性逼出简洁的设计 |
| LLM 放大已有倾向 | 追求质量的人会更好，追求数量的人会更糟 |
| LLM 只是工具 | 应服务于人类的"美德式懒惰" |
一句话总结： 人类时间的有限性是逼出优雅设计的根本动力。LLM 没有这种约束，所以它会让系统变得更大而非更好------除非我们人类用自己的"懒惰"来驾驭它。