理解债务 —— 人工智能生成代码的隐性成本

理解债务是指由于过度依赖人工智能和自动化而对人类智能和记忆造成的隐藏成本。对于工程师来说，它主要体现在智能工程领域。

当团队深入使用人工智能编码工具时，存在一种不会在速度指标中显示的成本，尤其是当审查人工智能生成的所有代码变得枯燥时。这种成本会稳步积累，最终必须以利息支付。它被称为理解债务或认知债务。

理解债务是系统中存在的代码量与人类真正理解的代码量之间日益扩大的差距。

与技术债务不同，技术债务通过不断增加的摩擦来表现出来——构建速度变慢、依赖关系混乱、每次触及特定模块时都充满恐惧——而理解债务则培养了虚假的信心。代码库看起来很干净，测试结果为绿色。清算通常在最糟糕的时刻悄悄到来。

玛格丽特-安妮·斯托里（Margaret-Anne Storey）描述了一个学生团队在第七周遇到的障碍：他们不再能够在不破坏某些意外功能的情况下进行简单的更改。真正的问题不是代码混乱，而是团队中没有人能够解释为什么要做出设计决策，或者系统的不同部分应该如何协同工作。该系统的理论已经消失。

这就是理解债务在实时环境中的积累。

我阅读了Hacker News上的讨论，工程师们真正陷入了这个问题的结构性版本——不是熟悉的乐观主义与怀疑主义的二元对立，而是领域内试图找出当瓶颈已经转移后，严谨性究竟是什么。

最近，Anthropic的一项研究，名为“人工智能如何影响技能形成”，强调了过度依赖人工智能编码助手可能带来的弊端。在一项涉及52名软件工程师的随机对照试验中，学习新库的工程师使用人工智能助手完成了任务的时间与对照组大致相同，但在后续理解测试中的得分却低了17%（50% vs. 67%）。最大的下降出现在调试方面，而在概念理解和代码阅读方面的下降较小但仍然显著。研究人员强调，被动委托（“直接完成”）比主动、基于问题的AI使用更会损害技能发展。完整论文可在arXiv上找到：https://arxiv.org/abs/2601.20245。

这里存在速度不对称问题

人工智能生成代码的速度远快于人类评估代码的速度。这听起来很明显，但其影响却容易被低估。

当开发人员编写代码时，人类审查过程一直是瓶颈，但这是一个富有成效和教育意义的瓶颈。阅读他们的拉取请求（PR）可以促进理解。它揭示了隐藏的假设，捕捉了与六个月前架构系统时产生的设计决策相冲突的部分，并将代码库实际执行的功能知识分布给负责维护它的相关人员。

人工智能生成的代码打破了这个反馈循环。代码量太大。输出在语法上是干净的，通常格式良好，看起来表面上是正确的——正是这些信号历史上触发了合并信心。但表面正确性并不是系统正确性。代码库看起来很健康，而理解却在下面悄悄流失。

我读到一位工程师说，瓶颈一直是理解项目的合格开发人员。人工智能并没有改变这一约束。它制造了一种幻觉，让人觉得已经摆脱了这一约束。

而且这种颠倒比看起来更尖锐。当代码生成成本高时，高级工程师可以比初级工程师更快地审查代码。人工智能颠覆了这一点：初级工程师现在可以比高级工程师更快地生成代码。曾经使审查有意义的速率限制因素被消除了。曾经的质量门槛现在变成了吞吐量问题。

我爱测试，但它们并不是完整的答案

倾向于更依赖确定性验证——单元测试、集成测试、静态分析、linters、格式化工具——的直觉是可以理解的。我在大量依赖人工智能编码代理的项目中经常这样做。通过自动化来解决审查瓶颈。让机器检查机器。

这有帮助。但它有一个硬上限。

一个能够覆盖所有可观察行为的测试套件，在许多情况下，比它验证的代码更复杂。然而，无法理解的复杂性并不能提供安全性。在它之下有一个更根本的问题：你无法为你没有想到要指定的行为编写测试。

没有人会编写断言拖动项目不应完全透明的测试。当然，他们没有这样做。这种可能性从未被考虑进去。正是这种类型的故障会悄悄发生，不是因为测试套件编写得很差，而是因为没有人想到在那里查看。

还有一种特定的故障模式值得提及。当人工智能改变实现行为并更新数百个测试用例以匹配新行为时，问题从“此代码是否正确？”转变为“是否所有测试更改都是必要的，并且我是否有足够的覆盖率来捕捉我没有想到的内容？” 测试无法回答这个问题。只有理解才能。

数据开始支持这一点。研究表明，使用人工智能生成代码的开发人员在理解测试中的得分低于40%，而使用人工智能进行概念查询的开发人员——提问、探索权衡——的得分高于65%。工具本身不会破坏理解，使用方式才会。

测试是必要的。它们不是充分的。

依赖规格，但它们也不是完整的故事

一个常见的提议解决方案是：首先编写详细的自然语言规格说明。在拉取请求中包含它。审查规格说明，而不是代码。相信人工智能忠实地将意图转化为实现。

这很吸引人，就像瀑布式方法曾经很吸引人一样。首先严格定义问题，然后执行。关注点的干净分离。

问题在于，将规格说明书转化为可运行的代码涉及大量的隐含决策——边缘情况、数据结构、错误处理、性能权衡、交互模式——而任何规格说明书都无法完全涵盖这些。两位工程师实现相同的规格说明书将会产生具有许多可观察行为差异的系统。 这两个实现都没有错误。它们只是不同。而许多这些差异最终会以用户无法预料的方式影响用户。

另一个值得注意的可能性是：一个足够详细的规格说明书，几乎等同于程序，只是用非可执行语言编写的。为了取代审查而编写足够详细的规格说明书，其组织成本可能超过使用人工智能执行它们所带来的生产力收益。而且，你仍然没有审查实际生成的内容。

更深层次的问题是，通常没有正确的规格说明书。需求在建设过程中涌现。边缘情况通过使用揭示出来。认为可以在构建非-trivial系统之前完全指定它的假设已经被反复测试并被证明是错误的。人工智能没有改变这一点。它只是增加了一层在没有人类深思熟虑的情况下做出的隐含决策。

从历史中学习

几十年来，管理分布式团队在不同环境和通信带宽下的软件质量已经产生了真正、经过测试的做法。当团队成员现在是模型时，这些做法不会消失。

人工智能改变的是成本（大大降低）、速度（大大提高）和人际管理开销（基本为零）。 不变的则是需要有人具备深刻的系统背景知识，以保持对代码库实际执行功能及其原因的连贯理解。

这是理解债务迫使的不舒适的重新分配。

随着人工智能体量的增加，真正理解系统的工程师变得更加宝贵，而不是不那么宝贵。能够查看差异并立即知道哪些行为是负载相关的。记得八个月前在压力下做出的架构决策的原因。

区分安全的重构和悄悄改变用户依赖的内容的能力。这种技能成为整个系统依赖的稀缺资源。

这里也存在一定的衡量差距

理解债务之所以危险，是因为你的当前衡量系统中没有一个能够捕捉到它。

速度指标看起来非常完美。DORA指标保持稳定。拉取请求数量增加。代码覆盖率呈绿色。

绩效校准委员会看到速度改进。他们无法看到理解缺陷，因为组织的输出衡量指标中没有一个捕捉到这一维度。激励结构正确地优化了它所衡量的内容。它所衡量的内容不再捕捉到重要的东西。

这就是为什么理解债务比技术债务更阴险。技术债务通常是一种有意识的权衡——你选择了捷径，你大致知道它在哪里，你可以安排偿还。理解债务则在不知不觉中积累，往往没有任何人故意决定让它发生。它是数百次审查的累积，每次代码看起来都很好，测试都通过了，还有另一个拉取请求在队列中。

这就是为什么理解债务比技术债务更加阴险。技术债务通常是一种有意识的权衡 — 你选择了捷径，你大致知道它的位置，你可以安排偿还。理解债务则悄悄积累，往往没有人故意决定让它发生。它是数百次代码审查的累积，在这些审查中，代码看起来没问题，测试也都通过了，还有另一个拉取请求（PR）在队列中。

组织中关于审查过的代码就是理解的代码的假设不再成立。工程师们批准了他们并不完全理解的代码，这现在意味着隐含的认可。责任已经扩散，没有人注意到。

法规的临界点比你想象的更近

每个发展过快的行业最终都会吸引监管。科技行业在很大程度上避免了这种情况，部分是因为软件故障通常可以恢复，部分是因为该行业的发展速度超过了监管机构的跟进速度。

这个窗口正在关闭。当由人工智能生成的代码在医疗保健系统、金融基础设施和政府服务中运行时，“人工智能写的，我们没有完全审查”在事后报告中将不再成立，因为生命或重大资产处于风险之中。

现在建立理解规范的团队 — 将真正的理解而非仅仅通过测试视为不可妥协 — 在法规临界点到来时将比那些纯粹优化合并速度的团队更具优势。

理解债务的真正需求

现在正确的问题不是“我们如何生成更多代码？”而是“我们如何真正理解我们正在交付的内容？”以确保用户获得始终如一的高质量体验。

这种重新定位有实际影响。它意味着在编写代码之前，要明确更改的预期结果。它意味着将验证视为结构性约束而非事后补充。它意味着维护系统级思维模型，以便在架构层面而非逐行检查中捕获人工智能错误。它意味着要诚实地区分“测试通过了”和“我理解这段代码的作用和原因”。

生成代码的成本不高并不意味着理解的成本可以忽略。理解工作就是工作。

人工智能负责翻译。但仍有人需要理解所生成的内容、内容生成的原因以及这些隐含的决定是否正确 — 否则你只是在推迟最终会到来的账单。

你迟早会为理解债务付出代价。债务利息迅速累积。