红杉资本 AI Ascent 2026 上 Karpathy 与合伙人的对谈 From Vibe Coding to Agentic Engineering 开场让人意外——这位写了十几年代码、把 Tesla Autopilot 和 OpenAI 都推上轨道的人，说自己”从未像现在这样感到落后”。
他把转折点定在 2025 年 12 月。在那之前一年多，他用 Cursor 的体验和大多数人差不多——能生成代码但经常要回头修，所以始终当辅助。12 月放假期间他多用了几天最新一代模型，发现生成的代码块直接能用，记不清上一次手动改输出是什么时候。从此他越来越信任系统，进入自己后来命名的氛围编程（vibe coding）状态，副业项目文件夹塞满了随手写的实验。
软件 3.0 让编程对象再次位移
软件 1.0 是手写显式规则——人把逻辑拆成一行行代码，机器执行。软件 2.0 是训练神经网络权重——编程对象从代码变成数据集、目标函数、网络架构，代码退居辅助工具，他在 Tesla 的自动驾驶训练就是典型。软件 3.0 是 GPT 这类模型在足够大任务集上训练后，本身变成一台可编程的通用计算机。提示词是新的编程语言，上下文窗口是操控这台解释器的杠杆。模型不再是更聪明的工具，而是新的计算基底。
大量应用本不该存在
OpenClaw（开源个人 AI 助手框架）的安装方式直接抛弃了 shell 脚本。跨平台安装脚本要兼容 Windows / macOS / Linux 各种环境，越写越臃肿；OpenClaw 的官方做法是给一段文字让你复制粘贴给 agent，由 agent 自己读环境、装依赖、闭环调试。Karpathy 把它当软件 3.0 的范式标本——重点不是精确写出每一步，而是找到”该粘贴给 agent 的那段文字”。
更极端的是他自己写的 MenuGen。最初版本是个完整 Web 应用——上传餐厅菜单照片，OCR 识别菜名，调图像生成器配图，再重渲染整张菜单，部署在 Vercel。后来他发现 Gemini 加 Nano Banana 一条提示词就能做到同样效果——直接把照片交给模型，让它在像素层面把菜品图覆盖到原菜单上。Karpathy 原话是”我整个 MenuGen 是 spurious 的，那个 app 本来就不该存在”。AI 不只是现有工作流的加速器，更要追问：哪些被认为必要的代码、应用、系统，在新范式下根本是冗余。
锯齿状能力来自可验证性
软件 3.0 的能力分布极不均匀——有些领域远超人类专家，有些却荒诞到失控。Karpathy 的解释只有一条：可验证性（verifiability）。
传统计算机自动化你能精确定义的事，大语言模型自动化你能验证的事。前沿实验室用庞大的强化学习环境训模型，能通过验证就拿到奖励。代码、数学、形式逻辑这类高可验证领域反馈闭环清晰，砸的算力最多，能力堆得最高。验证机制模糊的领域——常识、生活决策、审美判断——补丁就稀薄。两个荒诞反例：早期模型连 strawberry 里有几个 r 都数不清；现在能重构十万行代码、能挖掘安全漏洞的顶级模型，被问到去 50 米外的洗车店该开车还是走路，会推荐走路——完全没意识到洗车就是把车开过去。
对创业者的操作启示直接：即使前沿实验室没盯你的领域，只要身处可验证性强的细分行业，可以自己搭强化学习环境、做样本和评测，给基础模型微调出专属版本——可验证就能建反馈闭环，闭环建好就能用算力把模型质量推上去。
智能体工程取代氛围编程
去年他造了”氛围编程”这个词，让不会写代码的普通人也能用自然语言搭出能跑的东西，抬高了人人能做软件的下限。但氛围编程的产物在严肃生产环境里站不住——漏洞、性能问题、混乱的抽象都是常态。所以他抛出新概念：智能体工程（agentic engineering）。它不是氛围编程的升级版，而是上面一层——保持专业软件的质量、架构、逻辑自洽，再追求极致效率，守住质量的上限。
智能体工程的日常长什么样？开发者 99% 的时间不再直接写代码，而是统筹智能体、监督它们、把控全局。智能体是能力参差但极强的 AI 实习生，能填代码、调 API、写文档、debug，但顶层规格、架构选择、质量把关只能人来做。由此推出一个更狠的判断：所谓 10 倍工程师概念会被彻底改写。真正驾驭智能体工程的开发者远超任何明星工程师，一个人就能扛起一支中小型团队的吞吐。
他顺手怼了当下的招聘流程——还在让候选人手写算法、刷 LeetCode 小题，完全是旧范式。新面试方法很直白：扔一个真实大项目给候选人，比如给智能体搭一个高安全的 Twitter 克隆版，让另一批智能体模拟用户活动，再用十个 codex 5.4x 之类的高强度模型轮番攻击；候选人要让系统在攻击下不被攻破。考的是统筹、系统设计、质量把关，不是知识点。
守住规格、品位与理解
智能体工程把人推到哪一层？MenuGen 里有一个真实 bug：agent 设计支付时用 Stripe 邮箱对应 Google 邮箱，没有持久 user ID——但用户完全可以在两个平台填不同邮箱，资金就会丢失关联。这是 agent 在系统层面的典型错误：局部细节做对，看不到”必须有唯一主键”这种顶层判断。人就守在这种规格上——必须用 unique user ID 关联所有数据。
他自己的工作模式是把 PyTorch 和 NumPy 之间的 API 细节（keep_dims 还是 keepdim、dim 还是 axis、reshape / permute / transpose）全交给 agent，它们 recall 极强；但底层原理——tensor 有 underlying view、不同 view 共享 storage 还是另起 storage 影响内存效率——必须自己懂，否则没法判断 agent 写的代码是不是在做不必要的拷贝。
他引了一条让自己反复琢磨的推文：“你可以外包你的思考，但是不能外包你的理解。“他自己仍然是整个系统的瓶颈，因为信息得进自己脑子，才知道在做什么、为什么值得做、怎么指挥 agent。智能廉价的时代，理解力才是稀缺品。
他还做了个隐喻校准：LLM 是幽灵，不是动物。它没有进化出的内在驱动、好奇心、情感，对它发火不会让它表现更好或更差；它是统计模拟回路，预训练是基底，强化学习是补丁。把它当动物期待就会用错；当被召唤出来的统计实体看，反而能更准判断它何时靠谱、何时不靠谱。
智能体原生的世界
Karpathy 最后一个观察：现有基础设施——文档、UI、部署流程——都是为人写的。他最讨厌看到框架文档来一句”打开这个 URL 然后点……”——他的反应是”我不想做任何事，你告诉我该粘贴什么给我的 agent 就行”。智能体原生（agent-native）的判定很简单：能不能给一句”build menugen”，剩下的部署、DNS、服务串联全由 agent 完成。 MenuGen 当年最痛苦的不是写代码，是在 Vercel 上点各种菜单、配 DNS、串各种服务——智能体原生世界里这些都该消失。
把现有工作做快只是新范式最浅层的收益；真正值得投入的，是去找在旧范式下根本不可能存在的新机会。前提是把理解力守住。