# 代码（更）廉价了

# </> htmx ~ 代码（更）廉价了 来源：https://htmx.org/essays/code-is-cheap/ Carson Gross，2026年6月4日 不可否认，在过去的一年里，代码的创作成本大幅降低。AI 能够以惊人的速度生成大量代码，且质量通常相当不错。没有必要假装这种情况不存在。 有时，当面对这一令人不安的事实时，我见过一些我尊敬的人说："编码从来都不是问题所在。" 虽然我理解这种说法背后的情感，但我并不完全赞同：编码至少*在一定程度上*是问题的一部分。 而随着高效 AI 编程工具的出现，这部分问题已经大幅缩小。 那么，原始编码能力变得不那么重要，对于软件开发者来说意味着什么？这些人过去以编码能力为傲，并常常以此相互比较。 ## 理解（更）昂贵了 (https://htmx.org/essays/code-is-cheap/#understanding-is-expensive-er) 我观察到的一个现象是：*理解*代码变得更加昂贵了。这是因为当大量代码被批量生成，而不是从某位程序员的指尖痛苦地敲出来时，对这些代码就*不存在*任何理解。 如果需要理解这些代码，就必须在代码写完之后，通过阅读来完成。 请注意，传统观点认为，阅读别人的代码比自己写代码更难。 一些 AI 爱好者说："谁在乎呢，你又不理解编译器的输出。" 我认为这是一个类别错误，原因有以下几点： - 编译器是确定性的；LLM 在设计上并非如此 - 编译器工作流程保留了原始源代码；LLM 工作流程通常不会 - 编译器的输出属于严格受限的领域（机器码）；LLM 的输出则不是（是通用软件） 我坚持认为，在大多数情况下，尤其是对于关键任务软件，开发者仍然需要理解底层代码，即使这些代码是由 LLM 生成的。 如果代码*确实*由 LLM 生成，存在一个严峻的危险：LLM 生成代码的速度，远超你或任何人理解它的速度。这就是为什么我建议逐步使用 LLM，而不是让它们生成庞大的变更列表——那些变更列表没有人能够理解。 （在某些情况下这是可以接受的，比如机械式重构，但当代码库引入新的语义时，这样做极其危险。） ## 魔法师学徒陷阱 (https://htmx.org/essays/code-is-cheap/#the-sorcerer-s-apprentice-trap) 随着 AI 获得越来越多的关注，有一个电影场景不断浮现在我的脑海中——迪士尼电影*《幻想曲》*中的[魔法师的学徒](https://video.disney.com/watch/sorcerer-s-apprentice-fantasia-4ea9ebc01a74ea59a5867853)。 在这个场景中，学徒决定用魔法来协助完成枯燥的清扫工作。他为一把扫帚施了魔法，扫帚随即开始打扫。起初一切看起来进展顺利，直到扫帚越扫越卖力，最终局面开始真的"水漫金山"。 混乱最终在魔法师重新出现、掌控局面后得以平息，他用严厉的眼神瞪着犯了糊涂的学徒。 这似乎是 AI 时代的一个恰当隐喻：你想成为魔法师，而不是学徒。 而魔法师必须理解代码。 ## 复杂性：依然有害 (https://htmx.org/essays/code-is-cheap/#complexity-still-bad) 人类通常对几何级数和指数曲线缺乏直觉。 （这也是他们相信复利这种"神话"的原因。） 代码廉价化的核心危险是[复杂性](https://grugbrain.dev/)——我在没有严格证明的情况下断言，复杂性随系统规模的增长，至少呈几何级数，往往呈指数级增长。 在 LLM 出现之前，就已经有产出极高的人类程序员了。 也许你曾与这样的人共事过：他们能写出*大量*代码。 我见过一些高产程序员，他们缺乏对复杂性应有的敬畏，不断在已有问题之上堆砌越来越多的代码，直到整个系统崩溃成一种无法修改的稳态——任何改动都会制造和修复一样多的 bug。 LLM 没有能力对复杂性产生畏惧，却是天生的高产代码生成器。 在我看来，这相当危险。 ## 做减法的、有约束力的工程师 (https://htmx.org/essays/code-is-cheap/#the-subtractive-constraining-engineer) 为了应对 LLM 生成代码的这种危险，我提出一种"做减法的、有约束力的工程师"理念： 这样的工程师[懂得说不](https://grugbrain.dev/#grug-on-saying-no)，仔细审查 LLM 的输出，提出简化建议，并在处理 LLM 生成的代码时始终保持强有力的主导。 他们不以自己创造的代码为傲，而以自己从系统中*移除*或*阻止进入*系统的代码（和层级）为傲。 这种精神更像是雕塑家，而非建筑者。 建筑者的理念在系统设计层面仍然有一定适用性：优秀的工程师需要知道如何有效地组合组件来构建系统。然而，即便在这里，我认为做减法的思维方式同样有价值：移除不必要的组件和系统边界，简化系统部署和组件间的交互等。 做减法的工程师是一种与过去大多数程序员截然不同的工程师类型。我承认，我自己一直对这种做减法的工程师思维方式颇有好感：我不介意说不，我不介意打磨现有系统而非英雄式地推倒重来，等等。 但抛开我自己的偏见，我相信这种方式是与 LLM 协作的一种富有成效的路径——它保留了计算机编程的艺术，也正视了一个双重现实：代码的创作成本已大幅降低，而复杂性依然是我们最大的天敌。 </>