Andrej Karpathy 几个月前说了句话：他从未觉得自己作为程序员这么落后过。
说出这话的人是 OpenAI 联合创始人、前 Tesla Autopilot 负责人、AI 教育领域最会讲人话的那个人。他在红杉 AI Ascent 2026 上解释了这种落后感从哪来——2025 年 12 月，一个很清晰的拐点。之前他用 Claude Code 之类的 agentic 工具，LLM 写出的代码块经常有问题，需要手动改。12 月之后，他发现代码块基本没问题了，他要多少就给多少，他"记不清上一次纠正它是什么时候"。
这个拐点不是渐进的，是一道坎。过了这道坎，他的 side projects 文件夹爆炸了。
软件 3.0：上下文窗口就是你的杠杆
Karpathy 的软件三段论已经讲了一阵子了，但这次他把故事讲到了一个更锋利的地方。
Software 1.0：我写代码，明确规则，喂给 CPU。
Software 2.0：我造数据集、设计目标函数，训练神经网络，权重就是"程序"。
Software 3.0：我写 prompt，往上下文窗口里塞东西，LLM 是解释器，执行数字信息空间里的计算。
关键不在分类本身，在他举的例子。
OpenClaw 安装。 正常思维：写个 bash 脚本，处理各种平台差异。现实是——你只需要复制一段文本给 agent，agent 看你的环境，自己调试，自己搞定。没有脚本能做到这件事，因为脚本是 Software 1.0 的东西，它需要把每一步写死。Agent 是 Software 3.0，它有自带的智能，你只需要告诉它终点在哪。
MenuGen 的死亡。 Karpathy 自己做了个 app：拍餐厅菜单，OCR 识别菜名，用图像生成给每道菜配图，重新渲染菜单。挺有意思的小项目，deploy 在 Vercel 上。然后他看到了 Software 3.0 版本：拍张照片，丢给 Gemini，说"用 NanoBanana 把菜品图片叠到菜单上"。Gemini 直接输出一张带菜品的菜单图。
他做了整整一个 app 来干的事，一个 prompt 就替代了。MenuGen 不该存在。它在旧范式里工作，而新范式直接绕过了中间层。
这比"编程变快了"深得多。有些 app 会整个消失，不是被替代，是变得不必要。不是做得更快，是根本不需要做。
可验证性与锯齿智能
Karpathy 最近一直在写"可验证性"（verifiability）。他的核心观察：传统计算机能自动化你能用代码描述的东西；LLM 能自动化你能验证的东西。
原因在于前沿实验室的训练方式。这些模型在巨大的强化学习环境里训练，verification reward 驱动能力提升。所以模型在可验证的领域——数学、代码——表现突出，在不可验证的领域粗糙得离谱。
他举了个新例子："我要去 50 米外的洗车店，应该开车还是走路？" 当前的 SOTA 模型会告诉你走路，因为 50 米很近。同时，同一个模型在重构十万行代码库、发现零日漏洞。这种荒谬的落差就是锯齿智能（jagged intelligence）。
Karpathy 认为锯齿的成因有两个：一是 RL 训练本身的可验证性偏好，二是实验室选择聚焦的领域。GPT-3.5 到 GPT-4 象棋水平暴涨，不是因为能力自然增长，是因为有人往预训练集里灌了大量棋谱。能力不只来自 scaling，还来自数据分布里有没有你这个需求。
这个观察对创业者很实用：如果你在一个可验证但实验室还没怎么关注的领域，你可以自己做 RL 环境、自己微调，抢到实验室还没来得及覆盖的差异化能力。Karpathy 说他不想在台上"vape post"，但确实有这样的领域存在。
Vibe Coding vs. Agentic Engineering
Vibe coding 去年是他造的词。今年他明确区分了两个概念：
Vibe coding 是提高地板。人人都能用自然语言写东西了，门槛降到零。
Agentic engineering 是保持天花板。你仍然对软件质量负责，不能因为 vibe coding 就引入漏洞，但你要想办法用 agent 走得更快。
他把 agentic engineering 叫做一种工程学科——你有这些强大的、有点神经质的、随机性很强的 agent，怎么协调它们在不牺牲质量的前提下加速？这需要方法论，需要纪律，需要 engineering。
他观察到的是：10x 工程师的倍数已经不够形容了。真正擅长 agentic engineering 的人，效率远不止 10 倍。
关于招聘，他给了个很具体的建议：别再给算法题了。给一个大项目——比如"用 agent 写一个 Twitter clone，部署上线，做安全加固，然后我派 10 个 Codex 5.4x 去攻击它，它们不应该能攻破"。这才是考察 agentic engineering 能力的方式。
人还负责什么
当 agent 做得越来越多，人的什么能力变得更值钱而不是更不值钱？
Karpathy 的回答很精确：审美、判断、品味、规格设计、高层理解。
他举了个自己的例子。MenuGen 里，用户用 Google 账号注册，用 Stripe 买积分。两边的邮箱可能不同。他的 agent 在实现的时候，用邮箱地址来关联 Stripe 支付和 Google 账号。这种事情人类不会做——用户在 Stripe 和 Google 可能用完全不同的邮箱。但 agent 做了，因为对它来说"用邮箱匹配"是一种看起来合理但实际有 bug 的策略。
人需要设计正确的 spec：说清楚"用唯一 user ID 关联，不要用邮箱"。这类设计决策，agent 目前做不好。
另一个角度：他已经记不清 PyTorch 里 keepdims 还是 keepdim，reshape 还是 permute，dim 还是 axis 了。这些 API 细节他不管了。但他必须知道底层的 tensor 有 view 和 storage 的区别，操作 view 不复制内存，创建新 storage 就复制——这种底层理解不能丢。agent 处理细节，你掌握原理和方向。
他提到了 microGPT 项目——试图把 LLM 训练简化到极致。LLM 做不了这件事。他反复让它"再简化"，感觉像"在 RL 电路外面拔牙"。简化能力和审美判断不在当前模型的训练分布里。
动物 vs. 幽灵
Karpathy 用"召唤幽灵"来形容我们正在做的事。
这些模型不像动物智能。动物智能由进化塑造，有内在动机、好奇心、自主性。LLM 的底层是预训练的统计拟合，上面 bolt-on 了一层 RL，增加了一些"附肢"。它们是统计模拟电路。
对使用者来说，这个区分很实际：你冲它吼不会让它工作得更好或更差。它不害怕，不兴奋，没有动力。你需要理解它的运行机制来更好地驾驭它——哪些是 RL 电路覆盖到的，哪些是死角，什么时候该信任它，什么时候该亲自检查。
Agent-Native 基础设施
Karpathy 有个很实在的抱怨：现在的文档和基础设施还是给人类设计的。
"每次有人告诉我去某个 URL 看东西，我就……唉。"他想要的是：直接给我一段文本，让我丢给 agent。OpenClaw 的安装脚本已经走了这条路——不是 bash 脚本，是一段给 agent 的指令。
他的愿景：把工作负载拆成传感器和执行器——agent 感知世界的方式和 agent 作用于世界的方式——然后让基础设施变成 agent-first 的。
MenuGen 的痛苦不只是写代码，是部署。DNS 配置、各种服务的 settings 界面、把不同服务串起来——这些占了他大部分时间。理想状态：给 agent 一个 prompt，它不光写代码，还自己部署上线，你什么都不用碰。
最终形态：每个人和每个组织都有一个 agent 代表。我的 agent 跟你的 agent 谈，安排会议，处理细节。
什么还值得学
主持人问了个最终极的问题：当智能变得廉价，什么还值得深入学？
Karpathy 提到了一条最近一直在他脑子里转的推文："你可以外包你的思考，但你不能外包你的理解。"
他仍然需要信息进入自己的脑子。他仍然是系统的瓶颈——知道我们在建什么、为什么值得建、怎么指挥 agent。LLM 不擅长理解，你在这件事上仍然是独一无二的负责人。
这也是为什么他对 LLM 知识库项目那么兴奋——每次看到信息被重新组织、重新投射，他就获得新的洞察。这些工具的本质是增强理解。
我的判断
这场访谈比大多数 AI 演讲实在得多，因为 Karpathy 在两个层面同时工作：他在用这些工具（所以他知道什么好用什么不好用），同时在思考这些工具的本质。
Software 3.0 的 MenuGen 例子是整场最锋利的一刀。它不是在说"编程变快了"，它在说"有些软件不该存在"。这个判断比大多数 AI 分析深一层。如果你在做应用层产品，你得问自己：我的产品是不是一个 MenuGen？是不是有一个 prompt 能直接绕过我？
锯齿智能的解释也值得记住。能力不均匀不只是因为模型还不够好，它有结构性原因——RL 训练偏好可验证领域，加上实验室选择性地灌数据。这意味着有些领域的能力空白不是"等 scaling 解决"的问题，而是"没人把那个领域放进去"的问题。创业者的机会就在这个缝隙里。
"召唤幽灵"这个比喻比"人工智能"精确得多。它提醒你：你在跟一个统计模拟电路打交道，不是跟一个有动机的实体。这决定了你怎么信任它、怎么检查它、什么时候该自己动手。
但最让我记住的是最后那句：你可以外包思考，不能外包理解。 工具越强，理解的重要性反而越高，因为你是整个系统的方向盘。agent 可以做一切，但它不知道该往哪走。这才是人真正不可替代的地方。