理解成为新的瓶颈
理解成为新瓶颈
本文是我2026年7月在AI Engineer大会上的演讲文稿，同时也以推文串形式发布。
个人观点：我认为理解AI生成的代码依然至关重要！
接下来我会解释原因，并分享一些高效理解代码的思路。话不多说，我们直接切入正题。
如今AI生成的代码越来越多，大家都明显感觉到跟进难度在加大。
但好消息是：理解代码的方法不止一种！逐行查看代码差异绝非唯一途径。
本次演讲将重点介绍我在理解AI构建的系统时，发现颇为实用的几种技巧：
- 代码解释文档
- 检验理解程度的测试题
- 可交互的微型模拟环境
不过在此之前，我们得先回答一个更基础的问题……
为什么要理解？
为什么？我们为什么要理解代码？
现在不是应该让人类退出循环，交给AI自主迭代吗？随着AI越来越智能，人类深入细节的必要性难道不会越来越低？
我发现，很多人——哪怕是支持“理解代码”的人——对这个问题的回答都略有偏差！
一种常见的答案是：理解是为了验证。我们要检查AI的工作成果是否正确。
“正确”可以有很多层面：是否符合需求规格、架构是否合理……但本质上是一个“合格/不合格”的二元判断。
但问题在于：AI自我验证的能力正在飞速提升。这当然是好事！谁都不想AI犯错。
可这样一来，人类的价值在哪里？
这就引出了另一个答案：理解是为了参与**。**
了解AI的工作内容，能让你在创意流程中保持主动参与的状态。这一点至关重要，原因如下……
项目从来不是单次迭代就能完成的，而是需要与AI进行无数轮互动。
你对系统的理解深度，直接决定了你能否想出推动项目发展的下一个创意。
只有脑海中建立起一套完整的概念体系，你才能流畅、创造性地思考项目的演进方向。如果缺乏这种认知流畅度，你参与项目的能力就会受到极大限制。
顺便提一句，这与Margaret Storey和Simon Willison提出的认知债务概念密切相关。
它就像技术债务：短期内不懂系统运行原理似乎也能应付，但最终一定会带来麻烦。
好，既然理解如此重要。
那接下来的问题就是：怎么做？在与AI协作、快速推进项目的过程中，人类该如何建立这种理解？
其实，关于如何传递认知这件事，前人早有思考。我们可以从教育领域汲取灵感——能不能把教育领域最成功的理念借鉴过来，解决这个问题？
技巧一：结构化解释
今天我想分享三种实践方法。
第一种：结构化解释。什么样的解释才算好？
AI完成一项工作后，正是生成解释文档的绝佳时机。
最直接的方式是查看代码差异——也就是原始的变更内容。
但不妨换个思路：
**最优的解释是什么样的？**如果有一个团队——无论是人类还是AI——能贴心地把内容给你讲透彻，那体验会有多好？
我给出的答案是：我开发了一个名为/explain-diff的工具，我每天都会用，很多同事也觉得它很实用。
它能生成结构清晰的代码解释文档，格式支持HTML、Markdown或Notion文档。Notion很适合团队协作讨论这类文档（声明：我在Notion工作，因此可能带有主观倾向）。
我们以修改某款游戏的视角为例，看看这类解释文档包含哪些内容。
第一条原则：先讲背景知识！
在介绍变更内容之前，先帮我理解系统原本的状态。比如在这个例子中，先讲解游戏引擎的相关知识。
第二条原则：先讲直觉，再讲细节。
在展示代码之前，先说明目标——“用2D绘图技巧让花园呈现立体感”——并解释相关概念，比如什么是等轴测投影。
这些内容能帮我快速把握变更的核心，让我跟上节奏，以平等的姿态参与到对代码的理解中。
你还可以通过交互式图形建立直观认知。
比如在这个例子里，我可以拖动花园里的石块，观察坐标变化，以此理解等轴测视角的原理。
（这用到了Notion刚推出的新功能：现在可以在页面中嵌入交互式HTML内容。）
最后才轮到代码部分。但普通的代码差异只是按字母顺序排列的一堆修改文件，没有任何解释。
我称之为“可读式差异”的文档，会以散文式结构呈现——按合理顺序梳理变更，辅以解释说明和嵌入式代码片段。相比原始差异，这种形式的审阅效率要高得多。
最终产出的是一份完整的解释包。我还是会看原始代码差异，但一定会先读这份文档。
有时我会把它打印出来，带到咖啡馆阅读——这样更不容易分心。
颇具讽刺意味的是：AI把一项交互式工作，变成了能让我深度专注的纸质报告 :)
但这里有个问题：阅读本身就是件费力的事 😅
正如Andy Matuschak所说：“书籍行不通”！你很容易自欺欺人，以为自己读完了，实则根本没记住或理解。
怎么解决这个问题？我从Andy和Michael Nielsen在文章中嵌入间隔重复测试题的做法中获得了灵感。
现在我会在代码解释文档中加入类似的设计。在文档末尾，有一个包含5道题的交互式测试，我会尝试作答。
我的规则是：只有能通过测试，我才会把代码发给别人；审阅他人代码时也是如此。
**测试题是一种速度调节器。**与AI协作时，迭代速度很容易超过人类理解的速度。
测试题则是一种平衡力量：它让我能切实地问自己“我真的理解了吗？”，从而确保自己始终能全程参与创意过程。
技巧二：微型模拟环境
第二个思路：微型模拟环境。这一灵感来自富有远见的教育家Seymour Papert。
Papert提出了一个精妙的理念——“活在数学世界里”：如果想学好数学，就“活”在数学世界中，就像学法语要去法国生活一样。我们能不能构建一个环境，让孩子出于好奇心，自然而然地学习数学？
那这个理念如何应用到代码上？我们能不能打造一个可沉浸的环境，让你自然而然地理解系统的运行方式和变化逻辑？
去年我在开发Prolog解释器时，很难直观理解其内部运行机制。
于是我和AI协作开发了一个调试器，它能让我一步步跟踪逻辑语言的执行过程——可以回溯执行步骤，查看栈内数据，以及每一步执行的规则。我甚至可以给自己留下注释（比如“不错，这条规则应用正确”）。
自己动手调试，和让AI代劳调试，两者有天壤之别——亲力亲为的过程本身就是建立理解的过程。
再举个例子。我曾把个人网站从一个框架迁移到另一个框架，Claude帮我写了迁移脚本。但我很难审阅：我不熟悉新框架，只能含糊地说“看起来大概没问题”。
于是我让Claude为我打造了一个类似游戏的“指挥中心”，让我可以一步步手动完成迁移，同时观察可视化效果和文件结构的变化。它生成了一个UI界面，我可以点击按钮逐步执行迁移，旧网站和新网站会并排展示。
在这个指挥中心里，我看着新网站一点点成型。最终我获得的理解深度，和手动完成迁移几乎无异——但速度快得多，因为整个流程都已经为我梳理好了。
这里的核心是：AI可以生成辅助代码，帮助人类理解其他代码。
这意义重大！
技巧三：共享认知空间
最后一个技巧：共享认知空间。前面讲的都是个人如何理解代码……但在团队协作中，我们需要共同建立理解。
当你和他人拥有相同的心智模型时，沟通效率会大幅提升。你们有共同的词汇体系，能唤起相同的认知画面，从而可以顺畅地交流、碰撞创意。如果缺乏这种共享的认知框架，沟通就会变得困难重重。
我对打造团队共享认知环境充满期待——这也是Notion的核心价值之一。
最近Notion推出了大量新功能，支持人类与AI协作，让整个团队共同建立理解，而非各自为战。
举个小例子：现在可以在Notion中运行Claude和Cursor的AI代理。我现在很多编码工作都通过这种方式完成。
当这些AI在Notion中制定技术方案时，默认会创建在协作页面中，我可以立刻和团队成员评论、讨论。我们一起思考，而非孤军奋战！
核心始终是增强，而非替代
好了，我们来总结一下。今天我们讨论了一些理解代码的技巧……但实际上，这背后是一个更宏大的议题。
人类理解事物的运行原理，在任何时候都至关重要！不仅是为了验证，更是为了参与。
有意思的是，这并不是什么新理念。它可以追溯到计算机领域的起源……
50年前，Alan Kay就设想过，计算机可以成为一种全新的媒介，比书籍更适合教人们——尤其是孩子——如何思考世界。
这张照片里的孩子们看似在用iPad看视频，但实际上不是。他们在玩一款交互式游戏，同时通过修改游戏代码来理解物理原理。这可是50年前的事！
现在你应该能看懂这个梗图了。
技术的核心始终是增强人类能力，而非单纯的自动化。
如今AI让创建模拟环境变得如此容易……AI辅助学习，是计算机技术带来的最伟大的可能性之一。
这让我对未来充满信心！
**只要打造出合适的工具，我们就能比以往任何时候都更深刻地理解世界。**我们不必仅仅退出循环，反而可以更深入地参与其中。这取决于我们自己。
完
延伸阅读
如果你喜欢这篇演讲，或许也会喜欢我写的其他关于人机协作的文章：
别再搞AI copilots了！我们需要AI HUDs——“任何认真研究AI设计的人，都应该考虑非 copilot 形式的工具，更直接地拓展人类思维……”
AI生成工具能让编程更有趣——“我用AI打造了一个定制化调试器UI……这让我自己写代码的过程变得更有趣……”
像外科医生一样写代码——“识别并委派次要的繁琐任务，这样你就能专注于真正重要的核心工作。”