AI编程,不只是更快

我们以为 AI 只是写代码的“加速器”，但事实是，它正在成为接管整台计算机的“主进程”。从亲自堆砌代码的 Software 1.0，到训练模型的 2.0，如今我们已一脚踏入只需操控提示词（Prompting）与上下文的 Software 3.0 时代。在这场颠覆性的范式转变中，那些过去需要开发一整套底层架构的App，甚至连写给人类看的“使用文档”都可能沦为多余。当“思考”与“执行”正以日为单位被廉价外包，人类手中还剩下什么无法被替代？让我们跟随卡帕斯深邃的行业洞见，重新理解这场关于“智能体原生”的计算革命。

【读书笔记】

1.AI 编程的真正拐点不是“代码补全更好”，而是开发者开始把模型当成可持续协作的执行者，去年 12 月后，最新模型生成的代码片段“基本就是对的”，即使不断要求系统做更多，也基本能完成

2.Software 3.0 的核心变化，是“写代码”让位于“组织上下文和提示词”，Software 1.0 是手写代码，Software 2.0 是通过数据集训练神经网络，而 Software 3.0 中，编程变成 prompting，context window（上下文窗口）成为操控 LLM 解释器的杠杆

3.很多旧范式下的应用会被神经网络直接吞掉，产品机会应从“加速旧流程”转向“创造新信息处理形态”，MenuGen 原本通过 OCR、菜单重渲染、图像生成等步骤生成菜品图片，但 Software 3.0 版本只需把菜单照片交给 Gemini，并要求 Nano Banana 把图片叠加到菜单上即可

4.AI 自动化的速度取决于“可验证性”和实验室训练重点，而非单纯由任务难度决定，Karpathy 认为 LLM 通过 reinforcement learning environments（强化学习环境）和 verification rewards（验证奖励）提升，数学、编码等可验证领域更容易突进

5.人类工程师的价值会从实现细节迁移到规格、品味、判断和系统监督，他把 agents 类比为 intern（实习生），能处理大量底层工作，但会犯奇怪错误，因此人类必须负责 spec、plan、工程判断和顶层设计，而 API 参数细节可以交给 agent

本文编译自发布于2026年4月30日OpenAI 联合创始人Andrej Karpathy与 Sequoia 合作伙伴 Stephanie Zhan 的访谈，原链接：

https://podcasts.apple.com/us/podcast/andrej-karpathy-from-vibe-coding-to-agentic-engineering/id1750736528?i=1000764662696

以下是原文的全文翻译，enjoy!

注：正文中标蓝部分为读书笔记的对应原文。

Andrej Karpathy：OpenAI 联合创始人、特斯拉前 AI 负责人、现 Eureka Labs 创始人

Stephanie Zhan：Sequoia 合作伙伴

【正文】

Stephanie Zhan：就在几个月前，你说自己作为程序员从未像现在这样感到落后。尤其是从你口中听到这句话，非常令人惊讶。你能帮我们拆解一下这种感受吗？它更多是令人兴奋，还是令人不安？

Andrej Karpathy：是的，肯定两者都有。首先，我想和在座很多人一样，我过去一段时间一直在使用 AI coding tools，比如 Claude Code 以及类似工具，可能从它们推出后的这一年左右就在用。它们在生成代码片段方面做得很好，但有时也会出错，你需要手动修改，所以总体来说算是有帮助。然后我会说，去年 12 月对我来说是一个非常明确的拐点。当时我在休假，所以有更多时间。我想很多人也有类似经历。我开始注意到，随着最新模型的出现，生成出来的代码片段基本就是对的。然后我不断要求它做更多，它也基本都能做对。到后来我已经记不起上一次纠正它是什么时候了，于是我对这个系统越来越信任，然后我就进入了 vibe coding 的状态。我确实认为，那是一次非常剧烈的转变。

我觉得很多人实际上没有意识到这一点。我曾试图在 Twitter 或 X 上强调这一点，因为很多人在去年体验 AI 时，把它当成 ChatGPT 这样的东西。但你真的需要重新看一遍，而且需要从去年 12 月之后重新看，因为事情已经发生了根本变化。尤其是在 agentic coding workflow 上，它真的开始运转起来了。所以我会说，正是这种意识让我一路钻进了无穷无尽的 side project 兔子洞。我的 side projects 文件夹现在装满了各种随机项目，我几乎一直在 vibe coding。所以，是的，我会说这件事大概就是在 12 月发生的。此后我一直在观察这种变化带来的影响。

Stephanie Zhan：你谈过很多关于 LLM 是一种新计算机的想法，也就是说，它不只是更好的软件，而是一种全新的计算范式。Software 1.0 是显式规则，Software 2.0 是学习得到的权重，Software 3.0 就是现在这个东西。如果这真的成立，那么当一个团队真正相信这一点的那一天，他们会以什么不同的方式构建产品？

Andrej Karpathy：对，没错。Software 1.0 是我在写代码；Software 2.0 是我通过创建数据集并训练神经网络来编程。所以这里的编程有点像是在组织数据集，也许再加上一些目标函数和神经网络架构。接着发生的事情是，如果你在足够大规模的任务集合上训练一个 GPT 模型或 LLM，那么基本上，它会隐式地进行多任务学习，因为在互联网上训练时，你必须处理数据集中包含的各种任务。于是，这些模型在某种意义上就变成了一种可编程计算机。

所以，Software 3.0 的核心是，你现在的编程变成了 prompting。而 context window 里的内容，就是你操控这个解释器的杠杆。这个解释器就是 LLM，它会解释你的上下文，并在数字信息空间中执行计算。所以我想，是的，这就是这种转变。我觉得有几个例子真的让我深刻意识到了这一点。

也许这些例子会很有启发。比如，当 OpenClaw 出现时，如果你想安装 OpenClaw，按照传统预期，这通常会是一个 bash script，也就是一个 shell script。你运行一个 shell script 来安装 OpenClaw。但问题在于，为了适配大量不同平台和大量不同类型的电脑，这类 shell scripts 通常会膨胀得极其复杂。但本质上，你仍然困在 Software 1.0 的世界里，仍然试图把代码写清楚。

而实际上，OpenClaw 的安装方式是一段文本的复制粘贴，你应该把这段文本交给你的 agent。也就是说，它有点像一个小技能：复制这段内容，粘贴给你的 agent，它就会安装 OpenClaw。

这种方式强大得多，因为你现在是在 Software 3.0 范式下工作。你不需要精确写出安装过程中的每一个具体细节。agent 本身有自己的智能，它会把这些事情组织起来，按照指令行动，查看你的环境、你的电脑，然后执行智能操作，让事情运转起来，并在循环中调试问题。这强大得多。我觉得这是一种非常不同的思考方式：你要思考的是，应该复制粘贴给你的 agent 的那段文本是什么？这就是新的编程范式。

另一个想到的例子可能更极端，就是我在做 MenuGen 的时候。

MenuGen 的想法是这样的：你走进一家餐厅，餐厅给你一份菜单，通常上面没有图片，所以我不知道这些菜到底是什么样子。通常菜单上大概 30% 的东西我完全不知道是什么，有时甚至是 50%。所以我想拍一张餐厅菜单的照片，然后得到这些菜大概长什么样的通用图片。于是我 vibe coded 了这个应用，它基本上允许你上传一张照片，然后完成所有这些事情。它跑在 Vercel 上，会重新渲染菜单，提取所有菜品，然后用图像生成器给每一道菜生成图片。它会 OCR 出不同菜名，再用图像生成器生成图片，最后展示给你。

然后我看到了这个东西的 Software 3.0 版本，它让我震惊：你只需要拍一张照片，把它交给 Gemini，然后说，用 Nano Banana 把图片叠加到菜单上。接着 Nano Banana 基本上就返回了一张图片，和我拍下来的菜单照片完全一致，但它真的把菜单里不同菜品的图像渲染进了像素里。这让我非常震惊，因为实际上我的整个 MenuGen 都是多余的。

它仍然是在旧范式里运作，这个 app 本来不应该存在。Software 3.0 的范式要原始得多：你的神经网络做越来越多的工作，而你的 prompt 或 context 只是输入图像，输出则是一张图像，中间不需要任何 app。所以我认为，人们必须重新构想，不要停留在已有事物的范式里，也不要只把它看成是对现有事物的加速。

实际上，现在已经有新的事情可以做了。回到你关于编程的问题，我觉得把它仅仅理解成编程变得更快，也还是旧思维的一个例子。

这其实是更广义的信息处理正在变得可以自动化。所以它甚至不只是关于代码。过去的代码处理的是结构化数据，你针对结构化数据写代码。但比如在我的 LLM knowledge bases 项目里，你基本上可以让 LLM 为你的组织、为你个人创建 wiki。这甚至不是一个传统意义上的程序。以前这种东西不存在，因为没有一段代码能基于一堆事实创建一个知识库。但现在你可以拿这些文档，以另一种方式重新编译它们，重新排序，创造出某种新的、有趣的东西，本质上是对数据的重新框定。所以这是我们现在可以做的新事情。我不断试图回到这一点：不只是问，我们能不能把过去已有的事情做得更快；更重要的是，现在出现了以前不可能存在的新机会。我几乎觉得这件事更令人兴奋。

Stephanie Zhan：我很喜欢你刚才关于 MenuGen 的“多余”与“范式转变”的对比。我相信这里很多人也关注过你自己从去年 10 月到今年 1 月、2 月在编程方式上的变化。如果我们进一步外推，2026 年的等价物会是什么？就像 90 年代做网站、2010 年代做移动应用、上一个云时代做 SaaS 那样，未来回头看会显得完全显而易见、但今天仍然大多尚未被构建出来的东西会是什么？

Andrej Karpathy：沿着 MenuGen 的例子来说吧。我想，很多这类代码本来都不应该存在，而是由神经网络完成大部分工作。我确实认为，外推下去的画面会非常奇怪。你几乎可以想象一种完全神经网络化的计算机。比如，一个设备接收原始视频或音频，把它输入到神经网络中，然后用 diffusion 渲染出一个 UI；这个 UI 在某种意义上是为那一刻独特生成的。

我有一种感觉，在计算机早期，人们其实有点困惑，不知道计算机会更像计算器，还是更像神经网络。在 50 年代和 60 年代，这条路到底会走向哪里并不明显。当然，我们后来走上了计算器这条路线，并最终构建了经典计算。而现在的神经网络，其实是运行在现有计算机上的虚拟化层。但你可以想象，我认为未来很多东西会翻转过来：神经网络会变成 host process，而 CPU 会变成某种 coprocessor。

我们已经看到，智能计算中神经网络的算力消耗会接管并成为 FLOPs 支出的主导。所以你可以想象一些非常奇怪、非常陌生的东西：神经网络承担大部分重活，而工具调用只是某种历史遗留的附属物，用于处理某些确定性任务。真正掌控局面的，是以某种方式彼此联网的神经网络。所以如果外推下去，你可以想象出极其陌生的东西。但我觉得我们大概会一步一步走到那里。至于这个进程具体会怎样展开，我会说还待确定。

Stephanie Zhan：我想谈一谈“可验证性”这个概念，也就是 AI 会更快、更容易地自动化那些输出可以被验证的领域。如果这个框架是正确的，那么哪些工作会比人们意识到的更快发生变化？又有哪些职业是人们以为安全，但实际上高度可验证的？

Andrej Karpathy：是的。我花了一些时间写可验证性。基本上，传统计算机可以轻松自动化那些你能用代码精确定义的东西；而这一轮最新的 LLM，在某种意义上可以轻松自动化那些你能验证的东西。因为它们的工作方式是这样的：Frontier labs 在训练这些 LLM 时，会构建巨大的 reinforcement learning environments，并给予它们 verification rewards。由于这些模型的训练方式，它们最终会不断进步，并形成这种参差不齐的实体，在数学、编码及相关这类可验证领域能力达到峰值；而在不属于这类空间的任务上，它们会停滞，边缘能力也会更粗糙。

所以我写可验证性的原因，是因为我想理解这些东西为什么如此参差不齐。其中一部分和实验室如何训练模型有关，但我认为另一部分也和这些实验室关注什么、它们碰巧把什么放进数据分布有关。因为有些事情在经济中价值显著更高，于是会产生更多环境，因为实验室希望模型能在那些设置中工作。我认为代码就是一个很好的例子。可能有很多可验证环境是可以想象的，但因为这些能力并没有那么有用，所以没有被纳入训练组合中。对我来说，最大的谜题之一，过去一段时间我最喜欢的例子，是 “strawberry” 里有几个字母 r？

模型曾经非常著名地会答错这个问题。这就是 jaggedness 的一个例子。我想现在模型已经修补了这个问题，但新的例子是：如果我要去 50 米外的洗车店洗车，我应该开车还是走路？今天最先进的模型会告诉你走路，因为距离很近。可是，最先进的 Opus 4.7 怎么可能一边能重构 100,000 行代码库，或者发现 zero-day 漏洞，一边又告诉我要走路去洗车店？这太荒谬了。只要这些模型仍然保持这种 jaggedness，就说明第一，也许某些地方有点不对；第二，你确实需要在环中，你需要把它们当成工具，并且你必须持续关注它们正在做什么。

所以，长话短说，我所有关于可验证性的写作，都是在试图理解为什么这些东西如此参差不齐。这里是否存在某种模式？我觉得答案大概是“可验证性”加上“实验室是否关心”这两个因素的某种组合。

也许还有一个很有启发性的轶事：从 GPT-3.5 到 GPT-4，人们注意到模型的国际象棋能力提升了很多。我认为很多人当时觉得，哦，这只是能力自然进步的结果。但实际上，我认为这是公开信息，我记得在网上看到过，有大量国际象棋数据进入了预训练集。正是因为数据分布中有这些内容，模型才比默认情况下提升得更多。也就是说，OpenAI 的某个人决定加入这些数据，于是你就拥有了一项显著突出的能力。

这也是为什么我一直强调这个维度：我们在某种程度上受制于实验室正在做什么，受制于它们碰巧把什么放进训练组合中。你必须实际探索它们给你的这个没有说明书的东西。它在某些场景下有效，但在另一些场景下可能无效。你必须稍微探索一下。如果你所处的 circuit 是 RL 的一部分，你就会飞起来；如果你所处的 circuit 超出了数据分布，你就会挣扎。你必须弄清楚你的应用处在哪些 circuits 里。如果你不在这些 circuits 里，那你就真的需要考虑 fine-tuning，并做一些自己的工作，因为它不一定会从 LLM 开箱即用地出现。

Stephanie Zhan：我很想稍后再回到 jagged intelligence 这个概念。如果你今天是一位创始人，正在考虑创办一家公司，你想解决一个你认为可处理的问题，也就是一个可验证领域的问题。但你环顾四周，觉得天哪，这些实验室已经在最明显的领域，比如数学、编码以及其他领域，真正进入了逃逸速度。你会给现场创始人什么建议？

Andrej Karpathy：我想这也许回到了前一个问题。可验证性之所以重要，是因为它让某件事情在当前范式下变得可处理，因为你可以往里面投入大量 RL。所以也许可以这样看：即使实验室没有直接关注它，这一点仍然成立。如果你处在一个可验证的环境中，你能够创建这些 RL environments 或 examples，那么这实际上会让你有机会做自己的 fine-tuning，并从中获益。这本质上是一种已经能工作的技术。如果你有大量多样化的数据集、RL environments 等，你可以使用自己喜欢的 fine-tuning framework，拉动这个杠杆，然后得到一个效果相当不错的东西。

我不确定具体例子应该是什么，但我确实认为，有一些非常有价值的 reinforcement learning environments 是人们可以去思考的，它们并不属于目前的——是的，我不想把答案直接说出来，但有一个领域我认为非常——抱歉，我不想在台上 vague post。确实有一些这样的例子。

Stephanie Zhan：反过来说，你觉得哪些东西只是从远处看起来可以自动化？

Andrej Karpathy：我确实认为，最终几乎所有东西在某种程度上都可以被变成可验证的，只是有些比其他更容易。即便是写作这类事情，你也可以想象让一组 LLM judges 组成一个委员会，然后通过这种方法得到一些合理结果。所以问题更多是难易程度。我确实认为，最终，一切都可以自动化。

Stephanie Zhan：太棒了。好，去年你提出了 vibe coding 这个词，而今天我们所处的世界感觉更严肃一些，更像是 agentic engineering。你觉得两者之间有什么区别？你会如何称呼我们今天所处的阶段？

Andrej Karpathy：是的。我会说，vibe coding 是在抬高所有人能用软件完成事情的下限。这个下限上升了，每个人都可以 vibe code 任何东西，这非常棒，令人难以置信。但 agentic engineering 是要在专业软件开发中保持过去已有的质量标准。你不能因为 vibe coding 就引入漏洞。你仍然要像以前一样对自己的软件负责，只是你能不能更快？剧透一下：你可以。但问题是，如何正确地做到这一点？所以对我来说，我把它称为 agentic engineering，因为我认为它确实像是一门工程学科。

你有这些 agents，它们是有尖峰能力的实体，有点容易犯错，也有点随机，但它们极其强大。你如何协调它们，在不牺牲质量标准的前提下更快地推进？把这件事做好、做正确，就是 agentic engineering 的领域。所以我把它们看作不同的东西：一个是抬高下限，另一个是向上外推。

我现在看到的是，agentic engineer 的天花板非常高。过去人们谈论 10x engineer。我认为这件事会被大幅放大，10x 并不是你能获得的速度提升。从我现在的角度看，擅长这件事的人似乎能达到远远超过 10x 的峰值。

Stephanie Zhan：我很喜欢这个框架。Sam Altman 去年来 AI Ascent 的时候，说过一句很让人印象深刻的话：不同代际的人使用 ChatGPT 的方式不同。如果你 30 多岁，你会把它当成 Google search 的替代品；但如果你十几岁，ChatGPT 就是你通向互联网的入口。那么在今天的编程领域，对应的情况是什么？如果我们观察两个人使用 OpenAI、Claude Code、Codex 来写代码，一个你认为水平平庸，另一个你认为完全 AI native，你会如何描述他们之间的差别？

Andrej Karpathy：我想，就是尽可能发挥现有工具的能力，充分利用它们的所有功能，并投资于自己的 setup。就像过去所有工程师都习惯于尽可能用好自己的工具，无论是 Vim、VS Code，还是现在的 Claude Code、Codex 等等。所以就是投资自己的 setup，并充分利用可以使用的大量工具。我觉得它大概就是这个样子。

我还有一个相关想法。很多人现在可能会为此招聘，因为他们想招到强大的 agentic engineers。但我看到的是，大多数人仍然没有为了评估 agentic engineer 的能力而重构自己的招聘流程。

比如，如果你还在发一些 puzzle 让候选人解决，那仍然是旧范式。我会说，招聘应该变成这样：给我一个非常大的项目，看一个人如何实现这个大项目。比如，让我们写一个面向 agents 的 Twitter clone，然后把它做得很好、很安全，再让一些 agents 模拟这个 Twitter 上的活动。接着我会用 10 个 Codex high 来尝试攻破你部署的网站。它们会试图把它打坏，而它们不应该能打坏它。所以也许应该是这样的，对吧？因此，在这种设置中观察人们如何构建更大的项目、如何使用工具，可能是我主要会看的内容。

Stephanie Zhan：随着 agents 做得越来越多，你觉得哪种人类技能会变得更有价值，而不是更不重要？

Andrej Karpathy：这是个好问题。现在的答案是，这些 agents 有点像 intern，对吧？很了不起，但你基本上仍然必须负责美学、判断、品味，以及一定程度的监督。也许我最喜欢的一个关于 agents 古怪之处的例子，还是来自 MenuGen。

你用 Google account 注册，但用 Stripe account 购买 credits，而两者都有 email address。我的 agent 实际上试图在你购买 credits 时，把 Stripe 的 email address 和 Google 的 email address 对应起来。也就是说，它没有使用一个持久的 user ID；对人类来说，它是在试图匹配 email addresses。但你可以在 Stripe 和 Google 使用不同的 email address，于是资金就不会被关联起来。这就是这类 agents 仍然会犯的错误：为什么要用 email address 去交叉关联资金？它们可以是任意的，你可以使用不同的邮箱等等。这是一件非常奇怪的事情。所以我认为人们必须负责 spec，负责 plan。

其实我甚至不太喜欢 plan mode。当然它非常有用，但我觉得这里有一个更一般的东西：你必须和你的 agent 一起设计一个非常详细的 spec，也许基本上就是 docs，然后让 agents 去写它们。你负责监督和顶层类别，而 agents 在底层完成很多工作。所以我认为，你不再关心某些细节。比如在神经网络里的 arrays 或 tensors 上，PyTorch、NumPy、pandas 等不同 API 之间有大量细节。我已经忘了 KeepDims 和 keep_dim 的区别，也忘了是 dim 还是 axes，是 reshape 还是 permute 还是 transpose。我已经不记得这些东西了，对吧？因为你不需要记。这类细节由 intern 处理，因为它们有很好的 recall。但你仍然必须知道，比如底层有一个 tensor，底层有一个 view，你可以操作同一块 storage 的 view，也可以拥有不同的 storage，而后者效率更低。

我们仍然必须理解这些东西在做什么，理解一些基础原理，这样你才不会不必要地复制内存等等。但 API 的细节现在已经交出去了。所以你负责品味、工程、设计，负责判断事情是否合理，负责提出正确的要求，比如你要说，好的，这些必须是 unique user IDs，我们要把一切都绑定到它们上面。所以你做的是一部分设计和开发，而这些 engineers 则负责填空。这就是我们目前大概所处的位置。我想现在每个人当然也都看到了这一点。

Stephanie Zhan：你觉得有没有可能，随着时间推移，这种品味和判断会变得没那么重要？还是说天花板会继续升高？

Andrej Karpathy：这是个好问题。我会说，我希望它会改善。我认为它现在之所以没有改善，可能还是因为这部分不在 RL 里。可能没有 aesthetics cost 或 reward，或者做得还不够好之类的。我确实认为，当你真正看代码时，有时我会有点心脏骤停，因为它不一定总是超级出色的代码，而且非常臃肿。有很多复制粘贴，有一些尴尬而脆弱的抽象。它能工作，但真的很粗糙。我确实希望未来的模型能在这方面改善。

还有一个很好的例子是 microGPT 项目，我当时试图把 LLM training 简化到尽可能简单。模型讨厌这件事。它们做不到。我不断 prompt 一个 LLM，让它继续简化、继续简化，但它就是做不到。你会感觉自己处在 RL circuits 之外。感觉像是在拔牙，完全不是光速前进。所以我确实认为，人类在这方面仍然掌握主导权。但我也认为，没有什么根本性原因阻止它改善。几乎只是 labs 还没有把这件事做好。

Stephanie Zhan：我很想回到 jagged forms of intelligence 这个想法。你曾在一篇非常发人深省的文章里写过 animals versus ghosts。核心观点是，我们不是在构建 animals，而是在召唤 ghosts。这些是参差不齐的智能形式，由数据和 reward functions 塑造，而不是由内在动机、乐趣、好奇心或 empowerment 这类通过进化产生的东西塑造。为什么这个框架很重要？它实际上会如何改变你构建、部署、评估甚至信任它们的方式？

Andrej Karpathy：是的。我写这篇东西的原因，是因为我试图理解这些东西到底是什么，对吧？如果你对它们是什么、不是什么有一个好的模型，你使用它们时就会更有能力。我确实认为，不知道这是否有真正的实用力量。我不确定它是否真的有 real power，它有点哲学化。但我认为，它让你接受这样一个事实：这些东西不是 animal intelligence。比如你对它们大喊大叫，它们不会因此工作得更好或更差，也不会受到什么影响。

它们都是某种统计模拟 circuits，底层是 pre-training，也就是统计，然后在上面再接上 RL，于是它提高了某些能力。也许这只是一种心智模型，用来判断我正在面对什么，什么可能有效、什么不太可能有效，以及如何修改它。但我实际上并没有一个明确清单，比如“这里有五个显而易见的方法能让你的系统变得更好”。更多是对它保持怀疑，并随着时间推移去摸索。

Stephanie Zhan：这就是起点。好，你现在非常深入地和 agents 一起工作，而这些 agents 不只是聊天，它们有真实权限，有本地上下文，并且真的会代表你采取行动。当我们都开始生活在这样的世界里时，世界会是什么样子？

Andrej Karpathy：是的，我想这里很多人可能都对这种原生 agentic environment 会是什么样子感到兴奋。

一切都必须被重写。现在一切本质上仍然是为人类写的，而它们必须被迁移。我大多数时候使用不同 frameworks、libraries 或类似东西时，它们的 docs 本质上仍然是写给人类的。这是我最讨厌的小问题。不要再告诉我该做什么了。我不想做任何事情。我想知道的是，我应该复制粘贴给我的 agent 的东西是什么？所以每次有人告诉我“去这个 URL”之类的，我就会觉得，哦，你看，大家都还在为人类写东西。我认为大家都对如何把需要发生的 workloads 分解成面向世界的 sensors 和 actuators 感到兴奋。

我们如何让它变得 agent native？也就是说，首先向 agents 描述它，然后围绕那些对 LLM 非常清晰、可读的数据结构做大量自动化。所以，是的，我希望未来会有很多 agent-first infrastructure。关于 MenuGen，当我写那篇关于 MenuGen 的 blog post 时，很多工作、很多麻烦甚至不在于写 MenuGen 的代码，而在于把它部署到 Vercel 上。因为我必须和各种不同服务打交道，把它们串起来，还要去它们的 settings 和 menus 里配置 DNS，真的非常烦人。所以这是一个很好的例子：我希望我能给一个 LLM 一个 prompt，说 build MenuGen，然后我不需要碰任何东西，它就以同样方式部署到互联网上。我认为这会是一个很好的测试，看看我们的基础设施是否正在变得越来越 agent native。

最终，我会说，是的，我确实认为我们正在走向这样一个世界：每个人、每个组织都会有一个 representation。我的 agent 会和你的 agent 交谈，以确定我们会议的一些细节或类似事情。我确实认为这大致就是事情的走向。不过，是的，我想这里每个人都对此感到兴奋。

Stephanie Zhan：我非常喜欢 sensors 和 actuators 这个视觉类比。我之前其实没有这样想过，非常有意思。好，我觉得我们必须用一个关于教育的问题来结束，因为你可能是世界上最擅长把复杂技术概念讲简单的人之一，而且你也非常认真地思考我们该如何围绕它设计教育。当智能变得廉价、我们进入 AI 的下一个时代时，还有什么仍然值得深入学习？

Andrej Karpathy：最近有一条推特让我非常震撼，我几乎隔一天就会想到它。大概意思是：你可以外包你的思考，但你不能外包你的理解。

Stephanie Zhan：这句话说得真好。

Andrej Karpathy：是的。因为我仍然是这个系统的一部分，信息最终仍然必须以某种方式进入我的大脑。我感觉自己正在变成一个瓶颈，甚至只是要知道我们到底想构建什么、为什么它值得做、我该如何指挥我的 agents 等等。所以我仍然认为，最终必须有什么东西来指挥思考和处理，而这在某种根本层面上仍然受理解能力的约束。

这也是我对所有 LLM knowledge bases 非常兴奋的原因之一，因为我觉得这是我处理信息的一种方式。每当我看到信息被投射成一种不同的形式，我总觉得自己获得了洞见。所以对我来说，这真的就是大量 prompts，用来在某个固定数据集上做 synthetic data generation。我很享受每次读一篇文章时，我的 wiki 会从这些文章中逐步构建起来，我也喜欢围绕这些内容提问。我认为这些工具最终是在某种意义上增强理解的工具。而理解仍然是一个瓶颈，因为如果你不理解，你就无法指挥它们，无法成为一个好的 director。LLM 当然并不擅长理解，你仍然独特地负责这一点。所以我认为，服务于这一目标的工具非常有趣，也非常令人兴奋。

Stephanie Zhan：我很期待几年后再回到这里，看看我们是否已经完全被自动化出局，而它们是否连理解也一并接管了。