AI大神、前OpenAI创始成员Andrej Karpathy(安德烈·卡帕西)近日在Y Combinator AI Startup School进行了题为《Software in the era of AI》的演讲。本文为此次演讲的中文版。
原视频链接:https://www.youtube.com/watch?v=LCEmiRjPEtQ
卡帕西: 大家好。我很高兴今天能来到这里,和大家聊聊人工智能时代的软件。我知道在座的许多听众,无论是本科生、硕士生还是博士生,都即将踏入这个行业。我认为现在进入这个行业,是一个极其独特且非常有趣的时期。
之所以令人兴奋,是因为软件正在再次发生变革。我说“再次”,是因为我之前也发表过类似的演讲。但关键在于软件总是在不断演进,所以我总有很多新内容来支撑新的演讲。而且我认为,它正在发生相当根本性的变化。
可以说,在过去的70年里,软件在如此根本的层面上并没有发生太大的变化,但在最近几年里,变革却相当迅速。这意味着有海量的工作等待我们去完成,也有大量的软件需要被编写和重构。
所以,让我们审视一下软件的领域。如果我们将它想象成一张软件地图,我们就可以开始理解当前的格局以及在这个不断发展的领域中所蕴藏的机会。
GitHub,它就像是所有已编写软件的集合。这些是给计算机的指令,用于在数字空间中执行各种任务。如果放大来看,你会看到各种不同的代码仓库,这代表了所有已经编写出来的代码。

几年前,我注意到软件正在发生变化,出现了一种新型的软件,我当时称之为 Software 2.0。这个概念的核心是,Software 1.0 是你亲手编写的代码,而 Software 2.0 基本上就是神经网络,尤其是指神经网络的权重。你并非直接编写这些“代码”,更多的是通过调整数据集,然后运行优化器来创建神经网络的参数。我认为在当时,神经网络仅仅被视为另一种分类器,比如决策树之类的,所以我感觉这个框架的提法更为贴切。现在,我们在 Software 2.0 领域实际上有了类似 GitHub 的东西,我认为Hugging Face Hub 基本上就相当于 Software 2.0 领域的 GitHub。还有 Model Atlas,你可以在那里可视化所有已“编写”的模型。

顺便提一下,如果你好奇,中间那个巨大的圆点代表的是图像生成器 Flux 的参数。所以,每当有人在 Flux 的基础上微调 LoRa 时,你就在这个空间里创造出了一种新的图像生成器。所以基本上,我们有 Software 1.0,指的是用于计算机编程的传统代码。Software 2.0 则是用于“编程”神经网络的权重。这里有一个 AlexNet 的例子,它是一个图像识别神经网络。
直到最近,我们所熟悉的神经网络更像是功能固定的计算机,专为图像分类等特定任务而设计。然而,情况发生了变化——我认为这是一个相当根本性的变化——神经网络已经发展到可以用大型语言模型(LLM)进行编程。
我认为这是一个全新的、独特的事物;它代表了一种新型计算机。在我看来,它值得拥有一个新名称:Software 3.0。本质上,你的提示(prompt)现在就是程序,用于指导 LLM 的行为。值得注意的是,这些提示是用英语编写的,这使得它成为一种非常有趣的编程语言形式。

总结一下它们的区别:例如,如果你要做情感分类,你可以想象用 Python 编写一些代码来实现,或者你可以训练一个神经网络,或者你可以简单地向一个大型语言模型发出提示。这里展示的是一个 few-shot 提示,你可以想象通过修改它,以稍微不同的方式来“编程”这台计算机。

而且我认为我们正在目睹,或许你已经注意到,GitHub 上的许多代码不再仅仅是纯粹的代码了,其中夹杂了大量的英语描述。所以我觉得一种新的代码类别正在形成。因此,这不仅是一种新的编程范式,更令人惊奇的是,它是用我们的母语——英语——进行的。所以当几年前,我猜现在已经是几年前了,这件事让我感到非常震撼。

令人惊奇的是,我们现在正用英语为计算机编程。当我在特斯拉工作,致力于开发 Autopilot(自动辅助驾驶系统),试图让汽车能够自动驾驶时,我曾展示过这张幻灯片。你可以想象汽车的各种输入在底部,它们通过软件栈最终输出转向和加速指令。

当时我注意到,Autopilot 系统中包含了大量的 C++ 代码,这是 Software 1.0 的代码,同时也有一些用于图像识别的神经网络。我观察到,随着时间的推移,我们不断改进 Autopilot,神经网络的能力和规模都在持续增长。
尽管如此,所有的 C++ 代码依然存在,这揭示了传统编程与较新的机器学习技术之间复杂的互动关系。这种演变凸显了软件开发的转变,说明了机器学习正日益集成到曾经完全依赖于 C++ 等传统编程语言的系统中。
而且,许多最初用 Software 1.0 实现的功能和能力,都逐渐迁移到了 Software 2.0。例如,大量来自不同摄像头图像以及跨时间序列的信息整合工作,都是由神经网络完成的。
LLM 兼具公用事业、晶圆厂和操作系统的特性 → 新的 LLM OS(操作系统),由实验室制造(fabbed),如公用事业般分发(目前)。许多历史类比适用——我的看法是我们正处于计算领域的约20世纪60年代。

我确实认为这句话捕捉到了一些非常有趣的特性,即 LLM 现在无疑展现出了公用事业的属性。像 OpenAI、Google (Gemini)、Anthropic 等 LLM 实验室投入资本支出 (CapEx) 来训练 LLM,这有点像建设电网,然后需要运营支出 (OpEx) 通过 API 向我们所有人提供智能服务。

这种服务是通过计量付费来实现的,我们按百万 token 或类似的单位付费。而且我们对这个 API 有很多类似公用事业的需求:我们要求低延迟、高正常运行时间、一致的服务质量等等。在电力系统中,你可能会有一个转换开关,这样你可以将电力来源从主电网切换到太阳能、电池或发电机。在 LLM 领域,我们则可能有 OpenRouter 这样的工具和现存的众多 LLM。因为 LLM 是软件,它们并不争夺物理空间。所以,同时存在六家“电力”供应商并且你可以在它们之间切换是可以接受的,对吗?因为它们不像传统能源那样直接竞争。

而且我认为还有一点非常引人入胜,我们在过去几天确实也见证了这一点:很多 LLM 都宕机了,人们因此受阻,无法工作。我觉得很神奇的是,当最先进的 LLM 宕机时,这在某种程度上就像是全球范围的“智能衰减”。
这类似于电网电压不稳时的情况。随着我们对这些模型的依赖日益增加——这种依赖已经相当显著,并且我认为还会继续增长——地球似乎也因此变得“更笨”了。但 LLM 不仅仅具备公用事业的属性。
也可以说它们具备了一些晶圆厂 (fab) 的属性。原因在于构建 LLM 所需的资本支出相当巨大。这不像仅仅建造某个发电站那么简单,对吧?你投入的是巨额资金,而且我认为这项技术的复杂性正在迅速增长。
想象一下,当你使用NVIDIA GPU,只关注软件而不涉及硬件时,这有点像芯片设计公司(Fabless)的模式。但如果你同时也在构建自己的硬件,像谷歌那样在TPU上训练模型,那就更像英特尔模式,即拥有自己的芯片制造厂(Foundry)。所以,我觉得这些类比都有其合理之处。
然而,在我看来,最贴切的类比或许是将LLM比作操作系统。因为它们远不止是电力或自来水这样的基础资源,它们并非像自来水一样,作为一种标准化商品出现。它们是日益复杂的软件生态系统,因此不像电力那样是简单的商品。有趣的是,LLM的生态系统正以非常相似的方式形成:我们有一些闭源的提供商,比如Windows或macOS。

我认为LLM领域也是如此,我们有一些相互竞争的闭源提供商,而Llama生态系统目前可能正朝着类似Linux的方向发展。再次强调,我认为现在还为时尚早,因为这些模型目前还相对简单,但我们已经开始看到这不仅仅关乎LLM本身,更关乎所有的工具调用、多模态能力以及它们如何协同工作。
所以,当我不久前意识到这一点时,我试着将其勾勒出来,得出的结论是:LLM有点像一种全新的操作系统。因此,LLM也是一种新型计算机。

上下文窗口好比内存,LLM则负责协调内存和计算,利用这些能力来解决问题。从这个角度看,它确实非常像一个操作系统。
再举几个例子。比如,如果你想下载一个应用程序,假设是VS Code,你可以下载它并在Windows、Linux或Mac上运行。同样地,你可以选择一个LLM应用,比如Cursor,然后在GPT、Claude或Gemini系列模型上运行它。
它只是一个下拉菜单的选择。这方面也很相似。更让我感到震撼的类比是,我们当前的处境:

对于这种新型计算机而言,LLM的计算成本依然高昂,这使得LLM不得不集中在云端。我们都只是通过网络与其交互的瘦客户端,无法充分利用这些计算机的全部潜能。因此,采用分时模式是合理的——当它们在云端运行时,我们每个人都只是批处理任务中的一个维度。这与早期计算机的形态非常相似:操作系统在云端,所有数据都是流式传输,并且采用批处理方式。

个人计算革命尚未到来,因为它在经济上尚不可行,缺乏现实意义。然而,我认为有些人正试图改变这一格局。事实证明,像Mac mini这样的设备非常适合运行某些LLM。如果你进行单批次推理,这完全是内存密集型任务,因此实际上是可行的。
我认为这些可能预示着个人计算的早期迹象。但这尚未真正发生,其最终形态也尚不明朗。也许你们中的一些人会洞察先机,它究竟是什么,如何运作,或者它应该是什么形态。再举一个类比:每当我直接通过文本与ChatGPT或某个LLM对话时,感觉就像通过终端与操作系统交互。就像是纯文本界面,直接访问操作系统。而且我认为,一种通用的图形用户界面(GUI)尚未被真正发明出来。比如ChatGPT的“探测气泡”(这可能指某种特定功能或示例)。当然,我们稍后将探讨的一些应用确实有GUI,但还没有一种通用的GUI能适用于所有任务——如果这种说法合理的话。

在某些方面,LLM与操作系统和早期计算有着相当独特的区别。我曾写过关于一个让我觉得这次非常不同的特定属性:那就是LLM似乎颠覆了技术普及的方向。例如,电力、密码学、计算、飞行、互联网、GPS等许多以往的变革性新技术,通常首先被政府和企业采用,因为它们新颖、昂贵,之后才会普及到消费者。但我感觉大模型(LLMs)的情况恰恰相反。早期计算机可能完全服务于弹道计算和军事用途,但对于大模型而言,它们却常常被用来解决‘如何煮鸡蛋’这类日常问题。我大部分时间就是这样使用它们的。所以,我们拥有了一台神奇的新型计算机,它却在帮我煮鸡蛋,这对我来说真的很有趣。它并没有用于进行一些真正疯狂的军事弹道计算或某些尖端技术。实际上,企业和政府在采纳这些技术方面,反而落后于我们普通大众。所以这完全是反过来的。我认为这或许能启发我们思考如何使用这项技术,以及哪些会是首批应用等等。

大模型心理学:大模型 = “人类精神”,人类的随机模拟器,模拟器是一个自回归 Transformer。由于它们是在人类数据上训练的,所以具有一种涌现的心理,同时在某些方面超人,但在许多其他方面也很容易犯错。考虑到这一点,我们如何才能有效地与它们携手合作?
这太不可思议了。对我而言,现状如此令人难以置信,而现在轮到我们进入这个行业,为这些计算机编程了。这太疯狂了。所以我认为这非常了不起。
在我们为大模型编程之前,我们必须花些时间思考它们究竟是什么。我尤其喜欢探讨它们的“心理”。所以,我倾向于将大模型看作是某种“人类精神”。它们是对人类行为的随机模拟,而这个模拟器恰好是一个自回归Transformer。

Transformer是一种神经网络。它基本上是在词元(token)层面进行处理;它一块接一块地处理数据,每一块数据都有几乎等量的计算需求。这个模拟器当然也涉及到权重参数。这些数据源自互联网等。最终你得到了这样一个模拟器,因为它是在人类数据上训练的,所以它具有一种类人的涌现心理。
所以你首先会注意到,大模型拥有百科全书般的知识和记忆力,它们能记住海量信息,远超任何单个人类个体,因为它们阅读了巨量文本。这让我想起了电影《雨人》(Rain Man),我非常推荐大家观看。这是一部精彩绝伦的电影,我非常喜欢。片中的达斯汀·霍夫曼(Dustin Hoffman)饰演的角色,他拥有近乎完美的记忆力,能够像背诵电话簿一样记住所有姓名和号码。我觉得大模型在这一点上与之非常相似。它们能轻而易举地记住SHA哈希值和许多其他信息。所以它们在某些方面确实拥有超乎常人的能力,但同时,它们也存在许多可以说是认知上的缺陷。

它们有时会编造信息(出现幻觉),并且对自身的内部认知模型掌握不佳,至少不够充分——尽管这一点已有所改善,但仍不完美。它们表现出不均衡的智能水平:在某些解决问题的领域展现出超人能力,却又可能固执地认为9.11大于9.9,或者“strawberry”(草莓)这个词里有两个“r”。这些都是一些著名的例子。但基本上,它们存在一些容易导致错误的“粗糙之处”。我认为这也是其独特之处。它们还有点像患有顺行性遗忘症。我的意思是,如果你的团队加入一位新同事,这位同事会随着时间推移逐渐了解你的团队和工作方式,他们会理解……

人类在工作中会接触到大量的背景信息,然后回家睡觉,这个过程帮助他们巩固知识,并随着时间的推移积累专业技能。大模型天生不具备这种能力,我认为这在模型研发中尚未得到真正的解决。所以上下文窗口(context windows)更像是工作记忆,你需要非常直接地对其进行编程,因为它们不会自动变得更聪明。我认为很多人会因为这种类比而产生误解。在流行文化中,我推荐大家看两部电影。电影主角的参数(weights)是固定的,他们的上下文窗口每天早上都会被清空。这种情况下,他们很难正常工作或建立人际关系。而类似的情况,正持续发生在大模型身上。我还想指出一点,那就是大模型使用中一些与安全相关的限制。例如,大模型相当容易受骗。
它们可能会泄露你的数据等等。此外,还有许多其他与安全相关的考量因素。所以基本上,长话短说,你必须认识到,大模型一方面在某些方面展现出超凡的能力,另一方面又存在一系列认知缺陷和问题。然而,它们又极其有用。那么,我们该如何对其编程?如何规避其缺陷,同时充分利用其超能力呢?

大模型驱动:构建部分自主应用
现在,我想谈谈如何把握使用这些模型的机会,以及其中一些最大的机遇。这不是一个详尽无遗的列表,只是一些我认为对本次演讲而言比较有趣的方面。
首先让我感到兴奋的是我称之为“部分自主应用”的概念。以编码为例。你当然可以直接使用 ChatGPT。
然后复制粘贴错误报告,获取代码,再到处复制粘贴。但何必如此呢?为什么要直接与底层模型交互,而不是开发一个专用应用呢?那样会更有意义。我想你们很多人都用过 Cursor,我也在用。Cursor 正是这样一个理想的替代方案。

你不会想直接使用 ChatGPT。我认为 Cursor 是早期大模型应用的一个优秀范例,它具备许多卓越特性。
特别地,你会注意到 Cursor 拥有一个传统界面,允许人类像以前一样手动完成所有工作。但除此之外,它集成了大模型,使我们能够以更大的“代码块”或“任务单元”进行处理。因此,我认为大模型应用的一些共同且有用的特性值得强调:第一,它们承担了大量的上下文管理工作。第二,它们协调了对大模型的多次调用。
这些都为你协调好了。另一点我认为非常重要但可能未被充分理解的是:特定应用的图形用户界面(GUI)及其重要性。因为你不会想仅仅通过文本与系统交互。文本难以阅读、解释和理解,而且,你不会想直接通过文本执行某些操作。所以,最好能直接看到一个差异对比(diff),你可以看到哪些内容被添加,哪些被删减。只需使用 Command+Y 接受或 Command+N 拒绝要容易得多,而不是非得通过文本输入,对吧?GUI 允许人类审计这些易出错系统的工作,并加快审查速度。我稍后会再谈到这一点。我想指出的最后一个功能是所谓的“自主度滑块”。例如,在 Cursor 中,你可以使用顶部代码补全。

你可以使用 Command+L 修改整个文件,或者使用 Command+I,它能让你在整个代码仓库中进行操作——这更接近完全自主的代理模式。因此,你可以控制这个自主度滑块,根据当前任务的复杂程度,决定赋予工具多大程度的自主权来完成任务。再举一个相当成功的 LLM 应用案例:Perplexity。它也具备与我刚才在 Cursor 中指出的非常相似的功能:整合大量信息、协调多个 LLM 调用、拥有一个允许你审查其工作的 GUI(例如,它会列出引用来源)。
它同样有一个自主度滑块:你可以进行快速搜索,或进行研究,甚至可以进行深度研究并在10分钟后获取结果。这些都是你赋予工具不同程度自主权的表现。
所以我的问题是:我预感许多软件都将演变为部分自主的形态。它会是什么样子?对于那些正在维护产品和服务的人们,你们将如何使自己的产品和服务实现部分自主?
LLM 能看到人类所见的一切吗?LLM 能像人类一样行动吗?人类能否监督并持续参与到这个过程中?因为,需要再次强调的是,这些系统容易出错,远未达到完美。

在 Photoshop 或类似软件中,变更的差异对比(diff)会是什么样子?而且,许多传统软件现在都有各种各样的控制开关。
所有这些都必须改变,以便 LLM 能够访问和操作。我想强调一点,许多 LLM 应用中有一个方面我认为未得到应有的重视:我们现在更像是在与 AI 协作——通常 AI 负责生成,而我们人类负责验证。让这个“生成-验证”循环尽可能快地运转,符合我们的最大利益,这样我们才能高效完成大量工作。

我认为主要有两种方法可以实现这一点。第一,大幅加快验证速度。GUI 在这方面极其重要,因为它利用了我们大脑中的视觉处理能力——可以将其比作我们内置的“计算机视觉 GPU”。阅读文本费力且枯燥,但视觉感知则直观有趣,它就像一条通往大脑的快速通道。总的来说,我是这么看的。
第二,我们必须给 AI “套上缰绳”。我认为很多人对 AI 代理(agent)过于兴奋。但如果 AI 直接给我一个包含 1000 行代码改动的差异(diff)提交到我的代码仓库,那对我来说没什么用。我仍然是瓶颈,因为我必须确保这些代码没有引入 bug,确保它在做正确的事情,没有安全问题等等,对吧?所以我认为,基本上,我们必须让这个协作流程非常非常快,并且要想办法给 AI 套上缰绳,因为它有时会“反应过度”。这有点像这样。这就是我进行 AI 辅助编程时的感觉。如果我只是随意写写代码,一切看起来都很好;但如果我真的想把工作做好,情况就没那么理想了。
和你们许多人一样,我正在尝试探索一些方法,在我的编程工作流程中使用这些代理进行 AI 辅助编程。在我自己的工作中,我总是警惕过大的代码差异(diff)。我倾向于小步快跑,确保一切都在掌控之中,并让这个迭代循环尽可能快地运转。我倾向于处理小块的、单一的、具体的问题。所以我认为,你们中的许多人可能也在探索与 LLM 协同工作的类似方法。我还看到一些博客文章,试图为与 LLM 协作制定最佳实践。这里有一篇我读过的文章...
它讨论了一些技巧,其中一些正是关于如何给 AI“套上缰绳”。例如,如果你在提示 AI 时,AI 可能不会完全按你的意图行事,这时验证就会失败。你可能会要求它做别的事情,如果验证再次失败,你就会陷入反复修改的循环。因此,花更多时间使你的提示更具体、更明确是有意义的,这会增加成功验证的概率,从而让你能够继续前进。所以我认为我们许多人最终都会掌握类似这样的技巧。在我自己的工作中,我也对 AI 时代下的教育形态非常感兴趣。
我想大部分思考都集中在如何给 AI “套上缰绳”。我不认为直接对 ChatGPT 说“嘿,教我物理”就能奏效。我认为这行不通,因为 AI 很容易偏离主题,失去方向。所以对我来说,这实际上需要两个独立的应用程序。例如,一个给老师用的应用,另一个给学生用的应用。
在这两种情况下,我们都有了一个课程的“中间产物”,它是可审查的。我们可以确保其质量,确保内容一致性,并且 AI 在特定的教学大纲、特定的项目进展等方面被有效地“约束”住了。这样一来,成功的可能性更高,AI 也不会偏离轨道。我还想讲一个类比。
卡帕西: 我在特斯拉工作了五年。特斯拉的 Autopilot 也是一个部分自主的产品,并且与我们讨论的有很多共通之处。例如,仪表盘上就有 Autopilot 的 GUI,它会实时显示神经网络“看到”了什么。我们也有自主度滑块。在我任职期间,我们逐步为用户实现了越来越多自主化的任务。也许我想分享的故事是关于我第一次体验完全自动驾驶的经历。

可以想象一下,在那个年代,Google Glass 还算是个新鲜事物。你们中许多人可能还很年轻,甚至都不知道那是什么。但那确实是相当早期的探索了。
我们坐上车,在帕洛阿尔托(Palo Alto)周边行驶了大约30分钟,途经高速公路和城市街道。那次驾驶堪称完美,全程零人工干预。那是2013年,距今已经快12年了。
这让我感到非常震惊。当时我经历了那次完美的驾驶演示,心想:“哇,自动驾驶的时代指日可待了,因为它刚刚成功了!这太不可思议了!”但时至今日,12年过去了,我们仍在研究自动驾驶,仍在研发驾驶代理(driving agents)。
即便到了现在,我们实际上也还没有完全解决这个问题。你可能看到 Waymo 的车在路上行驶,但很多这类自动驾驶仍然需要大量的远程操作和人工介入。所以我们甚至还不能宣布完全成功。但我相信,自动驾驶最终一定会成功,只是花费的时间远超预期。软件开发非常棘手,就像自动驾驶一样。当我看到诸如“2025年将是AI代理之年”这样的说法时,我非常担心。我觉得这应该是“AI代理的十年”,而且还需要相当长的时间。我们需要人类的参与,必须谨慎行事。这毕竟是软件,我们需要严肃对待。
我经常想到的一个类比是钢铁侠的战衣。我一直很喜欢钢铁侠,因为它精准地反映了技术及其演进过程。我欣赏钢铁侠战衣的一点是,它既是增强工具,也是在托尼·斯塔克不在时能够自主行动的代理。在一些电影中,战衣可以自主操作,自行飞行并找到托尼。这正反映了“自主度滑块”的概念——我们可以构建增强工具,也可以创建代理,理想情况下,我们希望两者兼得。
然而,在现阶段,我认为与这些容易犯错的大语言模型(LLMs)合作,更像是拥有“钢铁侠战衣”,而非直接得到一个全能的“钢铁侠机器人”。重点不再是展示自主代理的炫目演示,而是开发具有部分自主性的产品。这些产品需要定制化的图形用户界面(GUIs)和用户界面/用户体验(UI/UX)设计,并且我们要确保人工验证的循环尽可能快速。原则上,不应忽视将这项验证工作自动化的可能性。你的产品中应该集成一个自主度滑块,并且你应该思考如何随着时间的推移逐步提升这种自主性。
大语言模型(LLMs)以自然语言编程 → 软件可访问性的巨大飞跃!(没错,这就是“氛围感编程” vibe coding)
我想稍微转换一下话题,讨论另一个独特的维度。现在不仅出现了一种新型的编程范式——它使软件能够实现自主性,而且这种“编程语言”就是自然语言(如英语),自然语言充当了天然的接口。突然之间,似乎每个人都成了程序员,因为每个人都会说像英语这样的自然语言。这对我而言极具前景和吸引力,而且我认为这是前所未有的变革。

过去,你需要花费五到十年的时间学习才能从事软件开发工作,但现在情况已然不同。所以我不知道是否有人听说过“氛围感编程”(vibe coding)。这条推文算是介绍了这个概念,我听说它现在成了一个流行的梗(meme)。有趣的是,我已经用了大约15年的Twitter,但至今仍无法预测哪条推文会火,哪条会无人问津。
我本以为那条推文会像后者一样默默无闻。我也不知道,它只是一连串的灵感迸发,却意外成了一个大热的梗 (meme)。我其实很难说清,但我想它大概是触动了大家的共鸣,为那种人人心有戚戚焉、却又难以言表的感觉赋予了名称。所以现在它甚至有了维基百科页面之类的东西。

主持人: 这就像……是的,现在感觉像是你做出了一个重大贡献,或者类似的事情。
卡帕西: Hugging Face 的 Tom Wolf 分享了一个我很喜欢的精彩视频。视频里是一群正在“vibe coding”的孩子们。
卡帕西: 我觉得这个视频非常暖心。我太爱这个视频了。看了这个视频,你怎么还会对未来感到沮丧呢?未来一片光明。我认为这最终会成为软件开发的新入口。我对这一代人的未来并不悲观。而且,我太爱这个视频了。

所以我也尝试了“vibe coding”,因为它太有趣了。当你想要构建一些高度定制化、市面上又找不到的东西时,“vibe coding”就非常棒了。你可以随心所欲地去做,比如就因为那天是周六。我用它构建了一个 iOS 应用。虽然我其实不会用 Swift 编程,但我居然能做出一个非常基础的应用,这让我非常惊喜。我就不细说了,因为它非常简单。但我喜欢的是,这只花了我一天时间,当天晚上它就在我的手机上运行起来了。我当时就觉得,哇,这太酷了!我不需要花五天时间去啃 Swift 文档之类的东西才能开始。

我还“vibe code”了一个叫 Menugen 的应用,它已经上线了;大家可以在 menugen.app 上试试。我经常遇到一个问题:去餐馆看菜单时,完全不知道那些菜名是什么,特别需要图片来帮助理解。既然市面上没有这样的工具,我想,嘿,那我就用“vibe coding”做一个吧。它的用法是:你访问 menugen.app,拍下菜单照片,Menugen 就会生成菜品图片。另外,注册用户都可以免费获得 5 美元的体验额度。
卡帕西: 所以,这对我来说成了一个主要的成本支出点。这个应用目前是负盈利状态,我在 Menugen 上已经亏了不少钱

有意思的是,Menugen 的演示版,在我的笔记本上几个小时就跑起来了。但我之后却花了一周时间把它真正部署上线,原因就是那些极其繁琐的配置。举个例子,如果你想给网页添加 Google 登录功能,Clerk 这个库会提供一大堆集成指南来教你怎么做。简直疯了!它会让你访问某个 URL,点击某个下拉菜单,选择某个选项,然后再去另一个地方点击另一个按钮。感觉就像是电脑在指挥我该怎么操作。我就想:你倒是自己做啊!为什么非得我来点这些?这到底是什么情况?我不得不一步步照着说明来。简直不可理喻!
大型语言模型(LLMs):数字信息的新一代消费者与操纵者(继图形用户界面/人类和应用程序接口/程序之后的新角色)→ 为AI代理而构建!
卡帕西: 因此,我演讲的最后一部分将聚焦于:我们能否直接为AI代理构建应用?我不想再做那些繁琐的点击操作了。AI代理能代劳吗?由此,我认为在数字信息的消费者和操纵者中,出现了一个全新的类别。过去,要么是人类通过图形用户界面(GUI)与信息交互,要么是程序通过应用程序接口(API)交互。但现在,我们有了一种全新的角色:AI代理。它们是计算机程序,却又带有些许人性,如同互联网上的“灵魂”,需要与软件基础设施进行交互。我们能为它们构建怎样的工具?这是一个全新的课题。

目前大量的文档都是为人类阅读而设计的,所以你会看到列表、粗体、图片等元素。这些对 LLM 来说并不直接友好。因此,我看到一些服务已经开始将文档专门转换为 LLM 友好的格式。例如,Vercel 和 Stripe 就行动得比较早,还有其他一些服务也在这样做,它们开始提供 Markdown 格式的文档。Markdown 对 LLM 来说非常易于解析,这非常好。
再分享一个我的亲身经历:大家可能知道 3Blue1Brown,他制作的数学动画非常精美。

卡帕西: 我非常喜欢他编写的一个名为 Manim 的动画库。我也想用它来做动画。关于如何使用 Manim 有海量的文档,我实在不想逐一阅读。于是,我把整个文档复制粘贴给一个 LLM,告诉它我想要实现的效果,结果它一次就成功了!LLM 完全按照我的要求生成了动画,这让我喜出望外。如果我们能让文档对 LLM 友好易懂,将会释放出巨大的潜力。我认为这太棒了,应该有更多这样的尝试。
但我想指出,这不仅仅是把现有文档转换成 Markdown 格式那么简单,那只是最容易的一步。我们实际上需要改变文档的内容本身。因为一旦文档中出现“点击”这样的指令,就会带来问题。LLM 目前还无法直接执行这类操作。例如,Vercel 正在用等效的 curl 命令来替换所有“点击”操作的描述,这样你的 LLM 代理就可以代你执行这些命令了。我觉得这种思路非常巧妙。
此外,Anthropic 推出了一个“模型上下文协议”(Model Context Protocol),它提供了另一种直接与 AI 代理沟通的方式——再次强调,代理是数字信息新一代的消费者与操纵者。我对这些新思路非常看好。另外,我也很欣赏市面上涌现的各种小工具,它们能帮助我们以 LLM 友好的格式来提取和处理数据。例如,当我访问一个 GitHub 仓库(比如我的 nanoGPT 仓库)时,我无法直接把仓库内容喂给 LLM 并进行提问,因为 GitHub 展示的是为人类设计的界面。
通过将 URL 中的 'github.com' 改为 'git.jst.ai',它就能把所有文件整合成一个大的文本文件,并生成一个目录结构,方便你直接复制粘贴到你喜欢的 LLM 中。一个更强大的例子是 DeepWiki,它不仅提供文件的原始内容,还会对 GitHub 仓库进行分析。DeepWiki 会专门为你的仓库构建全面的文档页面,这对于将其内容输入 LLM 非常有帮助。
我喜欢所有这些小工具,它们的核心功能就是通过修改 URL,就能让某些内容变得对 LLM 友好。这些都非常好,我认为未来应该有更多这类创新。
我想补充一点,未来 LLM 完全有可能——甚至在今天就已经部分实现——能够自行浏览网页、点击按钮等等。但我仍然认为,主动去适应 LLM,在某种程度上“迁就”它们,让它们更容易地访问和理解信息,是非常值得的。因为目前让 LLM 直接处理复杂的人类界面仍然成本高昂且困难重重。所以我确实认为,大量的软件,特别是那些不属于主流活跃项目或核心数字基础设施的“长尾”应用,尤其需要这些辅助工具。而对于大多数其他情况,我认为这种“双向奔赴”的努力是非常值得的。所以,如果这么说能讲通的话,我对这两种趋势(LLM能力增强和我们主动适配)都非常看好。

总而言之,现在是投身这个领域的黄金时代。我们将需要重写海量的代码。其中许多代码仍将由专业人士和程序员编写。这些 LLM 有点像公用事业,类似于芯片制造厂(fabs),但它们尤其像操作系统。然而,它们目前尚处于非常早期的阶段,好比 1960 年代的操作系统。我认为很多类比都说得通。这些 LLM 就像是容易犯错的小精灵,我们必须学会如何与它们协作。要做到这一点,我们就需要相应地调整我们的基础设施。

在构建这些 LLM 应用的过程中,我介绍了一些与 LLM 有效协作的方法,一些实现这些协作的小工具,以及如何通过快速迭代来打造具有部分自主能力的产品。同时,我们也需要为 AI 代理更直接地编写大量适配代码。
无论如何,回到钢铁侠战甲的那个比喻,我认为在未来十年,我们会看到那个“滑块”(人机协作的比例)不断从左(更多人工)向右(更多AI自主)移动。我非常期待看到那将是怎样一番景象,并迫不及待地想和大家一起去构建它。谢谢大家!
原视频链接:https://www.youtube.com/watch?v=LCEmiRjPEtQ
卡帕西: 大家好。我很高兴今天能来到这里,和大家聊聊人工智能时代的软件。我知道在座的许多听众,无论是本科生、硕士生还是博士生,都即将踏入这个行业。我认为现在进入这个行业,是一个极其独特且非常有趣的时期。
之所以令人兴奋,是因为软件正在再次发生变革。我说“再次”,是因为我之前也发表过类似的演讲。但关键在于软件总是在不断演进,所以我总有很多新内容来支撑新的演讲。而且我认为,它正在发生相当根本性的变化。
可以说,在过去的70年里,软件在如此根本的层面上并没有发生太大的变化,但在最近几年里,变革却相当迅速。这意味着有海量的工作等待我们去完成,也有大量的软件需要被编写和重构。
所以,让我们审视一下软件的领域。如果我们将它想象成一张软件地图,我们就可以开始理解当前的格局以及在这个不断发展的领域中所蕴藏的机会。
GitHub,它就像是所有已编写软件的集合。这些是给计算机的指令,用于在数字空间中执行各种任务。如果放大来看,你会看到各种不同的代码仓库,这代表了所有已经编写出来的代码。

几年前,我注意到软件正在发生变化,出现了一种新型的软件,我当时称之为 Software 2.0。这个概念的核心是,Software 1.0 是你亲手编写的代码,而 Software 2.0 基本上就是神经网络,尤其是指神经网络的权重。你并非直接编写这些“代码”,更多的是通过调整数据集,然后运行优化器来创建神经网络的参数。我认为在当时,神经网络仅仅被视为另一种分类器,比如决策树之类的,所以我感觉这个框架的提法更为贴切。现在,我们在 Software 2.0 领域实际上有了类似 GitHub 的东西,我认为Hugging Face Hub 基本上就相当于 Software 2.0 领域的 GitHub。还有 Model Atlas,你可以在那里可视化所有已“编写”的模型。

顺便提一下,如果你好奇,中间那个巨大的圆点代表的是图像生成器 Flux 的参数。所以,每当有人在 Flux 的基础上微调 LoRa 时,你就在这个空间里创造出了一种新的图像生成器。所以基本上,我们有 Software 1.0,指的是用于计算机编程的传统代码。Software 2.0 则是用于“编程”神经网络的权重。这里有一个 AlexNet 的例子,它是一个图像识别神经网络。
直到最近,我们所熟悉的神经网络更像是功能固定的计算机,专为图像分类等特定任务而设计。然而,情况发生了变化——我认为这是一个相当根本性的变化——神经网络已经发展到可以用大型语言模型(LLM)进行编程。
我认为这是一个全新的、独特的事物;它代表了一种新型计算机。在我看来,它值得拥有一个新名称:Software 3.0。本质上,你的提示(prompt)现在就是程序,用于指导 LLM 的行为。值得注意的是,这些提示是用英语编写的,这使得它成为一种非常有趣的编程语言形式。

总结一下它们的区别:例如,如果你要做情感分类,你可以想象用 Python 编写一些代码来实现,或者你可以训练一个神经网络,或者你可以简单地向一个大型语言模型发出提示。这里展示的是一个 few-shot 提示,你可以想象通过修改它,以稍微不同的方式来“编程”这台计算机。

而且我认为我们正在目睹,或许你已经注意到,GitHub 上的许多代码不再仅仅是纯粹的代码了,其中夹杂了大量的英语描述。所以我觉得一种新的代码类别正在形成。因此,这不仅是一种新的编程范式,更令人惊奇的是,它是用我们的母语——英语——进行的。所以当几年前,我猜现在已经是几年前了,这件事让我感到非常震撼。

令人惊奇的是,我们现在正用英语为计算机编程。当我在特斯拉工作,致力于开发 Autopilot(自动辅助驾驶系统),试图让汽车能够自动驾驶时,我曾展示过这张幻灯片。你可以想象汽车的各种输入在底部,它们通过软件栈最终输出转向和加速指令。

当时我注意到,Autopilot 系统中包含了大量的 C++ 代码,这是 Software 1.0 的代码,同时也有一些用于图像识别的神经网络。我观察到,随着时间的推移,我们不断改进 Autopilot,神经网络的能力和规模都在持续增长。
尽管如此,所有的 C++ 代码依然存在,这揭示了传统编程与较新的机器学习技术之间复杂的互动关系。这种演变凸显了软件开发的转变,说明了机器学习正日益集成到曾经完全依赖于 C++ 等传统编程语言的系统中。
而且,许多最初用 Software 1.0 实现的功能和能力,都逐渐迁移到了 Software 2.0。例如,大量来自不同摄像头图像以及跨时间序列的信息整合工作,都是由神经网络完成的。
LLM 兼具公用事业、晶圆厂和操作系统的特性 → 新的 LLM OS(操作系统),由实验室制造(fabbed),如公用事业般分发(目前)。许多历史类比适用——我的看法是我们正处于计算领域的约20世纪60年代。
卡帕西: 这是自动驾驶的软件栈。当时我就觉得这真的非常了不起。我想我们现在又看到了同样的事情发生,基本上我们拥有了一种新型软件,它正在渗透整个技术栈。我们现在有三种截然不同的编程范式。我认为如果你正准备进入这个行业,精通所有这些范式是一个很好的主意,因为它们各有优缺点,你可能希望根据具体功能,选择用 Software 1.0、2.0 还是 3.0 来实现。你是打算在神经网络中进行训练?还是直接向 LLM 提问?亦或这应该是一段明确的传统代码等等。所以我们都必须做出这些决策,并且能够自如地在这些范式之间切换。我现在想深入探讨的是,首先,在第一部分,我想谈谈 LLM 本身。

我确实认为这句话捕捉到了一些非常有趣的特性,即 LLM 现在无疑展现出了公用事业的属性。像 OpenAI、Google (Gemini)、Anthropic 等 LLM 实验室投入资本支出 (CapEx) 来训练 LLM,这有点像建设电网,然后需要运营支出 (OpEx) 通过 API 向我们所有人提供智能服务。

这种服务是通过计量付费来实现的,我们按百万 token 或类似的单位付费。而且我们对这个 API 有很多类似公用事业的需求:我们要求低延迟、高正常运行时间、一致的服务质量等等。在电力系统中,你可能会有一个转换开关,这样你可以将电力来源从主电网切换到太阳能、电池或发电机。在 LLM 领域,我们则可能有 OpenRouter 这样的工具和现存的众多 LLM。因为 LLM 是软件,它们并不争夺物理空间。所以,同时存在六家“电力”供应商并且你可以在它们之间切换是可以接受的,对吗?因为它们不像传统能源那样直接竞争。

而且我认为还有一点非常引人入胜,我们在过去几天确实也见证了这一点:很多 LLM 都宕机了,人们因此受阻,无法工作。我觉得很神奇的是,当最先进的 LLM 宕机时,这在某种程度上就像是全球范围的“智能衰减”。
这类似于电网电压不稳时的情况。随着我们对这些模型的依赖日益增加——这种依赖已经相当显著,并且我认为还会继续增长——地球似乎也因此变得“更笨”了。但 LLM 不仅仅具备公用事业的属性。
也可以说它们具备了一些晶圆厂 (fab) 的属性。原因在于构建 LLM 所需的资本支出相当巨大。这不像仅仅建造某个发电站那么简单,对吧?你投入的是巨额资金,而且我认为这项技术的复杂性正在迅速增长。
想象一下,当你使用NVIDIA GPU,只关注软件而不涉及硬件时,这有点像芯片设计公司(Fabless)的模式。但如果你同时也在构建自己的硬件,像谷歌那样在TPU上训练模型,那就更像英特尔模式,即拥有自己的芯片制造厂(Foundry)。所以,我觉得这些类比都有其合理之处。
然而,在我看来,最贴切的类比或许是将LLM比作操作系统。因为它们远不止是电力或自来水这样的基础资源,它们并非像自来水一样,作为一种标准化商品出现。它们是日益复杂的软件生态系统,因此不像电力那样是简单的商品。有趣的是,LLM的生态系统正以非常相似的方式形成:我们有一些闭源的提供商,比如Windows或macOS。

我认为LLM领域也是如此,我们有一些相互竞争的闭源提供商,而Llama生态系统目前可能正朝着类似Linux的方向发展。再次强调,我认为现在还为时尚早,因为这些模型目前还相对简单,但我们已经开始看到这不仅仅关乎LLM本身,更关乎所有的工具调用、多模态能力以及它们如何协同工作。
所以,当我不久前意识到这一点时,我试着将其勾勒出来,得出的结论是:LLM有点像一种全新的操作系统。因此,LLM也是一种新型计算机。

上下文窗口好比内存,LLM则负责协调内存和计算,利用这些能力来解决问题。从这个角度看,它确实非常像一个操作系统。
再举几个例子。比如,如果你想下载一个应用程序,假设是VS Code,你可以下载它并在Windows、Linux或Mac上运行。同样地,你可以选择一个LLM应用,比如Cursor,然后在GPT、Claude或Gemini系列模型上运行它。
它只是一个下拉菜单的选择。这方面也很相似。更让我感到震撼的类比是,我们当前的处境:

对于这种新型计算机而言,LLM的计算成本依然高昂,这使得LLM不得不集中在云端。我们都只是通过网络与其交互的瘦客户端,无法充分利用这些计算机的全部潜能。因此,采用分时模式是合理的——当它们在云端运行时,我们每个人都只是批处理任务中的一个维度。这与早期计算机的形态非常相似:操作系统在云端,所有数据都是流式传输,并且采用批处理方式。

个人计算革命尚未到来,因为它在经济上尚不可行,缺乏现实意义。然而,我认为有些人正试图改变这一格局。事实证明,像Mac mini这样的设备非常适合运行某些LLM。如果你进行单批次推理,这完全是内存密集型任务,因此实际上是可行的。
我认为这些可能预示着个人计算的早期迹象。但这尚未真正发生,其最终形态也尚不明朗。也许你们中的一些人会洞察先机,它究竟是什么,如何运作,或者它应该是什么形态。再举一个类比:每当我直接通过文本与ChatGPT或某个LLM对话时,感觉就像通过终端与操作系统交互。就像是纯文本界面,直接访问操作系统。而且我认为,一种通用的图形用户界面(GUI)尚未被真正发明出来。比如ChatGPT的“探测气泡”(这可能指某种特定功能或示例)。当然,我们稍后将探讨的一些应用确实有GUI,但还没有一种通用的GUI能适用于所有任务——如果这种说法合理的话。

在某些方面,LLM与操作系统和早期计算有着相当独特的区别。我曾写过关于一个让我觉得这次非常不同的特定属性:那就是LLM似乎颠覆了技术普及的方向。例如,电力、密码学、计算、飞行、互联网、GPS等许多以往的变革性新技术,通常首先被政府和企业采用,因为它们新颖、昂贵,之后才会普及到消费者。但我感觉大模型(LLMs)的情况恰恰相反。早期计算机可能完全服务于弹道计算和军事用途,但对于大模型而言,它们却常常被用来解决‘如何煮鸡蛋’这类日常问题。我大部分时间就是这样使用它们的。所以,我们拥有了一台神奇的新型计算机,它却在帮我煮鸡蛋,这对我来说真的很有趣。它并没有用于进行一些真正疯狂的军事弹道计算或某些尖端技术。实际上,企业和政府在采纳这些技术方面,反而落后于我们普通大众。所以这完全是反过来的。我认为这或许能启发我们思考如何使用这项技术,以及哪些会是首批应用等等。

大模型心理学:大模型 = “人类精神”,人类的随机模拟器,模拟器是一个自回归 Transformer。由于它们是在人类数据上训练的,所以具有一种涌现的心理,同时在某些方面超人,但在许多其他方面也很容易犯错。考虑到这一点,我们如何才能有效地与它们携手合作?
这太不可思议了。对我而言,现状如此令人难以置信,而现在轮到我们进入这个行业,为这些计算机编程了。这太疯狂了。所以我认为这非常了不起。
在我们为大模型编程之前,我们必须花些时间思考它们究竟是什么。我尤其喜欢探讨它们的“心理”。所以,我倾向于将大模型看作是某种“人类精神”。它们是对人类行为的随机模拟,而这个模拟器恰好是一个自回归Transformer。

Transformer是一种神经网络。它基本上是在词元(token)层面进行处理;它一块接一块地处理数据,每一块数据都有几乎等量的计算需求。这个模拟器当然也涉及到权重参数。这些数据源自互联网等。最终你得到了这样一个模拟器,因为它是在人类数据上训练的,所以它具有一种类人的涌现心理。
所以你首先会注意到,大模型拥有百科全书般的知识和记忆力,它们能记住海量信息,远超任何单个人类个体,因为它们阅读了巨量文本。这让我想起了电影《雨人》(Rain Man),我非常推荐大家观看。这是一部精彩绝伦的电影,我非常喜欢。片中的达斯汀·霍夫曼(Dustin Hoffman)饰演的角色,他拥有近乎完美的记忆力,能够像背诵电话簿一样记住所有姓名和号码。我觉得大模型在这一点上与之非常相似。它们能轻而易举地记住SHA哈希值和许多其他信息。所以它们在某些方面确实拥有超乎常人的能力,但同时,它们也存在许多可以说是认知上的缺陷。

它们有时会编造信息(出现幻觉),并且对自身的内部认知模型掌握不佳,至少不够充分——尽管这一点已有所改善,但仍不完美。它们表现出不均衡的智能水平:在某些解决问题的领域展现出超人能力,却又可能固执地认为9.11大于9.9,或者“strawberry”(草莓)这个词里有两个“r”。这些都是一些著名的例子。但基本上,它们存在一些容易导致错误的“粗糙之处”。我认为这也是其独特之处。它们还有点像患有顺行性遗忘症。我的意思是,如果你的团队加入一位新同事,这位同事会随着时间推移逐渐了解你的团队和工作方式,他们会理解……

人类在工作中会接触到大量的背景信息,然后回家睡觉,这个过程帮助他们巩固知识,并随着时间的推移积累专业技能。大模型天生不具备这种能力,我认为这在模型研发中尚未得到真正的解决。所以上下文窗口(context windows)更像是工作记忆,你需要非常直接地对其进行编程,因为它们不会自动变得更聪明。我认为很多人会因为这种类比而产生误解。在流行文化中,我推荐大家看两部电影。电影主角的参数(weights)是固定的,他们的上下文窗口每天早上都会被清空。这种情况下,他们很难正常工作或建立人际关系。而类似的情况,正持续发生在大模型身上。我还想指出一点,那就是大模型使用中一些与安全相关的限制。例如,大模型相当容易受骗。
它们可能会泄露你的数据等等。此外,还有许多其他与安全相关的考量因素。所以基本上,长话短说,你必须认识到,大模型一方面在某些方面展现出超凡的能力,另一方面又存在一系列认知缺陷和问题。然而,它们又极其有用。那么,我们该如何对其编程?如何规避其缺陷,同时充分利用其超能力呢?

大模型驱动:构建部分自主应用
现在,我想谈谈如何把握使用这些模型的机会,以及其中一些最大的机遇。这不是一个详尽无遗的列表,只是一些我认为对本次演讲而言比较有趣的方面。
首先让我感到兴奋的是我称之为“部分自主应用”的概念。以编码为例。你当然可以直接使用 ChatGPT。
然后复制粘贴错误报告,获取代码,再到处复制粘贴。但何必如此呢?为什么要直接与底层模型交互,而不是开发一个专用应用呢?那样会更有意义。我想你们很多人都用过 Cursor,我也在用。Cursor 正是这样一个理想的替代方案。

你不会想直接使用 ChatGPT。我认为 Cursor 是早期大模型应用的一个优秀范例,它具备许多卓越特性。
特别地,你会注意到 Cursor 拥有一个传统界面,允许人类像以前一样手动完成所有工作。但除此之外,它集成了大模型,使我们能够以更大的“代码块”或“任务单元”进行处理。因此,我认为大模型应用的一些共同且有用的特性值得强调:第一,它们承担了大量的上下文管理工作。第二,它们协调了对大模型的多次调用。
这些都为你协调好了。另一点我认为非常重要但可能未被充分理解的是:特定应用的图形用户界面(GUI)及其重要性。因为你不会想仅仅通过文本与系统交互。文本难以阅读、解释和理解,而且,你不会想直接通过文本执行某些操作。所以,最好能直接看到一个差异对比(diff),你可以看到哪些内容被添加,哪些被删减。只需使用 Command+Y 接受或 Command+N 拒绝要容易得多,而不是非得通过文本输入,对吧?GUI 允许人类审计这些易出错系统的工作,并加快审查速度。我稍后会再谈到这一点。我想指出的最后一个功能是所谓的“自主度滑块”。例如,在 Cursor 中,你可以使用顶部代码补全。

你可以使用 Command+L 修改整个文件,或者使用 Command+I,它能让你在整个代码仓库中进行操作——这更接近完全自主的代理模式。因此,你可以控制这个自主度滑块,根据当前任务的复杂程度,决定赋予工具多大程度的自主权来完成任务。再举一个相当成功的 LLM 应用案例:Perplexity。它也具备与我刚才在 Cursor 中指出的非常相似的功能:整合大量信息、协调多个 LLM 调用、拥有一个允许你审查其工作的 GUI(例如,它会列出引用来源)。
它同样有一个自主度滑块:你可以进行快速搜索,或进行研究,甚至可以进行深度研究并在10分钟后获取结果。这些都是你赋予工具不同程度自主权的表现。
所以我的问题是:我预感许多软件都将演变为部分自主的形态。它会是什么样子?对于那些正在维护产品和服务的人们,你们将如何使自己的产品和服务实现部分自主?
LLM 能看到人类所见的一切吗?LLM 能像人类一样行动吗?人类能否监督并持续参与到这个过程中?因为,需要再次强调的是,这些系统容易出错,远未达到完美。

在 Photoshop 或类似软件中,变更的差异对比(diff)会是什么样子?而且,许多传统软件现在都有各种各样的控制开关。
所有这些都必须改变,以便 LLM 能够访问和操作。我想强调一点,许多 LLM 应用中有一个方面我认为未得到应有的重视:我们现在更像是在与 AI 协作——通常 AI 负责生成,而我们人类负责验证。让这个“生成-验证”循环尽可能快地运转,符合我们的最大利益,这样我们才能高效完成大量工作。

我认为主要有两种方法可以实现这一点。第一,大幅加快验证速度。GUI 在这方面极其重要,因为它利用了我们大脑中的视觉处理能力——可以将其比作我们内置的“计算机视觉 GPU”。阅读文本费力且枯燥,但视觉感知则直观有趣,它就像一条通往大脑的快速通道。总的来说,我是这么看的。
第二,我们必须给 AI “套上缰绳”。我认为很多人对 AI 代理(agent)过于兴奋。但如果 AI 直接给我一个包含 1000 行代码改动的差异(diff)提交到我的代码仓库,那对我来说没什么用。我仍然是瓶颈,因为我必须确保这些代码没有引入 bug,确保它在做正确的事情,没有安全问题等等,对吧?所以我认为,基本上,我们必须让这个协作流程非常非常快,并且要想办法给 AI 套上缰绳,因为它有时会“反应过度”。这有点像这样。这就是我进行 AI 辅助编程时的感觉。如果我只是随意写写代码,一切看起来都很好;但如果我真的想把工作做好,情况就没那么理想了。
和你们许多人一样,我正在尝试探索一些方法,在我的编程工作流程中使用这些代理进行 AI 辅助编程。在我自己的工作中,我总是警惕过大的代码差异(diff)。我倾向于小步快跑,确保一切都在掌控之中,并让这个迭代循环尽可能快地运转。我倾向于处理小块的、单一的、具体的问题。所以我认为,你们中的许多人可能也在探索与 LLM 协同工作的类似方法。我还看到一些博客文章,试图为与 LLM 协作制定最佳实践。这里有一篇我读过的文章...
它讨论了一些技巧,其中一些正是关于如何给 AI“套上缰绳”。例如,如果你在提示 AI 时,AI 可能不会完全按你的意图行事,这时验证就会失败。你可能会要求它做别的事情,如果验证再次失败,你就会陷入反复修改的循环。因此,花更多时间使你的提示更具体、更明确是有意义的,这会增加成功验证的概率,从而让你能够继续前进。所以我认为我们许多人最终都会掌握类似这样的技巧。在我自己的工作中,我也对 AI 时代下的教育形态非常感兴趣。
我想大部分思考都集中在如何给 AI “套上缰绳”。我不认为直接对 ChatGPT 说“嘿,教我物理”就能奏效。我认为这行不通,因为 AI 很容易偏离主题,失去方向。所以对我来说,这实际上需要两个独立的应用程序。例如,一个给老师用的应用,另一个给学生用的应用。
在这两种情况下,我们都有了一个课程的“中间产物”,它是可审查的。我们可以确保其质量,确保内容一致性,并且 AI 在特定的教学大纲、特定的项目进展等方面被有效地“约束”住了。这样一来,成功的可能性更高,AI 也不会偏离轨道。我还想讲一个类比。
卡帕西: 我在特斯拉工作了五年。特斯拉的 Autopilot 也是一个部分自主的产品,并且与我们讨论的有很多共通之处。例如,仪表盘上就有 Autopilot 的 GUI,它会实时显示神经网络“看到”了什么。我们也有自主度滑块。在我任职期间,我们逐步为用户实现了越来越多自主化的任务。也许我想分享的故事是关于我第一次体验完全自动驾驶的经历。

可以想象一下,在那个年代,Google Glass 还算是个新鲜事物。你们中许多人可能还很年轻,甚至都不知道那是什么。但那确实是相当早期的探索了。
我们坐上车,在帕洛阿尔托(Palo Alto)周边行驶了大约30分钟,途经高速公路和城市街道。那次驾驶堪称完美,全程零人工干预。那是2013年,距今已经快12年了。
这让我感到非常震惊。当时我经历了那次完美的驾驶演示,心想:“哇,自动驾驶的时代指日可待了,因为它刚刚成功了!这太不可思议了!”但时至今日,12年过去了,我们仍在研究自动驾驶,仍在研发驾驶代理(driving agents)。
即便到了现在,我们实际上也还没有完全解决这个问题。你可能看到 Waymo 的车在路上行驶,但很多这类自动驾驶仍然需要大量的远程操作和人工介入。所以我们甚至还不能宣布完全成功。但我相信,自动驾驶最终一定会成功,只是花费的时间远超预期。软件开发非常棘手,就像自动驾驶一样。当我看到诸如“2025年将是AI代理之年”这样的说法时,我非常担心。我觉得这应该是“AI代理的十年”,而且还需要相当长的时间。我们需要人类的参与,必须谨慎行事。这毕竟是软件,我们需要严肃对待。
我经常想到的一个类比是钢铁侠的战衣。我一直很喜欢钢铁侠,因为它精准地反映了技术及其演进过程。我欣赏钢铁侠战衣的一点是,它既是增强工具,也是在托尼·斯塔克不在时能够自主行动的代理。在一些电影中,战衣可以自主操作,自行飞行并找到托尼。这正反映了“自主度滑块”的概念——我们可以构建增强工具,也可以创建代理,理想情况下,我们希望两者兼得。
然而,在现阶段,我认为与这些容易犯错的大语言模型(LLMs)合作,更像是拥有“钢铁侠战衣”,而非直接得到一个全能的“钢铁侠机器人”。重点不再是展示自主代理的炫目演示,而是开发具有部分自主性的产品。这些产品需要定制化的图形用户界面(GUIs)和用户界面/用户体验(UI/UX)设计,并且我们要确保人工验证的循环尽可能快速。原则上,不应忽视将这项验证工作自动化的可能性。你的产品中应该集成一个自主度滑块,并且你应该思考如何随着时间的推移逐步提升这种自主性。
大语言模型(LLMs)以自然语言编程 → 软件可访问性的巨大飞跃!(没错,这就是“氛围感编程” vibe coding)
我想稍微转换一下话题,讨论另一个独特的维度。现在不仅出现了一种新型的编程范式——它使软件能够实现自主性,而且这种“编程语言”就是自然语言(如英语),自然语言充当了天然的接口。突然之间,似乎每个人都成了程序员,因为每个人都会说像英语这样的自然语言。这对我而言极具前景和吸引力,而且我认为这是前所未有的变革。

过去,你需要花费五到十年的时间学习才能从事软件开发工作,但现在情况已然不同。所以我不知道是否有人听说过“氛围感编程”(vibe coding)。这条推文算是介绍了这个概念,我听说它现在成了一个流行的梗(meme)。有趣的是,我已经用了大约15年的Twitter,但至今仍无法预测哪条推文会火,哪条会无人问津。
我本以为那条推文会像后者一样默默无闻。我也不知道,它只是一连串的灵感迸发,却意外成了一个大热的梗 (meme)。我其实很难说清,但我想它大概是触动了大家的共鸣,为那种人人心有戚戚焉、却又难以言表的感觉赋予了名称。所以现在它甚至有了维基百科页面之类的东西。

主持人: 这就像……是的,现在感觉像是你做出了一个重大贡献,或者类似的事情。
卡帕西: Hugging Face 的 Tom Wolf 分享了一个我很喜欢的精彩视频。视频里是一群正在“vibe coding”的孩子们。
卡帕西: 我觉得这个视频非常暖心。我太爱这个视频了。看了这个视频,你怎么还会对未来感到沮丧呢?未来一片光明。我认为这最终会成为软件开发的新入口。我对这一代人的未来并不悲观。而且,我太爱这个视频了。

所以我也尝试了“vibe coding”,因为它太有趣了。当你想要构建一些高度定制化、市面上又找不到的东西时,“vibe coding”就非常棒了。你可以随心所欲地去做,比如就因为那天是周六。我用它构建了一个 iOS 应用。虽然我其实不会用 Swift 编程,但我居然能做出一个非常基础的应用,这让我非常惊喜。我就不细说了,因为它非常简单。但我喜欢的是,这只花了我一天时间,当天晚上它就在我的手机上运行起来了。我当时就觉得,哇,这太酷了!我不需要花五天时间去啃 Swift 文档之类的东西才能开始。

我还“vibe code”了一个叫 Menugen 的应用,它已经上线了;大家可以在 menugen.app 上试试。我经常遇到一个问题:去餐馆看菜单时,完全不知道那些菜名是什么,特别需要图片来帮助理解。既然市面上没有这样的工具,我想,嘿,那我就用“vibe coding”做一个吧。它的用法是:你访问 menugen.app,拍下菜单照片,Menugen 就会生成菜品图片。另外,注册用户都可以免费获得 5 美元的体验额度。
卡帕西: 所以,这对我来说成了一个主要的成本支出点。这个应用目前是负盈利状态,我在 Menugen 上已经亏了不少钱

有意思的是,Menugen 的演示版,在我的笔记本上几个小时就跑起来了。但我之后却花了一周时间把它真正部署上线,原因就是那些极其繁琐的配置。举个例子,如果你想给网页添加 Google 登录功能,Clerk 这个库会提供一大堆集成指南来教你怎么做。简直疯了!它会让你访问某个 URL,点击某个下拉菜单,选择某个选项,然后再去另一个地方点击另一个按钮。感觉就像是电脑在指挥我该怎么操作。我就想:你倒是自己做啊!为什么非得我来点这些?这到底是什么情况?我不得不一步步照着说明来。简直不可理喻!
大型语言模型(LLMs):数字信息的新一代消费者与操纵者(继图形用户界面/人类和应用程序接口/程序之后的新角色)→ 为AI代理而构建!
卡帕西: 因此,我演讲的最后一部分将聚焦于:我们能否直接为AI代理构建应用?我不想再做那些繁琐的点击操作了。AI代理能代劳吗?由此,我认为在数字信息的消费者和操纵者中,出现了一个全新的类别。过去,要么是人类通过图形用户界面(GUI)与信息交互,要么是程序通过应用程序接口(API)交互。但现在,我们有了一种全新的角色:AI代理。它们是计算机程序,却又带有些许人性,如同互联网上的“灵魂”,需要与软件基础设施进行交互。我们能为它们构建怎样的工具?这是一个全新的课题。
例如,网站可以通过 robots.txt 文件来指引网络爬虫的行为。与此类似,我们也可以创建一个 llms.txt 文件——一个简单的 Markdown 文件——来告诉大型语言模型(LLM)这个网站的主题内容。这种格式对 LLM 非常友好,易于读取。相比之下,如果让 LLM 去抓取并解析网页的 HTML,那将非常困难且容易出错,效果往往不佳。所以,直接用 LLM 能理解的方式与其“对话”是非常有价值的。

目前大量的文档都是为人类阅读而设计的,所以你会看到列表、粗体、图片等元素。这些对 LLM 来说并不直接友好。因此,我看到一些服务已经开始将文档专门转换为 LLM 友好的格式。例如,Vercel 和 Stripe 就行动得比较早,还有其他一些服务也在这样做,它们开始提供 Markdown 格式的文档。Markdown 对 LLM 来说非常易于解析,这非常好。
再分享一个我的亲身经历:大家可能知道 3Blue1Brown,他制作的数学动画非常精美。

卡帕西: 我非常喜欢他编写的一个名为 Manim 的动画库。我也想用它来做动画。关于如何使用 Manim 有海量的文档,我实在不想逐一阅读。于是,我把整个文档复制粘贴给一个 LLM,告诉它我想要实现的效果,结果它一次就成功了!LLM 完全按照我的要求生成了动画,这让我喜出望外。如果我们能让文档对 LLM 友好易懂,将会释放出巨大的潜力。我认为这太棒了,应该有更多这样的尝试。
但我想指出,这不仅仅是把现有文档转换成 Markdown 格式那么简单,那只是最容易的一步。我们实际上需要改变文档的内容本身。因为一旦文档中出现“点击”这样的指令,就会带来问题。LLM 目前还无法直接执行这类操作。例如,Vercel 正在用等效的 curl 命令来替换所有“点击”操作的描述,这样你的 LLM 代理就可以代你执行这些命令了。我觉得这种思路非常巧妙。
此外,Anthropic 推出了一个“模型上下文协议”(Model Context Protocol),它提供了另一种直接与 AI 代理沟通的方式——再次强调,代理是数字信息新一代的消费者与操纵者。我对这些新思路非常看好。另外,我也很欣赏市面上涌现的各种小工具,它们能帮助我们以 LLM 友好的格式来提取和处理数据。例如,当我访问一个 GitHub 仓库(比如我的 nanoGPT 仓库)时,我无法直接把仓库内容喂给 LLM 并进行提问,因为 GitHub 展示的是为人类设计的界面。
通过将 URL 中的 'github.com' 改为 'git.jst.ai',它就能把所有文件整合成一个大的文本文件,并生成一个目录结构,方便你直接复制粘贴到你喜欢的 LLM 中。一个更强大的例子是 DeepWiki,它不仅提供文件的原始内容,还会对 GitHub 仓库进行分析。DeepWiki 会专门为你的仓库构建全面的文档页面,这对于将其内容输入 LLM 非常有帮助。
我喜欢所有这些小工具,它们的核心功能就是通过修改 URL,就能让某些内容变得对 LLM 友好。这些都非常好,我认为未来应该有更多这类创新。
我想补充一点,未来 LLM 完全有可能——甚至在今天就已经部分实现——能够自行浏览网页、点击按钮等等。但我仍然认为,主动去适应 LLM,在某种程度上“迁就”它们,让它们更容易地访问和理解信息,是非常值得的。因为目前让 LLM 直接处理复杂的人类界面仍然成本高昂且困难重重。所以我确实认为,大量的软件,特别是那些不属于主流活跃项目或核心数字基础设施的“长尾”应用,尤其需要这些辅助工具。而对于大多数其他情况,我认为这种“双向奔赴”的努力是非常值得的。所以,如果这么说能讲通的话,我对这两种趋势(LLM能力增强和我们主动适配)都非常看好。

总而言之,现在是投身这个领域的黄金时代。我们将需要重写海量的代码。其中许多代码仍将由专业人士和程序员编写。这些 LLM 有点像公用事业,类似于芯片制造厂(fabs),但它们尤其像操作系统。然而,它们目前尚处于非常早期的阶段,好比 1960 年代的操作系统。我认为很多类比都说得通。这些 LLM 就像是容易犯错的小精灵,我们必须学会如何与它们协作。要做到这一点,我们就需要相应地调整我们的基础设施。

在构建这些 LLM 应用的过程中,我介绍了一些与 LLM 有效协作的方法,一些实现这些协作的小工具,以及如何通过快速迭代来打造具有部分自主能力的产品。同时,我们也需要为 AI 代理更直接地编写大量适配代码。
无论如何,回到钢铁侠战甲的那个比喻,我认为在未来十年,我们会看到那个“滑块”(人机协作的比例)不断从左(更多人工)向右(更多AI自主)移动。我非常期待看到那将是怎样一番景象,并迫不及待地想和大家一起去构建它。谢谢大家!