有什么东西悄悄变了——卡帕西的那场红杉对谈

📈 趋势 · 2026-05-02

[ 卡帕西在红杉AI Ascent 2026现场 ]

一个让我停下来的数字

2025年11月，Karpathy写了80%的代码，AI写了20%。

如今，这个比例倒过来了。

“Coding agents basically didn’t work before December and basically work since.”— Andrej Karpathy，红杉AI Ascent 2026

我第一次看到这句话的时候，愣了一下。不是因为这个数字有多惊人——80/20这个比例，Greg Brockman在OpenAI也说过类似的话。让我停下来的是”basically”这个词用了两次。一个在AI领域工作了十几年的人，用”基本上不能用”和”基本上能用了”来描述一个月内发生的变化——这不是在夸大，这是在说一件真实发生的事情。

Karpathy把这种状态叫做”AI psychosis”（AI精神错乱）——他说自己从12月开始就一直处于这种状态，试图搞清楚这个新的工作方式到底意味着什么。

这就是他在红杉那场对谈的起点。

软件的三次进化，以及我们现在在哪里

要理解Karpathy在说什么，需要先接受他的一个框架。他把软件的历史分成三个时代：

↑ 简单说：软件从”人写规则”→”人整理数据”→”人说意图”，每一步都在把更多的执行权交给机器。

这个框架本身不新鲜——Karpathy几年前就提出过Software 2.0的概念。但他在红杉这次说的是：Software 3.0正在吃掉1.0和2.0。

不是取代，是吃掉。

[ Software 1.0 / 2.0 / 3.0 三个时代的对比图 ]

“vibe coding”已经过时了

2025年2月，Karpathy造了一个词：vibe coding。

意思是：你不需要懂代码，你只需要描述你想要什么，让AI去实现。”完全沉浸在氛围里，拥抱指数级增长，假装代码根本不存在。”

这个词火了。它描述了一种真实存在的现象——大量非技术背景的人开始用AI工具搭应用，速度快得惊人。

但在红杉的对谈里，Karpathy说：vibe coding已经过时了。

不是说它不好用，而是说它只解决了一半的问题。

Vibe coding提高了地板——让不懂技术的人也能快速搭出一个原型。

但它没有提高天花板——用vibe coding搭出来的东西，往往有安全漏洞、架构脆弱、代码臃肿易碎。Karpathy自己说，AI写的代码”awkward and gross”（别扭又难看）。

他给下一个阶段起了个新名字：agentic engineering（智能体工程）。

Agentic engineering是什么

如果vibe coding是”我说你做”，那agentic engineering是”我指挥，你执行，我验证”。

Karpathy提出了一个关键洞见：

AI自动化的是你能验证的东西，而不是你能描述的东西。

这句话值得停下来想一想。

代码可以验证——跑一下，看有没有报错，看测试有没有通过。数学证明可以验证——对就是对，错就是错。但”这个设计方案好不好”、”这个产品方向对不对”——这些很难验证，所以AI在这些地方表现得很差。

这就是他说的”jagged intelligence”（锯齿状智能）——AI在某些领域超过人类，在另一些领域连基本常识都搞不定。不是均匀的强，是凹凸不平的强。

所以agentic engineering的核心技能，不再是写代码，而是：

① 任务分解：把一个大任务拆成Agent能处理的小块② 规格定义：在委托给Agent之前，把验收标准写清楚③ 输出评估：用合适的严格程度审查Agent的输出④ 失败分类：判断一个错误是可以修复的，还是根本性的⑤ 接管时机：知道什么时候该把控制权拿回来

[ vibe coding vs agentic engineering 对比示意图 ]

两个例子，一个关于安装，一个关于产品

Karpathy在对谈里举了两个具体例子。

例子一：OpenClaw安装器

传统的软件安装是这样的：写一个bash脚本，预先考虑所有可能的情况，然后发给用户。问题是，用户的环境千变万化，脚本总会在某些情况下失败。

OpenClaw的做法是：不写固定的安装脚本，而是给用户一段自然语言指令，让用户把这段指令交给一个Agent。Agent读取指令，检查用户的实际环境，发现缺少什么就补什么，遇到问题就自己调试。

这是Software 3.0的一个具体体现：软件不再是固定的逻辑，而是给Agent的指令。

例子二：MenuGen

Karpathy提到了一个叫MenuGen的应用——一个用AI识别菜单的工具。他用这个例子说明了一个让很多AI创业者不舒服的观点：

随着模型能力提升，很多AI应用会消失。不是因为它们做得不好，而是因为它们本质上是在包装模型的局限性。当模型本身变强了，这层包装就没有存在的必要了。

他的判断是：真正有价值的AI应用，是那些建立在高价值、可验证的工作流上的——不是通用的SaaS包装，而是在特定领域建立了自己的强化学习环境的产品。

反方信号：这个转变没有那么快

我需要说一个和Karpathy判断方向一致、但速度上有分歧的声音——来自Karpathy自己。

他在Dwarkesh播客上说过：他不认为基于编程Agent的AI加速会像某些人预测的那样快速到来。

为什么？因为”可验证性”这个门槛，在很多领域还没有解决。代码可以验证，但大多数知识工作——法律分析、医疗判断、商业决策——很难建立清晰的验证机制。没有验证机制，就没有可靠的强化学习，就没有真正可信赖的Agent。

还有一个更现实的问题：AI写的代码确实在增加，但代码质量的问题也在增加。Karpathy自己说AI代码”awkward and gross”——这不是在夸奖。一个数据库被vibe coding删掉的事故（PocketOS事件）已经发生了。当80%的代码由AI写，谁来负责这80%的质量？

我的修正是：这个转变是真实的，但它会比最乐观的预测慢，比最悲观的预测快。

如果Karpathy是对的，意味着什么

假设他的判断方向是对的，接下来6-12个月，我们可能会看到：

对工程师：写代码的时间减少，审查代码的时间增加。最有价值的技能不再是”能写什么”，而是”能判断什么”。那些能把模糊需求转化成清晰规格的人，会比那些只会写代码的人更值钱。

对初级开发者：这是最难的部分。Karpathy的80/20翻转，直接压缩了初级开发者的成长路径——以前你通过写大量代码来积累经验，现在这些代码被Agent写了。怎么在一个Agent写80%代码的环境里成长，目前没有人有好答案。

对产品和创业：Karpathy的”可验证性”框架给了一个筛选标准——你的产品是在解决一个可以被清晰验证的问题吗？如果是，AI可以帮你做得更好；如果不是，你可能只是在包装模型的局限性，等着被下一个更强的模型消灭。

对基础设施：Karpathy提到了一些具体的基础设施需求——llm.txt文件（类似robots.txt，告诉LLM怎么读你的网站）、LLM友好的文档格式、让代码库变成可消化文本的工具。这些听起来很小，但它们是Software 3.0时代的基础设施，目前还没有标准化。

我的判断

Karpathy在红杉说的那些话，我反复想了好几遍。

让我印象最深的不是那些框架和概念，而是他描述自己”AI psychosis”状态的那段话——一个在这个领域工作了十几年的人，说自己从12月开始就一直在试图搞清楚这个新的工作方式到底意味着什么。

这种困惑是真实的。不是表演出来的谦虚，是真的在摸索。

我觉得这才是这场对谈最有价值的部分：不是他给出了答案，而是他诚实地说，他也还在找答案。

💬 你在自己的工作里，有没有感受到这个”拐点”？代码、文案、分析——有没有某个时刻，你突然发现AI能做的事情比上个月多了很多？

以上，既然看到这里了，如果觉得不错随手点个赞、在看、转发三连吧如果想第一时间收到推送，也可以给我个星标⭐

谢谢你看我的文章，我们，下次再见。