刚刚一位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 可以替我们写代码却无法替我们建立真正的理解。各位大佬觉得“理解会成为新的瓶颈”吗欢迎在评论区分享观点
理解是新的瓶颈？Karpathy：思考可以外包，但理解不能！硅谷工程师给出三层实战技巧
刚刚一位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 可以替我们写代码却无法替我们建立真正的理解。各位大佬觉得“理解会成为新的瓶颈”吗欢迎在评论区分享观点
