▶ 原文链接

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

来源： YouTube | Andrej Karpathy | Apr 29, 2026 分类： 其他 原文发表： Apr 29, 2026 纪要生成： 2026-05-26

---

嘉宾/话题简介

Andrej Karpathy 是人工智能领域的杰出人物，曾作为联合创始人之一在 OpenAI 办公室内参与创建了 OpenAI，并曾在特斯拉主导 Autopilot 系统的研发工作。他因擅长以通俗易懂的方式解释复杂的技术变迁而闻名，是“软件 2.0”理念的提出者。去年，他创造了 “氛围编程” 一词，深刻影响了开发者社区对 AI 辅助编程的认知。

本集节目中，Karpathy 深入阐述了他近期关于 AI 发展的核心思考。他从自己在编程中感到的“前所未有的落后”这一惊人感受出发，系统地拆解了 “软件 3.0” 范式、“可验证性” 与模型 “锯齿状智能” 的根源，并定义了从 “氛围编程” 到 “智能体工程” 的演进，最终落脚于 AI 时代人类理解力与教育的终极价值。

---

分节详述

00:00 从“感到落后”到“氛围编程”：一个编程转折点

本节重点

• Karpathy 感到“落后”源于 AI 编程工具在连贯性上的根本性变化，而非个人能力下降。
• 2025年12月是一个分水岭，AI 生成的代码块开始持续无误，信任关系建立。
• 这种感受是“振奋”与“不安”的结合，催生了大量的个人项目实践。

详细精要

• Karpathy 的“落后感”解析：这种感受并非源于技能的退步，而是因为 AI 驱动的编程工具能力发生了质的飞跃，使得他个人的产出速度相对于工具的潜力显得“落后”。
• 这种感觉是“兴奋”和“不安”的混合体。
• 他使用智能体工具已有一段时间，起初工具只能处理代码片段，且经常出错，人工修正必不可少。
• 转折点发生在 2025年12月，他发现最新的模型生成的代码块能一次性完美运行，他不断要求更多，模型持续交付无误。

• 他意识到自己已经不记得上次去纠正 AI 代码是什么时候了，由此进入了全然的 “氛围编程” 状态。

• “氛围编程”的诞生与核心体验：这是一种对 AI 编程系统高度信任的新状态，用户只需不断提出需求，系统即可持续输出可信结果。

• Karpathy 强调，这是一个非常鲜明的转折点，许多人在 2025 年的体验还停留在类似 ChatGPT 的阶段，但实际上自 12 月起，情况已经发生了根本性变化。
• 这种变化尤其体现在 “智能体连贯工作流” 上，即 AI 能像一个真正的智能体一样，连贯地完成一项复杂任务，而不仅仅是孤立的代码生成。
• 这种新体验促使他沉迷于各种“无穷的”个人项目，他的项目文件夹被大量随机项目塞满，他无时无刻不在编程。
• 他认为当事情在可验证的领域中变得极为流畅、无需修正、完全可信时，就是在“氛围编程”。这是一种不费力、充满信任的心流状态。

💬 精华片段（中文）

“我记不起上一次纠正它是什么时候了。然后我就越来越信任这个系统……我那时就是在进行‘氛围编程’。”

"I can't remember the last time I corrected it. And then I was I just uh, you know, trusted the system more and more. And then I was vibe coding."

---

02:35 软件 3.0：将 LLM 视为一种新型计算机

本节重点

• 定义了从软件 1.0（人工编写指令）到 3.0（通过提示编程）的演进路径。
• 软件 3.0 的核心是将 LLM 看作一个可编程的“解释器”，编程手段变为提示和上下文窗口。
• 这种新范式不是对现有事物的加速，而是使得许多以前根本不存在的应用成为可能。

详细精要

• 软件演进的三个阶段：清晰地划分了编程范式的发展史。
• 软件 1.0：由人类显式地编写规则和代码。
• 软件 2.0：人类通过构建数据集、设定目标和神经网络架构来“编程”，神经网络的权重是学习的产物。

• 软件 3.0：当 GPT 或 LLM 在互联网的海量数据上接受了足够多的多任务隐式训练之后，它们本身就变成了一台“可编程的计算机”。此时的编程变成了提示工程，上下文窗口就是操纵这个 LLM“解释器”的杠杆，让它在数字信息空间中执行计算。

• 范式转移的例证：OpenClaw 安装：从必须编写精确的 Shell 脚本到只需给智能体一段文本指令。

• 传统上，像 OpenClaw 这样的软件为了兼容多种平台和计算机类型，其 Shell 安装脚本会变得极其复杂和臃肿，这是典型的软件 1.0 思维。
• 如今，OpenClaw 的安装方法已变成一段可以直接复制粘贴给智能体的文本。这是一种“技能”的封装。

• 这种方式更强大的原因在于，你不再需要精确地指定所有设置细节。智能体封装了自身的智能，它能观察你的具体环境、计算机状态，并执行智能操作来让事情运行，甚至在循环中自我调试。

• 范式转移的极端例证：MenuGen 的消亡与重生：一个精心编写的手机应用（app）被一个原始的、基于神经网络的原生操作所取代。

• Karpathy 最初构建的 MenuGen 应用是一个完整的程序：用户上传餐厅菜单照片 -> OCR 识别菜名 -> 调用图片生成器为每道菜生成图片 -> 重新渲染出一个带图的菜单。整个应用部署在 Vercel 上。
• 但 软件 3.0 版本彻底颠覆了这一切：用户直接用手机拍一张菜单照片，交给 Gemini，并给出提示：“使用 Nano Banana 将（菜品图片）覆盖到菜单上。”
• Nano Banana 直接在像素层面进行操作，返回了一张在原始菜单图片上直接渲染了对应菜品图片的新图片。

• 这个结果让 Karpathy 大为震撼，因为它证明了 整个 MenuGen 应用其实是多余的，是旧范式下的产物。在新范式下，整个处理过程被压缩成了“输入一张图，输出一张图”，中间的神经网络完成了所有工作。

• 新范式的核心意义：创造前所未有之物：软件 3.0 最激动人心的部分在于它使信息处理自动化，从而催生了此前在结构化和代码逻辑下无法想象的新应用。

• 传统的代码在结构化数据之上运行。
• Karpathy 的 “LLM 知识库”项目就是一个例子。它利用 LLM 根据一系列文档和事实，为个人或组织自动创建 Wiki。在没有 LLM 之前，这种能够基于事实进行重编译、重排序并构建知识库的“程序”是不存在的。
• 关键在于不要仅仅将 AI 看作是对现有事物的加速，而是要看到它解锁了全新的机会，去做那些以前根本不可能做到的事。

💬 精华片段（中文）

“整个 MenuGen 都是多余的……软件 3.0 范式要原始得多。你的神经网络做了越来越多的工作，你的提示或上下文就只是一张图，输出也是一张图，中间根本不需要任何 app。”

“All of my menu gen is spurious...the software 3.0 paradigm is a lot more kind of raw. It just um, your neural network is doing more and more of the work, and your prompt or context is just the image, and the output is an image, and there's no need to have any of the app in between.”

---

07:48 2026年的新机会：“神经网络优先”的原生应用

本节重点

• 未来的计算设备将以神经网络为宿主进程，而传统的 CPU 则降级为辅助性的协处理器。
• 许多在 App 时代被精心构建的代码将会消失，转而由神经网络基于原始输入（如视频、音频）即时生成动态 UI。
• 这种发展路径并非一蹴而就，而将是逐步演进的。

详细精要

• 对未来的极端推演：“神经计算机”：在未来的架构中，神经网络将成为系统的核心。
• 可以想象一种设备，它将原始的视频或音频直接输入神经网络，然后通过扩散模型等技术，实时渲染出一个为当下时刻量身定做的、独一无二的用户界面（UI）。

• 这意味着神经网络成为了宿主进程，负责大部分繁重的计算。而 CPU 等传统计算单元则退化为协处理器，只在需要执行特定、确定性的任务时被以“工具调用”的形式拉进来，成为一种“历史的附属品”。

• 计算历史的路径选择：这个想法有其历史渊源。

• 在上世纪五六十年代计算机科学的早期，人们对于计算机的未来形态是更像计算器还是更像神经网络曾有过犹豫。
• 最终历史选择了“计算器”路径，发展出了经典计算。现在，神经网络运行在由 CPU 等构成的虚拟机之上。

• Karpathy 预测，二者地位将会翻转。我们正在看到，投入到神经网络上的情报计算量正在接管全部浮点运算，并成为主导性的支出。

• 渐进式的演化路径：虽然最终形态可能很陌生，但演进过程将是“一块一块地”（piece by piece）发生的，具体的进度目前尚无法确定。

💬 精华片段（中文）

“在计算的早期，人们对于计算机是看起来像计算器还是像神经网络感到有点困惑……我们最终走了计算器的路径……但可以想象，很多东西会翻转过来，神经网络成为宿主进程，而 CPU 成为协处理器。”

“In the early days of computing actually, people were a little bit confused as to whether computers would look like calculators or computers would look like neural nets...we went down the calculator path...But you could imagine I think that a lot of this will flip and that the neural net becomes kind of like the host process. And the CPUs become kind of like the co-processor.”

---

09:53 “可验证性”之谜：为何AI能力如此“锯齿状”

本节重点

• AI 模型的能力之所以“锯齿状”，根本原因在于其训练范式——强化学习高度依赖可被验证的奖励信号。
• 模型在数学、代码等易于设定验证奖励的领域能力飙升，而在缺乏明确验证信号的常识领域则表现笨拙。
• 模型的特定能力峰值也与前沿实验室有意识地注入特定数据（如国际象棋数据）高度相关。

详细精要

• “可验证性”驱动能力：LLM 的训练本质上是巨大的强化学习环境，它们通过验证奖励来学习。
• 由于这种训练方式，模型变成了“锯齿状的实体”，在数学、代码等可以被自动验证的领域能力达到顶峰。
• 在那些无法被清晰验证的领域，模型的能力则相对粗糙和“停滞”。

• 因此，Karpathy 提出的判断是：经典计算机擅长自动化你可以在代码中精确指定的任何事；而这一代 LLM 擅长自动化你可以在某种意义上进行验证的任何事。

• “锯齿状”的经典案例：“草莓”与“洗车”：这些例子揭示了模型顶尖能力与低级错误并存的吊诡现象。

• 旧例：模型曾著名地无法准确回答“单词 strawberry 里有多少个字母 r？”，这是其“锯齿状”的经典体现。（注：此问题现已基本被补丁修复）
• 新例：即使是最先进的模型（如GPT-4.7级），当被问到“我想去50米外的洗车店洗车，我应该开车还是走路？”时，仍然会回答“走路，因为太近了。” 这完全是荒谬的，因为它忽略了“洗车”这个核心场景，把问题简化为了一个纯粹的距离问题。

• 此事令人深感“疯狂”，因为同一个模型能够同时重构一个包含十万行代码的庞大代码库，或发现零日漏洞，却在如此简单的常识推理上失败。

• “实验室关注度”与数据分布的影响：能力的“锯齿”不仅仅是技术上的可验证性问题，也受到实验室人为选择的影响。

• 国际象棋的例子：从 GPT-3.5 到 GPT-4，模型的下棋能力大幅提升。许多人认为这只是能力线性进步的自然结果。但根据公开信息，这主要是因为 OpenAI 有人决定将大量国际象棋的对弈数据放入了预训练数据集中。因为处于数据分布之内，能力出现了一个远超默认水平的峰值。
• 这说明，开发者在一定程度上“听命于”前沿实验室的决策。如果一个应用所处的领域恰好是 RL 训练的核心回路，并且处于数据分布之内，效果就会“起飞”。反之则会非常挣扎。
• 如果在通用大模型上表现不佳，开发者就必须考虑自己进行微调。

💬 精华片段（中文）

“当前最先进的 Opus 4.7 能同时重构一个十万行的代码库，或者找到零日漏洞，但却告诉我要走路去洗车？这太疯狂了。”

“State-of-the-art Opus 4.7 will simultaneously refactor a 100,000 line code base or find zero-day vulnerabilities and yet tells me to walk to this car wash? This is insane.”

---

13:30 对 AI 时代创始人的建议：寻找可验证的领域

本节重点

• 创始人应寻找那些虽然未被顶级实验室重点投入，但自身具有良好“可验证性”的领域进行深耕。
• 通过自建强化学习环境和数据集进行微调，是在通用模型之上构建护城河的关键技术。
• 从长远看，几乎所有领域最终都可以通过某种方式（如 LLM 陪审团）变得可验证。

详细精要

• 利用可验证性构建产品：即使实验室没有专注于某个领域，其内在的可验证性也为创业者提供了机会。
• 如果一个问题是可验证的，就意味着可以为之创建强化学习环境。
• 创始人可以积累大量、多样化的数据和 RL 环境，利用自己喜欢的微调框架“拉动杠杆”，训练出在特定领域表现出色的模型。这是一项在技术上非常可靠的方法。

• Karpathy 暗示存在一些非常有价值的、尚未被实验室充分开发的 RL 环境领域，但他选择在现场“打哑谜”，没有给出具体例子。

• 关于“自动化”的边界：回答一切能被自动化吗？

• Karpathy 认为，最终几乎所有东西都能在某种程度上变得可验证，只是难易程度不同。
• 即使是像“写作”这样看似主观的任务，也可以通过组建一个由多个 LLM 构成的评审委员会来制定评价标准，从而创造出验证信号。
• 因此，他的最终结论是“万物皆可自动化”。

---

15:35 “氛围编程” vs. “智能体工程”：一场从“地板”到“天花板”的革命

本节重点

• “氛围编程” 的目标是提高下限，让任何人都能创造软件。
• “智能体工程” 的目标是维持上限，在专业领域利用 AI 实现巨大加速而不牺牲质量和安全标准。
• “智能体工程”是一种新的工程学科，专注于如何高效、正确地协调这些能力强大但存在缺陷和随机性的智能体。
• 一个擅长智能体工程的工程师，其效率提升远超“10倍工程师”。

详细精要

• 两个概念的核心区别：
• 氛围编程：“地板”的抬升。让所有人都能进行软件创作，极大地降低了编程的准入门槛，释放了巨大的创造力。

• 智能体工程：关乎“质量标尺”的维护。你仍然需要对最终交付的软件负责，不能因为“氛围编程”而引入安全漏洞。核心问题变成了：如何在保证质量不下降的前提下实现极致的速度？

• 智能体工程的定义与特性：这是一门关于如何驾驭“锯齿状”、“易错”但“极其强大”的智能体的工程学科。

• 智能体是随机和易错的，这与传统软件工程的确定性前提截然不同。
• 这门学科的核心就在于，如何去协调这些智能体，在不牺牲质量的前提下实现开发速度的飞跃。

• “智能体工程”的上限极高。传统的“10 倍工程师”概念已经过时，Karpathy 观察到，擅长此道的人可以获得远超 10 倍的效率提升。

• 什么是“AI 原生”的编程者：他们善于将手头工具的性能压榨到极致。

• 就像过去优秀的工程师能熟练运用 Vim 或 VS Code 一样，AI 原生的工程师会深入投资于自己的 Coder、Codex 等智能体配置和工具链。
• Karpathy 进一步指出，大多数公司的招聘流程还没有跟上这个时代。通过解谜题来面试是旧范式。未来的面试应该是：让候选人实现一个大型项目（例如一个“供智能体使用的推特克隆”），并确保其安全和高质量，然后让 10 个不同的 Codex 智能体去尝试攻击该网站，网站不能被攻破。这或许才是考察智能体工程能力的正确方式。

💬 精华片段（中文）

“氛围编程是为了提高每个人的能力下限……而智能体工程则是为了保持专业软件原有的质量标准。”

“Vibe coding is about raising the floor for everyone... agentic engineering is about preserving the quality bar of what existed before in professional software.”

---

19:42 人类价值的新核心：品味、判断与顶层设计

本节重点

• 在 AI 智能体接管具体实现细节后，人类最宝贵的能力变为审美、品味、判断力和宏观把控。
• AI 在当前阶段会犯一些在人类看来非常诡异的逻辑错误，特别是在缺乏全局唯一标识符的情况下生硬套用启发式规则。
• 工程师的任务从记忆 API 细节，转变为理解底层原理并负责顶层设计和架构。

详细精要

• 品味与判断成为核心：目前，智能体是出奇地“内部化”的实体，人类需要在审美、判断、品味和监督方面发挥核心作用。
• MenuGen 的“诡异”错误：在 Karpathy 的 MenuGen 项目中，用户需要用 Google 账号登录，但通过 Stripe 账户购买积分。两者都关联了邮箱地址。智能体竟然试图用 Google 邮箱去关联 Stripe 的购买记录，而不是用一个统一的用户 ID。这暴露了智能体在没有明确、强健的全局 ID 概念时，会生硬地使用“邮箱”这类非唯一标识符来关联数据，导致充值失败。

• 这个例子说明，人类必须负责制定规格说明书，确定顶层范畴（如“必须有一个唯一用户ID来绑定一切”），而智能体则负责在框架下填充细节。

• 从记忆 API 细节到理解底层原理：工程师的知识结构正在发生转变。

• 大量具体的 API 细节（如 PyTorch 和 NumPy 中的 keepdim、dim、axis、reshape、permute、transpose）已无需记忆，智能体可以完美处理。
• 但是，工程师仍需深刻理解底层原理，例如张量的底层存储是共享的视图还是独立的拷贝，因为这直接关系到内存使用效率。不关心底层原理可能导致不必要的内存拷贝。
• 因此，劳动分工变为：工程师负责品味、工程设计、整体构思，确保方向正确；智能体则作为“实习生”填补具体的代码空白。

---

22:15 AI 会发展出“品味”吗？代码审美的RL难题

本节重点

• 当前模型生成的代码往往质量不高（臃肿、存在大量复制粘贴、抽象脆弱），因为“代码美学”难以被纳入强化学习的奖励函数。
• 即便强如 LLM，在“简化代码”这类任务上也可能会表现出极大的挣扎，仿佛身处 RL 训练回路之外。
• 这并非原理上不可能，只是尚未有实验室投入足够精力去攻克。

详细精要

• 代码质量现状：令人心跳骤停：当 Karpathy 审视 AI 生成的代码时，有时会感到一阵心悸。
• 生成的代码并非总是卓越，相反，经常臃肿不堪，存在大量的复制粘贴，以及各种别扭且脆弱的抽象。

• 虽然代码能跑（works），但实在“太恶心了”（really gross）。

• “简化代码”的挑战：“MicroGPT”项目：这个项目旨在将 LLM 训练代码简化到极致，但所有主流模型都在此任务上失败。

• Karpathy 反复提示 LLM 去“简化，再简化”，但效果如同“拔牙”（pulling teeth），根本不是模型在可验证领域那种“光速飞行”的感觉。

• 这使他确信，进行代码极致简化时，他们正处在 RL 训练回路的“圈外”。模型没有关于“简洁美学”的验证奖励。

• 可改善的未来：他认为这并非本质上的不可能，只是前沿实验室至今还没有去做。未来通过设计适当的奖励机制，模型的代码品味是可以被提升的。

💬 精华片段（中文）

“我试着不断地提示 LLM 去简化，再简化，但它就是做不到。感觉你完全处在 RL 的回路之外。”

“I tried to keep prompting an LLM to simplify more, simplify more, and it just can't. You feel like you're outside of the RL circuits.”

---

23:47 “动物 vs. 幽灵”：一种理解 AI 本质的框架

本节重点

• Karpathy 提出用“幽灵”而非“动物”来比喻当前的大语言模型。
• “动物”智能由内在动机、好奇心、进化等塑造，而“幽灵”智能则纯粹由预训练数据和强化学习的奖励函数塑造。
• 这种框架有助于在使用 AI 时保持合理预期和“怀疑”心态，避免拟人化带来的错误判断。

详细精要

• “幽灵”比喻的核心：理解 AI 是什么以及它不是什么，是有效使用它的基础。
• 当前的 AI 并非像动物一样具有内在动机、好奇心、乐趣或自我驱动力，这些是亿万年进化的结果。
• 它们更像“被召唤的幽灵”，其形态和能力的“基质”是预训练，即对大量数据的统计学模拟。而后在此基础上，“螺栓式地”附加了强化学习，以此提升其在特定任务上的表现。

• 如果你对它们大喊大叫，并不会让它们表现得更好或更差，因为它们没有情绪。

• 付诸实践的指导意义：这种哲学思辨具有实际价值。

• 它帮助使用者建立一个正确的“思维模式”，即对什么东西可能会奏效、什么东西不奏效有一个基本预期。
• 核心态度是保持怀疑，并在与模型的长期互动中摸索其边界。虽然无法得出“五个明确结论让你系统变得更好”，但这种怀疑精神是正确使用的起点。

---

25:19 迈向“智能体原生”世界：传感器、执行器与新型基础设施

本节重点

• 现有的一切基础设施（文档、部署服务、配置）都是为人类设计的，必须被重写为“智能体优先”。
• 理想形态是将工作负载分解为对世界的感知和行动（传感器/执行器模型），并构建“智能体可读”的数据结构。
• 未来每个人、每个组织都会有自己的智能体代表，彼此进行交互。

详细精要

• 当前生态的根本缺陷：为人类编写的一切：Karpathy 表达了他最大的“心头之恨”。

• 现在的软件框架和库，其文档依然是为人类编写的。文档会告诉他“去这个URL”、“做那个操作”，这让他恼怒不已。他需要的不是指导他做什么，而是一段可以直接复制粘贴给他的智能体的文本。

• “智能体原生”的痛点与实践：

• MenuGen 发布示例：为 MenuGen 写代码并不痛苦，但将其部署到 Vercel 的过程极其痛苦和繁琐。他不得不亲自处理各种服务、设置、菜单，配置 DNS 等。他的理想是：给 LLM 一个提示，“构建 MenuGen 并部署它”，然后智能体就能一步到位完成全部操作，无需人工干预任何中间步骤。这已成为他检验基础设施是否“智能体原生”的一个测试用例。
• 系统架构的变革：人们需要将工作负载重新思考为：如何将对世界的感知（传感器）和对世界的行动（执行器）直接暴露给智能体。

• 数据结构：需要创造对 LLM 来说极易读懂的、专门的自动化数据结构。

• 终极图景：智能体间的社交：世界正向着一个充满组织和个人智能体代表的方向发展。

• 未来，Karpathy 的智能体会和你的智能体交谈，来敲定会议的细节。

---

27:57 教育的未来：为何“理解”无法外包

本节重点

• 最核心的洞见：“你可以外包你的思考，但你无法外包你的理解”。
• 尽管 LLM 可以执行任务，但人类大脑仍然是信息处理的瓶颈，是决定“要构建什么”以及“为什么值得做”的终极决策者。
• 教育和个人知识管理的未来，在于利用 AI 工具（如 LLM 知识库）来增强而非替代人类的理解力。

详细精要

• 克氏名言：外包思考 vs. 外包理解：Karpathy 被一条推文深深震撼，并成为了他的核心信念。
• 推文内容大致是“你可以外包你的思考（outsource your thinking），但你无法外包你的理解（outsource your understanding）”。

• 这意味着，即使 AI 可以做所有的事，人类依然是整个系统的一环。信息最终必须进入人脑。Karpathy 感到自己正成为瓶颈：他需要知道正在构建什么，为什么值得做，以及如何指挥他的智能体。这一切都受限于他自身的理解。

• 知识管理作为理解的增强工具：他对自己发起的 LLM 知识库项目感到兴奋，因为它成为了他处理信息和深化理解的强大工具。

• 每当阅读一篇文章，他都会将其纳入一个正在通过文章案例逐步构建起来的个人 Wiki 中。通过这个知识库，他可以提出各种问题，获得对信息的全新“投影”和视角，从而获得洞察。
• 这是一种通过合成数据生成对固定数据进行多维度解析的方式。他认为这些工具是增强理解的途径，而非替代。因为只有人类才拥有理解的独特能力，而这是指导智能体成为优秀“导演”的先决条件。

💬 精华片段（中文）

“你可以外包你的思考，但无法外包你的理解。……LLM 绝对不擅长理解。你仍然独一无二地对此负有责任。”

"You can outsource your thinking, but you can't outsource your understanding... the LLMs certainly don't excel at understanding. You still are uniquely in charge of that."

---

专业术语注释

术语	解释
氛围编程	由 Karpathy 提出的概念，指一种对 AI 编程工具极度信任且无需过多人工检查和修改的状态。用户输入需求，AI 直接产出可信、可用的代码。
智能体工程	一门新兴的工程学科，专注于如何高效、安全地协调多个能力强大但存在随机性和缺陷的 AI 智能体，以在保证软件质量和安全的前提下实现极致的开发速度。
软件 1.0 / 2.0 / 3.0	Karpathy 定义的软件编程范式演进。1.0 指人工编写显式规则；2.0 指通过设计数据集和神经网络结构来训练模型；3.0 指通过向 LLM 提供提示和上下文窗口来编程，将 LLM 本身视为一个可编程的解释器。
LLM	大型语言模型。本集中尤指像 GPT-4 这样，通过海量互联网数据预训练和强化学习微调得到的，能理解和生成文本、代码等内容的巨型神经网络。
RL / 强化学习	一种机器学习训练范式，智能体通过与环境互动，根据获得的“奖励”信号（正或负）来学习何种行为能最大化累积奖励。在 LLM 中用于在可验证的领域（如数学、代码）上对齐和增强模型能力。
锯齿状智能	描述当前顶尖 AI 模型能力分布不均的现象。模型在某些高难度、可验证的任务（如竞赛数学、大型代码重构）上表现得像专家或超人，但在其他显而易见的简单常识任务上却犯低级错误。
可验证性	指一个任务或领域的输出结果是否能被一个自动化的、客观的标准进行评估。Karpathy 认为，当前 LLM 的训练范式决定了它们擅长自动化一切能被验证的事情，这是其能力“锯齿状”的根源。
预训练	在大规模、多样化的未标注或互联网文本数据上训练基础模型的第一步，目标是让模型学习语言的统计规律、世界知识和推理模式。这是模型“智能”的基石。
Nano Banana / Gemini	分别代表先进的图像生成/编辑模型和谷歌的旗舰多模态大语言模型。用来举例说明软件 3.0 范式下，复杂的图像处理任务可以被简化为一句话的指令。
传感器 / 执行器	控制论术语。Karpathy 借此比喻智能体原生世界的架构：LLM 作为核心处理器，通过“传感器”来感知世界信息（如读取文档、API），通过“执行器”来采取行动（如调用工具、修改代码）。

原文发表：Apr 29, 2026  ·  纪要生成：2026-05-26