引言

你是否也曾陷入这样的困境：借助 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 没有这种约束，所以它会让系统变得更大而非更好——除非我们人类用自己的“懒惰”来驾驭它。