2026 年 4 月，Andrej Karpathy 在 Sequoia Capital AI Ascent 现场接受了合伙人 Stephanie Zhan 的访谈。这场 30 分钟对话覆盖了编程范式剧变、Software 3.0 的实质、LLM 能力的锯齿状分布，以及"凭感觉编程"之后更严肃的下一步。
Vibe Coding 抬高下限，Agentic Engineering 保住上限
Karpathy 的个人转折点发生在 2025 年 12 月。那段时间他正好休假，有更多时间折腾 side project，明显感觉到最新模型生成的代码块开始"直接能用"——他进入了一种完全凭感觉编程的状态，最后创造了"Vibe Coding"这个词。
但 2026 年的访谈里，他的重点已经不只是 Vibe Coding。他明确区分了两者的定位：
Vibe Coding 抬高的是下限。 更多人可以用自然语言和 AI 做软件。不会写代码的人可以做小工具，会写代码的人可以更快做 side project。软件创造的入口变宽了。
Agentic Engineering 保住的是上限。 它面对的是专业软件：不能因为用了 AI 就引入安全漏洞，不能因为模型写得快就降低质量门槛，不能因为代码是 Agent 生成的就没人负责。Agent 是"有尖刺的实体"——能力很强，但会犯错，有随机性。工程师的工作是把它放进合适的流程里：生成方案、写代码、跑测试、互相检查，让系统有边界、有验证、有回滚。
10x 不是你获得的加速倍数。真正熟练的人，能把多个 Agent、工具、测试和上下文组织起来，产出速度会被放大得更厉害。
Software 3.0：程序的边界扩大了
Karpathy 把软件分成三个时代：
Software 1.0：传统软件，人写显式代码，计算机按规则执行。
Software 2.0：神经网络时代，人设计数据集、目标函数和架构，通过训练得到模型权重。Karpathy 早在 2017 年就写了《Software 2.0》。
Software 3.0：大语言模型时代。LLM 经过大规模任务训练后，变成一种可编程的计算机。你不再只是在代码编辑器里写函数，而是在 prompt、context window、文件、工具调用之间组织一段给模型执行的"上下文程序"。
他举了一个安装 OpenCL 的例子。传统做法是写 shell script 适配各种环境，随着目标环境变多，脚本不断膨胀，最后复杂到很难维护。但在 Software 3.0 里，安装说明本身就是一段可以复制给 Agent 的文本。Agent 会读取你的机器环境，执行步骤，遇到错误再调试。
现在的问题变成：哪一段文字应该复制给你的 Agent？这就是新的编程范式。
MenuGen 案例：旧范式被模型原生能力吞掉
Karpathy 做了个叫 MenuGen 的 App：拍菜单照片，App 识别菜名，生成菜品图，重新渲染菜单。后来他看到了 Software 3.0 版本：直接把菜单照片交给 Gemini，说"让 Nano Banana 把这些菜图叠加回菜单上"，Gemini 返回的是一张直接渲染好的新图片——原来写的整个 App 在他看来变得多余了。
我的整个 MenuGen 都是多余的。它还停留在旧范式里。那个 App 不应该存在。
这个判断是整场访谈最关键的商业洞察之一：很多 AI 应用公司以为自己在做"更快的软件"，但在 Software 3.0 里，模型本身的输入输出可能直接覆盖这个任务，中间 App 的结构就失去必要性。
LLM 是锯齿状智能，不是全面智能
Karpathy 提出了一个重要概念：LLM 的能力高度不均匀，是"锯齿状"的。
一个最先进的模型可以重构 10 万行代码、找到零日漏洞，却告诉我应该走路去洗 50 米外的车。
这道"洗车题"的错误在于：你要洗的是车，所以车必须到洗车店，而模型忽略了关键约束。
这种能力的分布不均匀不是"模型整体变聪明"的结果，而是取决于 RL 训练覆盖了哪些领域。Karpathy 直言：
某种程度上，我们完全受制于实验室给模型喂了什么数据。如果你的场景刚好落在 RL 训练覆盖的"能力回路"里，模型就会带你起飞；但一旦超出了这个数据分布，它就会觉得极其吃力。
这给使用者的要求很高：你不能因为模型在代码上很强，就默认它在所有工程判断上都强；你也不能因为它犯了洗车题这种错误，就断定它整体没用。正确做法是探索它的能力边界，找出哪些任务在"高峰"里，哪些在"断崖"旁。
什么人类技能会变得更有价值
Karpathy 的答案很具体：品味、判断、审美、监督，以及规格设计。
他把 Agent 比作实习生：能力越来越强，但会在人类觉得显而易见的地方犯错。MenuGen 的一个实际问题：用户用 Google 账号登录，但用 Stripe 账号付款。Agent 实现时试图用 Stripe 邮箱匹配 Google 邮箱来归类 credits——这在工程上是危险的，一个人完全可能用不同邮箱登录和付款。这类问题代码能跑，测试可能还过，但系统设计是错的。
Agent 没有真正理解身份、支付和资金归属的风险。人必须负责顶层设计、约束条件和判断标准。
Karpathy 不再记 PyTorch、NumPy、pandas 之间的细碎 API 差异，但仍然理解底层概念：张量是什么，view 和 storage 的关系是什么，什么时候只是改变同一块内存的视图，什么时候会复制数据。
他的原则是：细节可以外包，理解不能外包。 API 名称可以忘，但概念结构不能丢。
幽灵框架和使用原则
Karpathy 之前写过"动物 vs 幽灵"的文章。这次访谈他把这个框架落到一个很朴素的使用原则上：
LLM 不是动物式智能。它由人类文档、统计模式和奖励函数塑造的模拟实体。对它大喊大叫不会让它更努力，鼓励它也不是在激发内在动机。模型没有动物式情绪，它的行为来自统计模拟、上下文、工具、训练数据和奖励机制。
未来 6-12 个月值得盯的三个信号
- 前沿实验室在编程/数学之外往哪些领域注入 RL 数据——那里的能力会突然冒出来
- Agent-first 基础设施会不会有第一波收敛——MenuGen 部署的痛苦如果还在，"自动化社会"的路就长得多
- 模型下一代更新是否包含审美和代码质量相关的 RL 目标——如果包含，"品味不可替代"的护城河有效期就到那一天
访谈结尾，Karpathy 引用了一句话：
你可以外包你的思考，但不能外包你的理解。
他的解释很具体：信息必须进入他的脑子里。他感觉自己正在变成瓶颈：要知道到底在建什么，为什么值得做，怎样指导自己的 Agent。思考步骤可以让模型跑很多遍，但如果人没有理解，就无法判断哪条路线是对的，无法写出好的规格，也无法发现 Agent 在身份绑定、系统结构、代码质量上的错误。
真正稀缺的不是任何一个具体技能，而是判断"我们到底要做什么、为什么值得做"的能力。如果"几乎所有领域最终都能被验证"这个判断成立，瓶颈最终不在执行端，而在目标设定端。