软件正在(再次)改变——Andrej Karpathy 谈 AI 时代的软件范式革命

摘要
2025年6月,前特斯拉AI总监、OpenAI联合创始人Andrej Karpathy发表了一场关于"软件在AI时代如何变革"的演讲。他系统性地阐述了软件范式的三次演进:Software 1.0(人类编写的代码)、Software 2.0(神经网络权重)与Software 3.0(对大语言模型的自然语言提示)。Karpathy指出,大语言模型(LLM)不仅像电力一样是一种公用事业,更像操作系统一样是复杂的软件生态系统——我们正处于LLM操作系统的"1960年代",通过分时共享方式使用集中式计算资源,个人计算革命尚未到来。他深入剖析了LLM的"心理学"特征:具备百科全书级的记忆与知识,但同时存在幻觉、锯齿状智能和逆行性遗忘等认知缺陷。在应用层面,Karpathy倡导构建"部分自主应用"(Partial Autonomy Apps),以自主滑块(Autonomy Slider)让用户在增强与代理之间灵活切换,并以特斯拉自动驾驶十二年仍未完全解决为警示,提醒人们不要对AI Agent过于乐观。他创造的"氛围编程"(Vibe Coding)概念已成为流行文化现象,标志着人人皆可编程的新时代。最后,他呼吁为Agent这一新型数字信息消费者重新设计基础设施,从文档格式到交互协议全面适配。这是一场关于软件未来十年走向的深刻洞见。
正文
软件的三次范式变革
Karpathy开篇指出,对于即将进入行业的学生们而言,当下是一个极其独特且充满趣味的时刻,其根本原因在于——软件正在再次发生变革。
他说"再次",是因为他此前已做过一次类似演讲,但问题在于软件仍在持续变化。大致而言,软件在70年间未经历过如此根本性的变革,然而在过去短短几年内却已迅速经历了两次巨变。因此,海量的软件需要被编写与重写。
他展示了"GitHub地图"(Map of GitHub)这一工具,可视化呈现了所有已编写的软件——这些软件都是向计算机下达指令以在数字空间中执行任务的代码。
几年前,Karpathy观察到软件正在发生变化,出现了一种新型软件,他将其命名为Software 2.0。核心观点如下:
- Software 1.0:人类为计算机编写的代码(如Python、C++等)
- Software 2.0:神经网络的权重(Weights),人类不再直接编写这些"代码",而是通过调整数据集并运行优化器(Optimizer)来生成神经网络的参数
当时,神经网络被视为仅是一种分类器(Classifier),与决策树(Decision Tree)类似。因此,他认为这一框架性认知更为恰当。如今,Software 2.0领域已有自己的"GitHub"——Hugging Face基本等同于Software 2.0世界的GitHub。此外还有Model Atlas,可以可视化该领域所有已编写的"代码"。他特别提到,Model Atlas中最大的圆点位于中央,那便是Flux图像生成器的参数——每当有人在Flux模型基础上进行微调(Fine-tune),便相当于在这个空间中创建了一个"Git提交",从而生成一个不同版本的图像生成器。
然而,迄今为止我们所熟知的神经网络,大多是固定功能的计算机——例如将图像映射到类别。Karpathy认为,一个根本性的变化在于:神经网络变得可编程了——这一切源于大语言模型(Large Language Model, LLM)。他视之为全新且独特的计算形态,值得赋予新的命名:Software 3.0。
在Software 3.0中,提示词(Prompt)即是程序,它编程了LLM。值得注意的是,这些提示词是用英语编写的——这是一种非常有趣的编程语言。
以情感分类(Sentiment Classification)为例,可以三种方式实现:编写Python代码(Software 1.0)、训练神经网络(Software 2.0)、或向LLM提供简短提示(Software 3.0)。当前GitHub上越来越多的代码不再仅是纯代码,而是英语与代码交织的混合体——这正是一个不断增长的新代码类别。
这不仅是一种新的编程范式,更令人惊叹的是它使用我们的母语——英语。几年前Karpathy发布了一条推文表达了这一洞见:"我们正在用英语编程计算机。"这条推文至今仍置顶于他的账户。
在特斯拉工作期间,Karpathy负责自动驾驶(Autopilot)项目。他展示了当时的架构图:车辆输入信息通过软件栈产生转向与加速指令。他观察到,自动驾驶系统中存在大量C++代码(Software 1.0),同时也有执行图像识别的神经网络。随着自动驾驶能力的提升,神经网络不断增长,而C++代码不断被删除——许多原本以Software 1.0编写的功能被迁移至Software 2.0。例如,跨摄像头、跨时间的信息拼接工作改由神经网络完成,从而删除了大量C++代码。Software 2.0栈确确实实地"吞噬"了自动驾驶的软件栈。
如今,类似的现象再次上演——新型软件正在吞噬现有软件栈。我们拥有三种截然不同的编程范式,Karpathy建议即将进入行业的人必须精通所有三种范式,因为它们各有优劣。开发者需要决定:某项功能应以1.0、2.0还是3.0实现?是训练神经网络,还是提示LLM,亦或编写显式代码?我们都需要做出这些决策,并在不同范式之间流畅切换。
LLM:新型操作系统
公用事业属性
Karpathy引用了吴恩达(Andrew Ng)多年前的名言:"AI是新时代的电力。"他认为这一比喻捕捉到了某些本质特征——LLM确实展现出公用事业(Utility)的属性:
- 资本支出(CapEx):LLM实验室(如OpenAI、Gemini、Anthropic等)投入巨额资本训练模型,相当于建设电网
- 运营支出(OpEx):通过API向用户提供智能服务,按百万Token计费
- 服务质量需求:低延迟(Low Latency)、高可用性(High Uptime)、一致的质量——这与电力需求如出一辙
- 转换开关(Transfer Switch):正如电力系统可在电网、太阳能、电池、发电机之间切换,LLM领域有OpenRouter等工具,可在不同LLM之间轻松切换。由于LLM是软件,不争夺物理空间,因此可以同时拥有六个"电力供应商"并自由切换
他特别提到一个令人深思的现象:当最先进的LLM宕机时,世界仿佛经历了一场"智能褐色停电"(Intelligence Brownout)——如同电网电压不稳。随着我们对这些模型的依赖日益加深,整个星球的"智力"会在模型宕机时降低。这已十分显著,且将持续加剧。
晶圆厂属性
LLM不仅具有公用事业属性,也具有晶圆厂(Fab)的某些特征:
- 训练LLM所需的资本支出极其庞大,远不止建设一座发电站
- 技术树(Tech Tree)正在快速增长,深度技术树和研发秘密正在LLM实验室内集中
- 4纳米工艺节点(Process Node)可以类比为具有特定最大算力(FLOPS)的集群
- 仅使用Nvidia GPU进行软件开发的模式类似于无晶圆厂模式(Fabless Model)
- 同时自研硬件并在TPU上训练(如Google)则类似于Intel模式——拥有自己的晶圆厂
然而,这一类比也有局限:LLM终究是软件,而软件因其高度可塑性(Malleability)而防御性较弱。
操作系统类比——最贴切的比喻
Karpathy认为,最恰当的类比是:LLM如同操作系统。
LLM不是简单的电力或自来水这样的商品,而是日益复杂的软件生态系统。目前的行业格局与操作系统领域惊人地相似:
- 闭源提供商:相当于Windows和macOS——当前有少数几家闭源LLM竞争者
- 开源替代:相当于Linux——Llama生态系统可能正在成长为LLM领域的"Linux"
当前仍处于非常早期的阶段,这些还只是简单的LLM,但它们正变得更加复杂——不仅关乎LLM本身,还涉及工具使用(Tool Use)、多模态(Multimodality)以及所有这些如何协同工作。
Karpathy尝试勾勒了LLM作为操作系统的类比图:
- LLM本身相当于CPU
- 上下文窗口(Context Window)相当于内存
- LLM调度内存与计算资源来解决问题
更多类比:
- 跨平台应用:正如VS Code可以运行在Windows、Linux或macOS上,Cursor这样的LLM应用也可以通过下拉菜单切换运行在GPT、Claude或Gemini系列上
- 分时共享时代:当前LLM计算仍然非常昂贵,迫使LLM集中在云端,我们都是通过网络与之交互的瘦客户端(Thin Client)。没有人能完全独占这些计算机,因此分时共享(Time Sharing)是合理的——我们只是批处理中的一个维度。这与1960年代的计算机极为相似:操作系统在云端,一切通过网络流转,采用批处理模式
-
个人计算革命尚未到来:但已有早期迹象——Mac Mini等设备因其在批量为一的推理(Batch-1 Inference)中受内存带宽限制的特性,恰好适合运行某些LLM。然而,个人计算革命尚未真正发生,其形态尚不清晰——也许在座的某些人将发明它
-
终端与GUI:直接与ChatGPT等LLM进行文本对话,感觉就像通过终端(Terminal)与操作系统交互——只是纯文本的直接访问。而图形用户界面(GUI)尚未以通用方式被发明出来——ChatGPT是否应该拥有超越文本气泡的GUI?虽然某些应用拥有GUI,但尚不存在覆盖所有任务的通用GUI
技术扩散方向的反转
LLM与早期计算的一个独特区别在于:LLM翻转了技术扩散的方向。
传统上,电力、密码学、计算机、飞行、互联网、GPS等变革性技术,通常首先由政府和企业采用(因为新技术昂贵且稀缺),随后才扩散至消费者。然而LLM却反其道而行——早期计算机用于弹道计算和军事用途,而LLM却更多地用于"如何煮鸡蛋"这样的日常问题。我们拥有了一台神奇的计算机,而它在帮我们煮鸡蛋——不是帮助政府进行军事弹道计算或某些特殊技术。事实上,企业与政府对LLM的采用反而落后于普通个人。
小结
LLM是复杂的操作系统,处于计算史的1960年代阶段。我们正在重新经历计算的发展历程——当前通过分时共享方式、以公用事业形式分发。但史无前例的是,这些系统并非掌握在少数政府和企业手中,而是掌握在我们所有人手中——因为我们都拥有计算机,而ChatGPT一夜之间被分发到数十亿人的设备上。这太疯狂了。现在是我们进入行业、编程这些计算机的时代。
LLM的心理学
在编程LLM之前,需要深入理解它们是什么。Karpathy特别强调要关注LLM的"心理学"。
他将LLM视为"人灵"(People Spirits)——它们是人的随机模拟(Stochastic Simulations of People)。模拟器本身是一个自回归Transformer(Autoregressive Transformer)——一种神经网络,逐个Token生成输出,每个Token的计算量几乎相等。这个模拟器通过权重拟合了互联网上的所有文本。
由于LLM是在人类数据上训练的,因此它展现出类人的涌现心理(Emergent Psychology)。
超能力
百科全书级的知识与记忆:LLM能够记住远超任何单个人类的信息量,因为它阅读了如此之多的内容。Karpathy将其比作电影《雨人》(Rainman)中达斯汀·霍夫曼饰演的自闭学者(Autistic Savant)——几乎拥有完美记忆,可以阅读电话簿并记住所有姓名和号码。LLM可以轻松记住SHA哈希值等各类信息。
认知缺陷
- 幻觉(Hallucination):LLM经常编造内容,缺乏充分的自我认知(Self-Knowledge)模型。虽然已有改善,但远未完美
- 锯齿状智能(Jagged Intelligence):在某些问题解决领域表现出超人类能力,却会犯没有任何人类会犯的错误——例如坚称9.11大于9.9,或认为"strawberry"中有两个"r"。这些粗糙的边界可能让你栽跟头
- 逆行性遗忘(Retrograde Amnesia):Karpathy类比了职场中的场景——一位新同事加入组织后会逐渐学习,获取大量组织上下文,回家后睡眠巩固知识,随时间发展专业能力。LLM原生的并不具备这一能力。上下文窗口更像是工作记忆(Working Memory),需要直接编程工作记忆,因为LLM不会默认变得更聪明。他推荐了两部电影——《记忆碎片》(Memento)和《初恋50次》(50 First Dates)——两部电影的主角都是权重固定、上下文窗口每天清晨被清空的状况,这种情况下去工作或建立关系都极其困难
安全相关限制
LLM相当轻信(Gullible),容易受到提示注入(Prompt Injection)攻击,可能泄露数据等。还有许多其他安全相关的考量。
总之,开发者必须同时应对这个拥有超人类能力但又有诸多认知缺陷的存在,充分利用其超能力,同时巧妙规避其不足。
部分自主应用的机遇
编程领域的范例:Cursor
Karpathy首先讨论了"部分自主应用"(Partial Autonomy Apps)。以编程为例:可以直接去ChatGPT复制粘贴代码、Bug报告等,但为什么要直接与操作系统交互呢?更合理的方式是使用专用应用。
Cursor便是这样的早期LLM应用范例,具有以下共同特征:
- 上下文管理:LLM负责大量的上下文管理工作
- 多模型编排:在Cursor底层,有用于文件索引的嵌入模型(Embedding Model)、聊天模型、应用差分(Diff)的模型等,这一切都为用户编排好了
- 应用专用GUI:这一点可能未被充分重视。你不希望仅通过文本与操作系统直接交互——文本难以阅读、解释和理解,也不适合直接执行某些操作。将差分显示为红绿变更,用Command+Y接受或Command+N拒绝,远比输入文本高效。GUI使人类能够审计这些易犯错系统的工作并加速流程
- 自主滑块(Autonomy Slider):在Cursor中,你可以:
- Tab补全——主要由你掌控
- Command+K修改代码块
- Command+L修改整个文件
- Command+I让Agent在整个代码仓库中自由发挥——完全自主的Agent模式
你掌控自主滑块,根据任务复杂度调节愿意交出的自主权
搜索领域的范例:Perplexity
Perplexity同样具备上述特征:打包信息、编排多个LLM、提供可审计的GUI(如引用来源可检视),以及自主滑块——快速搜索、研究(Research)、深度研究(Deep Research),对应不同层级的自主权让渡。
部分自主化的未来
Karpathy提出核心问题:大量软件将成为部分自主的。对于维护产品和服务的人而言,如何使产品和服务部分自主化?LLM能否看到人类能看到的一切?LLM能否以人类可行动的所有方式行动?人类能否在此活动中保持监督并留在环路中?Photoshop中的"差分"是什么样的?当前大量传统软件的开关与界面都为人类设计,这一切都需要改变,使其对LLM也可访问。
加速生成-验证循环
在人与AI协作的新模式中,AI负责生成(Generation),人类负责验证(Verification)。使这一循环尽可能快速运转至关重要。Karpathy提出两大加速方法:
一、加速验证
GUI在此扮演关键角色。GUI利用了人脑中的"计算机视觉GPU"——阅读文本费力且无趣,但"看东西"轻松有趣,是通往大脑的高速公路。因此,GUI和可视化表示对于审计系统极其重要。
二、保持AI在可控范围内
Karpathy对AI Agent的过度热潮持谨慎态度。收到一万行代码的差分毫无用处——人类仍是瓶颈。即使这一万行代码瞬间生成,开发者仍需确保不引入Bug、执行正确、无安全问题。因此,必须让AI保持适度自主范围,避免其过度反应。
他展示了自己AI辅助编程的工作方式:始终以小增量块推进,确保每步正确,高速旋转生成-验证循环,专注于单一具体任务的小块。
他还推荐了一些与LLM协作的最佳实践。例如:如果提示词模糊,AI可能不会做你想要的事,验证就会失败,你就得重新请求,陷入循环。因此,花更多时间使提示词更具体,可以提高验证成功的概率并持续推进。
AI教育中的"可控"实践
Karpathy分享了他对AI时代教育的思考。直接去ChatGPT说"教我物理"效果不佳,因为AI会"迷失在森林中"。他的解决方案是将此拆分为两个应用:
- 教师应用:创建课程
- 学生应用:将课程提供给学习者
两者之间产生了可审计的中间产物——课程(Course),可以确保其质量与一致性,AI围绕特定大纲和项目进度被保持在可控范围内。这是一种有效的"拴住AI"的方式,大大提高了成功概率,避免AI迷失方向。
自动驾驶的启示
Karpathy在特斯拉工作了五年,对部分自主有深刻体会——特斯拉自动驾驶也是一款部分自主产品,具备前述诸多特征:仪表盘上的GUI展示神经网络所见,自主滑块随时间推移执行越来越自主的任务。
他讲述了一个关键故事:2013年,他第一次乘坐自动驾驶车辆——一位在Waymo工作的朋友带他在帕洛阿尔托试驾了约30分钟。那次试驾完美无缺,零干预——而那已是12年前。当时他感到自动驾驶近在咫尺。然而12年后的今天,我们仍在为自主驾驶而努力。虽然Waymo的车辆看起来无人驾驶,但背后仍有大量远程操作(Teleoperation)和人类在环。
他的核心警示:软件极其棘手,驾驶如此,AI Agent亦如此。 当他听到"2025年是Agent之年"时,他非常担忧——他认为这将是"Agent的十年",需要人类在环,需要审慎推进。这是软件,请认真对待。
钢铁侠套装:增强与代理
Karpathy用钢铁侠套装作为隐喻。他一直热爱钢铁侠,认为其在技术演进方向上异常精准:
- 钢铁侠套装既是增强工具(Augmentation)——Tony Stark可以驾驭它
- 也是代理(Agent)——在某些电影中,钢铁侠套装相当自主,可以自行飞行、寻找Tony等
这就是自主滑块——我们可以构建增强工具,也可以构建代理,两者都需要。但在当前阶段,面对仍有缺陷的LLM,Karpathy建议:与其构建钢铁侠机器人,不如构建钢铁侠套装。 不是炫目的自主Agent演示,而是部分自主产品——拥有定制GUI和UI/UX,使人类的生成-验证循环高速运转,同时不失对原则上可自动化工作的远见。产品中应有自主滑块,并思考如何随时间推移滑动这一滑块,使产品更加自主。
氛围编程:人人皆程序员
从专精到自然语言
Software 3.0的另一独特维度在于:它用英语编程,这是自然接口——突然间人人都是程序员,因为人人都会自然语言。过去需要五到十年学习才能从事软件工作,这一门槛已不复存在。
"氛围编程"的诞生
Karpathy创造了"氛围编程"(Vibe Coding)这一概念。他分享了有趣的故事:在Twitter上活跃了约15年,他仍无法预判哪条推文会病毒式传播、哪条无人问津。他原以为那条推文属于后者——只是洗澡时的一时兴起——但它却成了巨大的流行语。它之所以引起共鸣,是因为它为人们感受到了但无法言说的东西命名。如今甚至有了维基百科页面。
孩子们的氛围编程
Hugging Face的Thomas Wolf分享了一段视频:孩子们正在进行氛围编程。Karpathy认为这是一段无比温暖的视频——怎能看了之后对未来感到悲观?未来很美好。他认为氛围编程将成为软件开发的入门途径(Gateway Drug),他对这一代的未来并不悲观。
Karpathy的亲自实践
他也亲自尝试了氛围编程。氛围编程最适合构建极度定制化、市面上不存在的东西——尤其是在周末随性而为时:
- iOS应用:他其实不会Swift编程,但惊讶地发现自己能构建一个基础应用,仅用一天就在手机上运行了——无需先花五天阅读Swift文档
- Menu Gen应用:他遇到一个问题——到餐厅后看菜单不知所措,需要图片。于是他氛围编程了menu.app:拍照菜单,应用生成菜品图片。每位用户注册可获得5美元免费额度——这成了他生活中的主要成本中心,一个"负收入"应用
氛围编程的启示:代码不是最难的部分
Menu Gen给他带来的最大启示是:氛围编程写代码反而是简单的部分。当他试图将其变为真实产品——加入认证(Authentication)、支付(Payment)、域名(Domain Name)、推荐(Referral)、部署(Deployment)——这些DevOps工作极其困难,都不是代码,而是他在浏览器中点击各种界面,极其缓慢,又花了一整周。
他拥有了几个小时内可在笔记本电脑上运行的Menu Gen演示,但让它"真实化"却用了一周。原因在于:例如添加Google登录,Clerk库给出了大量指示——"去这个URL,点击这个下拉菜单,选择这个,去那里,点击那个"——一台计算机在告诉他应该执行的操作。"你来做好了,为什么是我在做?"
为Agent构建基础设施
新型数字信息消费者
Karpathy提出核心观点:现在出现了一类全新的数字信息消费者和操作者。过去只有人类通过GUI交互,或计算机通过API交互。现在出现了Agent——它们是计算机,但具有类人特征,是互联网上的"人灵",需要与我们的软件基础设施交互。我们能否为它们构建?
llms.txt:直接与LLM对话
正如网站上可以有robots.txt来指导网络爬虫的行为,同样可以有llms.txt——一个简单的Markdown文件,告诉LLM这个域名是关于什么的。这对LLM来说非常易读。如果让LLM解析网页HTML,则容易出错且不可靠。直接对LLM说话是值得的。
文档的LLM化
大量文档目前是为人类编写的——包含列表、粗体、图片——这些LLM无法直接访问。一些服务正在将文档专门转为LLM友好格式:Vercel和Stripe是先行者,提供Markdown格式的文档,而Markdown对LLM极其友好。
但不仅是格式转换——文档内容也需要改变。只要文档中出现"点击这里",对LLM就是问题——LLM目前无法原生执行点击操作。Vercel正在将每个"点击"替换为等效的curl命令,LLM Agent可以代替执行。
模型上下文协议
Anthropic推出的模型上下文协议(Model Context Protocol, MCP)是另一种与Agent——这一新型数字信息消费者——直接对话的协议方式。
LLM友好的数据摄取工具
一些实用工具正在帮助以LLM友好格式摄取数据:
- GitHub Ingest:将GitHub URL中的
github替换为github.ingest,即可将所有文件拼接为单一文本,附带目录结构,直接复制粘贴到LLM中使用 - Deep Wiki:不仅提供原始文件内容,还会让Devon对GitHub仓库进行分析,生成完整的文档页面,更便于复制给LLM使用
Karpathy喜爱这些只需更改URL即可让内容对LLM可访问的工具。
与LLM半途相遇
Karpathy指出:虽然LLM现在(且未来更将如此)能够自主浏览和点击,但仍然值得与LLM半途相遇(Meet LLMs Halfway)——让信息对LLM更易访问——因为使用LLM浏览和点击仍然相当昂贵且困难。许多软件将因非活跃维护而长期无法适配,因此我们需要这些中间工具。他对两种路径都持乐观态度。
总结与展望
Karpathy总结道:这是一个进入行业的绝佳时机。我们需要重写大量代码,这些代码将由专业开发者和氛围编程者共同编写。
LLM兼具公用事业、晶圆厂和操作系统的属性,但最贴切的类比是操作系统——而我们正处于LLM操作系统的1960年代。大量类比可以跨领域对应。
这些LLM如同有缺陷的"人灵",我们需要学习与之协作。为此,需要调整我们的基础设施。构建LLM应用时,他描述了与LLM高效协作的方式、使之成为可能的工具、以及如何高速旋转生成-验证循环来创建部分自主产品。
此外,大量代码还需要直接为Agent编写。
回到钢铁侠套装的类比——在未来十年,我们将看到自主滑块从左向右滑动。这将非常有趣,Karpathy迫不及待地期待与所有人一同构建这一切。