OpenAI重大更新！ OpenAI的智能体Codex，这次直接硬刚Claude Cowork。 图片 Codex是OpenAI的旗舰代码生成模型，支持GitHub Copilot

能改10万行代码

却让你走路去洗车

这事儿听起来确实有点离谱，对吧？

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

如今最顶尖的大模型，已经能游刃有余地重构一个包含10万行代码的复杂项目。可转过头来，当你问它“怎么洗车”时，它却可能一本正经地建议你：步行前往50米外的洗车店。

想想看，10万行代码是什么概念？那足以支撑起一个相当成熟和复杂的软件系统。而“走路去洗车”这个建议呢？恐怕连三岁小孩都能意识到问题所在：要洗的是车，车又不会走路。一个拥有如此强大技术能力的模型，竟会在这种常识性问题上“翻车”。

这正是Karpathy在谈话中着力描绘的“锯齿状智能”图景。AI的能力进步并非平滑均匀的斜坡，而更像是一块凹凸不平的锯齿板，高峰与深谷并存。因此，用简单的“行”或“不行”来二分判断AI，可能是当下最危险的认知误区。

新地平线

当软件可以「直接做到」

Karpathy分享了一个让他自己都感到些许尴尬的经历。他曾经开发过一个叫MenuGen的App，功能是拍摄餐厅菜单后，用OCR识别菜品名，再调用图像生成模型为每道菜配上图片。这是一个典型的“软件1.0”思路下的产物。

然而，他后来看到了一个堪称“软件3.0”的版本：用户只需把菜单照片发给Gemini，并附上一句提示词——“用Nanobanana把菜品贴到菜单上”。模型便直接输出了一张完整的、图文并茂的菜单。

那一刻的感受很清晰：自己那个需要精心编排技术栈的App，在新时代的范式面前，显得有些多余了。这揭示了第一个新地平线：AI不再仅仅是让旧流程加速，而是将原本需要一整套工程化实现的功能，压缩成了模型的一次性直接输出。

第二个地平线，是“.md”取代“.sh”。过去安装复杂软件，往往离不开冗长脆弱的bash脚本，环境稍有变化就可能崩溃。Karpathy提到了OpenClaw的安装方式：它提供的不是脚本，而是一段Markdown文字，指示你“把这段复制粘贴给你的智能体”。然后，智能体会自主检查你的环境、调试并完成安装。这里的Markdown，不再是给人看的说明书，而是给智能体看的可执行指令。

第三个地平线，是“LLM Wiki”。这是Karpathy在2026年4月提出的新理念。传统的RAG（检索增强生成）每次问答都是孤立的，模型需要重新解析文档，知识无法有效沉淀。LLM Wiki则不同，它让模型在一个Markdown文件夹构成的“知识库”中持续工作，你可以用Obsidian这类工具来浏览。新文档加入后，模型会自动更新相关条目、修订摘要、补充内部链接、甚至标记知识矛盾。在那份Gist中，Karpathy打了个比方：Obsidian是IDE（集成开发环境），LLM是程序员，而整个wiki就是被持续维护的代码库。知识，第一次被像软件工程一样系统地组织、积累和版本控制。

这三个例子共同指向一个核心转变：软件1.0时代，我们亲手写代码；软件2.0时代，我们训练模型权重；到了软件3.0时代，我们的核心工作变成了设计提示词（prompt）、管理上下文窗口（context window）和调度智能体。

锯齿状的背后

可验证性和经济学

解释了新范式，Karpathy进一步剖析了那个根本问题：模型的智能为何如此“锯齿状”，高低起伏悬殊？

他的观点很明确：这主要不是一个技术瓶颈，而是一个经济学问题。是市场规模和收入潜力，决定了顶尖AI实验室在强化学习阶段，优先将哪些能力打包进模型的训练数据分布。

强化学习依赖奖励信号，而奖励信号需要可验证性。任何一个领域，只要其产出能够被清晰验证——比如代码能否运行、数学题答案是否正确、安全漏洞能否复现——就能构建出强化学习环境，模型在该领域的能力便会飞速进化。

但“可验证”只是前提，“有钱赚”才是驱动力。OpenAI、Anthropic、Google这些实验室选择优先攻克哪些领域，背后是严酷的商业考量：市场空间是否足够大？付费意愿是否强烈？能否形成可持续的商业闭环？符合这些条件的领域，会被优先纳入强化学习的训练轨道；反之，则可能乏人问津。

Karpathy给出了一个生动的比喻：在强化学习的“轨道”上，模型的能力如同高速列车般飞驰；而一旦离开这些高投入、高验证度的数据分布，模型的表现就像拿着砍刀在丛林中摸索，举步维艰。

所以，今天我们看到的“锯齿状”能力分布，并非缺陷，而是一种必然的结构。它是“可验证性”与“经济激励”这两把刻刀，共同雕琢出的形状。

这对创业者而言至关重要。Karpathy给出了一个直白的建议：如果你想在AI领域创业，应该去寻找那些“可验证、但巨头尚未大规模投入”的垂直领域。然后，自己动手构建强化学习环境，对模型进行微调。这可能是当下构建竞争护城河最有效的路径之一。

换句话说，下一批原生AI公司，其核心资产可能就是它们所定义的“验证环境”本身。谁能设计出关键的可验证任务、构建高效的奖励循环、并持续积累边缘案例，谁就掌握了主动权。

就这样，Karpathy将看似神秘的“锯齿状智能”，还原成了一个清晰可分析的工程与经济交叉命题。

Vibe Coding的发明人

又造出新词

2025年2月，Karpathy在X上创造了“Vibe Coding”一词，用来形容那种高度依赖AI、几乎无需手动编码的开发方式。这个词火爆到被柯林斯词典选为2025年度词汇，而Cursor、Lovable、Replit等公司的估值飙升，背后正是这股浪潮的推动。

一年后，在这次对话中，Karpathy为这个概念升级了一个新词：智能体工程。

他对这两个概念的区分非常精辟：“氛围编程”是“抬高地板”，让几乎所有人都能参与创造软件；而“智能体工程”则是“保住天花板”，确保专业的软件开发不会因为AI的介入而降低标准和质量。

因为在他眼中，当前AI生成的代码往往显得臃肿，充斥着复制粘贴，抽象层次怪异且脆弱。代码能跑，但质量堪忧。

他举了一个真实的案例：他的智能体在MenuGen项目中，竟然试图用Stripe和Google返回的邮箱地址去做用户匹配，而不是使用一个持久化的唯一用户ID。这种错误，任何一位稍有经验的工程师都不会犯，但智能体却犯了。

因此，Karpathy给智能体下了一个精准的定位：它们就像一群“实习生”。实习生很有用，但你绝不会让他们独自负责生产环境的核心代码。需求定义、系统架构、安全保障、审美判断、结果验证……这些关键职责，智能体目前还无法独立承担。

“氛围编程”的爽感，主要存在于业余项目和原型验证阶段；而“智能体工程”才是专业软件开发的未来。前者降低了入门门槛，后者则对开发者提出了更高的要求——两者不能混为一谈。

这也是当前行业容易陷入的误区。在“氛围编程”的热潮下，人人都在欢呼“人人都是程序员”，但Karpathy却点出：能在智能体时代生存下来的工程师，不是那些编码最快的，而是那些最善于管理和驾驭智能体的。

你能外包思考

但不能外包理解

谈话中，主持人提出了一个普遍的焦虑：当智能体能够写代码、调度任务、自行安装软件时，人类的价值还剩下什么？

Karpathy引用了一条令他深受启发的推文：“你可以外包你的思考，但你不能外包你的理解。”

他的解读是：人类仍然是整个流程的“瓶颈”，因为只有人类才知道我们究竟要构建什么，以及为何要构建它。Karpathy将人类在智能体工作流中的角色，定位为“工程管理”或“工程导演”，具体承担六项核心职能：

第一，需求定义：清晰阐述要做什么；
第二，拆解计划：规划具体的实现路径；
第三，系统架构：设计系统的整体结构与蓝图；
第四，品味判断：评估并选择更优的方案；
第五，过程监督：确保智能体的执行不偏离轨道；
第六，结果验证：最终确认智能体的产出是否正确可靠。

这六项工作，智能体可以提供辅助，但无法承担最终责任。

Karpathy再次提及了他著名的“动物与幽灵”比喻。

他在2025年10月系统阐述过：幽灵之于动物，正如飞机之于鸟类。当前的前沿大模型研究，不是在创造拥有内在动机的“动物”，而是在“召唤幽灵”。这些幽灵是由数据和奖励信号塑造出的智能模拟，是一个全新物种。这意味着，我们不能像对待人类一样对待智能体，也不能像对待传统软件一样对待它们。

而人类的位置，就是“导演”。导演不亲自扮演每个角色，但必须懂戏。你不需要亲手编写每一行代码，但你必须清楚产品最终应该是什么样子、为何A方案优于B方案、以及上线后可能面临哪些风险。

红杉资本在2026年给出的观察是：AI应用的渗透速度仍在加快，“从0到1亿美元”的创业俱乐部，正在向“从0到10亿美元”升级。顶尖的AI创业公司，其单员工年产出已超过百万美元。这背后固然是智能体在高效执行，但能让智能体创造出如此高价值的，正是那些懂得如何当好“导演”的创始人。

在谈话的尾声，Karpathy描绘了一个更远的愿景：未来某天，神经网络或许会成为主处理器，而传统的CPU反而退居协处理器的位置。

但即便这条路最终走通，“导演”的位置也永远不会消失。因为“幽灵”永远不会替你思考你究竟想要什么。那些无法被外包的部分，恰恰是人类不可替代的价值所在。