Karpathy：从 Vibe Coding 到 Agentic Engineering，那个转折点发生在 2025 年 12 月
Andrej Karpathy 在红杉资本 AI Ascent 2026 的 29 分钟演讲中，系统阐释了 Software 3.0 范式、可验证性框架与 Agentic Engineering 工程纪律，并以真实 bug 案例说明 AI 时代里「品味与判断力」为何比 API 调用能力更关键。
리서치 브리프
2025 年 12 月，Andrej Karpathy 正在放假。他打开了最新的 AI 代理工具，开始写代码——然后发现自己已经不用纠错了。模型生成了一段，他要更多，模型给了，还是对的。再要更多，还是对。他想不起上一次手动改代码是什么时候。
「我从未感觉作为程序员落后得更多。」（"I've never felt more behind as a programmer."）这句话出自他一年前在 X（原 Twitter） 上发布的感慨，但直到在红杉资本 AI Ascent 2026 的舞台上，他才把它展开成了一套完整的分析框架。
这次演讲于 2026 年 4 月 29 日发布在 Sequoia Capital YouTube 频道1，29 分 49 秒，至今播放量已超 42 万次，是本届 AI Ascent 系列中互动最高的单条视频。
讲者是谁
Andrej Karpathy 的履历不需要过多介绍，但有几个节点值得在这里点一下，因为它们直接决定了他说的话有多少份量。
他是 OpenAI 的联合创始人之一，在早期主导了研究方向的建立。后来转去 Tesla，从零搭起了 Autopilot 的全栈 AI 系统，把端到端神经网络推进到量产自动驾驶的实际部署。再后来回到 OpenAI，主持 GPT-4 的训练工作。2023 年离职后，他创办了 Eureka Labs，专注于 AI 原生的教育产品。
他在 YouTube 上讲的《Neural Networks: Zero to Hero》系列课程，很多人的 LLM 入门就是从那里开始的。「Vibe coding」这个词，是他 2025 年初在 X 上随手发的一条帖子，没想到被整个行业沿用至今。
这次在 Sequoia 舞台上，他和合伙人 Stephanie Zhan 对谈，聊的是：从他造出那个词之后，这一年里他的认知发生了什么变化1。
内容大纲（带时间戳）
| 时间 | 话题 |
|---|---|
00:00 | 开场介绍 |
00:44 | 「我从未感觉落后得更多」——12 月的转折点 |
02:28 | Software 3.0 是什么：从显式规则到提示词 |
03:44 | 代理作为「安装器」——OpenClaw 案例 |
04:49 | MenuGen vs 原始提示词：旧范式的失效 |
07:37 | 2026 年回看会显而易见、但现在还没人做的事 |
09:41 | 可验证性（Verifiability）框架与「锯齿状智能」 |
13:39 | 给创始人的建议：找可验证的 RL 环境 |
15:46 | Vibe Coding 与 Agentic Engineering 的本质区别 |
25:17 | 代理原生基础设施与学习的意义 |
三条金句
金句一：
[00:44] 关于 12 月的转折"I just started to notice that with the latest models the chunks just came out fine and then I kept asking for more and it just came out fine… I can't remember the last time I corrected it."——「我注意到，最新的模型生成的代码块直接就是对的，我继续要更多，还是对的……我想不起上次纠错是什么时候了。」
这是整段演讲的核心情绪。Karpathy 不是在预测未来，他是在描述一个已经发生的事实：2025 年 12 月，代理编程的质量越过了某个临界点，工程师的工作模式需要重新定义1。
金句二：
[25:17] 关于思考的外包"You can outsource your thinking but you can't outsource your understanding."——「你可以把思考外包，但无法外包理解。」
他提到这是最近看到的一条推文，读完之后隔几天就要想一次。它划定了 AI 时代里人类真正在做的事——不是执行，而是理解：知道要建什么、为什么建，以及如何判断 AI 交给你的东西够不够好1。
金句三：
[15:46] 关于 Agentic Engineering 的定义"Vibe coding is about raising the floor for everyone… Agentic engineering is about preserving the quality bar of what existed before in professional software. You're not allowed to introduce vulnerabilities due to vibe coding."——「Vibe coding 是为所有人提高下限……Agentic Engineering 是在此基础上维持专业软件原有的质量标准。你不能因为用了 vibe coding 就引入漏洞。」
这句话对工程团队的管理者来说可能是最有操作价值的：Karpathy 明确区分了两种使用 AI 编程的模式，后者不是前者的自然延伸，而是需要主动建立的工程纪律1。
核心论点解读
Software 3.0：编程范式的第三次转变
Karpathy 在演讲中系统阐释了他的「三代软件」框架1：
- Software 1.0：程序员显式写规则，代码是人类的思想转译为机器语言
- Software 2.0：数据集和神经网络权重取代手写规则，程序员的工作变成「安排数据集和目标函数」
- Software 3.0：LLM 本身成为可编程的「解释器」，提示词和上下文窗口是新的编程语言
他用 OpenClaw（一个 AI 开发工具）的安装方式举例：传统安装是运行一个 shell 脚本，要针对不同平台写出极其复杂的分支逻辑；而 OpenClaw 的「安装」是一段文字，复制粘贴给代理，让代理自己看懂你的环境、自己调试、自己完成。「你不需要精确拼写出每一个细节，代理有自己的智能，它会弄清楚的」——这种描述上的粗放，在旧范式里是缺陷，在 Software 3.0 里是设计原则。
这对产品和工程决策有直接含义。如果你还在问「怎么把 AI 加进我的产品」，你可能已经在用 Software 1.0 的思维框架看待 Software 3.0 的世界——把 LLM 当成一个更聪明的 API，而不是一个可编程的推理环境。
可验证性决定 AI 能力的天花板
这是演讲里技术密度最高的部分。Karpathy 提出了一个解释 LLM 「锯齿状能力」（jagged intelligence）的框架：AI 在可验证的领域飞速提升，在无法验证的领域停滞不前1。
原因在于训练机制：前沿实验室用强化学习（RL）训练模型时，需要「验证奖励」——也就是说，模型必须能被自动评分，才能在那个领域持续迭代。数学和代码是完美的 RL 环境，答案对或错是客观的，所以模型在这两个领域进步最快。相比之下，「这段文字写得好不好」「这个决策明不明智」，很难设计出稳定的自动评分机制，模型的进步也就相对迟缓。
他用了一个让现场大笑的例子：「最前沿的模型能重构 10 万行代码库，能找出零日漏洞，但你问它'距离 50 米的洗车房，我应该开车去还是走路'，它会建议你走过去——因为近。这根本不正常。」1
这对创始人有直接的选题建议：如果你在找一个可以用 AI 深度改造的领域，先问自己：「这个领域的好坏能不能被自动验证？」能，就值得投入大量 RL；不能，就要格外小心，不要被演示效果迷惑。
Agentic Engineering：一个工程纪律问题，不是工具问题
Karpathy 给了一个他 MenuGen 项目里实际发生的 bug 案例：他的代理在处理用户账户时，试图用 Stripe 的邮箱地址和 Google 登录的邮箱地址做匹配——两个邮箱完全可以不同，结果导致充值记录无法归属到正确用户。
代理没有写出语法错误，它做出了一个「逻辑上说得通、但现实里根本不对」的设计判断1。这种错误不触发任何 linter，不报任何异常，只是静悄悄地让一部分用户的充值消失。code review 也很难抓到，因为代码逻辑本身是通的。
Karpathy 的结论是：人类在 Agentic Engineering 里的核心职责，是「品味、判断力、顶层设计」。你不再需要记住 PyTorch 里是
dim 还是 axis，代理帮你记；但你必须知道底层张量有没有被不必要地复制、架构上有没有潜在的内存问题——因为代理不会主动提醒你这种「不影响运行、但影响质量」的细节。对管理者来说，这意味着评估工程师的标准需要更新。Karpathy 提出了一个他认为更合理的面试场景：给候选人一个大型项目（比如「做一个 Twitter 克隆」），让他们用代理完成，然后用 10 个自动化攻击代理去尝试打穿这个系统。看谁能在规模和安全之间把握住那条线1。
LLM 是「幽灵」，不是动物
最后一个话题看起来像是在哲学层面转了个弯，但 Karpathy 认为它有很直接的实践含义：为什么他用「幽灵」（ghost）而不是「动物」（animal）来描述 LLM1。
动物是进化出来的——有内在动机、本能反应、情绪驱动，你冲它大喊，它会有反应。但 LLM 不是。它的「基底」是预训练时的统计特征，RL 只是在上面叠加了一些「突起」（appendages）。对它大喊，没用；夸它，也没用。它没有情绪，没有好奇心，没有天生的驱动力。
对使用者来说，这意味着「信任」和「不信任」都是错误的框架——它没有动机去配合你，也没有动机来对抗你，它就是在跑统计电路。你需要做的，是系统性地搞清楚它在哪些「电路」里跑得好，哪些电路里根本不在行。在它擅长的领域，速度远超人类；出了那个边界，它会静悄悄地犯下荒唐错误，完全不提醒你——因为它不知道自己出界了。
值不值得看完？
取决于你的角色：
工程师：强烈建议。
00:44 到 25:17 几乎每一段都有可以直接拿来调整工作方式的具体建议。他对代理 bug 的案例分析（MenuGen 账号匹配问题、代码风格问题）非常接地气，不是空谈。产品/创业方向：值得看。
09:41 的可验证性框架是选题的实用工具，07:37 关于「2026 年回看显而易见」的讨论虽然 Karpathy 故意没给出完整答案，但思路本身值得借用。管理者：至少看
15:46 之后的部分。他对「如何评估 Agentic Engineering 能力」的讨论，比大多数招聘框架更务实。
이 콘텐츠를 둘러싼 관점이나 맥락을 계속 보강해 보세요.