机器之心报道
机器之心编辑部
回顾 OpenAI 的早期成员，奥特曼成为 AI 浪潮的掌舵人之一，Ilya Sutskever 致力于探索 AI 安全的理想边界，而 Andrej Karpathy 则走上了一条「建造并分享」的道路。
他痴迷于用代码将 AI 蓝图变为现实，又乐此不疲地把建造过程做成公开课分享给世界。
所以，当他人在构建一家伟大的公司时，Karpathy 同时在构建着 AI 应用与下一代的 AI 建设者。
6 月 17 日，Andrej Karpathy 在 YC AI Startup School 活动中发表了约 40 分钟的演讲，主题为《Software in the era of AI》。
视频链接：https://www.youtube.com/watch?v=LCEmiRjPEtQ
Andrej 结合他在斯坦福、OpenAI 和特斯拉的工作经验，洞察到一个转变正在发生——软件正在再次经历变革。我们已经进入了「软件 3.0」时代，在这个时代，自然语言成为新的编程接口，而模型则完成剩下的工作。
他探讨了这一转变为开发者、用户以及软件设计本身带来了什么，并指出我们不仅仅是在使用新工具，更是在构建一种新型的计算机。
他提出了以下观点：
他将软件的发展划分为三个阶段：从人工编写指令的「软件 1.0」，到以神经网络权重为核心的「软件 2.0」，再到由 LLM 开启的「软件 3.0」。为了帮助理解 LLM 的本质，Karpathy 提出了多个类比，其中最贴切的是将其视为一种「新型操作系统」。它如同 1960 年代的早期计算机，算力集中在云端，用户通过类似命令行的界面进行交互。这是一个功能强大但仍处于非常初级的生态系统。LLM 是「有缺陷的超人」：它们知识渊博，但会产生幻觉、犯低级错误且没有长期记忆。因此，我们必须学会在监督下利用其能力，同时规避其不可靠性。他认为，当前最大的机遇并非完全自主的 AI，而是「部分自主性」产品。我们应构建像「钢铁侠战衣」一样增强人类能力的工具，通过高效的人机协作循环来完成任务，而非追求一步到位的自动化。展望未来，Karpathy 呼吁为 AI 重新设计数字基础设施。当前为人类设计的网站和文档对 AI 并不友好，未来的关键任务是使其变得机器可读、可操作，从而为更高阶的 AI 智能体铺平道路。
以下是机器之心根据原视频进行的不改变原义的编译和整理。
接下来让我们跟随 Andrej Karpathy 一起进入「软件 3.0」时代！
哇，这里人真多啊！大家好！很高兴今天能来到这里，和大家聊聊软件和人工智能时代。我了解到在座有很多学生，包括本科生、硕士生和博士生等，你们即将进入行业。我觉得现在正是进入这个行业一个非常独特、也很有意思的时期。
我认为，根本原因在于软件又一次在发生变化。我说「又一次」是因为我其实已经做过这个演讲了。但问题是，软件一直在变化。所以我其实有很多素材可以准备新的演讲，而且我觉得这种变化是尤为重要且影响深远。
粗略地说，软件在七十年里几乎没有在基础层面上发生太大变化。然而，最近几年它已经发生了两次相当迅速的重大变革。因此，现在有大量的工作需要做，有大量的软件需要编写和重写。
让我们来看看软件领域吧。如果我们把这想象成软件的地图，这里有一个非常棒的工具叫做「Github 地图」。这就像是所有编写过的软件的一个汇总。这些就是给计算机的指令，用来在数字空间里执行任务。如果你放大这里，这些都是不同类型的代码仓库，而这些就是所有已经写好的代码。
几年前，我注意到软件正在发生某种变化，周围出现了一种新型的软件，当时我称之为「软件 2.0」。这里的理念是，软件 1.0 是你为计算机编写的代码，而 软件 2.0 基本上就是神经网络，尤其是神经网络的权重。
你并不是直接编写这些代码，而是更多地调整数据集，然后运行优化器来生成这个神经网络的参数。我认为，在当时，神经网络被看作只是另一种分类器，比如像决策树之类的。因此，我觉得这种框架更为恰当。
现在，实际上我们已经在软件 2.0 领域拥有了类似 Github 的平台。我认为 Hugging Face 基本上就是软件 2.0 领域的 Github。此外还有 Model Atlas，你可以在那里可视化所有「代码」。
顺便说一下，如果你好奇的话，那个巨大的圆圈、中间的点，实际上就是图像生成器 Flux 的参数。因此，每当有人在 Flux 模型之上微调 LoRA，你基本上就是在这个空间里进行了一次 Git 提交，从而创造了一种不同类型的图像生成器。
简单来说，软件 1.0 就是我们编写的计算机代码，用来编程计算机；而软件 2.0 则是神经网络的权重，也就是用来「编程」神经网络的东西。这里举个例子，比如说 AlexNet 图像识别神经网络。
到现在为止，我们熟悉的神经网络都类似于固定功能的计算机，比如把图像变成类别之类的。我认为真正发生变化的是，神经网络现在能够通过 LLM 变得可编程。我觉得这一点非常新颖和独特，它是一种新型计算机。所以在我心里，值得给它一个新的称号，叫做软件 3.0。
基本上，你的提示词现在就是用来编程 LLM 的程序。而且非常神奇的是，这些提示词是用英语（自然语言）写的，所以它变成了一种非常有趣的编程语言。
也许可以这样总结区别：比如说你在做情感分类，你可以想象写一些 Python 代码来实现情感分类，或者你可以训练一个神经网络，或者你可以用提示词去引导 LLM。这里就是一个少样本提示，你可以想象通过改变它，用稍微不同的方式编程计算机。
所以，基本上我们有软件 1.0、软件 2.0，而且我认为现在我们看到——也许你已经注意到——很多 GitHub 上的代码已经不只是代码了，有很多英语夹杂在代码里。所以我觉得正在出现一种新类型的代码。
这不仅是一种新的编程范式，对我来说，更神奇的是它用的是我们的母语——英语。所以几年前这让我非常震惊，我在推特上发了这个想法，我觉得引起了很多人的关注。这就是我现在置顶的那条推文：「非常神奇的是，我们现在在用英语编程计算机。」
当我在特斯拉的时候，我们正在研发自动驾驶系统，努力让汽车能够自动驾驶。那时候我展示了一张幻灯片，你可以想象汽车的输入在底部，它们通过一个软件栈来产生转向和加速。
当时我观察到自动辅助驾驶系统中有大量的 C++ 代码，那就是软件 1.0 的代码。然后还有一些神经网络在做图像识别。我注意到，随着我们让自动辅助驾驶系统变得更好，神经网络的能力和规模都在增长。除此之外，所有的 C++ 代码正在被删除，很多原本用 1.0 方式编写的功能和能力转移到了 2.0。
举个例子，从不同摄像头收集的图像信息以及跨时间的信息拼接，很多都是由神经网络完成的，这样我们就能删除很多代码。所以软件 2.0 堆栈实际上已经贯穿了自动驾驶系统的软件栈。当时我觉得这非常了不起，而且我认为我们现在又在经历同样的事情，基本上我们有一种新的软件，它正在「吞噬」整个软件栈。
我们现在拥有三种完全不同的编程范式。我认为如果你要进入这个行业，熟练掌握这三种范式是非常有益的，因为它们各有优劣。你可能需要根据情况选择用 1.0、2.0 或 3.0 范式来实现某些功能——比如该训练神经网络？还是直接提示 LLM？又或者应该编写显式代码？我们需要做出这些决策，并且实际上可能需要在不同范式之间流畅切换。
Part 1：How to think about LLMs？
现在我想探讨的是：首先，在第一部分我想谈谈 LLM，以及如何理解这种新范式、其生态系统和形态。
比如：这台新型计算机是什么？它长什么样？生态系统又是怎样的？多年前吴恩达（Andrew Ng）的一句话让我印象深刻（他应该在我之后发言），他说：「AI 是新型电力。」
我确实认为这句话捕捉到了一个非常有趣的核心——如今的 LLM 确实具有基础设施属性。像 OpenAI、Gemini、Anthropic 等 LLM 实验室投入资本支出训练模型，这相当于建设电网；然后通过运营支出将智能通过 API 提供给我们所有人。访问方式是按量计费（例如按每百万 tokens 付费），我们对这类 API 提出类似公共设施的需求：低延迟、高可用性、质量稳定性等。
在电力系统中，你可以用转换开关切换电网、太阳能、电池或发电机等电源。在 LLM 领域，我们可能有开放路由层（open router），轻松在不同 LLM 供应商间切换。由于 LLM 是软件，不占用物理空间，因此可以有多个「电力供应商」（例如六家），用户可自由切换——毕竟它们不存在直接物理竞争关系。
我觉得这也挺有趣的，而且这几天我们就看到了这种情况：很多 LLM 都宕机了，人们就像被卡住一样无法工作。我觉得很有意思的是，当最先进的 LLM 宕机时，世界就像是经历了一次「智能断电」。就像电网电压不稳时，整个地球都变得更迟钝了一样。我们对这些模型的依赖已经非常显著，而且我认为这种依赖还会继续增长。
我觉得这个类比也有些模糊，因为正如我提到的，这是软件，而软件的可防御性较低，因为它非常容易改变。所以我觉得这是个挺有意思的思考点。实际上你可以做很多类比，比如 4 纳米制程节点，或者某种具备最大算力的集群。
你可以想象，当你只用 NVIDIA 的 GPU 做软件，而不做硬件时，这有点像晶圆代工模式；但如果你像谷歌那样自研硬件，用 TPU 训练，那就是像英特尔模式，你拥有自己的晶圆厂。所以我觉得这里有一些合理的类比。
但在我看来，最贴切的类比可能是把 LLM 看作操作系统——它们不仅仅是像电力或水那样的商品，不是从水龙头里流出来的标准化产品，而是日益复杂的软件生态系统。
我觉得有趣的是，这个生态系统的形成方式也非常相似：你有几个闭源提供商，比如 Windows 或 macOS，然后有开源的替代品，比如 Linux。对于 LLM 来说，也有几个竞争的闭源提供商，而 Llama 生态系统目前可能最接近未来可能发展成类似 Linux 的角色。
再次说明，我认为现在还为时过早，因为这些只是简单的 LLM，但我们开始看到它们将会变得复杂得多。这不仅仅是关于语言模型本身，还关乎所有工具的使用、多模态能力以及这些功能如何协同工作。所以当我前阵子意识到这一点时，我尝试把它画出来，在我看来 LLM 有点像一种新的操作系统，对吧？
所以，LLM 是一种新型计算机。它的核心设置有点像 CPU，上下文窗口有点像内存。然后，LLM 通过协调内存和计算能力，利用这里的所有功能模块来解决问题。因此，从这个角度看，它确实非常像一个操作系统。
再举一些类比。比如你想下载一个应用，假设我要下载 VS Code，我可以下载 VS Code，并在 Windows、Linux 或 Mac 上运行它。同样地，你可以拿一个基于 LLM 的应用，比如 Cursor，然后可以在 GPT、Claude 或 Gemini 系列上运行它，对吧？只需要在下拉菜单里选择一下。所以在这方面也是类似的。
另一个让我印象深刻的类比是，我们现在仿佛处于上世纪 60 年代的计算纪元。对于这种新型计算机而言，LLM 的算力仍然非常昂贵，这迫使 LLM 必须集中在云端，而我们都只是通过网络与其交互的「瘦客户端」，我们中没有人能完全独占这些计算机的资源。
因此，采用「分时共享」系统是合理的，我们每个人都只是云端计算机运行时批处理中的一个维度。这与当时计算机的形态非常相似。操作系统在云端，所有数据都是流式传输，并且存在批处理。
所以，「个人计算革命」尚未发生，因为它在经济上还不划算。但我想，有些人正在尝试。事实证明，像 Mac Mini 这样的设备，就非常适合运行某些 LLM，因为如果你进行的是单批次（batch-1）推理，整个过程是极其受限于内存带宽的，而这恰好是它的优势。
我认为这些可能是个人计算时代的一些早期迹象，但这尚未真正发生。它未来会是什么样子还不清楚。或许你们中的一些人将会发明出它是什么、它如何工作，或者它应该是什么样子。
我再提一个类比，每当我在纯文本环境中与 ChatGPT 或某个 LLM 直接对话时，我都感觉自己像是在通过终端与一个操作系统对话。它就是纯文本的，是与操作系统的直接连接。而且我认为，一个通用的 GUI 尚未被真正发明出来。
比如，ChatGPT 是否应该有一个超越文本气泡的 GUI？当然，我们稍后会提到的一些应用确实有 GUI，但还没有一种能贯穿所有任务的通用 GUI，如果你们能明白我的意思。
在某些相当独特的方面，LLM 与早期计算时代的操作系统有所不同。我曾写过关于一个特性的文章，这个特性在我看来这次是截然不同的。
文章链接：https://karpathy.bearblog.dev/power-to-the-people/
那就是 LLM 颠覆了通常存在于技术中的技术扩散方向。例如，对于电力、密码学、计算、飞行、互联网、GPS 等许多变革性技术，通常政府和企业是首批用户，因为新技术既昂贵又复杂。它只在后期才会扩散到消费者层面。
但我感觉 LLM 把这个顺序颠倒了。早期计算机可能完全是为了弹道学和军事用途，但对于 LLM，它的应用却是关于「如何煮鸡蛋」之类的事情。这确实是我的很多用法。所以，我们拥有了一台神奇的新型计算机，而它在帮我煮鸡蛋，这对我来说太奇妙了。它不是在帮助政府做一些像军事弹道计算或某些特殊技术那样疯狂的事情。
事实上，企业或政府在采用这些技术方面，反而落后于我们普通大众，这完全是反过来的。我认为这或许能启发我们思考该如何使用这项技术，或者最早的应用会是什么样。
所以，总结一下目前为止的观点：我认为，将 LLM 称为复杂的操作系统是准确的说法。它们就像是上世纪 60 年代的计算机，我们正在重新经历整个计算演进的过程。它们目前通过分时共享的方式提供，像公共事业一样被分发。而全新且史无前例的是，它们不掌握在少数政府和企业手中，而是掌握在我们所有人手中，因为我们都有电脑，而它只是软件。ChatGPT 就像是瞬间被传送到了我们数十亿人的电脑上。这太疯狂了。我至今都觉得这种情况的发生很不可思议。
Part 2：LLM Psychology
现在，轮到我们进入这个行业，为这些计算机编程了。这太棒了。所以，我认为这是非常了不起的。在我们为 LLM 编程之前，我们必须花些时间思考这些东西到底是什么。我尤其喜欢谈论它们的「心理」。我倾向于将 LLM 看作是「人类心智」，它们是对人类的随机模拟。
在这种情况下，这个「模拟器」恰好是一个自回归 Transformer。Transformer 是一个神经网络，它在词元（token）的层面上工作，一块接一块地处理，每个区块消耗的计算量几乎相等。
当然，这个模拟器本质上包含一些权重，我们用互联网上所有的文本数据等来拟合它。最终你就得到了这样一个模拟器。因为它是在人类数据上训练出来的，它涌现出了类似人类的心理特征。
所以，你首先会注意到，LLM 拥有百科全书式的知识和记忆力，它们能记住很多东西，远超任何单个人类个体，因为它们阅读了太多的东西。这让我想起了电影《雨人》，我真的非常推荐大家去看。这是一部很棒的电影，我非常喜欢。达斯汀·霍夫曼在片中扮演一个学者症候群患者（autistic savant），拥有近乎完美的记忆力，他可以读完一本电话簿，然后记住里面所有的名字和电话号码。
我觉得 LLM 在某些方面非常相似。它们可以轻易记住 SHA 哈希值和许多不同种类的东西。所以，它们在某些方面的确拥有超能力，但它们也有一系列的、我称之为「认知缺陷」的东西。比如，它们会相当频繁地产生幻觉、胡编乱造，并且没有一个很好的内部自我认知模型，至少是不够完善的。这一点虽然有所改善，但仍不完美。
它们还表现出「锯齿状的智能」，也就是说，它们在某些解决问题的领域会表现出超人的能力，但又会犯一些基本上任何人类都不会犯的错误。比如，它们会坚持认为 9.11 比 9.9 大，或者坚持认为「strawberry」（草莓）这个单词里有两个「r」。
这些都是一些著名的例子。但基本上，你总会遇到一些容易让你栽跟头的棘手问题。所以，我认为这也是其独特之处。它们（LLM）还患有「顺行性遗忘症」。我这里想说的是，如果你的公司来了一位新同事，随着时间的推移，这位同事会逐渐了解你的组织，他们会理解并积累大量关于组织的背景信息。他们回家、睡觉、巩固知识，并逐渐建立起专业技能。
LLM 天生不会这样做。而且我认为，在 LLM 的研发领域，这个问题也尚未真正解决。所以，上下文窗口实际上就像是「工作记忆」，你必须非常直接地去编程这段工作记忆，因为它们不会默认就变得更聪明。
我认为很多人都被流行文化中关于 AI 的类比误导了。我推荐大家看两部电影：《记忆碎片》和《初恋50次》。在这两部电影中，主角的「权重」是固定的，他们的「上下文窗口」每天早上都会被清空，当这种情况发生时，去上班或维持人际关系都变得非常有问题。而这种情况时时刻刻都在所有 LLM 身上发生。
我想指出的另一点是与使用 LLM 相关的安全限制。例如，LLM 相当容易上当（轻信），它们很容易受到提示词注入攻击，可能会泄露你的数据等等。此外，还有许多其他与安全相关的考量。
所以，长话短说，你必须同时思考这个拥有超凡能力，却又带着一堆认知缺陷和问题的东西。我们该如何驾驭它们？我们该如何规避它们的缺陷，同时又能享受到它们的超凡能力？
Part 3：Partial autonomy apps
我现在想切换到下一个话题，谈谈我们该如何使用这些模型，以及其中最大的机遇是什么。这并非一个详尽的清单，只是我认为对于本次分享来说比较有趣的一些点。我首先感到兴奋的是我称之为「部分自主性应用」的东西。
举个编码的例子，你当然可以直接去用 ChatGPT，到处复制粘贴代码、错误报告之类的东西，获取代码，然后再把所有东西都复制粘贴回来。但你为什么要这样做呢？你为什么要直接通过这个「底层系统」来操作？拥有一个专门为此设计的应用程序要合理得多。
所以我认为，就像你们中的许多人一样，我也在使用 Cursor。Cursor 正是你想要的那种工具，而不是直接去用 ChatGPT。我认为 Cursor 是一个非常好的早期 LLM 应用的例子，它具备了一系列我认为在所有 LLM 应用中都通用的、非常有用的特性。
你会特别注意到，我们保留了一个传统界面，允许人类像以前一样手动完成所有工作。但除此之外，我们现在有了 LLM 集成，这让我们能以更大的代码块为单位进行操作。
所以，我想指出一些我认为 LLM 应用所共有且有用的特性：
第一，LLM 基本上处理了大量的上下文管理工作。 第二，它们编排了对 LLM 的多次调用。以 Cursor 为例，其底层有用于分析你所有文件的嵌入模型，还有将代码差异（diffs）应用到代码中的聊天模型。而这一切都为你自动编排好了。
另一个我认为非常重要但可能未被充分赏识的，是特定于应用的 GUI 及其重要性。因为你不会想直接通过文本与这个「底层系统」对话，文本很难阅读、解释和理解。而且你也不想直接在文本中执行某些操作。
比如，以红色和绿色的高亮形式查看代码差异，就要直观得多。你可以清楚地看到哪些是新增的，哪些是被删除的。通过 Command + Y 接受或 Command + N 拒绝也要容易得多。我不应该需要用打字的方式来完成这些，对吧？所以，GUI 允许人类审计这些易出错系统的工作，并能提升效率，这一点我稍后还会再谈。
我想指出的最后一个特性，是我所说的「自主性滑块」。例如，在 Cursor 中，你可以只使用 Tab 键进行代码补全，这时主要由你掌控。你也可以选中一个代码块，然后用 Command + K 只修改那部分代码。你还可以用 Command + L 来修改整个文件，或者用 Command + I，这基本上就是让 AI 在整个代码仓库（repo）里随心所欲地修改。这就是完全自主的、智能体化的版本。所以，你可以掌控这个「自主性滑块」。根据手头任务的复杂性，你可以调整你愿意为此任务放弃的自主程度。
或许可以再举一个相当成功的 LLM 应用的例子——Perplexity，它也具有我刚才在 Cursor 中指出的非常相似的特性。它打包了大量信息，编排了多个 LLM 的调用，它有一个允许你审计其部分工作的 GUI。
例如，它会引用来源，你可以检查这些来源。它也有一个「自主性滑块」。你可以只做一个快速搜索，也可以进行普通研究，或者选择深度研究，然后在 10 分钟后回来看结果。这些都只是你赋予工具的不同程度的自主性。
所以，我的问题是，我感觉很多软件都将变得部分自主。我正试图思考那会是什么样子？对于你们中许多正在维护产品和服务的人来说，你将如何让你的产品和服务变得部分自主？LLM 能否看到人类能看到的一切？LLM 能否以人类能做的所有方式行动？以及，人类如何监督并保持在整个流程中？因为，重申一次，这些都是易出错的、尚不完美的系统。比如，在 Photoshop 里，一个「差异（diff）」看起来会是什么样的？
而且，现在很多传统软件，它们有各种各样的开关和选项，这些都是为人类设计的。所有这些都必须改变，变得能让 LLM 访问和使用。
关于这些 LLM 应用，我想强调一点，我不确定它是否得到了应有的关注。我们现在正与 AI 合作，通常是它们负责「生成」，而我们人类负责「验证」。让这个「生成-验证」循环尽可能快地运转，是符合我们利益的，这样我们才能完成大量工作。
我认为有两种主要方法可以实现这一点。
第一，你可以极大地加快验证速度。我认为 GUI 对此就极其重要，因为 GUI 利用了我们每个人大脑中的「计算机视觉 GPU」。阅读文本费力又无趣，但「看」东西很有趣，它就像一条直通你大脑的高速公路。所以我认为 GUI 以及各种可视化呈现方式，对于审计系统非常有用。
第二，我想说的是，我们必须「约束住 AI」。我认为很多人对 AI 智能体过于兴奋了。给我一个上千行代码的差异（diff）提交到我的代码仓库，这对我是没有用的。我仍然是瓶颈，对吧？尽管那 1000 行代码是瞬间生成的，但我必须确保它没有引入新的错误，确保它做的是正确的事情，并且没有安全问题等等。所以我想，是的，基本上，让这个流程快速运转是符合我们利益的，我们必须设法约束住 AI，因为它太容易反应过度了。
这有点像我在进行 AI 辅助编码时的感受。如果我只是在进行「氛围编程」，一切都很好很棒。但如果我真的想完成工作，有一个反应过度的智能体在那儿做各种事情，感觉就没那么好了。所以这张幻灯片做得不太好。
抱歉，但我想，和你们许多人一样，我正试图摸索出一些在我的编码工作流中利用这些智能体进行 AI 辅助编码的方法。在我自己的工作中，我总是害怕收到过大的代码差异（diffs）。我总是以小步、增量的方式进行。我想确保一切都好，我想让这个循环转得非常快。我倾向于处理小块的、具体的单一任务。所以我想，你们中的许多人可能也在形成类似的使用 LLM 的工作方式。
我也看到过许多试图为 LLM 的应用总结最佳实践的博客文章。这是我最近读到的一篇，我觉得写得相当不错。它探讨了一些技巧，其中一部分是关于如何「约束」人工智能。
举个例子，如果你给出的提示（prompt）很模糊，那么人工智能可能无法准确地执行你的意图。在这种情况下，验证就会失败。然后你就会要求它做别的事情。如果验证失败，你就会陷入反复修改的循环。因此，多花一点时间让提示更具体会更有意义，这能增加验证成功的概率，让你得以继续推进工作。我想我们很多人最终都会发现类似的技巧。
在我自己的工作中也是如此，我目前很感兴趣的是，在一个拥有 AI 和 LLM 的时代，教育会是什么样子？
我认为，我的大量思考都集中在如何约束 AI 上。我不认为直接去对 ChatGPT 说「嘿，教我物理」这种方式是可行的。我认为这行不通，因为 AI 很容易就会「在森林里迷路」（意指失去方向）。因此，对我来说，这其实是两个独立的应用程序。
例如，有一个供教师创建课程的应用程序，然后有另一个应用程序，接收这些课程并将其提供给学生。在这两种情况下，我们现在都有了一个「课程」作为中间产物，这个产物是可审查的，我们可以确保它的质量是好的，内容是一致的，并且 AI 被约束在特定的教学大纲和项目进度规划之内。这是一种约束 AI 的方法，我认为这种方法成功的可能性要大得多，AI 也不会迷失方向。
我还想提及另一个类比，那就是我对「部分自主性」并不陌生。我在特斯拉为此工作了五年。那也是一个部分自主性的产品，并具有许多共同的特征。比如，仪表盘上就是自动驾驶的 GUI，它会向我展示神经网络所看到的东西等等。我们还有一个「自主性滑块」，在我任职期间，我们通过它为用户逐步增加了更多的自主任务。
我想简单分享一个故事，我第一次乘坐自动驾驶汽车是在 2013 年。我有一个在 Waymo 工作的朋友，他邀请我在帕洛阿尔托（Palo Alto）体验一次。这张照片是我当时用谷歌眼镜（Google Glass）拍的。你们中很多人可能太年轻了，甚至不知道那是什么。但它在当时可是风靡一时。我们坐进车里，在帕洛阿尔托的高速公路、街道上行驶了大约 30 分钟。那次驾驶体验非常完美，全程零人工干预。那是在 2013 年，距今已经 12 年了。这让我相当震惊，因为在经历了那次完美的驾驶和演示后，我感觉自动驾驶的时代即将到来，因为它看起来已经实现了，简直不可思议。
但 12 年后的今天，我们仍然在研究自主性，仍在开发驾驶智能体。即使是现在，我们实际上也还没有完全解决这个问题。你可能会看到 Waymo 的汽车在路上行驶，看起来是无人驾驶的，但你要知道，其中仍有大量的远程操作和「人类在环」的介入。所以我们甚至还没有宣布成功，但我认为它最终肯定会成功，只是花费了很长的时间。
所以，我认为这类软件真的非常棘手，就像自动驾驶一样棘手。因此，当我看到诸如「2025 年是智能体元年」之类的说法时，我会感到非常担忧，我更倾向于认为，这应该是「智能体的十年」，这需要相当长的时间。我们需要「humans in the loop」，我们必须谨慎行事。这毕竟是软件，我们必须严肃对待。
我经常想到的另一个类比是钢铁侠战衣。我一直很喜欢《钢铁侠》，我认为它在很多方面都非常精准地预见了技术将如何发展。我最喜欢钢铁侠战衣的一点是，它既是一种增强工具——托尼·斯塔克可以驾驭它，同时它也是一个智能体。在一些电影里，钢铁侠战衣表现出高度的自主性，可以自己飞行，找到托尼等等。这就是所谓的「自主性滑块」——我们可以构建增强工具，也可以构建智能体，而我们希望两者兼得。
但在现阶段，我想说，考虑到我们使用的是尚不可靠的 LLM，我们更应该构建的是「钢铁侠战衣」式的增强工具，而不是「钢铁侠机器人」那样的自主智能体。我们应该少做一些华而不实的自主智能体演示，多开发一些部分自主性的产品。这些产品拥有定制化的功能和用户界面/用户体验设计。我们这样做是为了让用户的「生成-验证」循环变得非常快，但我们也不能忽视这样一个事实，即这些工作原则上是有可能被自动化的。你的产品中应该有一个「自主性滑块」，并且你应该思考如何推动这个滑块，让你的产品随着时间的推移变得更加自主。我认为这类产品中存在着大量的机会。
现在我想转换一下话题，谈谈另一个我认为非常独特的维度。不仅出现了一种支持软件自主化的新型编程语言，而且正如我所提到的，它是用英语来编程的，这是一种自然接口，于是突然之间，似乎人人都是程序员了，因为每个人都会说像英语这样的自然语言。
这让我感到前景极其光明，也非常有趣，我认为这是史无前例的。过去，你需要花五到十年的时间学习某样东西，才能在软件领域有所作为。现在情况已经不同了。我不知道是否有人碰巧听说过「氛围编程（Vibecoding）」。
就是这条推文引入了这个概念，但我听说它现在已经成了一个重要的网络迷因（meme）。关于这件事有个小故事：我使用推特（Twitter）大概有 15 年了，但我仍然搞不清楚哪条推文会病毒式传播，哪条会无人问津。
我当时以为这条会是后者，只是一些灵光一现的想法。但它最终变成了一个现象级的迷因，我真的无法预测。但我想，这或许是它引起了大家的共鸣，为一种人人都能感觉到但无法言说的东西命了名。所以现在它都有维基百科页面了，好像成了一项重大贡献之类的。
来自 Hugging Face 的 Tom Wolf 分享了一个我非常喜欢的、很棒的视频。这些是正在进行「氛围编程」的孩子们。
我发现这个视频非常暖心，我太喜欢这个视频了。你怎么能看着这样的视频而对未来感到悲观呢？未来是美好的。我认为这最终会成为通向软件开发的「入门砖」。我对下一代的未来并不悲观。是的，我真的很爱这个视频。
我也尝试了一下「氛围编程」（vibecoding），因为它真的太有趣了。当你想要构建一个看起来完全不存在的、超级定制化的东西时，「氛围编程」就非常棒，你只是想即兴发挥一下，可能因为那天是周六或者别的什么原因。所以我做了这个 iOS 应用，我其实并不会用 Swift 编程，但我能构建出一个超级基础的应用，这让我自己都感到震惊。
我就不解释具体内容了，虽然有点傻，但这基本上就是一天的工作量，当天晚上它就在我的手机上运行了，我当时就觉得，「哇，这太神奇了。」我完全不需要为了入门而去读好几天的 Swift 文档。
我还「氛围编程」了另一个叫 Menu Gen 的应用。这个是上线的，你可以在 menuGen.app 上试试。我遇到的问题是，每次去餐厅，我看完菜单也不知道那些菜到底是什么，我需要图片。但并没有这样的工具，所以我想，「嘿，我要用『氛围编程』做一个。」
它看起来是这样的：你访问那个网站，拍一张菜单的照片，然后它就会为菜单生成图片。每个注册用户都能获得 5 美元的免费额度，因此，这成了我生活中的一个主要成本中心。所以这对我来说是个负收入应用，我在 Menu Gen 上已经亏了一大笔钱。
好吧，但 Menu Gen 对我来说最奇妙的一点是，「氛围编程」——也就是写代码的部分——反而是整个项目里最简单的部分。绝大多数工作量都发生在我试图把它做成一个「真实」产品的时候，也就是当你需要加入用户认证、支付、域名和 Vercel 部署时。
这部分真的非常困难。而且这些跟写代码都没关系，所有这些「开发运维」（Devops）的工作都是我在浏览器里手动点击完成的。这整个过程极其枯燥，额外花了我一个星期。所以，一件真正让我着迷的事情是，我只用了几个小时就在我的笔记本上做出了 Menu Gen 的核心演示版本，但之后却花了我整整一个星期，仅仅因为我想把它变成一个正式上线的产品。原因就是，这个过程实在太烦人了。
举个例子，当你想给你的网页添加谷歌登录功能时，我知道这字很小，但你看这个 Clerk 库为了告诉我如何集成，给了巨量的指令。这太疯狂了。它告诉我：访问这个 URL，点击这个下拉菜单，选择那个选项，再到另一个地方点击那个按钮。它就像在指挥我该做什么。一台计算机在告诉我应该执行什么操作。那你为什么不自己做呢？我到底为什么要干这个？见鬼了！我必须遵循所有这些指令，这太疯狂了。
Part 4：Build for agents
因此，我认为我演讲的最后一部分，重点将关注于：我们能不能直接为「智能体」构建？我不想再做这种工作了。
好的。所以概括地说，我认为现在出现了一类全新的数字信息消费者和操纵者。过去只有通过图形界面（GUI）操作的人类，或者通过应用程序接口（API）交互的计算机。而现在，我们有了一个全新的物种——「智能体」（agents）。
它们是计算机，但在某种程度上又很像人类，对吧？它们就像是互联网上的「人类心智」，需要与我们的软件基础设施进行交互。我们能为它们而构建吗？这是一个全新的课题。
举个例子，你可以在你的域名下放置 robots.txt 文件来指示或建议网络爬虫在你网站上的行为方式。同样地，你或许可以有一个 llm.txt 文件，它只是一个简单的 Markdown 文件，用来告诉 LLM 这个域名是关于什么的。
对于 LLM 来说，这会非常易于读取；相反，如果让它去获取你网页的 HTML 并尝试解析，则非常容易出错，也很困难，它会搞砸，根本行不通。所以我们可以直接与 LLM 对话。很多文档目前都是为人类编写的，所以你会看到列表、粗体和图片，这些内容 LLM 无法直接访问。
我看到现在一些服务正在将他们的文档大量地转为专门面向 LLM。例如，Vercel 和 Stripe 是这方面的先行者，但我也看到了其他一些公司已经开始这样做了。他们用 Markdown 格式来提供文档。Markdown 对于 LLM 来说超级容易理解，这很棒。
再举一个我自己的简单例子，可能有些人知道 3Blue1Brown，他制作了非常精美的数学动画视频。是的，我超爱他写的那个叫 Manim 的库，我想用它来做我自己的动画。
网上有大量关于如何使用 Manim 的文档。我其实不想读完它们，所以我把整个文档复制粘贴给了 LLM，描述了我想要的效果，然后它直接就搞定了。LLM 就像是为我「氛围编程」出了我想要的动画。我当时就觉得，「哇，这太神奇了！」
所以，如果我们能让文档对 LLM 来说是清晰易读的，这将解锁巨大的应用潜力。我认为这非常了不起，并且应该得到更广泛的推广。
我想指出的另一点是，很遗憾，你不能只是简单地把你的文档转换成 Markdown 格式。那只是最简单的部分。我们实际上必须改变文档的内容，因为任何时候当你的文档里出现「点击」（click）这个词，这就不好了，LLM 目前无法原生执行这个动作。
所以，Vercel 正在做的一件事就是，把每一个「点击」都替换成一个等效的 curl 命令，这样你的 LLM 智能体就可以代表你来执行。我认为这一点非常有趣。当然，还有 Anthropic 公司提出的「模型上下文协议」（Model Context Protocol，MCP），这也是另一种直接与作为新型数字信息消费者的「智能体」对话的方式。因此，我非常看好这些想法。
我非常喜欢的另一点是，现在出现了许多小工具，它们能帮助我们以对 LLM 非常友好的格式来接收数据。举个例子，当我想用我的一个 Github 代码库，比如我的 nanoGPT 库时，我无法直接把它输入给 LLM 然后提问，因为我们现在看到的，是 Github 上为人类设计的交互界面。
所以，你只需要把 URL 从 Github 改成 get ingest，它就会自动把所有文件拼接成一个巨大的文本文件，并创建出目录结构等等。这样处理好的内容就可以直接复制粘贴到你最喜欢的 LLM 里使用了。
Deep Wiki 是一个更能说明问题的例子。它处理的不仅仅是这些文件的原始内容。这是来自 Devin 的一个功能，他们让 Devin 对 Github 代码库进行分析，然后 Devin 会为你的代码库构建一整套文档页面。你可以想象，这样的内容对于复制粘贴到 LLM 中会更有帮助。所以我很喜欢所有这些小工具，它们只需要你改一下 URL，就能让某些内容可以被 LLM 所访问。这一切都非常好。是的，我认为未来应该有更多这样的工具。
我还想补充一点，未来 LLM 绝对有可能——甚至不是未来，就是现在——它们将能够四处浏览并点击各种东西。
但我仍然认为，我们主动向 LLM「妥协」或「折中」是非常值得的，让它们能更容易地访问所有这些信息。因为我认为，目前让 LLM 这样做的成本仍然相当高昂，而且难度也大得多。因此，我确实认为，对于大量的软件，会有一个长尾效应，它们不会主动去适配（LLM），因为这些代码库或数字基础设施并非「实时活跃」的。所以我们将需要这些（数据提取）工具。
但我认为对其他人来说，在某个中间点与模型达成某种妥协是非常值得的。所以，如果这样说得通的话，我对（模型主动适应和我们主动适配）两个方向都保持乐观。
总而言之，现在是投身这个行业的绝佳时机。我们需要重写大量代码，这些代码将由专业人士和氛围编程者（byte coders）编写。这些 LLM 就像是基础设施，有点像芯片制造厂（fabs），但它们尤其像是操作系统，不过还处于非常早期的阶段，就像是 1960 年代的操作系统。我认为很多类比都是相通的。这些模型就像是会犯错的、你知道的，如同「灵魂」般的存在，我们必须学会如何与它们共事。为了做到这一点，我们需要相应地调整我们的基础设施。
因此，当你构建这些 LLM 应用时，我刚才描述了一些与这些模型高效协作的方法，以及一些能实现这种协作的工具，还有如何快速地迭代这个循环，并最终创造出「部分自主」的产品。然后，是的，我们还需要为「智能体」（agents）更直接地编写大量代码。
但无论如何，回到钢铁侠战衣的那个比喻，我认为在未来大约十年里，我们将见证（技术的）指针从左向右移动。我对它未来的形态充满了极大的兴趣，也很期待看到它最终的样貌。我迫不及待地想与大家一起创造未来，谢谢。
