AI 范式Karpathy软件 3.0

Karpathy 说他的 App「不应该存在」：一个程序员亲手删掉自己的作品

去年他造了「vibe coding」这个词，被柯林斯词典评为年度词汇。

今年他做了个能用的 App，然后亲口说：「我的整个 App 都是多余的，它不应该存在。」

更反常的是——他说自己作为一个程序员，从未像现在这样觉得自己如此落后。

这话从 Andrej Karpathy 嘴里说出来，分量不一样。OpenAI 联合创始成员、前 Tesla AI 总监、斯坦福 CS231n 的缔造者。2026 年 4 月，他在红杉资本 AI Ascent 的炉边访谈里，用 30 分钟讲清了一件事：软件的地基，在过去半年里被换掉了。

一、转折点：他记不清上次改 bug 是什么时候了

时间要拨回 2025 年 12 月。

在这之前，Karpathy 用 Cursor、Claude Code 这类工具已经一年多了。它们的表现是「有帮助，但常要修补」——生成的代码块不错，但总有那么几处需要你自己动手。

那个 12 月他正好休假，有更多时间折腾 side project。然后事情变了：模型生成的代码块开始「直接能用」。他试着要更多，还是能用。再往后他意识到——自己已经记不清上一次纠正模型输出是什么时候了。

你就这么越来越信任这个系统，然后一不小心，就已经在 vibe coding 了。

—— Andrej Karpathy

他特别强调，很多人对 AI 的印象还停留在「一个类似 ChatGPT 的东西」：你问一句，它答一句。但他让所有人重新看一眼，而且要看 12 月之后的版本。

真正质变的不是「模型更聪明了」，而是 agentic coherent workflow——模型能连续规划、写代码、调试、执行、再根据环境反馈继续修正。这是一个持续连贯的工作流，不是一次问答。

它带来一个听起来很残酷的结论：过去程序员比的是能写多少代码、记住多少 API、怎么调试；现在比的是，你能不能正确地指挥一组强大但会犯错的智能体。

二、软件 3.0：安装一个工具，就是复制一段话

Karpathy 有一套他讲了多年的软件分期。这次他讲得最直白：

最直观的例子，是 Claude Code 的安装方式。

按老习惯，安装一个命令行工具，你会期待一个 shell 脚本。但 shell 脚本要适配各种平台、各种机器，会越写越膨胀，最后复杂到没人敢动。

而 Claude Code 的实际安装方式是：复制一段文本，交给你的智能体。

智能体自己读取你的机器环境、执行步骤、遇到报错就调试。

现在的问题变成了：哪一段文字，应该复制给你的智能体？这就是新的编程范式。

这句话的重点不是「程序员以后只写提示词」。Karpathy 的意思是——程序的边界变大了。过去的「程序」是一个代码文件；现在的「程序」可能是一段说明、一个上下文窗口、一组工具权限、一个测试环境，加上模型内部已经学到的大量统计结构。

三、最扎心的一段：他亲手做出来的 App，被他判了死刑

Karpathy 讲了自己的一个项目：MenuGen。

想法很朴素——在餐厅拿到菜单，一堆菜名看不懂，尤其是陌生菜系。他想做个应用：拍一张菜单照片，识别菜名，为每道菜生成一张大致图片，再重新渲染成「带图的菜单」。

用传统方式做，这条路很长：上传照片 → OCR 识别文字 → 抽出菜名 → 调图像生成器 → 重新排版 → 部署上线。他确实用 vibe coding 把这个 App 做出来了，能跑。

然后他看到了另一种做法：

直接把菜单照片丢给 Gemini，说一句「让 Nano Banana 把这些菜品图叠加回菜单上」。

模型返回的不是结构化数据，也不是一堆组件，而是一张新图片——原菜单还在，每道菜的位置上已经渲染好了配图。

没有 app，没有后端，没有数据库。

我的整个 MenuGen 都是多余的。它还停留在旧范式里。那个 App 不应该存在。

—— Andrej Karpathy

这是整场访谈里最锋利的一个商业判断。

很多 AI 应用团队以为自己在做「更快的软件」——过去一件事要十步，现在压成三步。但在 Software 3.0 里，模型的输入输出可能直接把整条链路吃掉，中间那层应用结构就失去了存在的理由。

真正值得警惕的问题：
你正在做的业务里，有多少环节其实也「不应该存在」？那些过于精细的中间层、复杂的 SOP、手工拼起来的管线——它们可能只是旧范式留下的化石。

Karpathy 说，更让他兴奋的不是把已有的事情做快，而是那些以前根本不可能存在的东西。

比如他的 LLM Knowledge Bases：把文章、文档、事实重新编译成个人或组织的 wiki。传统代码擅长处理结构化数据——表格、数组、字段、明确规则；而 LLM 擅长的是「理解文本之间的关系、重新排序信息、生成新的知识结构」。这类事过去不是程序能干的事。

四、一个荒诞的 bug：它能重构十万行代码，却让你走路去洗车

访谈里最出圈的一段，是「洗车题」。

我要去 50 米外的一家洗车店洗车。我应该开车去，还是走路去？

最先进的模型回答：走路去吧，太近了。

它完全忽略了问题的关键——你要洗的是车，所以车必须得到洗车店。

一个能重构十万行代码、能找到零日漏洞的模型，却告诉我应该走路去洗 50 米外的车。

—— Andrej Karpathy

这就是他说的 锯齿状智能（jagged intelligence）：能力曲线不是平滑上升的，而是有高峰、有断崖。有些任务强得惊人，有些任务弱得荒诞。

为什么会这样？答案在「可验证性」

Karpathy 给了一个非常清晰的框架：

传统计算机容易自动化「你能写进代码的东西」；这一代 LLM 容易自动化「你能验证的东西」。

LLM 不需要你把所有规则写出来，但它需要某种判断输出好坏的方式。数学题能验证答案，代码能跑测试，安全漏洞能复现——这类任务可以被放进强化学习环境：模型尝试解题，系统给奖励或惩罚，模型在大量样本中优化。

前沿实验室正是构造了海量可验证任务，模型才在数学、代码这些领域形成「高峰」。

能力不是自然进化，是有人做了决定

他举了一个极具说服力的细节：从 GPT-3.5 到 GPT-4，模型的国际象棋能力提升非常大。很多人以为这是「能力的自然演进」。

但实际情况是——有人在 OpenAI 决定把大量棋局数据加进了预训练集。数据进了分布，能力就跟着上去了。

一个看起来是「模型变强」的故事，被重新解释成了「实验室做的一个产品决策」。

给使用者的实操结论：
如果你的场景刚好落在训练覆盖的能力回路里，模型会带你起飞；一旦超出这个分布，它会极其吃力。这时你需要认真考虑微调，别指望 LLM 开箱即用。

所以更准确的做法是：主动去探索它的能力边界，搞清楚自己的任务落在「高峰」还是「断崖」旁边。

五、他暗示了一个金矿，然后在台上停住了

主持人问他：如果创业者今天想解决一个可验证的问题，但大厂已经在数学、代码这些最明显的领域加速了，还有机会吗？

Karpathy 没有列赛道，而是给了一套找机会的方法：

可验证性，让一个问题在当前范式下变得「可解」。即便大实验室没有重点投入某个领域，只要你能构造出大量、多样的强化学习环境——让模型尝试、失败、拿奖励——你就有了自己微调并取得优势的路径。

说到这里，他几乎要举一个自己认为很有价值的领域。然后停住了：

我不想直接给出答案……抱歉，我不是有意要在台上发一条含糊的推文。

台下笑了。

但这个停顿本身就是信号：窗口期还没关。

他还补了一句更激进的话——几乎所有事情，最终都可能在某种程度上变得可验证。写作、设计这类看起来主观的任务，也可以设想用一组 LLM judges（模型评审团）做近似评价。

不过要谨慎理解：数学和代码容易，因为答案或测试相对明确；写作、审美、战略判断则要困难得多。这是「程度和难易」的问题，不是「能不能」的问题。

六、Vibe Coding 抬下限，Agentic Engineering 守上限

去年他提出 vibe coding，今年他补上了更严肃的下一步。两者的分工他讲得很清楚：

vibe coding 让不会写代码的人也能做工具，让会写代码的人更快做 side project——软件创造的入口变宽了。

但专业软件有专业软件的底线：不能因为用了 AI 就引入安全漏洞，不能因为模型写得快就降低质量门槛，也不能因为代码是智能体生成的就没人负责。

Vibe Coding 抬高的是所有人能做软件的下限；Agentic Engineering 要保住的是专业软件过去已有的质量门槛。

—— Andrej Karpathy

他把这些智能体称为「spiky entities」——带尖刺的实体。能力很强，但有随机性、会犯错、不稳定。工程的工作不是盲目信任它们，而是把它们放进有规格、有边界、有验证、有回滚的流程里。

他还顺手修正了一个行业迷信：「10x 工程师」——「10x 根本不是你能获得的加速倍数。」真正精通这套方法的人，产出远超 10 倍。

七、智能体会把付款绑到错误的邮箱上

被问到「什么人类技能会变得更值钱」，Karpathy 的答案是：品味、判断、审美、监督，以及规格设计。

他讲了一个 MenuGen 里的真实 bug。

用户用 Google 账号登录，但买积分时走的是 Stripe。两边都带邮箱。智能体在实现购买逻辑时，试图用 Stripe 的邮箱去匹配 Google 的邮箱，把积分归到对应用户身上。

问题在于——一个人完全可以用不同邮箱登录 Google 和付款。用邮箱做跨系统的身份关联，资金就无法归属。

你为什么要用邮箱来交叉关联资金？它们本来就可以是任意的、可以不一样的。这种做法太奇怪了。

—— Andrej Karpathy

这类错误没有语法问题，代码能跑，测试可能还过——但系统设计是错的。智能体没有真正理解身份、支付与资金归属之间的风险。

正确做法是用系统内部稳定的 persistent user ID 绑定身份和支付记录。而这类决策，必须由人来定。

他还举了一个更技术的例子。他现在已经不再记 PyTorch、NumPy、pandas 之间那些琐碎的 API 差异——keepdims 还是 keepdim，dim 还是 axis，reshape、permute、transpose 分别怎么用。这些交给「实习生」就行，它们记忆力极好。

但他强调，人必须理解底层机制：张量是什么，view 和 storage 是什么关系，什么时候只是改同一块内存的视图，什么时候会真的复制数据。不懂这些，就会放任模型写出低效甚至错误的代码。

一句话总结这一段：
细节可以外包，理解不能外包。API 名字可以忘，概念结构不能丢。

八、代码能跑，但「很丑」——这一点 AI 还没学会

主持人追问：那品味和判断力，会不会随着模型进步越来越不重要？

Karpathy 没把话说死。他认为没有什么根本性障碍阻止模型变好，只是实验室还没做到——很可能是因为还没有足够好的「美学奖励」进入强化学习回路。

他看模型生成的代码时，有时会「心脏病发作」。代码能跑，但很臃肿、大量复制粘贴、抽象别扭、结构脆弱。

最典型的是他尝试把 LLM 训练代码简化到极致的那件事：他不断地让模型「再简化一点」，模型就是做不到。

你能感觉到你完全在强化学习回路之外。就像在拔牙。

—— Andrej Karpathy

模型擅长生成「常见的工程形态」，却不擅长克制、优雅的抽象压缩。人目前仍然是这方面的主导者。

九、我们不是在造动物，我们是在召唤幽灵

Karpathy 写过一篇文章，核心比喻是「动物与幽灵」。他写这篇是因为——他也在试图理解这些东西到底是什么。

动物智能来自进化、身体、环境互动、内在动机、好奇心、持续学习。动物会被后果塑造。

LLM 完全不是这样。它来自海量人类文档的统计结构，再叠加强化学习、偏好数据和工具调用。它是由人类文档与奖励函数塑造出的模拟实体。

这个框架的实用落点其实非常朴素：不要把它当动物。

你对它大喊大叫，不会让它因为害怕而更努力；你鼓励它，也不是在激发它的内在动机。它的行为来自统计模拟、上下文、工具和奖励机制。

如果你对它大吼，它不会因此工作得更好或更差，毫无影响。

—— Andrej Karpathy

所以，不要笼统地问「AI 聪不聪明」。要问的是：它在哪些训练分布里强？哪些奖励信号塑造了它？哪些任务上可能踩到断崖？

十、最后一块拼图：一切都要为智能体重写

被问到「当智能体有了权限、有了本地上下文、能代表你行动，世界会变成什么样」时，Karpathy 的回答是：几乎一切都要重写。

他最大的抱怨特别真实——今天几乎所有的文档，都还是写给人看的：去某个 URL，点某个设置，复制某个 key，打开某个菜单，配置某个 DNS。

他的反应是：为什么还有人在告诉我该怎么做？我什么都不想做。我想知道的是，哪一段东西可以复制给我的智能体。

这不是懒，而是范式在变。Agent-first 基础设施的目标，是把世界拆成「智能体能读懂的输入」和「智能体能安全调用的动作接口」。不是让智能体去模拟人点网页，而是让它直接理解状态、调用动作、收到反馈。

他又回到 MenuGen：这个项目最麻烦的部分其实不是写代码，而是部署——在 Vercel 上连服务、进各种设置页、配 DNS、把所有东西串起来。

他希望未来的验收标准是：给 LLM 一句 Build MenuGen，它不仅能写代码，还能完成部署、上线到互联网、配好依赖服务，全程不需要人去一个个菜单里点。

再远一点，他设想每个人、每个组织都可能拥有自己的智能体代表。以后安排会议、协调事项，可能变成「我的智能体和你的智能体去谈」。

十一、「你可以外包思考，但不能外包理解」

主持人最后问他：当智能变得便宜，什么仍然值得深入学习？

他引用了一句话作为整场的收束：

你可以外包你的思考，但不能外包你的理解。

You can outsource your thinking, but you can't outsource your understanding.

这句话很容易被写成励志格言，但 Karpathy 的解释非常具体。

他仍然必须是系统的一部分。信息必须进到他的脑子里。他感觉自己正在变成瓶颈——他要知道到底在建什么、为什么值得做、怎样指导自己的智能体。

思考可以让模型跑很多遍。但如果人没有理解，就无法判断哪条路线是对的，无法写出好的规格，也无法发现智能体在身份绑定、系统结构、代码质量上的那些错误。

这也解释了为什么他喜欢做 LLM Knowledge Bases：把资料重新投影成 wiki，用不同的组织方式帮自己获得洞见。这不是让 AI 代替理解，而是用 AI 增强理解。

把前面所有例子串起来看：

· 智能体可以记 API 细节，但人要理解张量、视图和内存效率；
· 智能体可以写支付逻辑，但人要理解用户身份和资金归属；
· 智能体可以生成大量代码，但人要判断抽象是否臃肿、结构是否脆弱；
· 智能体可以帮你思考很多方案，但人要知道目标是否值得做。

写在最后：三个值得盯住的信号

这场访谈里有一个耐人寻味的张力：他一边说智能体写的代码丑得让他心脏病发作，一边说自己已经停止修改了。

能跑的代码和好代码，不是一回事。但「用着丑的、但用着」——这可能比任何 hype 都更接近当下真实的开发状态。

另一个问号藏在最后。他说品味和判断暂时不可替代，原因只是「实验室还没做」。如果这个判断成立，那么所谓「人类不可替代的部分」，不是因为人类独一无二，而是因为训练方法还没到位。

所以未来 6 到 12 个月，他给了三个值得盯住的信号：

工具会变，模型会变，范式会变。

但「你想做什么」「为什么这件事值得做」「下一步往哪走」——这些问题的答案，始终在你自己脑子里。

别把它们也外包出去。

内容来源
本文基于 Andrej Karpathy 在红杉资本「AI Ascent 2026」现场与合伙人 Stephanie Zhan 的炉边对谈（约 30 分钟）整理改写。时间线背景：Karpathy 于 2026 年 5 月 19 日宣布加入 Anthropic 预训练团队。中文表述参考了 baoyu.io、华尔街见闻等译本，并与英文文字稿交叉核对；个别专有名词在各译本间存在差异，涉及具体项目名与数字请以原始视频为准。