軟體正在發生根本變化：Andrej Karpathy 舊金山 AI創業學院演講萬字實錄

2025/06/19

•

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）。但如果你像Google一樣，自己製造硬體，在 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 應用共享的一些有用特性包括：

LLM 負責大量的上下文管理工作。
它們編排對 LLM 的多次呼叫。 以 Cursor 為例，它在後台呼叫了用於處理所有檔案的 embedding 模型、實際的聊天模型，以及將程式碼變更（diffs）應用到程式碼的模型，這一切都為你編排好了。
應用專屬的圖形介面（GUI）及其重要性。 這一點非常重要，但可能沒有得到應有的重視。因為你不想直接用文字與作業系統對話。文字很難閱讀、解釋和理解。而且，你也不想在文字中本地執行某些操作。直接看到一個用紅色和綠色表示的變更 diff，看到增加了什麼、刪除了什麼，要容易得多。用 Command + Y 接受或 Command + N 拒絕，也比我必須在文字中輸入要方便得多。GUI 讓人類能夠審計這些易錯系統的工作，並提高效率。 我稍後會再回到這一點。
最後一點我想指出的特性是，我稱之為 “自治滑塊”（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 合作，通常是它們進行生成，我們人類進行驗證。讓這個循環儘可能快地運轉，符合我們的利益，這樣我們才能完成大量工作。我認為有兩種主要方式可以實現這一點：

大幅加快驗證速度。 我認為 GUI 在這方面極其重要，因為它利用了我們大腦中的電腦視覺 GPU。閱讀文字是費力的，不好玩，但看東西是好玩的，它就像一條通往你大腦的高速公路。所以我認為 GUI 對於審計系統和視覺化表示非常有幫助。
我們必須給 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 工作的朋友，他邀請我在帕洛阿爾托兜了一圈。我當時用Google眼鏡拍了這張照片。你們很多人可能太年輕，都不知道那是什麼了。但當時這可是風靡一時。我們坐上這輛車，在帕洛阿爾托的高速公路和街道上行駛了大約 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 的演示版，但之後花了一周時間才讓它真正上線。原因就是，這個過程太煩人了。比如，如果你想給你的網頁加上Google登錄，我知道這字很小，但這是 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 有效合作的方法，以及一些使之成為可能的工具，以及你如何能非常快速地轉動這個（生成-驗證）循環，從而創造出部分自治產品。然後，是的，大量的程式碼也需要更直接地為智能體而編寫。

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