Karpathy Sequoia AI Ascent 2026
Andrej Karpathy 2026 年 4 月在 Sequoia Capital 的 AI Ascent 现场接受 Stephanie Zhan 的访谈。约 30 分钟的对谈是他 2025 年 2 月提出 Vibe Coding 概念后第一次在公开场合系统性给出"下一步是什么"的答案。访谈视频：https://www.youtube.com/watch?v=96jN2OCOfLs
转折点：2025 年 12 月
Karpathy 把 2025 年 12 月标为个人编程方式的转折点。最新模型生成的代码从「有帮助但常要修补」变成「直接可用」。他记不清上次纠正模型代码是什么时候。他用 Vibe Coding 命名这种状态——人用自然语言持续提出意图，模型生成、修改、调试代码，人不再逐行写或读 diff。
但他强调，访谈的重点不再是 Vibe Coding，而是 Agentic coherent workflow。模型不只是回答问题，而是连续规划、写代码、调试、执行、根据环境反馈持续修正。
Software 3.0：编程边界扩大
Karpathy 把软件分为三期：
- Software 1.0：人写显式代码
- Software 2.0：人设计数据集 + 目标函数 + 网络架构，训练得到模型权重
- Software 3.0：人通过 prompt + context window + 工具调用 + 外部环境，组织一段给 LLM 执行的「上下文程序」
Karpathy 用 OpenClaw 安装为例：传统做法是写一个 bash script 兼容各种平台，最后会膨胀到不可维护。OpenClaw 的做法是给一段说明文本——「复制这段，丢给你的 AI agent」。Agent 自带智能，会读取环境、调试、循环跑通。
现在的问题变成：哪一段文字应该复制给你的 Agent？这就是新的编程范式。
这与 Prompts replacing download buttons 同方向：程序边界从代码文件扩大到一段说明、一个上下文窗口、一组工具权限、一个测试环境。
MenuGen：「这个 App 不应该存在」
Karpathy 用 MenuGen（拍菜单 → 识别 → 生成菜品图 → 重新排版）展示了 应用被模型原生能力直接吞掉 的判断。
旧范式做法：上传照片 → OCR → 抽菜名 → 调用图像生成器 → 重新排版 → Vercel 部署。Karpathy 用 Vibe Coding 实现了。
Software 3.0 版本：直接把菜单照片交给 Gemini，让 Nano Banana 把菜品图叠加回菜单上。Nano Banana 返回的不是结构化数据，而是一张新的图片——原菜单仍在，菜品已经渲染进去。
我的整个 MenuGen 都是多余的。它还停留在旧范式里。那个 App 不应该存在。
判断含义：很多 AI 应用以为自己在做「更快的软件」（10 步压成 3 步）。但模型的输入输出可能直接覆盖整个任务，中间 App 的结构就失去必要性。「以前根本不可能存在的东西」比「把已有东西做得更快」更值得做。
Jagged Intelligence：能重构 10 万行代码却让你走路去洗车
Karpathy 用「锯齿状智能」描述 LLM 能力曲线——不平滑上升，而是有高峰和断崖。经典反例：
一个最先进的模型可以重构 10 万行代码、找到零日漏洞，却告诉我应该走路去洗 50 米外的车。
完整推理见 Model Spikiness。
根本原因：能力分布取决于实验室的数据决策。GPT-3.5 → GPT-4 国际象棋能力大幅提升，不是「模型变聪明」，而是 OpenAI 决定加了大量国际象棋数据。可验证（数学、代码、安全漏洞）的领域容易构造 RL 奖励信号，能力会飙升；不可验证的领域，能力可能很弱。
创业含义：去造你自己的 RL 环境
别追大模型逃逸速度，去造你自己的 RL 环境！
只要任务可验证，只要你能构建对应的 RL 环境或足够多的示例，就有机会自己做 fine-tuning 吃到红利。几乎所有事情最终都能在某种程度上变得可验证——写作、设计这类主观任务也可以用一组 LLM judges 形成近似评价。Karpathy 自己 Eureka Labs 做的 AI 教育就是这种领域。他在台上明显有判断却不愿透露具体方向：「我不是有意在台上发含糊推文的。」
Vibe Coding 抬下限，Agentic Engineering 保上限
| 维度 | Vibe Coding | Agentic Engineering |
|---|---|---|
| 目的 | 抬高所有人做软件的下限 | 保住专业软件的质量上限 |
| 用户 | 不会写代码的人 + 想快速做 side project 的工程师 | 专业软件工程师 |
| 风险 | 软件能跑但可能不安全 | 不能因为用 AI 就引入漏洞、降低质量 |
| 能力 | 自然语言提需求 | 设计、协调、监督 Agent |
Agent 是「spiky entities」——能力强但会犯错、有随机性、不稳定。工程师不是盲目信任，而是把它们放进合适的流程里：生成方案、写代码、跑测试、互相检查、留有边界、验证、回滚。详见 DHH Agentic Engineering。
10x 已是常态，真正的 Agentic 工程师是 100x
10x 不是你获得的加速倍数。
软件行业过去说「10x engineer」效率超普通人 10 倍。Agentic Engineering 里能力被进一步放大几十到一百倍。真正熟练的人能把多个 Agent、工具、测试和上下文组织起来。
Spec 是不能外包的
Karpathy 反对所谓「plan mode」，主张人必须负责 specification。Agent 是执行主体，但系统设计、规范定义、质量约束是人不可外包的责任。
你得和 Agent 一起把一份非常细的 spec 设计出来，某种程度上它甚至应该接近完整文档，然后让 Agent 去填充实现；你自己负责的是顶层监督和大类结构，而 Agent 负责底层执行。
具体例子：MenuGen 中 Agent 试图用 Stripe 邮箱去匹配 Google 邮箱来归属购买的 credits。代码能跑、测试可能过，但系统设计是错的——人完全可能用一个邮箱登录 Google、用另一个邮箱付款。正确做法是用系统内部稳定的 persistent user ID。Agent 没有真正理解身份、支付和资金归属的风险。这种错误必须靠人写 spec 来约束。
AI-native 工程师的画像
不是会刷算法题，而是会做大项目并保证安全。Karpathy 提出的面试方式：
甩给候选人一个极大的项目，比如做个给 Agent 用的 Twitter 仿盘，要求做得绝对安全。然后挂上 10 个 Cursor 当作"红队"，放开手脚去攻击你做出来的这个网站。
考察的是：把模糊目标变成清晰规格、指挥 Agent 完成大规模实现、识别安全和架构风险、设置测试与验证、在模型生成的大量代码里保持质量判断、让最终系统经得起外部攻击。
动物 vs 幽灵：使用 LLM 的心智模型
Karpathy 反复强调，LLM 不是动物式智能：
- 动物智能 = 进化 + 身体 + 环境互动 + 内在动机 + 持续学习
- LLM 智能 = 大规模预训练（人类文档统计结构）+ RL + 偏好数据 + 工具调用
操作含义：不要对 LLM 大喊大叫（它不会因害怕而更努力），不要鼓励它（不是在激发内在动机）。它的行为来自统计模拟、上下文、工具、训练数据和奖励机制。如果不懂这点，就会笼统问「AI 聪不聪明」，而不是问「在哪些训练分布里强、哪些奖励信号塑造了它、哪些任务可能出现锯齿状断崖」。
Agent-first Infrastructure
为什么还有人在告诉我该做什么？我什么都不想做。"给我复制粘贴给 Agent 的东西是什么？"
整个工具链、文档、API、权限、日志、部署、配置、账单、回滚都需要重写为 agent-native：把世界拆成 Agent 能读懂的输入 + 能安全调用的动作接口。这是 AI 搜索可见性 和 Agentic Infrastructure 主题的源头判断。
Karpathy 设想测试标准是「给 LLM 一句 Build MenuGen，它能写代码、部署、上线、配置依赖，整个过程不要人去菜单里点」。
智能变便宜后，最贵的是理解
你可以外包你的思考，但不能外包你的理解。
Karpathy 仍是系统的一部分。信息必须进入他的脑子。他觉得自己正在变成瓶颈——要知道在建什么、为什么值得做、怎样指导 Agent。
具体翻译：
- Agent 可以记 PyTorch / NumPy 的 keepdims、dim、reshape API 差异，人要理解 tensor、view、storage 和内存效率
- Agent 可以写支付逻辑，人要理解用户身份和资金归属
- Agent 可以生成大量代码，人要判断抽象是否臃肿、结构是否脆弱
- Agent 可以帮你思考方案，人要知道目标是否值得做
智能变便宜之后，学习不是不重要了，而是学习的重心变了：更少时间在机械记忆和低层执行上，更多时间在系统理解、问题定义、质量判断、因果关系和领域直觉上。
三个值得盯的信号
未来 6-12 个月：
- 前沿实验室在编程/数学之外，往哪些领域注入 RL 数据——那里的能力会突然冒出来
- Agent-first 基础设施（部署、auth、payments）会不会有第一波收敛——MenuGen 部署的痛苦如果还在，「自动化社会」的路就长得多
- 模型的下一代更新是否包含审美和代码质量相关的 RL 目标
隐含张力
第一，他一边说 Agent 写的代码丑得让他心脏病发作，一边说自己已经停止修改了。能跑的代码和好代码不是一回事。
第二，他暗示有「被低估的 RL 机会」领域却不愿公开。一个不愿在台上发含糊推文的人主动回避，本身是信号：窗口期还没关。
第三，他给「动物 vs 幽灵」框架降级，又用「你可以外包思考但不能外包理解」收束。如果「几乎所有领域最终都能被验证」成立，那么瓶颈最终在目标设定端，不在执行端。但这句话的有效期取决于实验室是否把审美和判断纳入 RL 训练目标——如果做了，那么「人类不可替代」的部分会进一步收缩。
Related
- claude-code/karpathy-nopriors-qa — 早期 No Priors 播客 Q&A
- harness-engineering/lou-tiancheng-harness — 楼天城同期判断
- harness-engineering/model-spikiness — Jagged intelligence 详解
- product-trends/vibe-coding-market-dynamics — Vibe Coding 商业天花板
- harness-engineering/dhh-agentic-engineering — Agentic Engineering 实践
- harness-engineering/agentic-infrastructure
- product-trends/saas-extinction