刚刚，一位Notion的工程师Geoffrey Litt在X上发布了一篇文章 Understanding is the new bottleneck，并直接抛出观点：理解 Agent 编写的代码很重要
“理解是新的瓶颈！”
刚刚，一位Notion的工程师Geoffrey Litt在X上发布了一篇文章 Understanding is the new bottleneck，并直接抛出观点：理解 Agent 编写的代码很重要！
知名博主 Peter Yang 评论：“对于一个还在努力学习如何阅读代码的人来说，这太棒了！我马上就安装 explain-diff 技能。”
随着 Agent 为我们编写的代码越来越多，要跟上它们的步伐越来越难。
这就引出了一个问题：当 Agent 越来越聪明，我们是不是应该退出循环，让它自己跑？
当 AI 越来越聪明，人类为什么还要理解代码？
常见的答案是，理解是为了验证。我们看代码，是为了检查它对不对、符不符合需求、架构合不合理。说到底，这是一个“对、错”的判断题。
但 Geoffrey Litt 给出的答案是：理解是为了参与。 一个项目从来不是“一次性交付”，而是无数次循环迭代。如果理解跟不上，我们能参与项目的深度就会被限制。
这跟“认知负债的概念很像：短期内你可以靠“不理解也能跑起来”蒙混过关，但迟早要还债，很多时候是团队集体“跟丢了剧情”。
推广认知负债的 Simon Willison 也转发评论：“我非常喜欢这种‘理解参与’的认知债务问题框架，尤其是在与编码 Agent 合作时。”
那么，下一个问题是“我们该如何理解？”
Geoffrey 给出了理解的三个技巧：理解、微观世界、共享空间
第一，解释。
每次 Agent 完成一段工作，其实都是一次“讲解”的机会。最简单的做法是看代码差异。
但如果换个角度：“最好的解释”应该是什么样的?
Geoffrey 开发了一个/explain-diff的技能，它会自动生成结构化的讲解文档（HTML、Markdown 或 Notion 页面都可以），并遵循几个原则：
原则一：先补背景知识。 在讲“改了什么”之前，先讲清楚“原来是什么样”。比如改一个游戏引擎的视角逻辑，先讲清楚这个引擎本身是怎么工作的。
原则二：先建立直觉，再看细节。 在看代码之前，先说清楚这次改动的目标是什么、涉及哪些概念。比如“让花园看起来有三维感”，顺带讲清楚“等距投影”是什么，甚至可以配上可交互的小图。
原则三：把 diff 写成“叙事”，而不是文件清单。 普通 diff 是一堆按字母顺序排列、毫无解释的改动文件。而“文学化的 diff ”则是按照合理的逻辑顺序，像讲故事一样，穿插解释和代码片段——读起来比原始 diff 容易得多。
最终能产出一份讲解“文档包”。这也就意味着 AI 把一件本该互动的事，变成了一份可以安静专注阅读的纸质报告。
但阅读本身就是苦力活。 就像 Andy Matuschak 说的那样，“书是没用的”，你很容易骗自己“我读完了“，但其实什么都没记住、没理解。
Geoffrey 的解决办法是借鉴 Andy 和 Michael Nielsen 在“间隔重复测验嵌入文章“上的做法：在文档末尾都会附一个交互式小测验（五道题左右），并且测验答不对，就不能把代码发给别人；审查别人的代码时也一样。
备注：Andy Matuschak 是软件工程师、设计师、研究员，曾在 Apple 构建 iOS，后来在 Khan Academy 工作。
Michael Nielsen，澳大利亚量子计算科学家，是量子计算领域的先驱之一。
这个测验的作用，是给 AI 循环装上一个“限速器”。 和 AI 协作时，循环运行的速度很容易超过人类理解的速度，而测验就是那股反向的制衡力量。
第二，微观世界。
第二个技巧的灵感来自教育家 Seymour Papert。他有个理念叫“生活在数学国”，想学好数学，就应该“住”在一个数学的环境里，就像想学好法语，最好的办法是搬去法国住。
那么把这个思路搬到代码上：能不能造一个“世界”，让你身处其中，自然地直觉到系统是怎么运作、怎么变化的?
Geoffrey 举了两个例子：
一是他在写一个 Prolog 解释器时，很难直觉到内部到底发生了什么。于是和 Agent 一起做了个调试器，可以单步执行逻辑规则、来回拖动时间轴、查看每一步的调用栈，甚至可以给自己留评论。
关键区别在于：是自己做一个工具来调试，还是让 Agent 直接帮你调试。
二是他把个人网站从一个框架迁移到另一个框架，Claude 写了个脚本直接搞定，但这特别难审核。于是他让 Claude 做了个“小游戏”：一个指挥中心界面，他自己一步步点按钮完成迁移，新旧网站并排跑着，亲眼看着新网站一点点上线。这样获得的理解，和亲手一行行迁移差不多，但速度快得多，因为整个过程都被可视化了。
这里的重点是：Agent 不仅能写代码，还能写出“帮助人类理解代码的代码“。
第三，共享空间。
最后一个技巧，是关于团队协作的。
当你和同事拥有相同的思维模式时，沟通效率会大大提高，你们有共同的“词汇表”，一说就能想到同一幅画面，可以顺畅地碰撞创意。缺了这层共同的结构，沟通会变得费劲很多。
比如现在可以直接在 Notion 里跑 Claude 和 Cursor agent，当这些 Agent 产出技术方案时，默认就是一个可协作的页面。团队可以立刻在上面评论、讨论。是“一起想“，而不是“各想各的”。
理解不是为了验证，而是为了参与
50 年前，Alan Kay (2003年图灵奖得主) 就设想过：计算机可以成为一种新的媒介，比书本更好，用来教会人们（尤其是孩子）如何思考这个世界。他设想的画面里，孩子们看起来像是在用 iPad 刷视频，但其实他们是在一边玩一个交互式游戏，一边修改代码，借此更深地理解物理学，这是五十年前的想象。
AI 的意义从来不只是自动化，而是增强人类。 让 AI 来教导我们是计算机技术迄今为止带来的最大可能性之一。
网友：测验只会增加工作量，却收效甚微
关于 Geoffrey 的观点，有网友表示赞同：“这些是我找到的为数不多的几个切实可行的想法，而且看起来很有说服力！”
当然，有赞同就有否定：
“很有意思，但我不同意。测验只会增加工作量，却收效甚微。它只不过是家庭作业而已。”
写在最后
过去几年，行业一直在讨论各种瓶颈：算力是瓶颈、数据是瓶颈、上下文是瓶颈等。例如，OpenAI 联合创始人 Greg Brockman直言，算力才是真正的硬通货，并且绝对不够！谷歌 CEO Pichai 认为当前最迫切需要解决的是内存瓶颈。
Geoffrey Litt 也给出了他的答案：理解，才是新的瓶颈。
Andrej Karpathy 也在播客中提到过类似想法：“你可以外包思考，但你不能外包理解。我现在越来越觉得，真正的瓶颈甚至变成了：我是否足够理解我们到底在建什么、为什么值得建、我该如何指挥这些 agent。”
Agent 可以替我们写代码，却无法替我们建立真正的理解。
各位大佬觉得“理解会成为新的瓶颈”吗，欢迎在评论区分享观点！