機器之心報道

機器之心編輯部

回顧 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）更直接地編寫大量代碼。

但無論如何，回到鋼鐵俠戰衣的那個比喻，我認為在未來大約十年里，我們將見證（技術的）指針從左向右移動。我對它未來的形態充滿了極大的興趣，也很期待看到它最終的樣貌。我迫不及待地想與大家一起創造未來，謝謝。