Perlis 的 120 条编程警句：AI 编程火了，软件业的老毛病没少

一个页面，120 句话，读起来不像怀旧材料，更像给今天的软件业补了一张旧账单。

耶鲁大学网站收录的 Alan J. Perlis《Epigrams in Programming》，不是段子合集。Perlis 是计算机科学早期重要人物，也是首位图灵奖得主。他写下的这些短句，刺的不是某个过时语言，而是软件行业反复发作的老病：复杂性、抽象幻觉、工具崇拜、文档失灵。

反常点在这里：半个世纪过去，编程工具从命令行走到 IDE，再走到大模型助手，很多问题却没有变少。只是换了更贵的外壳。

这 120 条警句刺中的不是旧技术，是旧人性

Perlis 的警句很短，但刀口很稳。它们不靠预测未来取胜，而是抓住了软件工程里最难改的东西：人如何逃避复杂性，组织如何奖励新东西，工具如何制造新的依赖。

这张表足够说明问题。Perlis 不是在嘲笑某种语言落后，而是在提醒：软件的麻烦往往不在写出来那一刻，而在它进入组织、进入依赖链、进入长期维护之后。

“写一个错误程序，比理解一个正确程序容易。”这句话放到今天，应该贴在每个 AI 编程工具的提交按钮旁边。生成很快，理解很慢。能跑一遍，不等于团队接得住。

“优化阻碍演化。”这句也不老。很多团队不是不会优化，而是太早把系统钉在一个假设上。业务一变，所谓性能优势变成迁移成本。

AI 编程没有取消软件工程，只是把责任链拉长了

我不太买账一种说法：既然 AI 能写代码，软件工程里的很多规矩就可以松一松。现实更接近相反方向。代码越容易生成，审查、测试、文档和归责越不能省。

大模型编程当然有价值。它能补全样板代码，迁移旧接口，解释陌生代码，降低入门门槛。对个人开发者，它是省时间的工具；对团队，它可能减少重复劳动。

但它没有替你理解系统。

Perlis 那句“当我们写会‘学习’的程序时，结果是我们学了，它们没有”，放在今天并不是反 AI。它提醒的是边界：模型输出的是概率上像代码的文本，组织承担的是确定性的维护责任。中间差的那一截，不能靠演示视频补上。

对程序员来说，动作很具体：不要把 AI 生成代码当作提交依据，要把它当作待审查草稿。尤其是权限、并发、数据迁移、错误处理、依赖升级这些位置，少信“看起来对”。

对技术管理者来说，别用生成行数和交付速度包装效率神话。更该盯的是四个变量：代码审查责任有没有明确，测试覆盖有没有跟上，文档是否随接口更新，出了问题谁能回滚。

如果这些变量没有变化，AI 编程带来的可能只是更快的债务发行速度。天下熙熙，皆为利来。工具厂商卖效率，团队内部争预算，工程师追新栈，最后账单常常落在维护者身上。

这里也要留一个限制。不是所有团队都会被 AI 放大混乱。小团队、边界清楚的内部工具、一次性脚本，收益会更直接。风险最高的是长期运行、多人协作、依赖复杂、责任模糊的系统。也就是大多数公司真正赚钱或保命的系统。

越成熟的软件业，越会被维护成本反噬

软件行业常把自己讲成永远年轻。但从结构看，它越来越像铁路、报业或早期电力网络：扩张期讲速度，成熟后吃维护。铺得越远，回头修路越贵。

这个类比不完全一样。软件复制成本低，迭代速度快，铁路和报业没有大模型这样的生成工具。但相似处很关键：系统一旦成为基础设施，新增功能只是表面，兼容、治理、迁移、责任分配才是长期成本。

Perlis 说过：“把旧程序适配到新机器，通常意味着让新机器表现得像旧机器。”今天的云、容器、微服务、AI 编程助手，经常也在做这件事：新工具包着旧流程，新算力供养旧包袱。

这就是我更在意的地方。行业总爱把问题说成“工具还不够强”。可很多时候，问题不在产品能力，而在激励设计。

工程师喜欢新抽象，因为它让问题看起来更优雅。管理者喜欢新平台，因为它让复杂系统看起来更可控。公司喜欢新工具，因为它容易写进效率叙事。结果是复杂性不断转移，很少被消灭。

接下来最该观察的，不是哪个模型又多会写代码。更关键的是团队有没有改变工程制度：

• AI 生成代码是否必须经过同等审查；
• 关键模块是否有明确 owner；
• 文档是否进入交付标准，而不是上线后补；
• 依赖和框架数量是否被管理，而不是任由增长；
• 技术债是否有预算和时间窗口偿还。

这些变量比演示更诚实。模型能力会继续进步，但软件组织能不能把复杂性关进笼子，才决定它是效率工具，还是债务放大器。

Perlis 的 120 条警句没有过时，因为它们讲的不是古早计算机，而是软件行业反复回避的现实：工具越来越聪明，系统不一定更可控；写代码越来越容易，理解代码反而更值钱。

回到开头那张旧账单。Perlis 的价值不在于他预测了 AI 编程，而在于他早早看见了软件的性格。软件会变，软件人改得很慢。