当 AI 一天能写 3.7 万行代码，程序员最珍贵的美德反而更稀缺了

不是代码写得慢，而是代码写得太轻松了

程序员圈子里有一句流传很久的话，出自《Programming Perl》作者 Larry Wall：优秀程序员有三种“美德”——懒惰、急躁和傲慢。这里的“懒惰”当然不是躺平，而是一种很技术人的偷懒：既然同样的事迟早要做很多次，那不如今天多花点脑力，把它抽象成更简洁、更通用的结构，省掉未来无穷无尽的重复劳动。

Bryan Cantrill 这篇文章最精彩的地方，就在于他把这个老话题，精准地对准了今天最热的对象：LLM，也就是大语言模型辅助编程。过去两年，AI 写代码已经从“新鲜玩具”变成了很多团队的日常工具。GitHub Copilot、Cursor、Claude Code、OpenAI 的各类编码代理，让“先让 AI 写一版”几乎成了新的默认动作。问题也随之出现：当生成代码几乎没有成本，软件工程会变得更优雅，还是更臃肿？

Cantrill 的答案相当直接，甚至有点不留情面：LLM 天生不具备“懒惰”这项美德。因为对模型来说，工作量几乎是零。它不会因为将来要维护这段代码而心烦，不会因为模块太绕、依赖太多、命名太乱而失眠，更不会在吊床上发半小时呆，只为了想出一个更漂亮的抽象。它只会源源不断地“加”。在人类世界里，偷懒常常逼着我们做减法；在模型世界里，廉价劳动却很容易把系统推向加法失控。

3.7 万行代码的炫耀，为何让工程师皱眉

Cantrill 文中点名了 YC 总裁 Garry Tan。后者曾高调分享自己借助 LLM 写代码的效率，声称达到“每天 3.7 万行，而且还在加速”。这类说法在社交媒体上很有传播力，因为它正中当下科技圈一种熟悉的兴奋点：规模、速度、爆发、压榨极限。听起来像健身房里的 PR 纪录，只不过把杠铃换成了代码行数。

可稍微懂点软件工程的人，都会本能地警惕这种指标。代码行数从来不是质量指标，很多时候甚至是反指标。一个优秀工程师解决问题，往往不是多写 5000 行，而是删掉 2000 行，再把系统做得更清楚。历史上最经典的软件工程成就，常常都不是“写了多少”，而是“能不能少写、少依赖、少出错、少让后来人骂你”。

更有戏剧性的是，波兰软件工程师 Gregorein 对 Tan 展示的那个“newsletter-blog-thingy”做了一次拆解，结果堪称 LLM 时代的软件考古现场：一次加载里包含多个测试 harness、一个 Hello World 级别的 Rails 应用、一个莫名其妙混进去的文本编辑器，还有 8 个不同版本的同一 logo，其中一个居然还是 0 字节文件。这个细节很有代表性。它不是说 AI 代码不能修，而是说明当“生成”本身变得极其廉价时，杂质也会以惊人的速度累积。

这让我想到今天很多 AI 编程演示视频的共同套路：几分钟起一个项目，十几分钟堆出一个产品原型，界面花里胡哨、功能似乎样样都有。可镜头很少继续拍下去——一周后还能不能改？一个月后还能不能查 bug？半年后团队里来了新人，看不看得懂？软件工程真正昂贵的部分，从来不是敲出第一版，而是让系统持续可理解、可迭代、可交接。

人类的“懒”，其实是一种很昂贵的优化能力

Cantrill 有个判断我非常认同：人类工程师之所以会追求简洁，不是因为我们道德高尚，而是因为我们真的会累。时间有限、注意力有限、记忆有限，所以我们天然会排斥那些未来会反复折磨自己的复杂结构。说白了，正因为人类有认知负担，才会逼着自己发明好抽象、好接口、好边界。

这也是为什么很多伟大的软件系统，最终都不是靠“蛮力生产”取胜，而是靠设计上的克制。Unix 的哲学如此，Go 语言对复杂特性的压制如此，早年的 Smalltalk、后来的 Erlang 乃至 Rust 的某些设计争论，骨子里都围绕一个问题：系统复杂性到底该放在哪里，谁来承担。

LLM 的特殊之处在于，它可以在很短时间里把“复杂性债务”做成分期付款的样子。今天先能跑，明天再修；这一层先套一层，后面再重构；能生成 5 个版本，就懒得先想清楚到底该要哪一个。短期看，这是效率；长期看，这可能是把维护成本悄悄转嫁给未来的人类。模型不为未来负责，负责的是团队里那个三个月后接手项目的倒霉工程师。

所谓“程序员的懒惰”，真正珍贵的地方恰恰在这里：它不是不干活，而是不愿意以后一直干蠢活。好的抽象不是炫技，是对未来时间的节省；好的架构不是为了 PPT 上好看，而是为了让系统不至于长成一座谁也不敢碰的违章建筑。

AI 编程真正的分水岭，不是能不能写，而是谁来做最后的减法

如果把这场争论粗暴理解成“AI 写代码不行”，那就误会了 Cantrill，也误会了现实。今天几乎没有严肃工程团队会否认 LLM 的价值。它确实能补测试、写脚手架、生成文档、辅助迁移旧代码、解释陌生接口，甚至在一些局部重构和排障任务上表现得相当亮眼。Oxide 这样的工程公司也明确承认，大模型是极其重要的工具。

真正的分歧在于：AI 应该扮演主建筑师，还是超级施工队？在我看来，至少在当下，答案更接近后者。它可以极大提升执行效率，但很难天然地产生“我是不是应该少造一层”的警觉。换句话说，LLM 擅长扩写，不天然擅长克制；擅长填充，不天然擅长取舍。软件工程里最难的部分，恰恰是那些需要取舍、需要节制、需要长期责任心的决策。

这也是为什么今天行业里出现了一个有趣反差。一边是“vibe coding”越来越流行，很多人靠自然语言就能迅速做出应用；另一边，真正成熟的团队反而开始强调工程纪律：更清晰的代码评审、更严格的测试、更明确的依赖治理、更强的可观测性。这不是保守，而是一种现实主义。因为你越是拥有廉价生成能力，就越需要昂贵的判断能力。

过去十几年，软件行业一直在降低门槛：云服务让部署不再痛苦，开源框架让搭系统快得惊人，低代码工具让非专业开发者也能做业务系统。LLM 把这件事又往前推了一大步。更多人能写软件，当然是好事。但随之而来的问题也更尖锐：当“创作软件的人”越来越多，其中很多人甚至不把自己当程序员时，谁还会主动为那些隐藏在系统深处的复杂性负责？

比起更快生成，我们更需要重新发明“工程审美”

我觉得 Cantrill 这篇文章真正戳中行业神经的地方，并不只是批评某位高调的 AI 编程拥趸，而是在提醒整个行业：我们可能正把软件工程里最难、也最不性感的部分丢掉。那部分东西很难在短视频里展示，也不适合社交媒体炫耀——比如删掉一个多余层级，比如把 6 个重复模块收敛成 1 个，比如为了减少未来认知负担，今天硬着头皮重做接口边界。

这些事情没有“每天 3.7 万行代码”那么抓眼球，却更接近真正的工程价值。说得夸张一点，未来几年软件行业最稀缺的，可能不再是会不会用 AI，而是有没有能力在 AI 狂飙产出之后，冷静地做减法、做归纳、做清理、做命名、做边界。

这背后其实还有一个值得继续追问的问题：如果 AI 让代码产出像流水一样便宜，软件团队的核心能力会不会从“生产代码”转向“审计复杂性”？未来最重要的工程师，也许不是写得最快的人，而是最会识别坏抽象、最会拒绝无效生成、最能把一团膨胀系统收束回简单形态的人。

我并不悲观。每一次生产力工具革命，都会先制造一波泡沫式繁荣。早年可视化建站如此，移动互联网模板化开发如此，云时代的“先上再说”也是如此。热闹之后，行业总会重新发现那些老原则：清晰、约束、可维护、可演进。AI 不会废掉这些原则，只会让它们显得更昂贵，也更重要。

从这个意义上说，“懒惰”不是程序员正在失去的古典美德，反而会成为 AI 时代最值得捍卫的工程品质。因为只有真正怕麻烦的人，才会认真避免给未来制造更大的麻烦。