讨论 AI 在代码维护方面的不足，以及人类工程师的直觉和经验的重要性。
过去一个月内，我听到了这些说法：自从 2025 年以来就没有写过代码；代码审查已死；人们不再阅读代码。显然，行业正在转型，然而，那些陷入不再阅读和编写代码陷阱的个人和组织只会自食恶果。事实上，vibe-coded 项目随着时间的推移会变成不可维护的混乱。原因是简单但难以修复：代码的可维护性和良好的架构没有好的衡量标准，因为要几个月甚至几年才能注意到不良架构或不可维护代码的影响。当然，我们可以定义出糟糕的代码：难以阅读、难以理解、难以适应未来的任何变化。这种代码在改变一个东西时，会以非常不确定的方式破坏程序，或者在远离更改的地方破坏逻辑，类似于‘蝴蝶效应’。这种代码中添加功能意味着一个重大的任务，因为需要在多个地方更改代码，并且仍然忘记修复所有内容，从而导致不一致。在设计中不变量不清楚的代码，其作者不再在场以防止违规并确保一致性。难以测试的代码，需要模拟并暴露实现细节，导致脆弱的测试最终阻止有意义的重构。然而，我们知道识别糟糕的代码需要时间，可能是几个月或几年。当然，经验丰富的软件工程师有一种能够检测代码“味道”的嗅觉，可以在观察到不良影响之前采取行动。熟练的开发人员和专家依赖他们通过汗水和泪水建立起来的直觉，长时间工作以调试和修复生产问题，发誓再也不重蹈覆辙。这种直觉实际上无法变成一份严格的规则列表，因为一切都是情境依赖的。专家与使初学者更高效的相同规则和食谱不兼容。专家不遵循规则，他们制定规则。因此，我们面临一个问题……首先，AI 没有被训练去理解代码的可维护性意味着什么。例如，任何强化学习都需要一个可以立即衡量的奖励信号，而不是在几个月或几年后。AI 从规则书中学习规则，这些规则是为初学者准备的。AI 从野外的代码中注意到模式，坦白说，大多数野外的代码都很糟糕。你注意到 AI 在“简化”代码方面的糟糕程度了吗？是的，SOTA 模型。它甚至无法正确定义函数，选择将函数拆分成更小的函数，而这些函数实际上是不可重用的。从一个较大的函数中提取一个较小的函数是一个非常糟糕的选择，如果你要理解较大的函数，你必须也要阅读提取的较小函数的实现。定义可重用和清晰的函数是一种艺术形式，一种需要掌握的艺术。大多数开发者，仍然是 Dreyfus 模型中的“高级初学者”，无法定义良好的、清晰的、可重用的函数，AI 目前也无法做到。如果人们仍然控制着 AI 并从这些错误中学习，这还不算太糟。但我们看到一个趋势，即人们依赖 AI 来编写代码，甚至
原文链接: https://alexn.org/blog/2026/09/22/ai-has-no-wisdom-and-neither-will-you/