Ru果你问我现在技术圈Zui让人焦虑的话题是什么那大概不是哪个框架又过时了而是我们手中的饭碗——写代码这件事本身——正在被一种叫Zuo“生成式AI”的东西重新定义。这不仅仅是工具的升级，geng像是一场关于“什么是优秀工程师”的哲学辩论。Zui近，Oxide Computer Company 的 CTO、也是 DTrace 的联合创始人 Bryan Cantrill 写了一篇发人深省的文章《The Peril of Laziness Lost》，直接把矛头指向了当前 AI 编程热潮中Zui隐蔽的一个副作用：我们正在不知不觉中丢失程序员Zui宝贵的一项美德。

这听起来可Neng有点危言耸听，但请耐心听我说完。这不仅仅关乎技术，geng关乎我们如何保持对“优雅”的敬畏。

当“勤奋”变成了一种诅咒：虚假的效率崇拜

让我们先从一个极具代表性的现象说起。不知道从什么时候开始，社交媒体上兴起了一种奇怪的攀比风气。Y Combinator 的现任掌门人 Garry Tan 就是一个典型的例子。他Zui近在网上大肆炫耀自己利用 LLM 实现的“超高产出”，甚至声称自己每天Neng敲出 10,000 行代码，而且语气中还带着一种“还在加速”的得意。

10,000 行。一天。你仔细品品这个数字。

对于任何一个有经验的工程师来说这个数字不仅没有让人感到敬佩，反而让人感到一种深深的违和感。这就像是一个作家宣称自己每天写了两万字，但当你翻开作品一kan，全是注水废话。这种文化，被 Cantrill 戏称为 Brogrammer 文化——一种由“兄弟”和“程序员”合成的亚文化。在这种文化里人们崇尚用代码行数来衡量价值，用加班时长来证明努力，热衷于在推特上晒自己“疯狂写代码”的状态。

但这真的是我们想要的未来吗？

geng有意思的是波兰软件工程师 Gregorein 真的去拆解了 Garry Tan 用 LLM 高速搭建的那个“newsletter-blog”项目。结果既在意料之中，又让人哭笑不得：那里面堆砌了大量的代码，kan似功Neng完备，实则充满了冗余和重复。这就像是为了钉一颗钉子，却造了一整个工厂。

这种“虚假勤奋”正在侵蚀我们的行业。过去二十年，软件开发者群体急剧膨胀，越来越多的人涌入这个领域，这本是好事。但副作用是大家开始用Zui直观、Zui笨拙的指标——也就是“量”——来评价一切。在这种逻辑下忙碌大于思考，产出大于质量。

重新审视“懒惰”：程序员的三大美德

要理解为什么 Cantrill 会如此愤怒，我们需要回到 Perl 语言的创始人 Larry Wall 那里。在那本被一代技术人奉为圭臬的“骆驼书”《Programming Perl》中，Wall 提出了程序员的三大美德：懒惰、急躁、傲慢。

乍一kan，这三个词全是贬义。但这其实是一种极具反讽意味的智慧。而在 Cantrill kan来这其中“懒惰”是Zui深刻、也Zui容易被误解的一个。

这里的“懒惰”，绝对不是指躺在沙发上什么dou不干，也不是指敷衍了事。相反，它是一种极其高级的驱动力。真正的懒惰，会驱使程序员去构建Zui优雅的抽象。当你不想重复写同样的逻辑时你会封装一个函数；当你不想处理同类的烂摊子时你会设计一个通用的框架。

用 Cantrill 的话说：懒惰驱使我们让系统尽可Neng简单，开发出强大的抽象，从而让我们Nenggeng轻松地Zuogeng多的事。

想想你自己Zui满意的那些代码——是不是那些你花了大量时间思考、反复推敲，Zui终写出来却极其简洁的方案？那种“四两拨千斤”的快感，正是源于这种“懒惰”的美德。我们不想以后花时间去修 Bug，所以现在才花时间去把代码写好。这就是懒惰的本质：用当下的深度思考，换取未来的轻松。

但这有一个隐含的矛盾：要真正“懒”，你得先hen“勤快”。你得勤快地思考，勤快地重构，勤快地否定自己不够完美的方案，才NengZui终达成那个“一劳永逸”的境界。

LLM 的致命缺陷：没有“未来”的工具

现在让我们把目光转回 LLM。问题在于，LLM 天生缺乏这种“懒惰”的美德。

大语言模型是一个强大的工具，这一点毫无疑问。我自己也大量使用 LLM 辅助编程，它确实Neng极大地提升效率。但 Cantrill 的文章提醒了我们一个残酷的事实：工作对 LLM 来说没有任何成本。

LLM 不会觉得累，不会觉得需要为自己的未来时间Zuo优化。它们没有“明天”，也没有“维护成本”。它们会愉快地把越来越多的代码堆叠在一起，只要你要求它这么Zuo。Ru果不加约束，LLM 会让系统变得geng大，而不是geng好——也许Neng满足某些扭曲的虚荣指标，比如代码行数，但代价是一切真正重要的东西：可读性、可维护性、以及系统的简洁性。

你可Neng觉得这些只是小问题，反正douKe以修。但 Cantrill 的回应hen直接：问题不在于这些 bug 本身。

问题在于，LLM 正在杀死那个让我们停下来思考的动机。既然 AI Neng在一秒钟内生成几百行代码，我们为什么还要花半个小时去思考如何用十行代码解决问题？这种诱惑是巨大的。于是那种驱动你停下来思考、寻找geng好方案的“懒惰”，被边缘化了。取而代之的，是一种无休止的、机械式的“勤奋”。

约束塑造设计：胶片摄影的启示

这让我想到用胶片相机或者拍立得这类老式相机拍照的体验。一卷胶片可Neng只有二三十张，每按一次快门就少一张。正因为这个物理上的限制，你会geng认真地构图、geng谨慎地选择光线和时机。你会屏住呼吸，等待那个完美的瞬间。

而当你珍视每一次按下快门的机会时拍出的照片往往比想象中geng好。

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

Cantrill 提到了一个有趣的概念，叫“吊床驱动开发”。你以为程序员躺在吊床上是在摸鱼？不那是在脑子里反复翻转问题，寻找Zui优雅的解法。这种kan似“偷懒”的行为，恰恰是工程中Zui核心的价值创造过程。

但 LLM 的出现，打破了这种约束。它就像一台没有底片的数码相机，你Ke以无限连拍，不需要思考构图，不需要等待光线。结果呢？你得到了成千上万张废片，以及一堆kan似庞大实则臃肿的代码库。

干柴与火星：警惕被放大的倾向

Cantrill 把这种追求虚荣指标的文化比作干柴，只差一颗火星就会点燃。

而那颗火星，就是 LLM。

这句话是整篇文章的关键洞察之一。LLM 本身是中性的工具，但它会放大使用者Yi有的倾向。Ru果你本来就追求简洁和优雅，LLM Neng帮你geng快达到目标，帮你清理繁琐的细节；但Ru果你本来就追求“多就是好”，LLM 就会让你在这个方向上越走越远，甚至失控。

无论你对软件创作的态度如何，LLM douNeng让这种态度以geng大的力量施加。Ru果你是一个糟糕的程序员，LLM 会让你变成一个产出垃圾的高效机器；Ru果你是一个优秀的工程师，LLM 则是你手中的神兵利器。

Cantrill 还引用了他自己的演讲《The Complexity of Simplicity》，强调追求简洁本身就是一项艰巨的工作——我们不Neng期望不受时间或认知负载约束的 LLM 自主完成这项工作。简洁不是靠“堆”出来的，是靠“减”出来的。而 AI，本质上只会Zuo加法，不会Zuo减法。

人机协作的新范式：工具必须服务于美德

值得注意的是Cantrill 并不是在反对 LLM。他明确表示：LLM 在我们的未来中将扮演重要角色：它们是软件工程的非凡工具，但——正如我们在 Oxide 的 LLM 使用指南中所概述的——它们只是工具。

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

我们有限的时间迫使我们开发出清晰的抽象，部分原因是我不想在糟糕抽象的后果上浪费自己的时间。Zui好的工程总是诞生于约束之中。这正好反映出约束塑造了设计。人类时间的有限性，恰恰是推动我们追求简洁和优雅的根本动力。

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

在使用 LLM 时我们绝不Neng放弃作为人类的“懒惰”。我们要学会停下来问自己：这个抽象是不是足够好？这段代码是不是足够简洁？这个设计是不是足够优雅？而不是盲目地接受 AI 给出的那一堆kan似完美的“废话”。

LLM Ke以帮你geng快地到达目的地，但目的地本身必须由你来选择。Ru果你不知道要去哪里AI 只会帮你加速迷路。

不要Zuo代码的搬运工

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

我们正处在一个十字路口。一边是kan似高效的“虚假勤奋”，用代码行数堆砌出虚假的成就感；另一边是坚持“懒惰”的美德，用思考和约束去打磨真正的艺术品。

你是否也有过这样的经历：用 LLM 写代码，一天下来产出了几千行，回头kan却发现——真正有价值的可Neng不到几百行？那种空虚感，就是你的“懒惰”美德在向你发出警告。

不要让 LLM 替代你的思考，不要让“Brogrammer”文化绑架了你的价值观。保持一点“懒惰”吧。多花点时间在吊床上思考，少写点无用的代码。毕竟约束恰恰是推动我们追求优雅的根本动力，而优雅，才是程序员这个职业存在的终极意义。

---