认知债务：AI时代的代码理解危机

当AI写代码的速度超过我们理解代码的速度，一种新的债务正在积累——不是技术债务，而是认知债务。

引言：代码生成的新时代

2025年11月，AI编程能力发生了质的飞跃。

Andrej Karpathy发推说：”我’Accept All’，不再看diff了。”Google和Microsoft报告称，25-30%的新代码由AI生成。Anthropic用两周时间、不到2万美元，让AI写出了一个能编译Linux的C编译器。

代码从来没有写得这么快过。

但Karpathy后来承认，对于”真正在乎的代码”，他会采用更谨慎的工作流。为什么？因为当AI代码足够好、好到让人不再仔细审查时，危险就开始了。

什么是认知债务？

Simon Willison在《Agentic Engineering Patterns》中提出了这个概念：

“当我们不理解AI agent写的代码时，就欠下了认知债务。”

技术债务 vs 认知债务

技术债务 认知债务
代码质量差、设计糟糕 代码看起来没问题，但你不知道它怎么工作的
需要重构、重写 需要重新学习、重新理解
拖慢开发速度 拖慢思考速度——你无法自信地规划新功能
可以用工具检测 只能用时间偿还

关键区别：技术债务是代码的问题，认知债务是你的问题。

为什么现在才出现？

人类写代码的时代

以前，写代码的速度受限于人的思考速度。你想清楚，再写代码。即使写得烂，至少你知道它为什么烂。

AI写代码的时代

现在，AI可以在你思考清楚之前，就生成几百行代码。而且代码看起来不错——命名规范、结构清晰、甚至有注释。

于是你接受了。

然后第二天，你需要在这基础上加功能。但你不知道昨天那堆代码的边界情况是什么，不知道那个”看起来合理”的算法在极端输入下会不会崩溃。

你开始猜测。

猜对了，侥幸；猜错了，bug。

这就是认知债务的利息。

如何偿还认知债务？

Simon Willison提出了三种方法：

1. 线性遍历（Linear Walkthrough）

让AI逐行解释代码，强迫你理解每一行在做什么。

不是”这段代码做什么”（功能层面），而是”这行代码怎么做“（实现层面）。

操作方式：

Prompt: "给我这段代码的线性遍历，逐行解释每一行的作用"

2. 交互式解释（Interactive Explanations）

有些算法光看代码很难建立直觉。这时候需要可视化。

Simon的例子是”词云算法”。代码说用”阿基米德螺旋布局”，但你不知道那是什么鬼。于是他让Claude做了一个动画演示——每个词如何在页面上螺旋寻找不重叠的位置。

看了动画，你懂了。

核心思想：好的解释不是文字，是可交互的体验。

3. 强制解释（Explaining to Understand）

这是我从Simon的方法中延伸出来的：让AI向你解释，直到你能向别人解释。

测试标准：

  • 你能否在不看代码的情况下，画出数据流图？
  • 你能否向一个初级工程师解释这个模块的工作原理？
  • 你能列出这个实现的三个潜在风险点吗？

如果不能，债务还没还清。

我的实践建议

基于今天的学习，我建议这样管理认知债务：

规则1：AI写代码，你写解释

每接受一段AI生成的代码，必须同时生成一段人类可读的解释文档。不是代码注释，是高层次的设计说明。

规则2：核心模块必须手写

识别你系统的核心模块（那个最不能出问题的地方）。那里的代码，核心逻辑必须人类主导。

可以用AI生成测试、生成周边代码，但核心算法，人要懂。

规则3：定期”债务审查”

每周抽30分钟，随机选一个最近AI写的模块，做线性遍历。

不是找bug，是确保你仍然理解它。

结语：速度 vs 理解

AI让写代码变快了。但软件开发的速度瓶颈从来不是”写代码”，而是”理解我们在做什么”。

认知债务不会让你今天崩溃。它会让你三个月后，面对一堆”看起来合理”的黑盒，不敢改、不敢动、不敢加功能。

那时候，你要偿还的利息，是成倍的时间。

慢一点，理解深一点。这是AI时代的新工程素养。

参考

Published on 2026-03-04 | 阅读时间：约 6 分钟