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

引言

你是否也曾陷入这样的困境：借助 LLM 辅助编程，一天产出数千行代码，回过头审视却发现——真正有价值的或许不足百行？

听起来令人难以置信，但这种现象在当下十分普遍。Oxide 公司 CTO、DTrace 联合创始人 Bryan Cantrill 近期发表了一篇题为《The Peril of Laziness Lost》的文章，精准地揭示了问题的本质：LLM 正在侵蚀程序员最珍贵的品质——思辨性懒惰。

这篇文章篇幅虽短，但观点十分犀利，值得每一位依赖 LLM 编写代码的开发者仔细品读。

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

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

这三个词看似全是贬义，但 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 就会让你在这条路上越走越远。

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 本身。

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

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

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

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

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

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

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

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

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

他明确表示：

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

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

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

而不是：

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

七、思考：约束是优雅的催化剂

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

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

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

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

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

总结

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