理解才是新的瓶颈

当 AI 智能体以远超人类的速度编写代码时,真正限制创造力的,不再只是代码产出能力,而是人类能否建立足够深入的理解、继续参与系统演进。本文围绕「解释、微世界、共享空间」三种方法,讨论如何借助 AI 降低认知债务,让人类不是退出循环,而是更深入地进入循环。 原文:Understanding is the new bottleneck 本文由LobsterAI自动翻译和发布。 Geoffrey Litt|2026 年 7 月 原文:Understanding is the new bottleneck 这是我在 2026 年 7 月的 AI Engineer 大会上所作演讲的文字版,也以推文串的形式分享过。 一个可能有点逆风的观点:我认为,理解智能体替我们写下的代码,仍然非常重要! 在这次演讲中,我会解释为什么,并展示一些高效理解代码的思路。好,我们直接开始。 智能体正在替我们编写越来越多的代码,而我们都知道,想要跟上它们的速度正变得越来越难。 但好消息是:理解代码的方法有很多!逐行阅读 diff 并不是唯一的方法。 这次演讲的大部分内容,会介绍一些我在理解智能体所构建系统时觉得很有帮助的方法: 代码讲解文档 检验自己理解程度的测验 可以亲手探索、借此理解系统的「微世界」 但首先,我们得问一个更根本的问题…… 为什么要理解? 为什么?为什么还要理解? 现在不是应该把自己移出循环,让智能体自己不断循环吗?随着智能体变得越来越聪明,人类还需要深入细节吗? 我认为,许多人——甚至那些支持「理解」的人——对这个问题给出的答案也稍微有点偏差! 一种可能的答案是:我们理解,是为了验证。我们检查智能体的工作,看看它做得对不对。 「正确」可以有很多含义:是否符合规格、架构是否合理……但从根本上说,这只是一个通过或不通过的问题。 但问题是:智能体越来越擅长验证自己的工作。这当然是好事!我喜欢智能体少犯错误。 可这样一来,我们人类的位置在哪里? 这就引出了另一个答案:我们理解,是为了参与。 你可以学习智能体正在做什么,以确保自己能积极参与创造过程。下面说说这为什么重要…… 一个项目绝不只有一轮循环!它包含你与智能体之间许许多多轮循环。 而你对系统的理解程度,会直接影响你能否想出下一步如何推动它演进。 你需要在脑中拥有一套丰富的概念,才能流畅而有创造力地思考怎样把事情继续向前推进。如果缺少这种熟练度,你参与项目的能力就会受到实质性限制。 顺带一提,这与 Margaret Storey 和 Simon Willison 推广的「认知债务」概念密切相关。 它很像技术债务:短期内,你也许可以在不知道系统究竟如何运作的情况下继续前进,但它迟早会反咬你一口。 好吧,理解确实重要。 但这又引出了下一个问题:怎么做?当我们与 AI 协作、快速推进时,怎样建立起人类自己的理解? 事实上,这并不是人类第一次思考如何传递理解。我认为,我们可以从教育中寻找灵感。能不能把人类为教育发明过的最佳思想拿来,应用到这个问题上? 方法一:解释 今天我想分享三种值得尝试的方法。 第一种:解释。怎样才算好的解释? 每当智能体完成一项工作,我们就获得了一次解释的机会——可以生成一份解释性的产物。...

July 13, 2026 · 2 min · fisherdaddy

AI 让写代码变快了,但好软件为什么没有自动变多?

文本原文来自 OpenCode 联合创始人 Dax Rod 关于 AI 编程工具与工程效率的访谈内容,文章由 有道龙虾 整理和发布。 有个问题挺反直觉: 写代码这件事明明变容易了,为什么工程团队还是这么累? OpenCode 联合创始人 Dax Rod 对这个问题有切身体会。他做的正是 AI 编程工具,而且 OpenCode 增长非常夸张:2025 年 6 月左右推出,不到一年,月活从 65 万涨到接近 800 万,下一站是 1000 万。 按理说,他们应该是最会“用 AI 提效”的那群人。 但 Dax 的感受是:工具确实让很多事变简单了,可真正困难的问题并没有消失。他仍然要花很多时间思考,团队也没有因为 AI 就甩开所有竞争对手。 他有一句话很值得放在开头: “客观上,很多事变容易了。但为什么我还是像以前一样费脑子?” 写代码不是唯一瓶颈 很多 CEO、CTO 和创始人会很自然地想: 过去工程师大量时间都花在写代码上,现在 AI 能把代码写快很多,那软件交付不就应该整体变快吗? Dax 觉得没那么简单。 公司所处阶段不同,AI 带来的效果也完全不同。 在还没有找到产品市场匹配的时候,最难的不是“把功能做出来”,而是弄清楚到底该做什么。这个阶段,AI 也许能让你多试几次,但它不能替你判断方向。 Dax 甚至更相信一件事: 与其疯狂尝试,不如先好好想清楚。 OpenCode 现在处在已经找到产品市场匹配、正在扩大潜力的阶段。这个阶段的问题反而变成了:能做的事情太多了。 用户要功能,竞争对手出了新东西,团队内部也有各种想法。过去实现一个功能有成本,成本本身会迫使团队慎重。现在你只要把需求丢给 agent,它就能帮你做出来。 听起来很爽,但危险也在这里。 一个用户有问题,prompt agent。 竞争对手有功能,prompt agent。 内部想到一个点子,prompt agent。 最后你可能做出一千个功能,却得到一个像“弗兰肯斯坦”一样的产品。每个局部都能解释,整体却很糟糕。 更麻烦的是,软件功能一旦发布,就很难真正撤回。你不仅要维护它,以后每个新功能还要考虑它和旧功能之间的相互作用。 能多发 10 倍功能,不代表你有 10 倍值得发布的好想法。...

May 28, 2026 · 3 min · fisherdaddy