AI 没有智慧，你也一样。

# AI没有智慧，你也不会有 来源：https://alexn.org/blog/2026/09/22/ai-has-no-wisdom-and-neither-will-you/ 仅在过去一个月，我就听到过这些说法： - *自2025年以来我就没写过代码了*； - *代码审查已死*； - *人们不再阅读代码了*。 诚然，行业正在变革，但那些陷入“不再阅读和编写代码”陷阱的人和组织，只会让自己陷入险境。 事实上，凭感觉编写的项目会随着时间推移演变成难以维护的烂摊子。原因很简单，却难以解决：代码可维护性和良好的架构难以通过即时指标来衡量，因为其影响可能在数月甚至数年后才会显现。 我们当然可以定义什么是糟糕的代码：难以阅读、难以理解、难以根据未来需求演进的代码。那种改动一处就会以不可预知的方式破坏程序，或者影响到与改动处相隔甚远的逻辑的代码，类似于“蝴蝶效应”。那种为了添加一个功能就需要修改多处代码，却仍难免遗漏导致不一致的代码。那种设计不变量不清晰、原作者已离开无人维护一致性、难以测试（依赖mock且暴露实现细节，导致测试脆弱、最终阻碍有意义的重构）的代码。 然而，我们都知道一个事实：发现糟糕代码需要时间。数月，甚至数年。当然，经验丰富的软件工程师拥有敏锐的嗅觉，能在观察到坏结果前很久就察觉到代码异味并采取行动。 熟练的开发者，即专家，依赖于他们通过汗水和泪水建立起来的直觉——那些为了调试和修复生产问题而长时间工作，发誓再也不犯同样错误的经历所积累的直觉。这种直觉无法简单地罗列成刻板的规则，因为一切都取决于上下文。专家与那些能提高新手效率的相同规则和惯例是不兼容的。*专家不遵循规则，他们制定规则。* 因此，我们面临一个问题…… 首先，AI并非基于“代码可维护性意味着什么”来训练的。例如，任何强化学习都需要能够立即衡量的奖励信号，而不是等数月或数年。AI从为初学者编写的规则手册中学习规则。AI从海量代码中发现模式，但说实话，大部分现有代码质量相当糟糕。我们无法为可维护的代码定义一个适应度函数，至少目前我们无法识别出这样的函数，否则它早已被集成到我们的代码检查工具中了。 你注意到AI在“简化”代码方面有多糟糕了吗？是的，即使是顶尖的模型。它甚至无法正确地定义函数，而是倾向于将一个函数拆分成若干个小函数，但这些小函数实际上并不具备可复用性。如果为了理解一个更大的函数，你还必须去阅读其拆分出来的小函数的实现，那么从中提取小函数就是非常糟糕的选择。定义清晰、具有可复用性的函数是一门艺术，一门需要精通的艺术。大多数开发者，按照德雷福斯技能习得模型（https://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition）来看，仍处于*“高级新手”*阶段，他们尚无法定义良好、清晰、可复用的函数，而目前的AI也做不到。 如果人们仍然掌控局面并能从错误中学习，情况还不至于太糟。但我们正看到一种趋势：人们依赖AI来编写、甚至阅读代码。 这些人将永远无法达到精通，因为他们不再自己做选择，不再为编码中的错误承担责任，也不再从错误中学习。现在犯错的是AI，AI不会从这些错误中学习，而那些依赖AI编程的人同样也不会。 糟糕！ 别误会，我认为大语言模型是很好的工具。我不是卢德主义者，我已经将AI整合到日常工作中，同时也在教导同事们我所学到的东西。我很乐意使用大语言模型来处理我们必须应对的那些枯燥、耗神的工作。我也很享受我所看到的效率提升。但归根结底，它只是一种工具，和其他所有革命一样，它的光芒也会消逝；在我看来，它已经在消退，因为如今科技新闻确实相当乏味。 人们其实很不擅长做预测。我相信未来会让我们所有人惊讶。但是，我要做一个自己的预测…… > 未来我们会看到越来越多公司自豪地将“禁止AI”政策作为竞争优势来宣传。而他们是正确的。 *“但自动化装配线总是更高效啊”*，人们如此说，但软件行业是特殊的，因为我们一直在进行大规模自动化，我们做的一切都是自动化，大语言模型并非实现自动化的唯一途径，而且视情况而定，它甚至可能是一种干扰。*“编程问题”*在任何有意义的层面上都尚未解决。当然，你可以指示大语言模型为你构建一个C/C++编译器，或者你可以直接克隆GCC或LLVM，而且你会得到一个更好的C/C++编译器，还是免费的。也许，与其重新发明同样的CRUD应用，我们还有更好的方式来花费时间和资源（人类的需求和欲望是无限的，总有新的目标可以追求）。 如果个人和公司不开始负责任地使用它，将会带来后果。