从“代码助手”到“自主代理”:12月的范式跃迁
Andrej Karpathy 指出,AI 编程体验在 2023 年与 2024 年 12 月发生了根本性断裂。此前,开发者主要使用类似 ChatGPT 的辅助工具,虽然能生成代码片段,但经常出错,需要人工反复编辑和修正。然而,2023 年 12 月成为关键转折点,随着最新模型能力的提升,AI 生成的代码片段不再需要大量修正,开发者可以连续要求生成更多代码,且系统能保持连贯性。这种转变让 Karpathy 感到既兴奋又不安,因为他发现自己“从未像现在这样感到落后于程序员同行”。
“我几乎不记得上次纠正它是什么时候了,然后我就越来越信任这个系统。”
这一变化促使 Karpathy 深入探索 Agentic Workflow(代理工作流),并开始大量使用 Vibe Coding 模式。他观察到,许多开发者此前将 AI 视为简单的代码补全工具,但 12 月之后的模型在代理式连贯工作流上真正开始生效。这种能力的提升使得开发者能够进入一个“无限侧项目”的兔子洞,极大地扩展了个人开发的边界和效率。
软件 3.0:LLM 作为可编程计算机
Karpathy 提出了 软件 1.0、2.0 和 3.0 的演进框架,以解释这一技术变迁的本质。软件 1.0 是显式规则,即编写具体的代码指令;软件 2.0 是学习到的权重,即通过创建数据集和训练神经网络来编程,核心在于安排数据、目标和架构。而 软件 3.0 则是将 LLM 视为一种可编程计算机。在这种范式下,编程转变为提示工程(Prompting),上下文窗口成为操作 LLM 解释器的杠杆,LLM 在数字信息空间中进行计算。
“软件 3.0 是关于提示,上下文窗口是你用来操作 LLM 这个解释器的杠杆。”
在这一新范式中,开发者不再需要精确拼写所有底层细节,而是通过提供文本指令,利用 LLM 自身的智能来理解环境、执行操作并调试。这种转变不仅仅是工具的效率提升,而是计算范式的根本改变,使得人类开发者能够以更高的抽象层级与计算机交互,将复杂的实现细节交由 LLM 处理。
案例对比:OpenClaw 安装与 Menu Genie 的重构
为了具体说明软件 3.0 的威力,Karpathy 对比了两个案例。首先是 OpenClaw 的安装过程。在传统软件 1.0 范式下,为了适配不同平台,安装脚本(Bash 脚本)会变得极其复杂。而在软件 3.0 范式中,安装过程简化为一段复制粘贴给 AI 代理的文本指令。代理具备智能,能查看用户环境、执行安装、调试问题,无需开发者编写复杂的跨平台兼容代码。这种“给代理一段文本”的方式比编写精确脚本更强大。
另一个极端案例是 Menu Genie 应用的重构。Karpathy 最初用 Vibe Coding 构建了一个应用:用户上传餐厅菜单照片,应用通过 OCR 识别文字,调用图像生成器生成对应菜品的图片,并在 Vercel 上部署运行。然而,软件 3.0 的极简版本让他震惊:只需将照片发给 Gemini,并提示其使用 Nanobanana 工具将生成的图片覆盖到菜单原图上。Nanobanana 直接在像素层面渲染并合成图片,无需构建完整的应用程序、OCR 流程或图像生成管线。这一案例证明,AI 代理可以直接处理端到端的视觉任务,取代了传统软件开发的复杂栈。
“这颠覆了我的认知,因为实际上所有这一切都可以通过简单的提示和工具调用完成。”
软件范式的重构:从“应用中间层”到“神经直出”
当前许多开发者仍受困于旧有的软件范式,试图在既有的应用架构中寻找AI的位置,但这是一种思维误区。Karpathy指出,真正的变革在于认识到软件3.0范式的原始性与直接性:神经网络正在承担越来越多的工作,而提示词或上下文仅作为输入,输出直接呈现结果,中间无需任何传统应用程序作为中介。这种转变不仅仅是让编程速度变快,更是对信息处理自动化的重新定义。过去,代码主要处理结构化数据;而现在,LLM能够处理非结构化文档,例如通过构建组织内部的Wiki知识库,将事实重新编译、排序,生成以前无法通过传统代码实现的新颖信息结构。这种新机会比单纯加速现有流程更具吸引力,因为它创造了此前不可能存在的事物。
"It's not just about programming and programming becoming faster. This is more general information processing that is automatable now."
2026年的计算形态:神经网络成为主机进程
展望未来,计算架构可能发生根本性逆转。回顾20世纪50-60年代,人们曾困惑计算机应像计算器还是神经网络,最终选择了经典计算路径。然而,随着智能计算逐渐占据FLOPs的主导地位,Karpathy预测神经网络可能成为主机进程,而CPU退化为协处理器。在这种“神经计算机”中,设备直接接收原始视频或音频输入,通过神经网络利用扩散模型渲染出针对当下时刻独特的UI界面。这种形态虽然看似怪异且遥远,但正在逐步实现。工具调用(Tool Use)将仅作为处理确定性任务的历史遗留附件,而核心驱动力将是执行主要负载的神经网络。这种架构的翻转意味着我们不再依赖传统程序逻辑,而是通过端到端的神经映射来生成交互界面,这将是继90年代网站、2010年代移动应用之后的下一个显而易见的技术浪潮。
可验证性悖论:模型能力的“锯齿状”分布
AI自动化在可验证领域(如数学、代码)进展迅速,但在其他领域却显得笨拙,这种能力分布呈现显著的锯齿状(Jagged)特征。前沿实验室在训练LLM时,通过强化学习环境给予验证奖励,导致模型在可验证任务上能力峰值极高,而在非验证领域则停滞不前。这种差异部分源于训练数据的分布,因为某些领域(如代码)在经济上更具价值,因此被赋予了更多的训练环境。Karpathy以“草莓中有几个字母”为例,说明模型曾在此类简单任务上失败,尽管现在已修复,但新的矛盾更加突出:最先进的模型(如Opus 4.7)能够重构10万行代码库或发现零日漏洞,却在处理“距离洗车店50米,开车还是走路”这种常识推理时,错误地建议“走路”。这种极端的能力反差揭示了当前模型在常识推理与复杂逻辑处理之间的巨大鸿沟,暗示了训练机制或数据分布中仍存在未被解决的深层问题。
"State-of-the-art models today will tell you to walk because it's so close. How is it possible that state-of-the-art Opus 4.7 will simultaneously refactor a 100,000 line codebase... and yet tells me to walk to this car wash?"
能力落差的数据化呈现
为了更直观地展示当前大模型在高复杂度逻辑任务与基础常识推理之间的巨大性能落差,以下表格对比了不同任务类型下的模型表现特征。尽管具体基准测试分数随版本迭代变化,但能力维度的非对称性是普遍现象。
| 任务类型 | 具体案例/场景 | 模型表现特征 | 能力维度评估 |
|---|---|---|---|
| 代码重构 | 重构100,000行代码库 | 能够高效完成,逻辑严密 | 极高 (可验证领域) |
| 安全漏洞挖掘 | 发现零日漏洞 (Zero-day) | 具备高级分析与模式识别能力 | 极高 (可验证领域) |
| 数学计算 | 复杂数学证明/计算 | 通过强化学习优化,准确率显著提升 | 高 (可验证领域) |
| 常识推理 | 距离50米去洗车店,开车vs走路 | 错误建议“走路”,缺乏物理常识 | 极低 (非结构化推理) |
| 字符计数 | “Strawberry”中的字母数量 | 早期版本频繁出错,现已修复 | 中/高 (已修补的锯齿点) |
这种锯齿状能力分布表明,当前的AI并非通用智能,而是在特定奖励机制下形成的特化实体。理解这一特性对于判断哪些工作将被快速自动化至关重要:凡是输出可被严格验证的领域,自动化速度将远超预期;而看似简单但依赖常识的领域,模型仍可能表现出令人惊讶的愚蠢。
模型能力的“人为”边界与可验证性陷阱
Andrej Karpathy 指出,当前大模型的能力表现并非完全由算法自然演进决定,而是深受实验室数据注入策略的影响。用户必须意识到自己处于“半盲目”状态,需要像使用工具一样保持警惕,因为模型在特定分布内表现优异,一旦超出该分布就会遭遇性能断崖。他以 GPT-3.5 到 GPT-4 的国际象棋能力跃升为例,揭示了这一现象背后的真相:这并非单纯的模型架构进步,而是因为 OpenAI 在预训练数据集中大量注入了国际象棋相关数据。这种数据分布的偏移导致模型在该领域的表现远超默认预期,证明了“可验证性+实验室关注”是能力爆发的关键组合。
“很多人以为这只是能力的自然 progression,但实际上是因为大量国际象棋数据进入了预训练集,模型才获得了这种峰值能力。”
这意味着开发者不能假设模型具备通用全能性,必须主动探索模型在不同设置下的表现边界。如果应用逻辑落在模型经过强化学习(RL)优化的“电路”中,性能会极佳;若落在数据分布之外,则必须通过微调(Fine-tuning)和额外工程工作来弥补,因为模型不会“开箱即用”地解决所有问题。
创业者的破局点:构建可验证的强化学习环境
对于试图利用 AI 创业或构建产品的创始人,Karpathy 的核心建议是聚焦于“可验证性”(Verifiability)。他认为,即使大型实验室不再直接关注某些垂直领域,只要该领域具备可验证性,开发者就可以通过构建大量的强化学习(RL)环境和多样化数据集,自行进行微调。这种技术路径是“即插即用”的:只要拥有合适的 RL 环境数据,利用现有的微调框架即可显著提升效果。
“可验证性使得某事在当前范式下变得可行,因为你可以向其投入海量的强化学习资源。”
Karpathy 暗示,目前存在一些高价值的 RL 环境领域尚未被大厂充分覆盖,这些领域正是创业者的机会所在。通过建立可验证的反馈闭环,开发者可以绕过对通用模型能力的依赖,转而构建专用的高效智能体。这种策略不仅降低了对外部模型演进的依赖,还通过“拉动杠杆”的方式,利用自有数据获得比通用模型更优的性能表现。
从 Vibe Coding 到 Agentic Engineering 的范式转移
Karpathy 明确区分了 Vibe Coding(氛围编码)与 Agentic Engineering(智能体工程)的本质差异。Vibe Coding 的核心价值在于“抬高地板”,让每个人都能通过自然语言快速生成代码,极大地降低了软件开发的入门门槛。然而,Agentic Engineering 则致力于“维持质量上限”,即在专业软件工程中,不能因使用 AI 而引入漏洞或降低可靠性。它要求开发者在保持原有质量基准的前提下,利用智能体实现效率的指数级提升。
“Vibe Coding 是关于抬高每个人的地板……而 Agentic Engineering 是关于保留之前专业软件的质量标准。”
Karpathy 认为,Agentic Engineering 是一种工程学科,旨在协调那些具有尖峰特性、不可靠且随机的智能体,以在不牺牲质量的情况下加速开发。他预测,精通此道的工程师所能带来的效率提升远超传统的“10 倍工程师”概念,甚至能实现远超 10 倍的性能峰值。这种转变标志着 AI 辅助编程从“玩具阶段”进入“严肃工程阶段”,要求开发者具备更高的架构设计和质量控制能力。
AI 原生开发者的核心竞争力:工具链的深度定制
在讨论不同代际用户如何使用 AI 工具时,Karpathy 指出,真正的区别在于对工具功能的深度挖掘与个性化配置。正如资深工程师会精通 Vim 或 VS Code 的快捷键与插件生态,AI 原生开发者(AI Native)也会投入大量精力优化其 AI 编程工具(如 OpenClaw, Claude Code, CodeEx)的工作流设置。这种差异并非源于年龄,而是源于是否愿意投资于自己的工具链,以最大化利用 AI 的功能。
“就像以前工程师习惯于充分利用他们使用的工具……现在则是投资于你的设置,无论是 Claude Code 还是 CodeEx。”
Karpathy 强调,“平庸”与“完全 AI 原生”的区别在于开发者是否建立了高效的人机协作闭环。这包括定制提示词模板、自动化测试流程以及智能体之间的协调机制。通过深度定制,开发者可以将 AI 从简单的代码补全工具转变为复杂的工程协作伙伴,从而在速度和准确性上同时超越仅将 AI 视为“搜索引擎替代品”的用户。这种工具链的深耕是未来软件工程师的核心竞争力所在。
招聘范式重构:从解题到工程实战
当前企业在招聘Agentic Engineer(智能体工程师)时,普遍存在招聘流程未重构的问题。传统的面试方式往往侧重于解决孤立的谜题或代码片段,这属于旧范式,无法真实评估候选人驾驭复杂智能体工具链的能力。Karpathy 指出,有效的评估应当模拟真实的工程场景,要求候选人完成一个大型项目,例如构建一个具备高安全性和健壮性的 Twitter 克隆系统,并让智能体模拟用户活动,同时引入对抗性测试(如使用 10 个代码解释器以 5.4x 的强度进行攻击),以验证系统的抗压能力。
"Hiring has to look like give me a really big project and see someone implement that big project... make it really secure and then have some agents uh simulate some activity on this Twitter."
这种实战导向的评估方式,能够直观地观察候选人在构建大型项目时如何利用工具链,以及在面对智能体模拟攻击时的系统防御设计能力。通过这种端到端的项目实施过程,招聘方能更准确地判断候选人是否具备在智能体辅助下进行复杂工程落地的核心竞争力,而非仅仅具备零散的编码技巧。
人类角色演变:从细节实现到架构把控
随着智能体承担更多执行工作,人类工程师的价值重心发生了转移。Karpathy 将当前的智能体比作实习生,它们拥有极强的记忆力和执行效率,但在审美、判断力和全局 oversight(监督)方面仍显不足。一个典型的案例是 MenuGen 平台:当用户使用 Google 账号注册但通过 Stripe 购买积分时,智能体试图通过邮箱地址来关联两者,却忽略了用户可能使用不同邮箱的事实,导致资金无法正确关联。这揭示了智能体在跨系统数据关联和业务逻辑理解上的固有缺陷。
"Agents are kind of like these intern entities... you basically still have to be in charge of the aesthetics the judgment the taste and a little bit of oversight."
因此,人类工程师的核心职责转变为制定详细规范(Spec)和顶层设计。工程师需要定义唯一用户 ID等关键约束,确保逻辑的严密性,而将具体的 API 调用、代码填充等细节工作交给智能体。例如,在神经网络编程中,人类不再需要死记硬背 PyTorch 与 NumPy 中 keep_dims 与 keep_dim、axis 与 dim 等细微的 API 差异,而是需要理解底层张量存储、视图(View)与副本(Copy)的内存管理机制,以避免不必要的内存拷贝,确保底层架构的高效性。
智能体的局限:缺乏审美与内在动机
尽管智能体在代码生成上表现强劲,但其产出往往存在代码冗余、复制粘贴和脆弱抽象等问题。Karpathy 提到,有时看到智能体生成的代码会让他感到"心悸",因为代码虽然能运行,但结构臃肿且粗糙。这种问题在尝试极致简化(如 MicroGPT 项目)时尤为明显,模型难以跳出既有的RL(强化学习)电路,无法像人类一样通过直觉进行优雅的简化。
"I get a little bit of a heart attack because it's not like super amazing code necessarily all the time and it's very bloaty... awkward abstractions that are brittle."
Karpathy 认为,这种审美和判断力的缺失,根本原因在于当前的训练过程中缺乏对代码美学或简洁性的奖励机制(Reward)。他推测,随着未来模型在 RLHF 或类似技术中引入对代码质量和设计美感的评估,智能体的代码水平有望提升。然而,目前人类工程师在设计决策、需求定义和最终验收上的角色依然不可替代,智能体仍需在人类设定的规范框架内工作,填补具体的实现空白。
智能本质:召唤幽灵而非创造动物
Karpathy 提出了"锯齿状智能(Jagged Forms of Intelligence)"的概念,区分了动物式智能与幽灵式智能。动物式智能源于进化,具备内在动机、好奇心和探索欲;而当前的 LLM 则是召唤出的幽灵,其智能形态完全由数据分布和奖励函数塑造,缺乏内在的生命驱动力。
"We are not building animals, we are summoning ghosts... shaped by data and reward functions, but not by intrinsic motivation or fun or curiosity."
这一框架对构建、部署和评估智能体具有深远影响。理解智能体的非生物性,意味着开发者不能期望它们具备人类的直觉或常识推理能力,而必须通过精确的提示工程、严格的规范约束和持续的监督来引导其行为。这种数据驱动的智能虽然强大,但也极其脆弱,容易在未见过的分布或逻辑陷阱中失效。因此,信任智能体的前提是其行为被严格限定在人类设计的安全边界和逻辑规范之内,而非依赖其潜在的"理解"能力。