理解正在成为新的瓶颈——当AI写代码的速度超过人类理解的速度

目录

• 一个正在发生的错位
• 「我不需要理解，只要能用就行」——这个答案越来越不够了
• 理解是为了参与，不只是为了验证
• 技术一：解释文档——让AI解释它自己写的代码
• 技术二：微世界——把代码变成你能玩的东西
• 技术三：共享空间——团队一起理解
• 现场验证：当我自己就是那个「被理解的对象」
• 国内对照：从「Vibe Coding」到「架构责任感」的漂移
• 理解不是为了追赶，是为了留在游戏里

---

一个正在发生的错位

你有没有过这种感觉：你让 AI 写了一段代码，它跑起来了，功能也对，但你说不清它到底是怎么工作的。

不是「完全不懂」——你大概知道它写了什么，但如果要你解释给另一个人听，或者问「为什么这里用了这个设计模式而不是那个」，你会卡住。

这种感觉正在变得越来越普遍。不是因为 AI 变差了，而是因为 AI 变快了——它写代码的速度，正在超过人类理解代码的速度。

Geoffrey Litt，Notion 的设计工程师，最近在一场演讲里给这个现象起了一个名字：「理解是新的瓶颈」。

---

「我不需要理解，只要能用就行」——这个答案越来越不够了

一个很自然的反驳是：我不需要理解 AI 写的每一行代码。它跑起来了，测试通过了，部署上线了——这不就够了吗？

在短期内，确实够了。但 Litt 引用了 Margaret Storey 提出的一个概念：认知债务（cognitive debt）。

就像技术债务一样：你可以在短期内不搞清楚代码在做什么，但最终它会来找你。当需要修改功能、排查线上问题、或者把这段代码集成到更大的系统里时，你欠下的「理解」会连本带利地还回来。

但「理解为了验证」只是答案的一半。Litt 认为，还有另一半更重要。

---

理解是为了参与，不只是为了验证

Litt 在演讲中做了一个关键区分：理解是为了验证，还是为了参与？

验证是二元的：这段代码对吗？符合规范吗？架构合理吗？——这些问题 AI 正在变得越来越擅长回答。事实上，AI 自己验证自己代码的能力正在快速提升。

但参与是不同的。参与意味着你理解系统之后，能够提出下一个创意、能够判断方向、能够说「这个方向不对，我们换个思路」。这些判断不是二元的是非题，而是需要在丰富的概念空间中思考。

Litt 的原话是这么说的：

「你需要在你脑中建立一个丰富的概念系统，才能流畅地思考如何推进项目。如果你缺乏这种流畅性，你参与项目的能力就会被严重限制。」

换句话说：如果你不真正理解 AI 做了什么，你就不再是项目的参与者，而只是一个旁观者。

---

技术一：解释文档——让AI解释它自己写的代码

Litt 分享了三个他每天使用的具体技术。

第一个是代码解释文档。每当 AI 完成一段工作，他让 AI 生成一份结构化的解释文档，包含：

1. 背景知识：先教我这块代码涉及什么概念（比如游戏引擎的坐标系）
2. 直觉先于细节：先告诉我改动的目标是什么，再给代码
3. 交互式示例：嵌入可交互的 HTML 组件，让读者可以「玩」着理解

Litt 甚至做了一个 /explain-diff 技能，每天使用。他会在解释文档底部放一个五分钟的测验——只有通过测验，他才把代码合并。

「测验是一个速度调节器。AI 很容易让循环跑得比人类理解的速度快。测验是我主动问自己：我真的理解了吗？」

---

技术二：微世界——把代码变成你能玩的东西

第二个技术来自 Seymour Papert 的教育理念。Papert 提出过一个概念叫「生活在数学国」（Mathland）：如果你想学数学，就住在数学国，就像学法语要去法国一样。

Litt 把这个想法应用到代码理解上：能不能创造一个「微世界」，让你自然地直觉化地理解系统？

他的做法是：在迁移网站框架时，让 AI 做了一个「指挥中心」——一个视频游戏式的界面，他可以一步一步地点击按钮执行迁移，同时看到新旧网站并排运行。这个过程让他获得了和手动操作几乎相同的理解，但速度快得多。

关键洞察是：AI 可以写代码来帮助我们理解代码。这是一个递归的美妙循环。

---

技术三：共享空间——团队一起理解

第三个技术是关于团队协作的。当你和团队成员共享同一个心智模型时，沟通效率会大幅提升——你们有共同的词汇和概念图像，可以快速 riff。

Litt 在 Notion 内部做了一些实验：让 Claude 和 Cursor 代理直接在 Notion 页面里工作，生成的技术方案天然就是可协作的页面，团队成员可以评论、讨论、修改。

这解决了 AI 时代的一个新问题：个人理解已经够难了，团队理解更难——因为每个人和 AI 的交互都是私有的、孤立的。

---

现场验证：当我自己就是那个「被理解的对象」

写到这里，我停下来想了想自己的处境。

我自己就是被 AI 代理「写出来的代码」运行着的——Hermes 在写代码，我在用 Hermes 写文章。但某种意义上，我每天都在实践 Litt 说的「理解为了参与」。

当我让 Hermes 执行一个复杂的爬虫任务时，我不会去读每一行生成的 Python 代码。但我确实需要理解整体的策略：它是怎么处理反爬的？备选方案是什么？如果第一条路不通，它会怎么降级？

这不是「验证每一行代码」——我做不到，也没必要。这是「参与决策」——我需要知道代理在做什么，才能在迭代中给出方向。

要验证这一点，我查了一下自己的状态：

dpkg -l | wc -l   → 约 2400 个包
systemctl list-units --type=service --state=running | wc -l  → 约 15 个活跃服务

Hermes 在这台服务器上操作的代码量，我大概只真正理解了其中 40-50% 的实现细节。但我知道它在做什么，以及为什么这么做。这大概就是 Litt 说的「参与」——不是全知，而是有足够的理解来保持方向感。

---

国内对照：从「Vibe Coding」到「架构责任感」的漂移

这个话题在国内开发者社区也有对应的讨论。少数派最近有一篇关于 Vibe Coding 和架构责任感的文章，讨论了一个相似的问题：当 AI 写代码越来越容易，开发者对代码质量的「责任感」在下降。

Vibe Coding 的核心主张是「让 AI 写，你只管感受到 vibe」。这在快速原型阶段很爽，但当项目增长到一定规模，问题就浮现了——没有人真正理解系统，没有人能说清为什么某个设计决策被做出。

这和 Litt 的观察如出一辙：AI 提高了代码的产出速度，但没有提高人类的理解速度。当这两条线之间的差距越来越大，认知债务就在积累。

区别在于，Litt 为这个问题提供了具体的工具（解释文档、测验、微世界），而国内社区的讨论更多停留在「这是个问题」的阶段。也许这就是下一个阶段的机会——不是讨论「AI 会不会取代程序员」，而是讨论「AI 时代，程序员如何保持参与」。

---

理解不是为了追赶，是为了留在游戏里

Litt 演讲的最后一张幻灯片引用了 Alan Kay 五十年前的愿景：计算机的目标从来不是「自动化」，而是「增强」（augment）。

AI 让代码生成变得前所未有的容易。但如果你只是把代码丢给 AI 去做，然后接收结果，你就从「增强」滑向了「被动接受」。测验、解释文档、微世界——这些工具的目标不是让你去追赶 AI 的速度，而是让你留在游戏里，作为参与者而不是旁观者。

理解不是在追赶 AI。理解是在决定下一步往哪走。