AI 没有智慧，你也不会有了

yibie·约 4 分钟阅读

2026年9月22日9月22日

作者：Alexandru Nedelcu（Monix 作者，Typelevel 贡献者；专注低延迟高吞吐的 JVM 服务，Scala/Kotlin 与函数式编程）

仅仅过去一个月，我就听到这些说法：

「我从 2025 年起就没写过代码了」

「代码审查已死」

「人们不再读代码了」

行业确实在转型。但那些落入「不再读代码、不再写代码」陷阱的人和公司，是在拿自己冒险。

事实是：纯靠感觉（vibe）写出来的项目，会随时间退化成一团无法维护的乱麻。

原因简单，但难修：代码的可维护性和好的架构，没有我们能施加的好的度量——因为要察觉坏架构或不可维护代码的后果，需要几个月、甚至几年。

我们当然能给坏代码下定义：难读、难懂、难以应对未来抛来的任何变化。那种改一处就以非常不确定的方式把程序弄坏的代码，或者在你改动之外很远的地方把逻辑弄坏，像蝴蝶效应。那种加个功能就要大动干戈、要在多处改代码、还总漏掉某处、于是产生不一致的代码。那种设计的不变量不清楚、作者已不在场、没人守着防止违反、确保某种一致性的代码。那种难以测试、需要 mock、暴露实现细节、导致脆弱的测试、最终反而妨碍了有意义的重构的代码。

然而我们都知道一个事实：察觉坏代码需要时间。几个月，几年。

当然，有经验的软件工程师有个鼻子，能在坏后果被观察到之前很久就嗅出代码异味并采取行动。

熟练的开发者、专家，靠的是血汗筑成的直觉——长时间工作去调试和修生产问题，一边骂一边发誓再也不犯同样的蠢。那是种无法真正写成刚性规则清单的直觉，因为一切都是语境相关的。专家与那些让新手更高效的规则和配方是不兼容的。专家不遵守规则，他们制定规则。

于是我们有了一个问题……

第一，AI 没有被训练去理解「代码可维护」意味着什么。

比如说，任何强化学习都需要一个能立即度量的奖励信号，而不是几个月或几年。AI 从为新手写的规则手册里学规则。 AI 从野生代码里辨认模式——而说实话，野生代码大多相当糟糕。

没有适应度函数能定义可维护的代码，至少没有我们能分辨出来的那种，否则它早就被烘焙进我们的 linter 里了。

你有没有注意到 AI 在「简化」代码上有多糟糕？是的，我说的是 SOTA 模型。它连函数都定义不好——它会把函数拆成一些小函数，而那些小函数实际上并不可复用。如果为了理解那个大函数你不得不去读抽出来的小函数的实现，那么从大函数里抽小函数就是个很坏的选择。定义可复用且能澄清意图的函数是一门艺术，一门需要精通的艺术。

大多数开发者，按 Dreyfus 技能获得模型来说仍是「高级初学者」，没法定义出好的、能澄清意图的、可复用的函数——AI 目前也不能。

如果人们仍然掌控着局面、并能从这些错误中学习，这还不算太糟。

但我们看到一种趋势：人们依赖 AI 去写，甚至去读代码。

这些人将永远无法达到精通，因为他们不再做出选择，不再为自己的编码错误负责，也不再从那些错误中学习。现在是 AI 在犯错，AI 不从那些错误中学习，依赖 AI 编程的人也不从中学。

天哪。

别误会，我认为 LLM 是个很棒的工具。我不是卢德分子，我已经把 AI 整合进日常工作，同时还在教同事我学到的东西。我很乐意用 LLM 处理所有那些无聊、抽干灵魂的破事。我也在享受看到的效率收益。

但归根结底，它只是个工具，而且像所有其他革命一样，它的光芒也会褪去。在我看来，已经在褪了——因为现在的科技新闻说实话相当无聊。

人们其实很不擅长做预测。我相信未来会让我们所有人都意外。不过，我也要做一个自己的预测……

将来我们会看到越来越多的公司骄傲地吹嘘自己的「无 AI」政策是一种竞争优势。而他们是对的。

人们说「但自动化装配线总是更高效」——只不过软件行业是特殊的，因为我们一直在做大规模的自动化，我们做的一切都是自动化，LLM 不是唯一的手段，而且取决于语境，它实际上可能是一种干扰。

「编程已被解决」这句话在任何有意义的角度上都不成立。当然，你可以指示 LLM 给你造一个 C/C++ 编译器，或者你直接 clone 一份 GCC 或 LLVM，还能得到一个更好的 C/C++ 编译器，而且还免费。

也许有比重新发明同一个 CRUD 应用更好的时间和资源用法（人类的需求和欲望是无限的，永远不缺新目标可以做）。