仅在过去一个月里，我就听到了这些说法：
- “自 2025 年以来我就没写过代码了”；
- “Code review 已死”；
- “人们不再阅读代码了”。
诚然，行业正在转型，然而，那些落入“不再阅读和编写代码”这一陷阱的个人与组织，这么做的后果只能自负。
事实是，vibe coding 的项目会随时间推移退化成无法维护的混乱。原因很简单，却难以解决：代码可维护性和良好架构并没有我们可以应用的良好度量手段，因为要察觉坏架构或不可维护代码的影响，往往需要数月甚至数年。
我们当然可以定义什么是坏代码：难以阅读、难以理解、难以演化的代码——无论未来抛给我们什么。那种改一处就会以极不确定的方式弄坏程序、或在远离改动的地方破坏逻辑的代码，宛如“蝴蝶效应”。那种添加一个功能就意味着一项艰巨任务的代码——需要在多处修改，却仍会漏掉某些地方，从而造成不一致。那种设计不变量不清晰、原作者已不在场来防范违规、无法保证一致性的代码。那种难以测试的代码——需要 mock 并暴露实现细节，导致测试脆弱不堪，最终反而阻碍有意义的重构。
然而，我们确知察觉坏代码需要时间，数月甚至数年。当然，经验丰富的软件工程师拥有能嗅出代码坏味道的“鼻子”，能在坏影响被观察到之前很久就采取行动。
那些熟练的开发者、专家，依靠的是用汗水和泪水铸就的直觉——他们长时间调试和修复生产环境问题，发誓再也不会愚蠢到重复过去的错误。这种直觉无法被固化成一条条僵化的规则，因为一切都取决于上下文。专家与那些能让新手更高效的规则和配方并不兼容。专家不遵守规则，他们制定规则。
于是我们就有了一个问题……
首先，AI 并没有针对“代码可维护性意味着什么”接受训练。举例来说，任何强化学习都需要能够立即度量的奖励信号，而不是数月或数年之后。AI 从为新手编写的规则手册中学习规则。AI 从现实世界中的代码里发现模式，而老实说，现实世界中的大多数代码都相当糟糕。你无法为可维护的代码定义出一个适应度函数（fitness function），至少是我们还无法辨识出这样的函数，否则它早就被内置进我们的 linter 里了。
你有没有注意到 AI 在“简化”代码方面有多糟糕？是的，我说的是 SOTA 模型。它甚至无法正确地定义函数，总是选择把函数拆成实际上并不可复用的小函数。如果为了理解那个大函数，你还必须去阅读被抽取出来的小函数的实现，那么从大函数中抽取小函数就是一个非常糟糕的选择。定义可复用、能澄清意图的函数是一门艺术，一门需要达到精通才算掌握的艺术。大多数开发者在 Dreyfus 技能习得模型中仍处于“高级新手”（advanced beginners）阶段，无法定义出好的、有澄清性的、可复用的函数，目前的 AI 也一样做不到。
如果人们仍然保持掌控，并能从那些错误中学习，事情还不至于这么糟。但我们正看到一种趋势：人们依赖 AI 来写代码，甚至读代码。
这些人永远不会达到精通，因为他们不再做出选择，不再为编码中的错误承担责任，也不再从错误中学习。现在犯错的是 AI，AI 不会从这些错误中学习，而依赖 AI 编码的人同样也不会。
糟糕吧！
别误会，我认为 LLM 是很棒的工具。我不是勒德分子（Luddite），我已经把 AI 融入了日常工作，还把学到的东西教给了同事。我很乐意用 LLM 来处理那些无聊、消耗灵魂的破事。我也确实在享受效率上的好处。但归根结底，它只是一个工具，而且和所有其他革命一样，它的光芒终将黯淡；在我看来，它已经在黯淡了，因为现在的科技新闻说实话相当无聊。
人们其实很不擅长做预测。我相信未来会让我们所有人都感到意外。不过，我也要做出一个自己的预测……
在未来，我们会看到越来越多的公司自豪地把“NO-AI（无 AI）”政策当作竞争优势来宣传。而且他们会是对的。
“可是自动化流水线总是更有效率啊”，人们会说。问题在于软件行业很特殊：我们一直都在大规模地做自动化，我们所做的一切都是自动化，LLM 并不是唯一的自动化手段，而且视情境而定，它实际上可能是一种干扰。“编程问题并没有被解决”，在任何有意义的意义上都没有。当然，你可以指示 LLM 给你构建一个 C/C++ 编译器，但你也可以直接 clone GCC 或 LLVM，还能免费得到一个更好的 C/C++ 编译器。而且，与其重新发明同样的 CRUD 应用，也许有更好的方式来使用我们的时间和资源（人类的需求与欲望是无穷的，不缺新的目标可以去奋斗）。
如果个人和公司不开始对 AI 的使用负起责任，后果将会随之而来。
标签：
| 观点
参与
通过提交 pull request 来修正或补充本文：
订阅邮件以接收新文章通知。没有垃圾邮件，只有内容。
由 Mailchimp 提供支持。参见隐私政策。
© 2009-2026