低廉代码的隐藏成本：从外包到 AI 的教训

编写代码的成本已经崩塌。随着 LLMs 和 coding agents 的兴起，功能完备、合格且平庸的代码现在可以以五年前难以想象的速度和成本生成。然而，正如历史所暗示的那样，当生产成本下降时，成本并不会消失——它只是发生了迁移。

这种现象并不新鲜。行业内许多人还记得 2000 年代初的外包浪潮，当时的目标是通过将生产转移到劳动力成本较低的地区来降低开发成本。虽然经济学逻辑是合理的，但长期的结果往往是机构知识和架构意图的丧失。我们现在正面临着与 AI 生成代码类似的拐点。

成本的迁移：从生产到维护

当编写代码的成本很高时，开发者被迫要有目的性。每一行代码都是基于约束、未来扩展性和系统架构的深思熟虑的决定。当代码变得“廉价”时，对为什么选择特定实现的批判性思考动力就会减弱。

AI 工具可以生成通过测试并直接交付的代码，但它们往往无法捕捉代码背后的意图。这造成了一个危险的鸿沟：我们拥有了功能完备的软件，但我们不再理解其存在的逻辑。这与许多公司在对外包时代掉入的陷阱相同——他们收到了要求的交付物，但失去了让系统能够在数十年内进行演进和维护的“为什么”。

AI 驱动开发的主要风险之一是文档和推理过程的侵蚀。与人类开发者不同，AI 不会自然地维护一个关于项目长期架构目标的心理模型。

社区讨论突出了几个关键担忧：

文档鸿沟： 对文档的需求日益增长，这些文档不仅要人类可读，还要“agent-ingestible”（可供 agent 摄取），以便 AI 理解它正在修改的系统的约束条件。
“黑盒”效应： AI 生成的代码往往缺乏人类开发者可能会提供的注释或原理说明。虽然有人建议通过提示词让 AI 在代码中包含其推理过程，但根本问题仍然在于 AI 是在预测下一个 token，而不是在设计系统。
盲目信任的风险： 一些开发者承认依赖 AI 来阅读并向他们解释代码，这实际上将人类从理解的环节中移除了。正如一位用户所指出的，“我并不阅读代码……我让 LLM 阅读代码并告诉我它在做什么。”

为了避免重蹈覆辙，团队必须找到方法将目的性重新引入 AI 辅助的工作流中。开发者社区涌现出了几种实用的方法：

与其依赖代码本身来讲述故事，一些团队正在实施专门的决策日志。一种方法是维护一个 decisions.md 文件，每当 agent 向人类询问产品或架构选择时，就对其进行更新。这捕捉到了那些在生成的 diffs 中消失的意图。

为了防止对代码库失去掌控，一些开发者主张进行严格的审查过程。这包括实时阅读 AI 做的每一个改动，并要求对任何模糊的逻辑立即进行解释。这确保了开发者仍然是架构师，而 AI 仅仅是工具。

有一种强有力的观点认为，AI 生成代码的标准不应低于人类编写的代码。如果一段代码无法理解或无法维护，那么无论它是由谁——或什么——编写的，都不应该被合并。对最终产品的控制权至关重要。

集成 coding agents 将开发者的认知负荷从“内存密集型”（了解语法和 API）转向了“计算密集型”（对系统进行推理并验证输出）。虽然效率的提升是不可否认的，但危险在于将代码视为一种商品，而非架构意图的体现。

如果我们把 AI 生成的代码视为一种可抛弃的资产，我们就有可能构建出一个今天能用但明天无法理解或修改的软件未来。目标不是停止使用 AI，而是确保生产成本与理解成本保持挂钩。