“软件正在再次改变”|Karpathy 大神2025年YC AI Startup School 开幕演讲回顾 |《YC档案馆》Day 002

内容之外 · Y COMBINATOR · AI STARTUP SCHOOL

Andrej Karpathy：软件正在再次改变

Software Is Changing (Again)

“我们现在正在用英语编程计算机。这足以让软件迎来一个新的大版本。”

Y Combinator AI Startup School · Andrej Karpathy · 2025年6月17日演讲 · 2025年6月19日发布 

大家好。今天很高兴来到这里，和大家聊聊 AI 时代的软件。听说现场很多人还是本科生、硕士生、博士生，或者正准备进入行业。

我觉得，你们现在进入行业的时间点非常特别，也非常有意思。根本原因是：软件正在再次发生变化。

我说“再次”，是因为其实我以前已经做过一场类似的演讲。问题在于，软件还在继续变，所以我又有了一大堆新材料。

我认为，这一次变化非常根本。粗略地说，软件在过去大约 70 年里没有发生过这么基础层面的变化；但在最近几年，它却连续发生了两次非常快速的变化。

所以今天有巨量工作等着我们去做，也有巨量软件需要被重新编写。

Software 1.0：我们熟悉的代码

先把整个软件世界想象成一张地图。这里我展示的是一个叫 Map of GitHub 的工具。你可以把它理解成：人类到目前为止写出来的软件代码，全部被铺在一张地图上。

这些仓库，本质上都是给计算机的指令，用来让计算机在数字空间里完成各种任务。

Software 2.0：不是直接写代码，而是训练权重

几年前，我观察到软件正在发生变化，出现了一种新型软件。当时我把它叫作 Software 2.0。

Software 1.0，就是我们直接给计算机写的代码。

Software 2.0，则主要是神经网络——更准确地说，是神经网络的权重。

你不再直接一行一行写这些代码，而是更多地调整数据集，然后运行优化器，让优化器生成神经网络参数。

当时很多人把神经网络看成一种新的分类器，就像决策树那样。我认为这种理解太窄了，所以提出 Software 2.0 这个框架。

今天，我们甚至已经有了 Software 2.0 世界里的 GitHub：Hugging Face。

你可以把 Hugging Face 看成 Software 2.0 的代码仓库。不同模型、权重、微调版本，就像代码世界里的 commit。

例如图像生成模型 Flux。每当有人在 Flux 基础上做一次微调，本质上就像在这个 Software 2.0 空间里提交了一次新的 commit，于是你得到一个略有不同的图像生成器。

所以，Software 1.0 是编程计算机的代码；Software 2.0 是编程神经网络的权重。

过去我们熟悉的神经网络，大多还是固定功能计算机：输入一张图，输出一个类别；输入一个信号，输出某个固定预测。

Software 3.0：神经网络第一次变得“可编程”

我认为真正发生根本变化的地方，是神经网络随着大型语言模型出现以后，第一次变得可编程。

这是一种新的计算机，所以在我脑子里，它值得一个新的版本号：Software 3.0。

你的 prompt，现在就是程序。你通过 prompt 去编程一个 LLM。

更不可思议的是，这些程序居然是用英语写的。

假设你要做情感分类。你可以写一些 Python 代码，这是 Software 1.0；你可以训练一个神经网络，这是 Software 2.0；你也可以只写一小段 prompt，让大型语言模型完成，这是 Software 3.0。

今天 GitHub 上已经越来越常见一种新形态：代码中混杂着大量英文。

所以我们不只是遇到了新的编程范式，还遇到了一个非常特殊的事实：新的编程语言，恰好就是人类的自然语言。

几年前我第一次真正意识到这一点时，非常震撼。我发了一条后来长期置顶的推文：我们现在正在用英语编程计算机。

Tesla：Software 2.0 怎样真正“吃掉”Software 1.0

我在 Tesla 做 Autopilot 时，就曾经看见过一轮类似变化。

车辆底层会接收来自摄像头和其他传感器的输入，最后输出方向、加速和制动。

最开始，整个 Autopilot 里有大量 C++，也就是 Software 1.0；同时夹杂着一些做图像识别的神经网络，也就是 Software 2.0。

但随着 Autopilot 变得越来越好，神经网络在能力和规模上不断扩张，而很多原来用 C++ 手写的逻辑则不断被删除。

例如，不同摄像头之间、不同时间帧之间的信息拼接，原来很多是用传统代码处理的；后来逐渐交给神经网络。

所以 Software 2.0 几乎是字面意义上一路“吃穿”了 Autopilot 的软件栈。

而我认为，现在同样的事情又要发生一次。

我们现在有三种完全不同的编程范式：1.0、2.0、3.0。

如果你现在要进入行业，我非常建议你对三者都熟练。因为它们各有优缺点。

面对一个功能，你必须判断：这应该写成显式代码？应该训练一个神经网络？还是应该直接通过 prompt 调用 LLM？

未来的软件工程师必须能够在这三种范式之间流畅切换。

接下来，我想先讨论：LLM 到底是一种什么样的新计算机？它的生态应该怎样理解？

第一种类比：LLM 像公用事业

Andrew Ng 很多年前说过一句话：AI 是新的电力。

我觉得这个类比确实捕捉到了某些很重要的东西。今天的 LLM 非常像公用事业。

OpenAI、Gemini、Anthropic 这些实验室先投入巨额资本开支训练模型，这有点像建设电网。

然后它们再持续投入运营成本，通过 API 把“智能”输送给所有人。

我们按使用量计费，比如每百万 token 多少钱。

而我们对这些 API 的要求，也非常像对公用事业的要求：低延迟、高可用性、稳定质量。

在电力系统里，你可能有转换开关，可以在电网、太阳能、电池、发电机之间切换。

在 LLM 世界里，你可能有 OpenRouter，让应用可以在不同模型之间快速切换。

因为这些 LLM 是软件，不会像不同发电商那样争夺物理空间，所以你完全可以同时拥有六家‘智能供应商’，根据需要切换。

最近几天几个主流 LLM 都出现过宕机。非常有意思的是，人们一下子就卡住了，工作做不下去。

当最先进的 LLM 掉线时，世界会发生一种‘智能欠压’。就像电网电压不稳一样，整个地球突然变笨了一点。

而随着我们越来越依赖模型，这种现象会越来越明显。

第二种类比：LLM 又有点像晶圆厂

LLM 不只像公用事业，它们也有一点像晶圆厂。

原因是训练先进模型所需的资本开支巨大，而且技术树增长得极快。

大量深技术、研发诀窍正在集中到少数 LLM 实验室里。

你甚至可以做一些半导体行业的类比：某个几纳米制程，大概可以类比为某种特定规模的最大算力集群。

如果你只使用 Nvidia GPU，只做软件，不自己造硬件，那么很像 fabless 模式。

如果你像 Google 一样，自己做 TPU，又自己训练模型，那就更像 Intel——你连自己的‘晶圆厂’也一起拥有。

当然，这个类比也会失真，因为软件的可复制性和可塑性比真实晶圆厂强得多。

第三种类比：最像操作系统

但如果必须选一个我认为最有用的类比，我会说：LLM 最像一种新的操作系统。

它不只是水和电这种从水龙头里流出来的商品。它正在变成一个越来越复杂的软件生态。

今天的 LLM 生态也开始像操作系统市场：有几个封闭式供应商，就像 Windows、macOS；同时也有开放生态，就像 Linux。

在 LLM 里，我们有几家相互竞争的闭源供应商，也可能有一个类似 Linux 的开源模型生态。目前 Llama 也许最接近这种位置。

当然，现在还很早。未来它不会只是一个简单 LLM，还会包括工具调用、多模态、各种上下文管理和编排。

如果从计算机结构类比：LLM 像 CPU；context window 有点像内存；模型负责在问题求解过程中协调计算和记忆，再调用各种外部能力。

从这个角度看，它非常像一个新的操作系统。

再举一个类比。你去下载 VS Code，可以选择 Windows、Linux 或 Mac 版本。

同样，你使用 Cursor 这样的 LLM 应用，也可以在 GPT、Claude、Gemini 等模型之间切换。

应用和底层‘操作系统’之间，开始出现一种非常熟悉的分层关系。

LLM 的计算时代，大概还在 1960 年代

我觉得我们现在非常像计算机历史里的 1960 年代。

这种新计算机的算力还非常昂贵，所以 LLM 必须集中部署在云端。

我们每个人都只是 thin client，通过网络与云里的大计算机交互。

没有任何个人可以独占一整台这种昂贵计算机，于是最合理的方式就是 time sharing：所有人共享同一台大机器，只是成为云端 batch 里的一个维度。

这和早期计算机历史非常相似。操作系统在中央大机上，一切通过网络终端访问，计算被分时。

真正的个人计算革命还没有在 LLM 世界里发生，因为经济上还不成立。

但已经有人在尝试。比如 Mac mini 对某些本地 LLM 其实很合适，因为 batch size 为 1 的推理非常受内存带宽约束。

这也许是个人计算早期的一点迹象。

但我们还完全不知道最终形态是什么。也许就在座的某些人会去发明它。

ChatGPT 今天更像终端，还没有真正的通用 GUI

每次我直接在文本里和 ChatGPT 或其他 LLM 对话，我都觉得自己像是在通过 terminal 访问操作系统。

这是一种非常直接的、文本式的操作系统入口。

而真正通用的 GUI，似乎还没有被发明出来。

ChatGPT 未来的 GUI 到底应该是什么？它是否应该继续只是聊天气泡？

当然，后面我会讲到的一些应用已经有自己的 GUI，但还没有出现一个跨所有任务的通用 LLM GUI。

这一次最反常：技术扩散方向翻转了

LLM 和历史上的操作系统还有一个非常特别的不同点。

大多数变革性技术，比如电力、密码学、计算机、航空、互联网、GPS，都是政府和大型企业最先使用。

因为它们刚出现时昂贵、复杂、稀缺，然后才逐渐扩散到消费者。

但 LLM 完全反过来了。

早期计算机可能先用于弹道、军事等任务；今天我们得到一种神奇的新计算机，结果我先拿它来问：鸡蛋到底煮几分钟。

这是很奇妙的。消费者反而走在前面，企业和政府在 adoption 上落后。

而且这种新计算机一夜之间就可以通过软件分发到几十亿人的设备上。

这在技术史上非常不寻常。

所以目前为止，我对 LLM 的总结是：它们像公用事业，也像晶圆厂，但尤其像操作系统；我们正处在它们的 1960 年代；我们正在把整个计算机产业重新做一遍。

而更前所未有的是：这种新计算机不是只掌握在几家政府或公司手里，而是几乎所有人都能直接用。

这就是为什么我觉得，你们现在进入行业的时点非常疯狂，也非常难得。

但在真正编程这种新计算机以前，我们必须先花一点时间理解：LLM 到底是什么。

LLM 是“people spirits”

我喜欢把 LLM 想成一种“people spirits”——人类幽灵。

它们是对人的随机模拟。

底层模拟器恰好是一个自回归 Transformer。Transformer 是一种神经网络，它一次生成一个 token：一块、一块、一块地往前走。

而且几乎每生成一个 token，都要消耗近似规模的计算。

我们把这个模拟器的权重拟合到互联网上的大量人类文本，所以最后得到一个极其奇怪的东西：它因为训练在人类数据上，而涌现出一种类人的心理。

它们像《Rain Man》：记忆超人

第一件最明显的事情，是 LLM 拥有百科全书式知识和记忆。

它们读过的东西远远超过任何单个人类，所以在很多记忆型任务上非常夸张。

这让我想到电影《Rain Man》。Dustin Hoffman 演的是一位自闭症学者，可以翻完电话簿，然后记住所有名字和电话号码。

LLM 有点像这样。它们可以轻松记住 SHA hash、大量冷知识和各种具体模式。

所以在某些维度，它们确实拥有超能力。

但它们也有非常奇怪的认知缺陷

与此同时，它们会幻觉，会编造东西，而且对‘自己知道什么、不知道什么’没有足够好的内部模型。

这个问题这些年变好了一些，但远没有完全解决。

它们还表现出所谓的锯齿状智能。

在某些问题域里，它们会比人类强很多；但在另一些地方，它们会犯几乎没有正常人会犯的错误。

例如坚持 9.11 大于 9.9，或者数错 strawberry 里有几个 r。

这些粗糙边缘意味着：你会在非常意想不到的地方绊倒。

它们还有一种“顺行性遗忘”

如果一个新同事加入你的公司，他会随着时间逐渐学习组织背景、积累上下文、理解公司文化。

他晚上回家睡觉，会巩固知识，长期逐渐形成 expertise。

LLM 原生不会这样。

这是目前 LLM 研发里还没有真正被解决的东西。

Context window 更像工作记忆。你必须非常直接地去编程和管理这部分工作记忆。

模型不会因为每天和你一起工作，就天然像人类员工那样持续变得更了解组织。

如果要找大众文化类比，我推荐两部电影：《Memento》和《50 First Dates》。

两部电影里的主角都像是：模型权重固定，但每天早上 context window 被清空。

想象一个同事每天来上班都忘掉昨天发生了什么，你就能理解这件事为什么麻烦。

安全性：这些“人类幽灵”还很容易被骗

还有一些与安全有关的问题。

LLM 非常容易轻信，也容易受到 prompt injection 影响，可能泄露数据，还存在很多其他安全风险。

所以归根结底，我们正在面对这样一种系统：它在一些事情上极其超人，在另一些事情上又带着非常奇怪的认知缺陷。

真正的问题是：怎样编程它们，怎样绕开缺陷，同时利用它们的超能力？

接下来我想转到机会：我们到底应该怎样使用这些模型？这里当然不是完整清单，只是我觉得特别有意思的一些方向。

我最兴奋的一类：部分自治应用

第一类，我把它叫作 partial autonomy apps——部分自治应用。

以编程为例。

你当然可以直接打开 ChatGPT，不断复制粘贴代码、bug report、报错，再把生成结果复制回来。

但为什么要直接和‘操作系统’对话？

更合理的是使用一个专门为编程设计的应用。

所以很多人会用 Cursor，我自己也用。

Cursor 是早期 LLM 应用里一个非常好的例子，因为它展示了很多可能适用于未来 LLM 应用的通用属性。

第一：应用替你做大量上下文管理

Cursor 会替你管理项目上下文，而不是让你每次手工复制粘贴所有相关文件。

第二：它在后台编排多个模型

底层并不是只有一个聊天模型。它可能用 embedding model 处理你的文件，也有真正对话的模型，还有专门应用 diff 的模型。

这些东西被应用统一编排，所以用户不必关心。

第三：应用专属 GUI 极其重要

这一点经常被低估。

你不应该永远只和 LLM 交换文字。文本很难读，也很慢。

例如代码变化，最合理的交互不是让模型用文字描述：‘我删了哪一行，新增了哪一行。’

你应该直接看红绿色 diff，一眼看出增加和删除。

然后按 Command-Y 接受，Command-N 拒绝。没必要在聊天框里打字回答 yes/no。

GUI 让人类更容易审计这些并不可靠的系统，也让验证速度大幅提高。

第四：自主性滑杆

Cursor 里还有一个我非常喜欢的概念：autonomy slider——自主性滑杆。

你可以只用 Tab completion，这时人类几乎完全掌控。

你可以选中一小段代码，用 Command-K 只改这一段。

你可以用 Command-L 改整份文件。

也可以直接让它在整个 repo 里自由行动——这就接近 full autonomy agent。

所以你一直在自己选择：对当前任务，我愿意把多少控制权交出去？

任务越简单、越可验证，你可以把滑杆往右推；任务越复杂、越危险，就应该把滑杆往左拉。

Perplexity 也是同样结构

Perplexity 同样展示了这些属性。

它把大量信息组织起来，在后台编排多个 LLM，有 GUI 帮你审计来源，还提供不同自主程度。

你可以只做快速搜索，也可以做 Research，或者 Deep Research，让它十分钟后回来。

这些本质上只是你给工具的自治程度不同。

所以我真正想问的是：未来大量软件是不是都会变成部分自治？

如果你今天维护一个产品或服务，你应该开始问：LLM 能不能看到人类能看到的一切？LLM 能不能采取人类能采取的所有行动？人类能不能监督这些行动并始终留在闭环里？

例如 Photoshop 里的 diff 应该长什么样？

今天大量软件里的开关、按钮、菜单都只为人类设计。未来这些能力也必须暴露给 LLM。

在这些 LLM 应用里，有一个我认为还没有得到足够重视的问题。

今天 AI 和人的合作结构，大致是：AI 做生成，人类做验证。

既然这样，对我们最有价值的事情，就是让这个闭环尽可能快。

第一条：把验证速度做快

GUI 在这里极其重要。

因为 GUI 可以利用每个人脑子里的‘视觉 GPU’。

读长文本很费力，也不太愉快；但看图、看颜色、看布局，对大脑来说是一条更高带宽的输入高速公路。

所以视觉表示非常适合做审计。

第二条：把 AI 拴在绳子上

我觉得很多人对 AI Agent 过度兴奋了。

如果一个 agent 瞬间给我的代码仓库生成 10,000 行 diff，这对我没有帮助。

因为真正的瓶颈仍然是我。

即使那 10,000 行代码一秒钟就生成了，我仍然必须确认它有没有引入 bug、是不是做了正确的事情、有没有安全问题。

所以我们必须保持 AI 在可控范围内。

我自己做 AI assisted coding 时，一直害怕特别大的 diff。

我倾向把工作切成很小、很具体的增量，一小块一小块做，然后快速完成生成—验证循环。

我想很多人也正在形成类似的工作流。

好 prompt 的价值：减少验证失败

最近我读到一些总结如何与 LLM 高效协作的文章，其中一个很好的原则就是：prompt 如果太模糊，AI 更容易做出和你期待不一样的东西。

一旦验证失败，你就得返工、重问、重新生成，整个闭环开始打转。

所以很多时候，值得在 prompt 阶段多花一点时间，把要求说得更具体，提高一次通过验证的概率。

教育也需要“中间可审计物”

我最近也很关心 AI 时代的教育。

我同样觉得：不能只是打开 ChatGPT，然后说‘教我物理’。

因为 AI 很容易在森林里走丢。

对我来说，更合理的是两类应用。

一个应用让老师创建课程；另一个应用把课程交付给学生。

两者之间有一个中间产物——课程本身。

这个产物是可审计的：我们可以检查课程是不是正确、前后是否一致、项目顺序是否合理。

同时 AI 也被约束在一个明确 syllabus 和明确 progression 里，不会随便漂走。

我认为，这种结构比一句‘教我物理’成功率高得多。

Tesla Autopilot：我第一次体验自动驾驶，是 2013 年

我对部分自治并不陌生，因为我在 Tesla 大概做了五年类似的东西。

Autopilot 本身就是部分自治产品。

车辆仪表盘里会显示神经网络看到了什么，这其实就是一个 GUI。

而且 Autopilot 一直有某种自主性滑杆：随着系统能力提高，我们逐步替用户承担更多驾驶任务。

我第一次坐真正的自动驾驶车，其实是在 2013 年。

我有一个朋友在 Waymo 工作，他带我在 Palo Alto 附近坐了大约 30 分钟。

我当时还用 Google Glass 拍了一张照片。现场很多人可能年轻到都没听过 Google Glass，但当时它一度非常火。

那次驾驶经过高速公路、城市道路，整个过程零干预。

注意，这是 2013 年。

那次完美 demo 给我的感觉是：自动驾驶马上就要来了。它已经完全可以工作，这太疯狂了。

但现在十二年过去，我们还在继续做自动驾驶。

今天你会看到 Waymo 在街上无人驾驶，但背后仍然存在大量远程操作、人类介入和复杂系统。

我们甚至还没有真正宣布这个问题彻底解决。

我当然认为现在自动驾驶最终一定会成功，但它花的时间远比当年一个完美 demo 让人想象的久。

为什么我对“2025 是 Agent 元年”非常警惕

软件非常棘手，而驾驶同样是软件问题。

所以每次我看到‘2025 是 Agent 元年’这样的说法，都会很紧张。

我的感觉更像是：这会是 Agent 的十年，而不是 Agent 的一年。

我们需要很长时间，需要人类在闭环里，需要认真、谨慎地推进。

这毕竟是软件。要认真一点。

Iron Man：最好的类比不是机器人，而是战衣

我一直很喜欢 Iron Man，因为我觉得它对技术未来的某些直觉非常准确。

Iron Man 战衣既是 augmentation，也是 agent。

Tony Stark 可以直接驾驶它；但在一些电影里，战衣也可以自主飞行、寻找 Tony、执行任务。

这正是我说的自主性滑杆。

我们可以构建 augmentation，也可以构建 agent；长期当然两者都要。

但在今天这些仍然容易犯错的 LLM 面前，我更愿意说：少造 Iron Man 机器人，多造 Iron Man 战衣。

也就是说，少追求那些看起来很炫的全自动 agent demo，多做部分自治产品。

这些产品应该有专门的 GUI、UI/UX，让人类与 AI 之间的生成—验证循环尽可能快。

但同时不要忘记：从原则上说，这些工作未来确实可能自动化。

所以产品里应该有一条自主性滑杆，而且你应该持续思考怎样随着系统变强，逐步把滑杆往右推。

接下来我想换一个维度。

Software 3.0 不只意味着多了一种支持自动化的新编程语言。它还有一个极其独特的特点：这种编程语言就是英语。

而所有会说自然语言的人，都突然获得了一种编程能力。

这让我非常乐观，也非常兴奋，因为这在软件史上完全没有先例。

过去，你通常需要花五到十年学习，才有能力真正做软件。

现在不一定了。

Vibe Coding

不知道现场有多少人听说过 Vibe Coding。

这个词来自我发的一条推文。

我在 Twitter 上已经很多年了，到今天也完全不知道哪条推文会火、哪条会没人理。

发这条推文时，我本来觉得它大概属于后者，只是某种洗澡时突然想到的东西。

结果它完全变成了一个 meme。

我猜它只是给一种很多人已经感受到、却还没有名字的体验起了名字。

现在甚至有 Wikipedia 页面。

小孩子已经开始 Vibe Coding

Hugging Face 的 Thomas Wolf 分享过一段我非常喜欢的视频：一些小孩正在 vibe coding。

我觉得那是一段特别健康、特别令人开心的视频。

你怎么看完这样的视频还能对未来悲观？

我觉得 Vibe Coding 很可能会成为很多人进入软件开发的‘入口药物’。

我并不对下一代的软件能力悲观。

我自己也试过：不会 Swift，也能一天做出 iOS App

我自己当然也会 vibe coding，因为真的很好玩。

尤其当你只是想做一个高度定制、外面根本没有的东西，而今天刚好是星期六，你想随手把它做出来。

我做过一个 iOS App。

我其实不会 Swift，但让我震惊的是，我依然能做出一个非常基础的应用，而且当天就跑在自己的手机上。

这对我来说很不可思议，因为我不需要先花五天读 Swift 文档才能开始。

MenuGen：代码反而成了最容易的部分

我还 vibe coded 了一个叫 MenuGen 的应用。

问题非常简单：我去餐厅看菜单，经常根本不知道那些菜是什么，我需要图片。

现成产品里没有我想要的东西，于是我就说，好吧，我自己 vibe code 一个。

你可以拍一张菜单照片，然后 MenuGen 会为菜单项目生成图片。

每个注册用户还有 5 美元免费额度，所以目前它是我人生里的重大成本中心——这是一个负收入应用，我已经亏了很多钱。

但真正让我觉得有意思的是：写代码本身反而是 MenuGen 最容易的部分。

真正困难的是，我想把它从一个本地 demo 变成一个真实服务。

我需要 authentication、payments、domain name、deployment。

这些都不是在写代码。

而是在浏览器里不停点按钮。

几小时我就能在本机把 demo 跑起来，但又花了一周才把它真正上线。

最荒谬的瞬间：电脑在告诉我该点哪里

例如给网页加入 Google 登录。

某个库的文档会给你一大堆操作：打开这个网址，点这个下拉菜单，选这个，再去另一个页面点击那个。

我看着这些说明突然觉得很荒谬：现在是计算机在告诉我应该怎样操作计算机。

那你自己为什么不做？为什么是我在点？

这就是我最后一部分演讲想解决的问题：我们能不能直接为 agent 构建基础设施，让它们来做这些事情？

我认为，数字信息现在出现了一个新的消费者和操作者类别。

以前只有两类：人通过 GUI 操作软件；程序通过 API 操作软件。

现在出现第三类：Agent。

它们当然还是计算机，但又有一点像人——前面我说过，它们像互联网上的 people spirits。

问题是，我们现有的软件基础设施并没有为这种新消费者设计。

从 robots.txt 到 llms.txt

网站今天可以放 robots.txt，告诉网络爬虫怎样访问这个域名。

同样，我们也可以想象一个 llms.txt——一个非常简单的 Markdown 文件，直接告诉 LLM：这个网站是做什么的、有哪些重要入口。

这对 LLM 来说非常容易读。

如果你非要让它抓整个 HTML，再自己理解 DOM、按钮、样式、导航，它就更容易出错。

既然如此，为什么不直接用机器更容易理解的格式和它说话？

文档也必须重写给 LLM

今天大量文档都是给人类写的：列表、粗体、图片、页面跳转。

越来越多服务正在把文档重新做成更适合 LLM 的形式。

Vercel、Stripe 都是比较早开始做这件事的公司，它们提供 Markdown 版本文档。

Markdown 对 LLM 非常友好。

我自己有一次想使用 3Blue1Brown 的动画库 Manim。

文档很多，我不想全读，于是把文档整个复制给 LLM，然后描述自己想要什么。

结果几乎一次就做出了我想要的动画。

这让我更加相信：如果文档本身对 LLM 可读，会解锁大量新用法。

但仅仅把 HTML 转成 Markdown 还不够

真正的问题是，文档内容本身也得改变。

只要文档里写着‘点击这里’，对 agent 就非常糟糕，因为它还需要模拟人的视觉交互。

Vercel 的一个做法，就是把文档里的‘点击这个按钮’，替换成等价的 curl 命令。

这样 LLM agent 就可以直接执行。

所以我们不是只在换格式，而是在把软件能力从‘只能给人点’改成‘机器也能原生调用’。

MCP：直接为 Agent 提供协议

当然，还有 Anthropic 的 Model Context Protocol，也就是 MCP。

它代表了同样的方向：直接给 agent 一套结构化协议，让它作为新的信息消费者和操作者去使用数字系统。

我对这些方向都非常看好。

GitIngest、DeepWiki：把人类界面翻译成 LLM 界面

我还非常喜欢一类小工具：只要改一下 URL，就能把人类界面转成 LLM 友好形式。

例如我自己的 nanoGPT GitHub 仓库。

GitHub 页面是给人看的，直接把整个页面交给 LLM 并不理想。

但如果把 URL 里的 github 换成 gitingest，它会把仓库文件拼成一个巨大文本，附上目录结构，直接可以复制给 LLM。

DeepWiki 更进一步。

它不只是把源码原样拼起来，而是让 Devin 去分析仓库，再生成整套文档页面。

这种结果更适合直接交给 LLM。

我非常喜欢这种‘改一下 URL，整个资源瞬间适配 LLM’的工具。

即使模型未来会自己点击，今天也值得“和模型在中间相遇”

当然，现在甚至今天的模型就已经可以控制浏览器、点击按钮。

未来这方面能力一定会更强。

但我仍然认为，非常值得为它们专门重构基础设施。

因为让 agent 通过视觉点击 GUI，今天仍然贵、慢、脆弱。

互联网还有很长的长尾，很多软件不会马上被重写，所以我们当然也需要会操作旧 GUI 的 agent。

但对于仍然活跃、仍然迭代的软件系统，最合理的做法应该是主动和 LLM 在中间相遇：让系统本身变得更容易被 agent 使用。

最后总结一下。

这是一个非常惊人的时间点，非常适合进入软件行业。

我们需要重写大量代码，也会写出大量新代码。

有些代码仍然由专业程序员来写，也会有大量代码由普通人通过自然语言生成。

LLM 有一点像公用事业，有一点像晶圆厂，但尤其像操作系统。

而且现在真的太早了。

我们大概还在 LLM 操作系统的 1960 年代。

所以很多早期计算机历史的类比都会重新发生。

这些 LLM 又像一群有缺陷的 people spirits。

它们很强，但会犯错，所以我们必须学会怎样与它们一起工作。

为了做到这一点，我们需要修改自己的数字基础设施。

构建 LLM 应用时，我们应该认真设计人类和模型之间的生成—验证闭环，让它运转得非常快。

我们应该构建部分自治产品，而不是一开始就追求全自动。

与此同时，还要直接为 agent 写很多软件，让它们可以成为数字世界新的原生参与者。

如果回到 Iron Man 的比喻，我认为未来十年大概会发生这样的事情：我们会把自主性滑杆，从左边一点一点推向右边。

这个过程会是什么样，我非常好奇。

我也迫不及待想和你们一起把它做出来。