Andrej Karpathy：从氛围编程到智能体工程

在本次 2026 年 AI Ascent 大会的访谈中，红杉资本合伙人 Stephanie Zhan 与 OpenAI 联合创始人、前特斯拉 AI 负责人兼 Eureka Labs 创始人 Andrej Karpathy 展开了一场深度对话。

Andrej 探讨了自他去年提出“氛围编程（Vibe coding）”这一概念以来，软件开发领域发生的翻天覆地的变化。他坦言自己作为程序员“从未感到如此落后”，并详细阐述了基于大语言模型（LLM）的“软件 3.0（Software 3.0）”范式。随着 AI 能力的提升，编程正从“氛围编程”向更严谨的“智能体工程（Agentic engineering）”演进。他还深入分析了 AI 的“锯齿状智能（Jagged intelligence）”，提出我们应该将 LLM 视为基于统计学和强化学习召唤出的“幽灵”，而非具备内在动机的“动物”。在智能体无处不在的未来，尽管人类可以外包“思考”，但永远无法外包“理解”，人类的品味、判断力和监督能力将变得前所未有的重要。

---

专用词语翻译列表

英文原词	中文翻译	备注说明
Vibe coding	氛围编程	Andrej 提出的概念，指高度依赖 AI 直觉生成代码的轻松编程方式
Agentic engineering	智能体工程	在氛围编程之上发展出的更严谨、注重质量的 AI 协作工程学科
Software 1.0 / 2.0 / 3.0	软件 1.0 / 2.0 / 3.0	1.0: 人工写代码; 2.0: 训练神经网络; 3.0: 提示词与上下文窗口驱动
Verifiability	可验证性	指 AI 生成的输出能否被轻易验证对错的特性
Jagged skills / Jagged intelligence	锯齿状智能 / 参差不齐的能力	指大模型在某些（如数学、编程）领域极强，在常识领域却可能犯傻的现象
Ghosts vs. Animals	幽灵与动物	Andrej 的比喻：AI 是统计学和算法召唤出的“幽灵”，而非由进化产生的“动物”
Context window	上下文窗口	大模型处理提示词的信息容量
Reinforcement Learning (RL)	强化学习	训练前沿大模型的核心技术之一
Sensors and actuators	传感器与执行器	借用物理控制系统概念，形容未来智能体感知世界和采取行动的方式

---

访谈全文

Stephanie Zhan: 我们非常激动地迎来第一位特别嘉宾。他曾协助构建了现代 AI，随后致力于向大众解释现代 AI，并偶尔还会为现代 AI 重新命名。他正是在这间办公室里协助创立了 OpenAI。当年也是他成功让特斯拉的 Autopilot 系统运转起来。他拥有一种罕见的天赋，能让最复杂的技术变革显得既通俗易懂又势不可挡。

大家都知道他去年创造了“氛围编程（Vibe coding）”这个词。但就在几个月前，他说了一句更令人震惊的话：他作为程序员从未感到如此落后。今天我们就从这里开始聊。谢谢你，Andrej，感谢你的到来。

Andrej Karpathy: 大家好。很高兴来到这里，为大家开场。

Stephanie Zhan: 好的。就在几个月前，你说作为一名程序员，你从未感到如此落后。从你这样的人口中听到这句话挺让人震惊的。你能帮我们剖析一下这种感觉吗？那是一种令人兴奋的感觉，还是令人不安的？

Andrej Karpathy: 肯定是两者的混合体。首先，和大家一样，我也使用智能体工具（比如 Claude Code 及类似工具）有一阵子了。大概在过去一年里，它们在处理代码块时表现得非常好，偶尔会出错，你需要去修改，这已经很有帮助了。到了 12 月份，对我来说出现了一个非常清晰的转折点。当时我在休假，有更多的时间。我想很多人也有类似的感受。

我开始注意到，使用最新的模型时，生成的代码块直接就能用。我继续提出更多要求，结果依然很好。我已经记不清上次修改它的代码是什么时候了。我对系统的信任度越来越高，然后我就完全进入了“氛围编程”的状态（笑）。这确实是一个非常鲜明的转变。我在 X（前 Twitter）上反复强调这一点，因为我觉得很多人去年体验的 AI 还停留在类似 ChatGPT 的阶段。

但你真的需要重新审视它，特别是从 12 月份开始，因为事情发生了根本性的变化，尤其是在这种连贯的、由智能体驱动的工作流上，它真的开始奏效了。所以，正是这种意识让我彻底掉进了搞无数“业余项目”的兔子洞。我的业余项目文件夹里塞满了各种随机的东西，我无时无刻不在进行氛围编程。这个转折点大概发生在 12 月，从那以后我一直在观察它带来的影响。

Stephanie Zhan: 你多次提到这样一个观点：大语言模型（LLM）是一台新计算机。它不仅仅是更好的软件，而是全新的计算范式。软件 1.0 是明确的规则，软件 2.0 是学习到的权重，而软件 3.0 则是这个新范式。如果这真的是事实，那么当一个团队真正相信这一点的第一天，他们的开发方式会有什么不同？

Andrej Karpathy: 完全正确。在软件 1.0 时代，我负责写代码；软件 2.0 时代，我通过创建数据集和训练神经网络来编程，所以编程其实变成了整理数据集、设定目标和设计神经网络架构。

接下来发生的事情是，如果你在一个包含海量任务的数据集上训练这些 GPT 模型或 LLM，由于它们是在整个互联网的数据上进行多任务训练的，它们实际上在某种意义上变成了一台可编程的计算机。因此，软件 3.0 的核心在于你的编程变成了“提示词工程（Prompting）”，而放在上下文窗口（Context window）里的内容，就是你用来控制 LLM 这个“解释器”的杠杆，让它在数字信息空间中执行计算。

这就是这种转变。我觉得有几个例子让我深刻体会到了这一点，也许这很有启发性。比如当 OpenClaw 发布时，如果你想安装它，正常情况下你会认为这是一个 bash shell 脚本。运行脚本就能安装 OpenClaw。但是，为了适配各种不同的平台和计算机，这些 shell 脚本通常会变得极其庞大和复杂。问题在于，你仍然被困在“想要亲自写代码”的软件 1.0 思维中。

实际上，安装 OpenClaw 的方式应该是复制粘贴一段文本给你的智能体——就是一个简单的“复制粘贴指令交给智能体”的技能，它就会帮你安装好。这种方式之所以强大得多，是因为你现在处于软件 3.0 的范式中，不需要精确拼凑出每一个安装细节。智能体拥有被打包好的智能，它遵循指令，观察你的环境和计算机，采取智能行动让程序跑起来，并在循环中自行调试。这强大太多了对吧？所以你需要转变思维方式：现在编程的范式就是“把这段文本复制粘贴给智能体”。

还有一个更极端的例子，是我在做 Menu Gen（菜单生成器）的时候。

Menu Gen 的初衷是：你去餐厅，他们给你一份菜单，通常没有图片。我不认识那些菜，可能 30% 到 50% 的菜我都不知道是什么。所以我想给餐厅菜单拍张照，然后生成这些菜品大概长什么样的图片。

于是我“氛围编程”出了这个应用：它让你上传照片，在 Vercel 上运行各种后端处理，它能重新渲染菜单，通过 OCR（光学字符识别）提取所有菜名，调用图像生成器生成菜品图片，最后展示给你。

然后，我看到了这个应用的软件 3.0 版本，简直惊呆了。做法是：直接把菜单照片发给 Gemini，然后说：“用 Nanobanana 把菜品图片覆盖在菜单上。” Nanobanana 返回的图像正是那张我拍的菜单原图，但它直接在像素层面上，把菜单里各个菜品的图片渲染了进去。这让我大为震撼，因为我之前写的那个 Menu Gen 应用其实是多余的。它依然在旧的范式里运行，那个中间层 App 根本不应该存在。

软件 3.0 的范式要直接得多。神经网络承担了越来越多的工作，你的提示或上下文只是一张图片，输出也是一张图片，根本不需要中间那个 App 存在。所以人们必须重新构建认知，不要局限在现有的范式中，认为这仅仅是“让现有的东西变快”，它实际上意味着全新的事物已经成为可能。

回到你关于编程的问题，如果只想着“编程变得更快”，那依然是旧思维。这其实是更广泛的“信息处理”的自动化，不仅仅关乎代码。以前的代码处理的是结构化数据；比如我做的 LLM 知识库项目，本质上是让大模型为你或你的组织创建 Wiki 维基百科。这甚至称不上是一个传统的“程序”。在以前这是不可能的，因为没有代码能根据一堆事实凭空生成知识库。但现在，你可以提取这些文档，换一种方式重新编译、排序，并将数据重塑为全新且有趣的东西。这都是以前做不到的新事物。

我一直试图回到这个核心点：我们不仅能把已有的事情做得更快，还有了许多以前根本不可能实现的新机会，我认为这才是更令人兴奋的。

Stephanie Zhan: 我很喜欢你描述的 Menu Gen 的演进过程和它所呈现的对比。我相信在座的很多人也关注了你从去年 10 月到今年 1、2 月间在编程方式上的个人演变。如果我们进一步推演，就像 90 年代建网站、2010 年代做移动 App、上一个云时代做 SaaS 一样，到了 2026 年，什么东西在事后看来会是理所应当的，但今天却几乎还没有人去构建？

Andrej Karpathy: 以 Menu Gen 为例，大量的中间代码本就不该存在，神经网络其实做了大部分工作。我认为这种推演看起来会非常怪异，因为你可以想象出一种纯粹的“神经网络计算机”。比如一个设备直接将原始视频或音频输入神经网络，然后利用扩散模型（Diffusion）为你此时此刻的场景即时渲染出一个专属的 UI 界面。

在计算的早期（50 年代和 60 年代），人们其实有些困惑：未来的计算机到底会像计算器，还是会像神经网络？结果很明显，我们走上了计算器的道路，构建了经典计算，而如今神经网络是以虚拟化的方式运行在现有的计算机上。但你可以想象，未来这可能会反转：神经网络成为底层的主进程，而 CPU 则变成了协处理器。

我们都看过那个图表，神经网络的智能计算力将接管并成为算力消耗的主导。你可以想象出一种极度陌生的情况：神经网络包揽了绝大部分重活，它们把使用工具（Tool use）当作某种历史遗留的附加功能，用来处理一些确定性的任务。但真正在掌控全局的是这些神经网络。

你可以将推演的结果想象得极其颠覆。我认为我们会一步步走向那个未来，尽管具体的演进路径仍有待观察。

Stephanie Zhan: 我想谈谈“可验证性（Verifiability）”这个概念。也就是说，在那些输出结果可以被验证的领域，AI 会更快、更容易地实现自动化。如果这个框架是正确的，那么哪些工作会比人们意识到的自动化得快得多？又有哪些人们自以为安全、但实际上高度可验证的职业会受到冲击？

Andrej Karpathy: 是的。我花了一些时间写关于可验证性的文章。传统的计算机很容易自动化那些你可以通过代码明确指定（Specify）的任务，而最新一轮的大语言模型很容易自动化你可以“验证（Verify）”的任务。因为当前沿实验室训练这些模型时，它们是在巨大的强化学习（RL）环境中进行的。

模型被赋予验证奖励，由于它们的训练方式，它们最终会进化成一种能力“参差不齐”的实体：它们在像数学和编程这类“可验证”的领域能力极高，但在那些无法明确验证的空间里却停滞不前，显得有些笨拙。我写可验证性，是为了试图理解为什么这些模型的能力会呈现出这种“锯齿状（Jagged）”。

这部分与实验室如何训练模型有关，但也与实验室的关注点以及他们偶然放入数据分布中的内容有关。有些能力在经济中价值极高，实验室为了让模型在这些设定中表现出色，就会建立更多的训练环境。编程就是一个很好的例子。可能还有很多其他可验证的环境，但因为实验室觉得不那么有用，就没有把它们纳入训练池。

对我来说，最大的谜团就是那个经典的例子：“Strawberry（草莓）”里有几个“r”？模型过去常在这里翻车，这就是锯齿状能力的一个体现。现在模型好像修复了这个问题，但新问题又来了：我想去 50 米外的洗车店洗车，我应该开车还是走路？目前最先进的模型会告诉你走路去，因为它觉得距离很近。

最先进的 Opus 4.7（注：指代假想或未来的前沿模型），可以同时重构 10 万行代码的庞大代码库，或者找到零日漏洞，却让我走路去洗车店洗车？这太疯狂了！

只要这些模型的能力仍然是锯齿状的，就表明：第一，模型可能在某些方面有点问题；第二，你必须在回路中（In the loop）充当监督者，你需要把它们当作工具，并与它们的工作保持接触。简而言之，我写关于可验证性文章的初衷，就是想搞清楚它们为什么如此参差不齐，这其中是否有规律可循。我觉得答案是“可验证性”加上“实验室是否关注”的结合体。

还有一个很有启发性的轶事。从 GPT-3.5 到 GPT-4，人们发现模型下国际象棋的水平大幅提升了。很多人以为这是模型整体能力的自然进化。但据公开信息，实际上是因为大量的国际象棋数据进入了预训练集，仅仅因为这些数据处于数据分布中，模型在这方面的能力就有了超乎预期的提升。OpenAI 的某个人决定加入这些数据，于是你就得到了一个能力达到顶峰的特定技能。

所以我一直在强调这个维度：我们在某种程度上受制于实验室的决策，受制于他们碰巧放进混合数据里的东西。你必须亲自去探索这个没有使用说明书的工具。它在某些设定下很好用，在另一些设定下可能不行。如果你碰巧踩在强化学习（RL）重点训练的思路上，你就能起飞；如果你的应用超出了他们的数据分布，你就会陷入挣扎。你必须弄清楚你的应用处于哪条回路上。如果不在其中，你就得认真考虑进行微调或自己做额外的工作，因为开箱即用的大模型可能无法满足你的需求。

Stephanie Zhan: 稍后我们再回到“锯齿状智能”的概念。如果你今天是位创始人，正考虑创立一家公司，你试图解决一个看似棘手但实际处于可验证领域的问题。当你环顾四周，发现大厂已经在最明显的领域（如数学、编程等）达到了逃逸速度。你会对在座的创始人提出什么建议？

Andrej Karpathy: 这可能又回到了刚才的问题。我认为，正是因为可验证性，你才可以在当前的范式下通过投入大量强化学习资源去解决问题。即使实验室没有直接关注你的领域，只要你处于一个可验证的场景中，你可以自己创建强化学习环境或案例，进行你自己的微调，并且从中获益。

这就是一项已经完全可用的底层技术。如果你拥有大量多样化的 RL 环境和数据集，你可以利用你喜欢的微调框架，拉动控制杆，就能得到表现非常不错的结果。我不知道具体的例子是什么，但我相信人们能想到一些非常有价值的强化学习环境，而这些环境目前并不在大厂的视野里。确实有这样的领域存在（笑，我不该在台上随意画大饼，但确实有这样的机会）。

Stephanie Zhan: 反过来说，你认为什么东西仍然只能在边缘徘徊，难以被自动化？

Andrej Karpathy: 我认为最终几乎所有的东西都可以在某种程度上被变得“可验证”，只是有些比另一些容易。哪怕是像写作这样的事情，你也可以想象建立一个由多个大模型组成的“评审委员会”，通过这种方法同样能得到合理的结果。这更多是个难易程度的问题。所以我认为，最终……一切都是可以被自动化的（笑）。

Stephanie Zhan: 太棒了。去年你创造了“氛围编程”这个词，而今天我们处于一个感觉更严肃的世界——智能体工程。你认为这两者之间有什么区别？你会如何称呼我们今天所处的阶段？

Andrej Karpathy: “氛围编程”是关于提高每个人在软件开发上的能力下限。门槛被拉高了，任何人都可以凭直觉“氛围编程”出任何东西，这不可思议且令人赞叹。

但我认为“智能体工程”是为了保住过去专业软件行业存在的高质量上限。你不能因为使用了“氛围编程”就在代码里引入漏洞。你仍然要像以前一样对你的软件负责。但你能做得更快吗？剧透一下：可以。问题是如何正确且妥善地做到这一点。

这就是我之所以称之为“智能体工程”的原因。它是一门工程学科。你拥有这些智能体，它们是能力参差不齐的实体，偶尔会犯错，带有一定的随机性，但同时又极其强大。如何协调它们以加快速度，同时不牺牲质量底线，妥善且正确地完成工作？这就是智能体工程的领域。

我认为它们是不同的。一个是提高下限，另一个是向更高处推演。我看到的是，智能体工程能力的天花板非常高。人们以前常说“10 倍程序员”，我认为这种能力现在被放大了无数倍。你获得的速度提升绝对不止 10 倍。在我看来，精通这项技能的人，其巅峰产能远远超过 10 倍。

Stephanie Zhan: 我非常喜欢这个框架。去年 Sam Altman 来参加 AI Ascent 时说了一句让人印象深刻的话：不同代际的人使用 ChatGPT 的方式是不同的。30 多岁的人把它当作谷歌搜索的替代品，而对十几岁的青少年来说，ChatGPT 是他们接入互联网的网关。在今天的编程领域有没有类似的平行现象？如果我们观察两个人使用 OpenClaw、Claude Code 或 Codex 写代码，一个你认为很平庸，另一个你认为是纯粹的“AI 原生”，你会如何描述他们之间的差异？

Andrej Karpathy: 这主要体现在能否最大限度地榨取现有工具的潜力，充分利用它们的所有功能，并在你自己的开发环境上进行投资。就像以前的工程师习惯于从 Vim、VS Code 等工具中榨取最大价值一样，现在换成了 Claude Code 或 Codex。深入打磨你的工作流，利用手头各种可用的工具，这就是明显的特征。

相关的另一个想法是，很多人现在都在试图招聘强大的“智能体工程师”。但我看到的是，大多数人还没有根据智能体工程师的能力来重构他们的面试流程。如果你还在给面试者出算法谜题，那依然是旧范式。

我认为新的招聘流程应该是：给你一个非常大的项目，看你如何实现它。比如：“用智能体写一个推特克隆版网站，要求功能完善且高度安全。然后让一些智能体在这个推特上模拟活跃用户。接着，我将使用 10 个 Codex、5 个 Claude 4.x 去攻击你部署的这个网站，尝试攻破它。你的网站必须能够抵御这些攻击。”

面试应该变成这样。在这样的设定下观察候选人，看他们构建大型项目，看他们如何运用工具，这才是我最关注的。

Stephanie Zhan: 随着智能体承担的工作越来越多，你认为什么样的人类技能会变得更有价值，而不是缩水？

Andrej Karpathy: 这是个好问题。目前来看，答案是智能体仍然像“实习生”一样的存在。尽管它们很了不起，但你仍然必须掌握美学、判断力、品味和一定的监督权。

分享一个我最喜欢的智能体做傻事的例子。在开发 Menu Gen 时，用户用 Google 账号注册，但使用 Stripe 账号购买积分，这两者都有各自的邮箱地址。当你购买积分时，我的智能体居然试图把 Stripe 的邮箱地址跟 Google 的邮箱地址进行比对，用这个来关联资金。它没有建立一个持久的用户 ID，而是试图跨越平台匹配邮箱地址！问题是，用户完全可以在 Stripe 和 Google 上使用不同的邮箱，这样资金就关联不上了。

这就是智能体依然会犯的错误。为什么要把邮箱地址作为交叉关联资金的凭证？邮箱是任意的。这做法太诡异了。

所以，人类必须主导需求规格和整体计划的制定。甚至我其实不太喜欢纯粹的“计划模式”。我觉得存在一种更普遍的合作方式：你需要和智能体一起设计出一份非常详细的需求文档，然后让智能体去编写代码。你负责监督和顶层逻辑分类，智能体负责底层的具体实现。

这样你就不用再去关心某些细枝末节了。以神经网络中的数组或张量（Tensors）为例。在 PyTorch、NumPy、Pandas 等库之间，存在大量琐碎的 API 差异。我早就忘了到底是 keep_dims 还是 keep_dim，是 dim 还是 axis，是 reshape、permute 还是 transpose。我不需要去记这些了。这些细节实习生（智能体）会处理，因为它们的记忆力极好。

但你仍然必须知道，比如这里存在一个底层张量，你可以操作它的视图（View），操作视图共享存储效率更高，如果复制存储效率就低。你必须理解这些东西的作用和底层逻辑，这样才不会造成不必要的内存拷贝。API 的细节被接管了，但你仍负责品味、工程设计，确保架构合理，确保你提出了正确的要求（比如指出必须用唯一的用户 ID 来绑定所有数据）。你在做设计和研发，工程师（智能体）在填空，这就是我们目前的现状，也是大家都在经历的。

Stephanie Zhan: 你觉得随着时间的推移，这种品味和判断力会不会变得不再那么重要？还是说机器的天花板会不断被抬高？

Andrej Karpathy: 好问题。我希望机器的这部分能力能够改善。目前它没能改善的原因，可能依然是因为“美学或品味”不属于 RL 的奖励回路，大厂还没有把它做得足够好。当你真的去查看 AI 写的代码时，有时会觉得心脏病都要犯了，因为它写的并不是什么极其出色的代码。代码常常很臃肿，有很多复制粘贴，还有脆弱且尴尬的抽象。虽然能跑，但真的非常恶心。

我确实希望未来的模型能改善这一点。比如在“Micro GPT”项目中，我试图让 LLM 尽可能简化模型训练的代码。模型极其讨厌这么做，它们做不到。我不断提示它“再简化一点”，它就是做不到。你会感觉自己超出了 RL 的训练回路，像是在拔牙一样艰难，根本体会不到“光速编程”的快感。所以，我认为人们在短期内仍将主导这方面的工作。但这并非根本性的阻碍，可能只是因为实验室还没投入精力去解决它。

Stephanie Zhan: 我想回到“锯齿状智能”的概念。你写过一篇非常引人深思的文章，探讨了“动物与幽灵（Animals vs Ghosts）”。你的观点是：我们构建的不是动物，我们是在召唤幽灵。这些是受数据和奖励函数塑造的参差不齐的智能形态，而不是由内在动机、乐趣、好奇心或权力感——这些随进化而来的东西——所塑造的。为什么这种框架很重要？它到底改变了我们构建、部署、评估甚至信任 AI 的方式吗？

Andrej Karpathy: 我写这个是因为我试图在脑海中理清它们到底是什么。如果你对它们“是”或“不是”什么有一个良好的心智模型，你就能更胜任地去使用它们。我不知道这算不算是一种具有实操性的力量，可能有点哲学意味。但我认为关键在于接受这样一个事实：这些东西不是动物智能。你对它们大吼大叫，并不会让它们表现得更好或更差，根本没用。

它们全都是基于统计模拟的回路。底层是预训练（统计学），然后上面叠加了强化学习（RL），这加剧了它们能力的离散和突变。这可能只是一种心态设定：帮助我判断在接触它们时，什么方法可能有效，什么无效，以及如何去修改它。我不是说这就有一套明确的“让系统变好”的五大步骤，它更多是帮助你在面对 AI 时保持警惕，在不断试错中摸索。

Stephanie Zhan: 这是一个起点。你现在深度参与了不再仅仅是“聊天”的智能体的工作，它们拥有真实的权限、本地上下文，还能代表你采取实际行动。当所有人都开始生活在这样的世界里时，那会是什么样子？

Andrej Karpathy: 我相信在座的很多人都对这个原生智能体环境感到兴奋。所有东西都必须被重写。当前的一切系统本质上还是为人类编写的，必须做出改变。当我在使用各种框架或库时，它们的文档基本还是写给人类看的，这是我最不能忍的。为什么还要一直告诉我“怎么做”？我什么都不想做！我只需要你告诉我：我该把什么文本复制给我的智能体看？（笑）

每次文档叫我去点击某个链接或者配置某项设置，我都觉得太烦了。因此，我认为大家感到兴奋的是：如何将需要完成的工作流，拆解成对世界的“传感器（Sensors）”和“执行器（Actuators）”？如何实现智能体原生化，优先用智能体能够理解的方式去描述系统，并围绕对 LLM 极其友好的数据结构实现大量自动化？

我希望未来会出现很多“智能体优先（Agent-first）”的基础设施。举个例子，当初我写那篇关于 Menu Gen 的博客时，大部分麻烦其实不在于写代码，而是在 Vercel 上部署它。我必须与各种服务打交道，把它们串联起来，去设置菜单里调整参数，配置 DNS，这太烦人了。

如果我可以直接给 LLM 一个提示：“构建 Menu Gen”，然后我什么都不用碰，它就以同样的方式直接部署到了互联网上。这就是一个很好的测试标准，用来检验我们的基础设施是否变得越来越原生于智能体。

最终，我们正在迈向一个智能体可以代表个人和组织的世界。我的智能体会去和你的智能体沟通，把我们开会的具体细节敲定下来。我认为这就是事情发展的方向，这里的所有人都对此充满期待。

Stephanie Zhan: 我非常喜欢传感器和执行器这种视觉化的类比。我以前从未这样想过，这非常有趣。好的，最后我们必须以一个关于教育的问题来结束。因为你可能是世界上最擅长把复杂技术概念变得简单易懂的人之一，并且对此如何设计教育有着深刻的思考。随着我们进入 AI 的下一个时代，当智能变得廉价时，什么东西还值得我们深入学习？

Andrej Karpathy: 最近我看到一条让我大为震撼的推文，我几乎隔天就会想起它。大致意思是：“你可以外包你的思考（Thinking），但你无法外包你的理解（Understanding）。”

我觉得这句话说得太好了。因为我依然是整个系统的一部分，信息依然需要进入我的大脑。我感觉自己成为了一个瓶颈：我必须知道我们到底想要构建什么？为什么值得做？我该如何指挥我的智能体？最终必须有某种东西来指导思考和处理过程，而这依然从根本上受限于人类的“理解力”。

这也是为什么我对 LLM 知识库如此兴奋的原因之一。我觉得那是我处理信息的一种方式，每当我对信息有了一种新的投射，我都感觉获得了新的洞见。对于我来说，那就像是基于固定数据生成合成数据的提示词。

现在，每当我读一篇文章，我的维基知识库就会把这些内容纳入进来，我很喜欢向它提问，或者让它重构信息。最终，这些都是增强我们理解力的工具。理解力依然是个瓶颈——因为如果缺乏理解，你就无法成为一个优秀的指挥者。既然 LLM 目前并不擅长真正的理解，那么这依然是由你全权负责的专属领域。所以，那些能够强化理解力的工具，我认为是非常有趣且令人兴奋的。

Stephanie Zhan: 我很期待几年后再请你来到这里，看看我们是否已经被完全移出了循环，看看 AI 是否连理解的工作也一并包揽了。非常感谢你的到来，Andrej。

Andrej Karpathy: （掌声）