Andrej Karpathy 剛剛在舊金山舉行的Y Combinator AI 創業學院的最新主題演講，這是Andrej最新的關于軟件工業領域正在發生巨變的集大成思考，我給大家把完整的中文文字版和視頻版都整理出來了，強烈建議收藏反復觀看和閱讀

Andrej 融合了他在斯坦福、OpenAI 和特斯拉的工作經驗，洞察到一場變革正在發生。軟件，正再次迎來巨變。Andrej認為我們已經進入了“軟件 3.0”時代——在這個時代，自然語言成為了新的編程接口，而模型則負責完成其余的工作

Andrej深入探討了這場變革對開發者、用戶乃至軟件設計本身的意義，并指出：我們不僅僅是在使用新工具，更是在構建一種全新的計算機

演講的核心觀點 (來自 Andrej Karpathy 本人！)：

• 可以肯定地說，軟件正在再次發生根本性的變革。大語言模型（LLM）是一種全新的計算機，而你用英語就能對它進行編程。因此，從軟件的角度來看，它們完全配得上一次重大的版本升級

• 大語言模型兼具了公共設施（utilities）、晶圓廠（fabs）和操作系統（operating systems）的特性 → 這催生了新的“大語言模型操作系統”（LLM OS），它由頂尖實驗室（labs）“制造”（fabbed），并像公共設施一樣分發（目前如此）。許多歷史上的類比都適用——我們正處于計算機發展的“1960 年代”

• LLM 心理學：大語言模型如同“人類心智的幽靈”（people spirits），它們是人類的隨機模擬，其模擬器是一個自回歸 Transformer 模型。由于它們基于人類數據訓練，因而涌現出一種獨特的心理學特性——在某些方面超越人類，但在許多其他方面又難免犯錯。鑒于此，我們該如何與它們高效地攜手合作呢？

• 大語言模型是“人類心智的幽靈” → 這意味著可以構建“部分自主”的產品

• 大語言模型可以用英語編程 → 這讓軟件開發變得極其大眾化！（就是所謂的“憑感覺編程”或“氛圍感編程”/ vibe coding）

• 大語言模型是數字信息新的主要消費者和處理者（在圖形界面/人類和 API/程序之外）→ 為 AI 代理（Agent）而構建！

以下是演講視頻以及中文文字版實錄

軟件再次迎來根本性變革：LLM，用英語編程的新型計算機

今天我很高興能在這里和大家聊一聊 AI 時代的軟件。我聽說在座的很多是學生，比如本科生、碩士、博士等等，你們即將進入這個行業。我認為，現在進入這個行業，正是一個極其獨特且非常有趣的時刻。究其根本，我認為原因在于，軟件正在再次發生變革。

我之所以說“再次”，是因為我其實已經講過這個話題了。但問題是，軟件一直在變，所以我總有大量的新材料來創作新的演講。而且我認為這次的變革是相當根本的。可以說，軟件在過去 70 年里，從未在如此基礎的層面上發生過大的變化，然而在最近幾年里，它卻迅速地變革了大約兩次。這意味著有海量的工作等著我們去做，有海量的軟件需要我們去編寫和重寫。

讓我們來看一下軟件的全貌。如果我們把這張圖想象成“軟件地圖”——這是一個叫做“GitHub 地圖”的炫酷工具——這基本上就是所有被編寫出來的軟件，它們是給計算機下達的、用于在數字空間執行任務的指令。如果你放大看，這里都是不同類型的代碼倉庫，這就是所有已被寫就的代碼

幾年前，我觀察到軟件似乎在變化，出現了一種新型的軟件。當時我稱之為軟件 2.0。這個想法是說，軟件 1.0 是你為計算機編寫的代碼；而軟件 2.0，基本上就是神經網絡，尤其是神經網絡的權重。你不是直接編寫這些“代碼”，更多的是在調整數據集，然后運行一個優化器來生成這些神經網絡的參數。當時，神經網絡還被看作是一種分類器，和決策樹之類的東西差不多。所以，我認為我提出的這個框架是更恰當的

現在，我們實際上有了一個軟件 2.0 領域的等價物。我認為 Hugging Face 基本上就是軟件 2.0 時代的 GitHub。還有一個叫 Model Atlas 的東西，你可以在上面可視化所有在那里編寫的“代碼”。順便說一句，如果你好奇，中間那個巨大的圓點，是 Flux（圖像生成器）的參數。每當有人在 Flux 模型之上進行微調時，就相當于在這個空間里創建了一個 Git 提交，從而創造出一種不同風格的圖像生成器

所以，基本上我們有：

• ?軟件 1.0：編程計算機的計算機代碼。

• ?軟件 2.0：編程神經網絡的權重。

這里有一個例子，AlexNet，一個圖像識別神經網絡。到目前為止，我們直到最近才熟悉的神經網絡，都像是功能固定的計算機，比如“圖像到類別”的轉換器。

我認為，真正發生變化的，也是一個相當根本性的變化，是神經網絡通過大型語言模型（LLM）變得可編程了。我視其為一種非常獨特的新事物，一種新型的計算機。因此，在我看來，它值得一個新的稱號：軟件 3.0。基本上，你的提示（prompt）現在就是用來給 LLM 編程的程序。而最了不起的是，這些提示是用英語寫的，這真是一種非常有趣的編程語言

所以，總結一下這三者的區別：以情感分類為例，你可以編寫一段 Python 代碼來做這件事（軟件 1.0），或者你可以訓練一個神經網絡（軟件 2.0），再或者，你可以給一個大型語言模型下達提示（軟件 3.0）。這里是一個少樣本提示（few-shot prompt），你可以想象如何修改它，用一種稍微不同的方式來“編程”這臺計算機

所以我們有了軟件 1.0、軟件 2.0，而且我認為我們正在看到一個新的代碼類別在增長。也許你已經注意到，很多 GitHub 上的代碼不再是純粹的代碼，而是夾雜了大量的英語。這不僅是一種新的編程范式，更讓我驚嘆的是，它竟然是用我們的母語——英語——來實現的。

幾年前，當這個想法讓我大開眼界時，我發了條推文，吸引了很多人的注意。這至今仍是我的置頂推文：我們竟然開始用英語給計算機編程了。

當我在特斯拉工作時，我們致力于開發 Autopilot（自動輔助駕駛）。我當時展示過這樣一張幻燈片：你可以想象，車輛的輸入在底部，經過一個軟件棧，最終輸出方向盤和油門的控制。我當時的觀察是，Autopilot 中有大量的 C++ 代碼，也就是軟件 1.0 的代碼，同時也有一些用于圖像識別的神經網絡。我觀察到一個趨勢：隨著我們不斷改進 Autopilot，神經網絡的能力和規模都在增長。與此同時，所有的 C++ 代碼都在被刪除，許多最初用軟件 1.0 實現的功能和能力，都被遷移到了軟件 2.0。舉個例子，大量拼接不同攝像頭圖像信息、以及跨時間信息融合的工作，都由一個神經網絡完成了。我們因此得以刪除了大量代碼。所以，軟件 2.0 技術棧毫不夸張地“吞噬”了 Autopilot 的軟件棧。

我認為，當時這非常了不起，而現在我們又一次看到了同樣的事情發生。我們有了一種新型的軟件，它正在吞噬舊的技術棧。我們現在有三種完全不同的編程范式。如果你即將進入這個行業，精通所有這三種范式是個非常好的主意。因為它們各有優劣，你可能需要決定某個功能是用 1.0、2.0 還是 3.0 來實現。你是要去訓練一個神經網絡？還是僅僅給 LLM 寫個提示？或者這應該是一段明確的代碼？我們都需要做出這些決策，并且可能需要在這些范式之間流暢地切換

LLM 的三重身份：公共設施、晶圓廠與操作系統

新的 LLM 操作系統，由各大實驗室“制造”，并（暫時）像公共設施一樣分發。許多歷史類比都適用——在我看來，我們正處于計算科學的 1960 年代。

接下來，在第一部分，我想談談 LLM，以及如何理解這個新的范式、它的生態系統是怎樣的。這種新型計算機到底是什么樣子的？它的生態系統又是什么樣的？

我被吳恩達（Andrew Ng）多年前的一句話深深打動。我想 Andrew 馬上就要在我之后演講了。他當時說：“人工智能是新的電力。” 我確實認為這句話捕捉到了一些非常有趣的東西。LLM 現在無疑感覺具備了公共設施（utilities）的屬性。

LLM 實驗室，比如 OpenAI、Gemini、Anthropic 等，它們投入資本支出（capex）來訓練 LLM，這就像是建設電網。然后，它們投入運營支出（opex），通過 API 向我們所有人提供智能服務。這是通過按量計費的方式實現的，比如我們按每百萬 token 付費。我們對這種 API 的要求，也非常像對公共設施的要求：我們要求低延遲、高可用性、質量穩定等等

在電力系統中，你會有轉換開關，可以在電網、太陽能、電池或發電機之間切換電源。在 LLM 領域，我們可能有像 OpenRouter 這樣的服務，可以輕松地在不同類型的 LLM 之間切換。因為 LLM 是軟件，它們不爭奪物理空間，所以同時擁有六個“電力供應商”并能在它們之間切換是完全沒問題的，因為它們不構成那么直接的競爭

還有一點很有意思，就在過去幾天，許多 LLM 服務都宕機了，人們感覺被困住，無法工作。這讓我覺得很奇妙：當最先進的 LLM 宕機時，實際上就像是世界范圍內的“智能斷電”（intelligence brownout），就像電網電壓不穩一樣。我們對這些模型的依賴越深，地球就會變得越“笨”。這種依賴已經非常顯著，而且我認為還會繼續增長。

但 LLM 不僅僅有公共設施的屬性，我認為說它們具備晶圓廠（fabs）的某些屬性也是公平的。原因在于，構建 LLM 所需的資本支出確實非常龐大，這可不像建個發電站那么簡單。你投入的是巨額資金。而且，這項技術的技術樹正在飛速發展。我們身處一個擁有深度技術樹、研發秘密的世界，而這些都集中在 LLM 實驗室內。不過，這個類比也有點模糊，因為正如我所說，這是軟件，而軟件的可防御性較低，因為它非常易變

所以，這是一個值得思考的有趣問題。你可以做出很多類比，比如 4 納米工藝節點，或許類似于一個擁有特定最大浮點運算能力的計算集群。當你使用英偉達的 GPU，只做軟件而不做硬件時，這就像是無廠模式（fabless model）。但如果你像谷歌一樣，自己制造硬件，在 TPU 上訓練，那更像是英特爾模式（Intel model），即擁有自己的晶圓廠。所以這里有些類比是說得通的。

但實際上，我認為最貼切的類比或許是：在我看來，LLM 與操作系統（operating systems）有非常強的相似性。這不僅僅是電或水，不是那種從水龍頭里流出來的商品。它們正日益成為復雜的軟件生態系統。它們不是像電力那樣的簡單商品

讓我感到有趣的是，這個生態系統的形成方式也與操作系統非常相似。你有少數幾個閉源提供商，比如 Windows 或 macOS，然后你有一個開源的替代品，比如 Linux。對于 LLM，我們同樣有幾個相互競爭的閉源提供商，而 Llama 生態系統目前可能最接近于未來可能成長為像 Linux 那樣的事物。當然，現在還為時過早，因為它們還只是簡單的 LLM，但我們開始看到它們將變得遠比現在復雜。這不僅僅是 LLM 本身，還關乎工具使用、多模態以及所有這些如何協同工作

當我前段時間意識到這一點時，我試著畫了一張草圖。在我看來，LLM 就像一個新的操作系統。LLM 是一種新型計算機，它就像是 CPU 的等價物。上下文窗口就像是內存。而 LLM 則利用所有這些能力，來協調內存和計算，以解決問題。從這個角度看，它確實非常像一個操作系統。

再舉幾個例子。比如你想下載一個應用，你訪問 VS Code 官網，你可以下載并在 Windows、Linux 或 Mac 上運行它。同樣地，你可以拿一個 LLM 應用，比如 Cursor，然后在 GPT、Claude 或 Gemini 系列上運行它，只是一個下拉菜單的選擇而已。所以在這方面也很相似

更多讓我感觸的類比是，我們仿佛正處于1960年代左右的時期。對于這種新型計算機來說，LLM 的算力仍然非常昂貴。這迫使 LLM 集中在云端，而我們都只是通過網絡與之交互的“瘦客戶端”。我們沒有人能完全獨占這些計算機。因此，采用分時共享（time-sharing）是合乎邏輯的，我們都只是云端計算機運行時批處理（batch）中的一個維度。這與那個時代的計算機非常相像：操作系統在云端，所有東西都通過流式傳輸，并且有批處理。所以，LLM 的個人計算革命尚未到來，因為它在經濟上還不劃算。但我想有些人正在嘗試，比如 Mac mini，事實證明它非常適合某些 LLM，因為如果你做單批次推理（batch-one inference），這完全是內存密集型的，所以效果不錯。我認為這些可能是個人計算的一些早期跡象，但這還沒有真正發生。它會是什么樣子，沒人知道。也許在座的某些人會去發明它是什么，它如何工作，或者它應該是什么樣

還有一個類比我想提一下。每當我在文本界面中直接與 ChatGPT 或某個 LLM 對話時，我都感覺自己像是在通過終端與操作系統對話。它就是文本，是與操作系統的直接交互。一個通用的圖形用戶界面（GUI）還沒有真正被發明出來。比如，ChatGPT 應該有一個除了聊天氣泡之外的 GUI 嗎？當然，我們稍后會講到的一些應用有 GUI，但還沒有一個跨所有任務的通用 GUI

不過，LLM 在某些相當獨特的方面也與早期的操作系統和計算有所不同。我曾寫過關于一個讓我印象深刻的、非常與眾不同的特性：LLM顛覆了技術擴散的方向。通常，對于像電力、密碼學、計算、飛行、互聯網、GPS 等許多革命性新技術，政府和企業通常是第一批用戶，因為它們新技術、價格昂貴等等，之后才會擴散到消費者層面。但我感覺 LLM 卻反過來了。比如，早期的計算機主要是用于彈道計算和軍事用途，但對于 LLM，它關心的卻是如何煮雞蛋之類的事情。這確實是我的很多用法。所以，我們有了一臺神奇的新計算機，它卻在幫我煮雞蛋，而不是幫政府做一些非常了不得的事情，比如軍事彈道計算或某些特殊技術，這讓我覺得很奇妙。事實上，企業和政府在采用這些技術方面，反而落后于我們普通大眾。這完全是反向的。我認為這或許能為我們思考如何使用這項技術，或者它的首批應用會在哪里提供一些啟示。

總結一下到目前為止的觀點：LLM 實驗室、LLM，我認為用這些詞語是準確的。但 LLM 是復雜的操作系統，它們處于計算科學的 1960 年代，我們正在重新經歷計算的演進。它們目前通過分時共享的方式提供，并像公共設施一樣分發。前所未有的是，它們并非掌握在少數政府和企業手中，而是掌握在我們所有人手中。因為我們都有電腦，它只是軟件，而 ChatGPT 就像是被瞬間傳送到了數十億人的電腦上，一夜之間。這太瘋狂了。我至今仍覺得這事不可思議。而現在，輪到我們進入這個行業，為這些計算機編程了。這太瘋狂了。所以我認為這非常了不起。

LLM 心理學：人格幽靈、超人與凡人的結合體

LLM = “人格幽靈”，是對人的隨機模擬，其模擬器是一個自回歸 Transformer。由于它們在人類數據上訓練，因此擁有一種涌現出的心理特質，既在某些方面是超人，又在許多其他方面容易犯錯。鑒于此，我們如何與它們高效地攜手合作？

在為 LLM 編程之前，我們必須花點時間思考這些東西到底是什么。我尤其喜歡談論它們的“心理學”。我喜歡把 LLM 想象成“人格幽靈”（people spirits）。它們是對人的隨機模擬，而這個模擬器恰好是一個自回歸的 Transformer。Transformer 是一個神經網絡，它以 token 為單位，一塊一塊地向前推進，每個 chunk 的計算量幾乎相等。這個模擬器當然包含了一些權重，我們用互聯網上所有的文本數據來擬合它。最終，你就得到了這樣一個模擬器。因為它是在人類數據上訓練的，所以它擁有一種類似人類的、涌現出的心理特質

你首先會注意到的當然是，LLM 擁有百科全書式的知識和記憶力。它們能記住很多東西，遠超任何單個的人類。這讓我想起了電影《雨人》（Rainman），我非常推薦大家去看，那是一部很棒的電影。達斯汀·霍夫曼在片中扮演一個自閉癥天才，他擁有近乎完美的記憶力，可以讀完一本電話簿后記住所有的名字和號碼。我感覺 LLM 非常相似，它們能輕易記住 SHA 哈希值和各種各樣的事情。所以，在某些方面，它們無疑擁有超能力

但它們也有一系列的，我稱之為“認知缺陷”。它們會頻繁地產生幻覺，編造事實，并且沒有一個非常好的、或者說至少是不足夠的內部自我認知模型。雖然這一點有所改善，但仍不完美。它們表現出“參差不齊的智能”（jagged intelligence）。它們在某些問題解決領域是超人，但又會犯一些基本上沒有人類會犯的錯誤，比如堅稱 9.11 大于 9.9，或者草莓（strawberry）里有兩個 R。這些都是些著名的例子。基本上，你隨時可能被它粗糙的邊緣絆倒

它們還患有“順行性遺忘癥”（anterograde amnesia）。我這里想說的是，如果一個新同事加入你的公司，他會隨著時間的推移了解你的組織，并積累大量關于組織的背景知識。他們回家睡覺，鞏固知識，并逐漸建立起專業技能。LLM 本身并不會這樣做。這在 LLM 的研發中也尚未得到解決。所以，上下文窗口實際上更像是“工作記憶”，你必須非常直接地去編程這個工作記憶，因為它們不會默認就變得更聰明。我認為很多人都被這方面的類比誤導了

在流行文化中，我推薦大家看兩部電影：《記憶碎片》（Memento）和《初戀50次》（50 First Dates）。在這兩部電影里，主角的“權重”是固定的，他們的“上下文窗口”每天早上都會被清空。當這種情況發生時，去工作或維持人際關系會變得極具挑戰性。而這正是 LLM 時時刻刻在經歷的

還有一點我想指出，是與使用 LLM 相關的安全限制。例如，LLM 相當容易上當受騙，它們容易受到提示注入（prompt injection）風險的攻擊，可能會泄露你的數據等等。還有許多其他與安全相關的考量。

所以，長話短說，你必須同時面對這樣一個事實：這是一個擁有超能力，但又有一堆認知缺陷和問題的存在。然而它們又極其有用。那么，我們該如何為它們編程？如何繞過它們的缺陷，同時享受它們的超能力？

轉換思路，談談機遇…

從“人格幽靈”到“部分自治產品”

現在我想切換到談論機遇：我們該如何使用這些模型？最大的機遇在哪里？這并非一個詳盡的列表，只是我在這次演講中認為有趣的一些點。

我首先感到興奮的，是我稱之為“部分自治應用”（partial autonomy apps）的東西。以編程為例，你當然可以直接去 ChatGPT，開始復制代碼、粘貼錯誤報告，然后獲取代碼再粘貼回來。但你為什么要這么做呢？為什么要直接和操作系統打交道？擁有一個專門為此設計的應用要合理得多。我想你們中的許多人都在用Cursor，我也在用。Cursor 就是你想要的東西，而不是直接去 ChatGPT。我認為 Cursor 是早期 LLM 應用的一個絕佳范例，它具備了許多我認為在所有 LLM 應用中都通用且有用的特性

具體來說，你會注意到，我們有一個傳統的界面，允許人類像以前一樣手動完成所有工作。但除此之外，我們現在有了這個 LLM 集成，它讓我們能以更大的區塊進行操作。我認為 LLM 應用共享的一些有用特性包括：

1. 1.LLM 負責大量的上下文管理工作。

2. 2.它們編排對 LLM 的多次調用。以 Cursor 為例，它在后臺調用了用于處理所有文件的 embedding 模型、實際的聊天模型，以及將代碼變更（diffs）應用到代碼的模型，這一切都為你編排好了。

3. 3.應用專屬的圖形界面（GUI）及其重要性。這一點非常重要，但可能沒有得到應有的重視。因為你不想直接用文本與操作系統對話。文本很難閱讀、解釋和理解。而且，你也不想在文本中本地執行某些操作。直接看到一個用紅色和綠色表示的變更 diff，看到增加了什么、刪除了什么，要容易得多。用Command + Y接受或Command + N拒絕，也比我必須在文本中輸入要方便得多。GUI 讓人類能夠審計這些易錯系統的工作，并提高效率。我稍后會再回到這一點。

4. 4. 最后一點我想指出的特性是，我稱之為“自治滑塊”（autonomy slider）。例如，在 Cursor 中，你可以只用 Tab 補全，這時你主要還是自己掌控。你可以選中一段代碼，用Command + K只修改那一段。你可以用Command + L修改整個文件。或者你可以用Command + I，讓它在整個代碼庫里自由發揮。這就是完全自治的智能體（agentic）版本。所以，你掌控著這個自治滑塊，根據手頭任務的復雜性，你可以調整你愿意放棄的自主權程度。

再舉一個相當成功的 LLM 應用的例子，Perplexity。它也具備我剛才在 Cursor 中指出的非常相似的特性。它打包了大量信息，編排了多個 LLM，它有一個 GUI 讓你審計它的部分工作，比如它會引用來源，你可以檢查它們。它也有一個自治滑塊：你可以做一個快速搜索，或者進行“研究”（research），或者進行“深度研究”（deep research），然后 10 分鐘后再回來看結果。這些都是你交給工具的不同程度的自主權

所以我的問題是，我感覺大量軟件都會變得部分自治。我正在思考這會是什么樣子。對于你們中許多維護產品和服務的人來說，你將如何讓你的產品和服務部分自治？LLM 能看到人類能看到的一切嗎？LLM 能以人類能采取的所有方式行動嗎？人類能監督并保持在這個活動循環中嗎？因為再說一次，這些是易錯的、尚不完美的系統。一個在 Photoshop 里的“diff”會是什么樣？而且，現在很多傳統軟件有各種開關和設置，都是為人類設計的。所有這些都必須改變，變得能為 LLM 所用。

對于許多我提到的 LLM 應用，有一點我想強調，但我不確定它是否得到了應有的關注。我們現在正與 AI 合作，通常是它們進行生成，我們人類進行驗證。讓這個循環盡可能快地運轉，符合我們的利益，這樣我們才能完成大量工作。我認為有兩種主要方式可以實現這一點：

1. 1.大幅加快驗證速度。我認為 GUI 在這方面極其重要，因為它利用了我們大腦中的計算機視覺 GPU。閱讀文本是費力的，不好玩，但看東西是好玩的，它就像一條通往你大腦的高速公路。所以我認為 GUI 對于審計系統和視覺化表示非常有幫助。

2. 2.我們必須給 AI 系上韁繩。我認為很多人對 AI 智能體（AI agents）過于興奮了。給我一個一萬行代碼的變更提交到我的代碼庫，這對我沒什么用。我仍然是瓶頸。即使那一萬行代碼是瞬間生成的，我必須確保它沒有引入 bug，確保它做的是正確的事情，確保沒有安全問題等等。

所以，基本上，讓這兩者（生成與驗證）的流程變得非常快，符合我們的利益。我們必須設法給 AI 系上韁繩，因為它反應太過度了。這就是我在進行 AI 輔助編程時的感受。如果我只是做一些小規模的編碼，一切都很好。但如果我真的想完成工作，有一個反應過度的智能體在做各種事情，感覺并不好

這張幻燈片不太好，抱歉。但我想，和你們許多人一樣，我正在摸索一些在我的編碼工作流中利用這些智能體的方法。在我自己的工作中，我總是害怕得到太大的變更（diffs）。我總是以小步、增量的方式進行，確保一切都好，我想讓這個循環轉得非常非常快。我專注于單一、具體的小塊工作。我想你們很多人可能也在形成類似的使用 LLM 的工作方式。

我也看到一些博客文章，試圖總結出與 LLM 工作的最佳實踐。這是我最近讀到的一篇，我覺得寫得很好。它討論了一些技巧，其中一些就與如何給 AI 系上韁繩有關。舉個例子，如果你的提示很模糊，AI 可能不會完全按你的意圖行事，那樣驗證就會失敗。如果驗證失敗，你就會開始兜圈子。所以，花多一點時間，讓你的提示更具體，這會增加驗證成功的概率，你就能繼續前進。這更有意義。

我認為我們很多人最終都會找到這樣的技巧。在我自己的工作中，我目前對 AI 和 LLM 時代的教育是什么樣子的很感興趣。對我來說，一個很大的思考點就是如何給 AI 系上韁繩。我不認為直接去 ChatGPT 說“嘿，教我物理”是行得通的。因為 AI 會在“樹林里迷路”。所以對我來說，這實際上是兩個獨立的 App：一個是給老師創建課程的 App，另一個是接收課程并服務于學生的 App。在這兩種情況下，我們都有了一個中間產物——課程，它是可審計的，我們可以確保它質量好、內容一致。AI 被限制在某個教學大綱、某個項目進度的“韁繩”之內。這是給 AI 系上韁繩的一種方式，我認為這樣成功的可能性要大得多，AI 也不會迷路

我還想提到的一個類比是，我對部分自治并不陌生。我在特斯拉為此工作了五年。那也是一個部分自治產品，并且有很多共同的特性。比如，儀表盤上就是 Autopilot 的 GUI，它向我展示神經網絡看到了什么。我們也有自治滑塊。在我任職期間，我們為用戶增加了越來越多的自動化任務

我想簡單講一個故事。我第一次乘坐自動駕駛汽車是在 2013 年。我有一個在 Waymo 工作的朋友，他邀請我在帕洛阿爾托兜了一圈。我當時用谷歌眼鏡拍了這張照片。你們很多人可能太年輕，都不知道那是什么了。但當時這可是風靡一時。我們坐上這輛車，在帕洛阿爾托的高速公路和街道上行駛了大約 30 分鐘。那次駕駛是完美的，零干預。那是 2013 年，距今已經 12 年了。這讓我很震驚，因為當我經歷那次完美的駕駛、完美的演示時，我感覺自動駕駛馬上就要實現了，這太不可思議了。但 12 年后的今天，我們仍然在研究自動駕駛，仍在研究駕駛智能體。甚至現在，我們都還沒有真正解決這個問題。你可能會看到 Waymo 的車在路上跑，看起來是無人駕駛，但背后仍有大量的遠程操作和人工介入。所以我們甚至還沒有宣布成功。但我認為它最終肯定會成功，只是花了很長時間

所以我覺得，軟件真的很難，就像駕駛一樣棘手。所以當我看到像“2025 年是智能體元年”這樣的說法時，我會非常擔憂。我感覺，這應該是智能體的十年，這需要相當長的時間。我們需要人類在環，我們需要謹慎地做這件事。這是軟件，我們嚴肅點。

還有一個我總是在思考的類比，就是鋼鐵俠戰衣。我一直很喜歡鋼鐵俠，我認為它在很多方面，對于技術及其發展方向的描繪都是正確的。我喜歡鋼鐵俠戰衣的一點是，它既是一種增強（augmentation）——托尼·斯塔克可以駕駛它，它同時也是一個智能體（agent）——在一些電影里，鋼鐵俠戰衣相當自主，可以飛來飛去找到托尼。這就是自治滑塊：我們可以構建增強工具，也可以構建智能體。我們想兩者兼顧

但在現階段，與這些易錯的 LLM 合作，我會說，我們需要的不是鋼鐵俠機器人，而更多是鋼鐵俠戰衣。不是去構建炫酷的自主智能體演示，而是去構建部分自治的產品。這些產品有定制的 GUI 和用戶體驗，這么做是為了讓人類的“生成-驗證”循環變得非常快，但我們又不失一個愿景：原則上，這項工作是可以自動化的。你的產品里應該有一個自治滑塊，你應該思考如何滑動這個滑塊，讓你的產品隨著時間的推移變得更加自主。這就是我認為存在大量機會的地方，在這些類型的產品里

用英語編程：軟件的普及化與“氛圍感編程”的興起

現在我想換個角度，談談另一個我認為非常獨特的維度。不僅出現了一種新的、允許軟件實現自主性的編程語言，而且正如我所說，它還是用英語編程的，這是一種自然的界面。突然之間，每個人都成了程序員，因為每個人都會說像英語這樣的自然語言。這對我來說是極其利好且非常有趣的，也是完全前所未有的。過去，你可能需要花五到十年學習某樣東西，才能在軟件領域做點什么。現在不再是這樣了

我不知道有沒有人聽說過“氛圍感編程”（vibe coding）？就是這條推文引入了這個詞。但我聽說這現在已經成了一個大梗了。關于這個有個有趣的故事：我在推特上大概有 15 年了，但我仍然不知道哪條推文會火，哪條會無人問津。我當時以為這條會是后者，就是個靈光一閃的想法。但它成了一個徹頭徹尾的梗，我真的搞不懂。但我想，它觸動了大家的共鳴，給了一種大家都能感覺到但說不出來的東西一個名字。現在它都有維基百科頁面了

是的，這現在成了我的一個重大貢獻之類的了

Hugging Face 的 Tom Wolf 分享了一個我很喜歡的、非常美好的視頻。這些是正在進行“氛圍感編程”的孩子們

我發現這個視頻特別暖心。我愛這個視頻。你怎么能看著這個視頻還對未來感到悲觀呢？未來是美好的。我認為這最終會成為通向軟件開發的入門“敲門磚”。我對下一代的未來并不悲觀。是的，我愛這個視頻。

我也試了一下“氛圍感編程”，因為它太好玩了。當你想構建一個超級定制化、似乎不存在的東西，并且只是因為是周六想隨便搞搞時，“氛圍感編程”就太棒了。我做了這個 iOS 應用，我其實不會用 Swift 編程，但我能做出一個超級基礎的應用，這讓我非常震驚。我就不解釋它是什么了，挺傻的。但這只花了一天的工作量，當天晚上它就在我手機上運行了。我當時就覺得：“哇，太神奇了。” 我不必為了入門而去讀五天的 Swift 文檔

我還“氛圍感編程”了這個叫 MenuGen 的應用。它現在是上線的，你可以在 menu.gen.app 上試試。我當時遇到的問題是，每次去餐廳，我看完菜單，完全不知道那些菜是什么，我需要圖片。但沒有這樣的東西。所以我想：“嘿，我要‘氛圍感編程’一個。”

它看起來是這樣的，你訪問 menu.gen.app，給菜單拍張照，然后 MenuGen 就會生成圖片。每個注冊用戶都能免費獲得 5 美元的額度，因此這成了我生活中的一個主要成本中心。所以這對我來說是一個負收入應用。我在 MenuGen 上已經虧了一大筆錢了。

但 MenuGen 對我來說最奇妙的一點是，代碼本身，也就是“氛圍感編程”的那部分，反而是最簡單的部分。大部分的工作，是在我試圖讓它真正可用的時候產生的：身份驗證、支付、域名、Vercel 部署……這些都非常困難。而且所有這些都不是代碼，所有這些 DevOps 的東西都是我在瀏覽器里點來點去完成的。這過程極其緩慢，又花了我一周時間

這真的很有趣：我在幾小時內就在我筆記本上做出了 MenuGen 的演示版，但之后花了一周時間才讓它真正上線。原因就是，這個過程太煩人了。比如，如果你想給你的網頁加上谷歌登錄，我知道這字很小，但這是 Clerk 這個庫告訴我的海量指令，關于如何集成它。這太瘋狂了。它告訴我：去這個 URL，點擊這個下拉菜單，選擇那個，再去那個地方，點擊那個。它像電腦一樣告訴我應該采取什么行動。你來做啊，為什么讓我來做？搞什么鬼！我不得不跟著所有這些指令操作，太瘋狂了

為智能體而構建：迎接數字信息的全新消費者

因此，我演講的最后一部分，關注的就是：我們能直接為智能體（agents）而構建嗎？我不想做這些工作，能讓智能體來做嗎？

粗略地說，我認為出現了一個全新類別的數字信息消費者和操縱者。過去只有通過 GUI 的人類，或通過 API 的計算機。現在，我們有了一個全新的東西——智能體。它們是計算機，但又有點像人，對吧？它們是互聯網上的“人格幽靈”。它們需要與我們的軟件基礎設施交互。我們能為它們而構建嗎？這是一個新事物

舉個例子，你可以在你的域名上放一個robots.txt文件，來指示——或者說建議——網絡爬蟲在你的網站上應該如何行為。同樣地，你或許可以有一個lm.txt文件，就是一個簡單的 Markdown，告訴 LLM 這個域名是關于什么的。這對 LLM 來說非常易讀。如果它非得去獲取你網頁的 HTML 并嘗試解析，那將非常容易出錯，很困難，而且會搞砸。所以我們可以直接與 LLM 對話，這值得做

大量的文檔目前是為人類編寫的。你會看到列表、粗體、圖片，這些都無法被 LLM 直接訪問。我現在看到一些服務正在將它們的文檔大量地轉向專門為 LLM 設計。例如，Vercel 和 Stripe是這方面的先行者，但我已經看到了更多。它們用 Markdown 提供文檔。Markdown 對 LLM 來說超級容易理解，這太棒了

再舉一個我自己的簡單例子。也許你們有人知道 3Blue1Brown，他在 YouTube 上制作非常精美的動畫視頻。是的，我愛他寫的那個庫 Manim。我想自己也做一個。Manim 有詳盡的文檔說明如何使用。我不想真的去讀它，所以我把整個文檔復制粘貼給了一個 LLM，然后描述了我想要什么。它直接就成功了。LLM “氛圍感編程”給了我一個我想要的動畫。我當時就覺得：“哇，太神奇了。” 所以，如果我們能讓文檔對 LLM 來說易于理解，將會解鎖海量的用途。我認為這非常棒，應該更多地發生

另一件我想指出的事是，不幸的是，這不僅僅是把你的文檔變成 Markdown 那么簡單，那只是容易的部分。我們實際上必須改變文檔的內容。任何時候你的文檔里說“點擊這里”，這都很糟糕。LLM 目前無法本地執行這個操作。所以 Vercel 正在把所有出現的“點擊”替換為等效的、你的 LLM 智能體可以代為執行的curl命令。我認為這非常有趣

當然，還有 Anthropic 的模型上下文協議（Model Context Protocol），這也是另一種直接與作為新消費者的智能體對話的協議。我對這些想法非常看好。

另一件我非常喜歡的事，是出現了一些小工具，它們幫助以 LLM 友好的格式攝取數據。比如，當我訪問一個 GitHub 倉庫，像我的 nanoGPT 倉庫，我沒法把它喂給一個 LLM 然后提問，因為這是 GitHub 上的人類界面。但當你把 URL 從github.com改成git-ingest.com，它實際上會把所有文件拼接成一個巨大的文本，并創建一個目錄結構等等。這樣就準備好被復制粘貼到你喜歡的 LLM 里去用了

一個可能更極致的例子是 Deep Demos，它不只是提供文件的原始內容。這是來自 Devin 的，他們讓 Devin 分析 GitHub 倉庫，然后 Devin 會為你的倉庫構建一整套文檔頁面。你可以想象，把這個復制粘貼到你的 LLM 里會更有幫助。我喜歡所有這些你只需要改一下 URL 就能讓某些東西變得能被 LLM 訪問的小工具

所以，這一切都很好。我認為應該有更多這樣的東西。我還想補充一點，未來 LLM 完全有可能——不，甚至今天就可能——四處游走并點擊東西。但我仍然認為，與 LLM 相向而行，讓它們更容易地訪問所有這些信息，是非常值得的。因為使用那些（視覺點擊）工具仍然相當昂貴，也困難得多。所以我確實認為，會有大量長尾的軟件不會主動適配，因為它們不是“活躍玩家”的代碼庫或數字基礎設施，我們將需要這些工具。但對于其他所有人來說，我認為在某個中間點相遇是非常值得的。所以，我對兩種方式都看好

總結一下：這是一個多么令人驚嘆的、進入行業的時刻！我們需要重寫海量的代碼。大量的代碼將由專業人士和編碼者來編寫。這些 LLM 有點像公共設施，有點像晶圓廠，但尤其像操作系統。但現在還太早了，就像是 1960 年代的操作系統，很多歷史類比都適用。這些 LLM 又像是易錯的“人格幽靈”，我們必須學會與它們合作。為了做好這一點，我們需要調整我們的基礎設施來適應它。

當你在構建這些 LLM 應用時，我描述了一些與這些 LLM 有效合作的方法，以及一些使之成為可能的工具，以及你如何能非常快速地轉動這個（生成-驗證）循環，從而創造出部分自治產品。然后，是的，大量的代碼也需要更直接地為智能體而編寫。

但無論如何，回到鋼鐵俠戰衣的類比，我認為在未來十年左右，我們將看到的是，我們會把那個自治滑塊從左向右移動。那會是什么樣子，將會非常有趣。我迫不及待地想和大家一起去構建它

參考：

https://www.youtube.com/watch?v=LCEmiRjPEtQ

?星標AI寒武紀，好內容不錯過?

用你的贊和在看告訴我～

求贊