機器之心報道

機器之心編輯部

取名大王 Karpathy。

萬萬沒想到，「幻覺」這個詞，竟然是 AI 大牛 Andrej Karpathy 命名的。

最近，一位網友在「The Thinking Machine」（一本新書）里發現了這么一段描述：「Karpathy 承認他的（神經）網絡有局限性：它只是在模仿言語，而不必真正理解其含義，當遇到它不理解的概念時，它就會『驕傲地』生成一些無意義的內容。Karpathy 將這類錯誤稱為「幻覺」（hallucinations）。 」

這個帖子，Karpathy 本人也看見了，并留言說：「 我相信這是真的，我在我 2015 年寫的《RNN 非凡的有效性》（Unreasonable Effectiveness of RNNs）這篇博文中就使用了這個詞。而且，據我所能記起的，這個詞本身也是我『幻覺』出來的。」

按照 Karpathy 的說法，我們找到了這篇博客，發現里面確實有包含「幻覺」的表述。當時，Karpathy 就已經指出，模型會「幻覺」出網址以及數學題方面的東西。但直到 2022 年 ChatGPT 橫空出世，這個詞才真正火起來，并作為一個熱門領域被研究。

不過，要想知道在 2015 年之前，是否有人使用「hallucination」或「hallucinate」來描述類似現象，可能需要查閱很多文獻。

這個有趣的溯源故事再一次證明了，Karpathy 是 AI 圈「實至名歸」的取名大師，因為 2017 年的「軟件 2.0」、2025 年的「軟件 3.0」、「氛圍式編程」、「細菌式編程」都是他提出來的，「上下文工程」雖然不是他提出來的，但也因為他的轉發評論而出圈。可以說，在推廣新概念這塊，沒有哪個 AI 大牛的影響力可以比肩 Karpathy。

在科研領域，不要小看「命名」的力量。正如 Gemini 所總結的，命名是「創造知識的奠基行為」，精確的命名是用于分類的「地址」、一個可供全球科學家共同對焦的「穩定靶標」。

這十年來，Karpathy 命名的那些概念逐漸受到重視，這也是他對科學做出貢獻的一種重要方式。

軟件 2.0、軟件 3.0

早在 2017 年， Karpathy 就提出了軟件 2.0 一詞。

https://karpathy.medium.com/software-2-0-a64152b37c35

在這篇文章中，Karpathy 表示軟件 1.0 時代的經典堆棧 —— 用 Python、C++ 等語言編寫。它由程序員編寫的顯式指令組成。通過編寫每一行代碼，程序員可以在程序空間中識別出具有某些期望行為的特定點。

相比之下，軟件 2.0 是用一種更加抽象、對人類不友好的語言編寫的，比如神經網絡的權重參數。人類不會直接編寫這種代碼，因為參數數量極其龐大（普通網絡可能有數百萬個權重），而直接手動調整權重幾乎是不可能的。

為了更清晰地類比，文中提到，在軟件 1.0 中，由人類編寫的源代碼（比如某些.cpp 文件）通過編譯生成可執行文件，從而完成實際任務。而在軟件 2.0 中，源代碼通常包含兩部分：1）定義預期行為的數據集，2）提供神經網絡架構（但具體細節由權重參數填充）。訓練神經網絡的過程，本質上就是將數據集編譯成最終可用的二進制文件 —— 即訓練好的神經網絡模型。

總結來說，軟件 1.0 是經典代碼時代，借助 Python 或 C++ 等，要求開發人員精確地理解語法和邏輯，以便逐步指導計算機。

軟件 2.0 是神經網絡時代，開發人員不再需要手動編寫規則，而是通過輸入數據來訓練模型。這些代碼成為模型的權重，通過優化而非明確的指令進行改進。

有意思的是，軟件 3.0 也是 Karpathy 提出的新概念，即提示詞時代。開發人員、甚至非開發人員，只需用簡單的英語描述他們想要什么（例如，構建一個跟蹤我日常任務的網站），AI 就會生成相應的代碼。

軟件 3.0 讓會說話就能編程從梗變成現實，prompt 成了源代碼，LLM 成了運行時，而人類第一次用母語直接向計算機下達復雜指令。

https://www.latent.space/p/s3

Karpathy 還強調了軟件 3.0 的幾個關鍵特點：

LLM 作為計算平臺：將大語言模型比作電力這樣的基礎設施。訓練一個大模型需要巨大的前期投入，就像建設一整套電網；而通過 API 使用它們，則像是按使用量付費。這一類比強調了大模型作為一種可擴展、可訪問的計算資源的角色。

自主滑塊：Karpathy 借鑒其在特斯拉關于自動駕駛方面的經驗，提出了自主滑塊的概念。這允許用戶調整 AI 的控制程度 —— 從最低限度的輔助（例如，建議代碼片段）到完全自主（例如，生成整個應用程序）。根據任務和用戶偏好提供靈活性。

氛圍編程

氛圍編程（Vibe Coding），是 Karpathy 在今年 2 月造出的。

簡單來說，氛圍編程就是鼓勵開發者忘掉代碼，進入開發的氛圍之中。更簡單地講，就是向 LLM 提出需求，然后「全部接受」即可。

https://x.com/karpathy/status/1886192184808149383

正如 Karpathy 所言，在氛圍編程中，你會完全沉浸在氛圍里，順著感覺走就行，甚至忘了自己其實是在寫代碼。這種方式之所以可能，是因為大語言模型現在已經強大到足夠離譜。Karpathy 還表示，自己在氛圍編程中，基本不用碰鍵盤，和大語言模型聊天，像個懶人一樣提出請求，最后選擇全部接受就可以了。

即使有出錯的地方，直接把錯誤信息粘貼進去，也不用解釋，模型就能自己改好。甚至 LLM 修不了的 bug，讓模型亂改幾下，問題也會消失。

這種方式已經不能算傳統意義上的編程了，你只要看到東西，說出想法，運行程序，復制粘貼，然后程序大致就能跑起來。

這不禁讓我們想起在程序員圈子里廣為流傳的硬核名言「Talk is cheap. Show me the code」。

最早可追溯到 2000 年 8 月，Linux 之父 Linus Torvalds 在 Linux-kernel 郵件列表里的一次回帖。當時有人長篇大論地描述某個設計思路，Linus 直接甩下這句話 Talk is cheap. Show me the code。

如今變成了「code is cheap, show me the talk（prompt）」。

細菌式編程

「細菌式編程」，即像細菌一樣編寫代碼。

https://x.com/karpathy/status/1941616674094170287

這種編碼方式受到細菌代碼（基因組）的啟發，具有以下特點：

一是小而精簡。要知道每行代碼都有成本，就像細菌基因組中每個基因都消耗能量，因此保持代碼精簡能夠讓自己寫的代碼「 生存 」得更好。二是模塊化，即代碼應該被組織成可交換的操縱子群組。三是自包含，代碼要能夠輕松地通過「水平基因轉移」進行復制粘貼。

這種編碼風格的核心思想是：如果你的代碼塊足夠小巧、模塊化、自包含且易于復制粘貼，那么開源社區就能通過「水平基因轉移」—— 也就是開發者之間的代碼共享 —— 而蓬勃發展。

Karpathy 還提出了一個有趣的檢驗標準：當你寫一個函數或類時，問問自己 —— 別人能否在不了解你其余代碼、不需要導入任何新依賴的情況下，直接「拿走」你的代碼并從中獲益？你的代碼能否成為 GitHub 上的熱門代碼片段？

這種「細菌式編碼」讓細菌能夠在從極寒到炙熱、從酸性到堿性的地球各個角落生存，甚至在太空真空中也能存活，并發展出令人驚嘆的多樣性。它非常擅長快速原型開發，但也有局限性 —— 無法構建復雜的生命體。

相比之下，真核生物的基因組就像一個更大、更復雜、更有組織的單體倉庫（monorepo）。雖然創新性較低，但卻是構建復雜生命、整個器官以及協調它們活動所必需的。

Karpathy 的建議是：利用智能設計的優勢，兩者兼顧。必要時構建真核生物式的單體倉庫骨架，但要最大化細菌式 DNA 的使用。這樣既能保持代碼的靈活性和可復用性，又能支撐起復雜系統的構建需求。

一次轉發，帶火上下文工程

以前 AI 圈流行提示詞工程，上下文工程卻很少有人討論。

其實這一術語并不新鮮，近兩年很多智能體構建者一直在關注這個事情，只是一直不溫不火的。經過 Karpathy 轉發并點評后，迅速火出圈，現在相關帖子瀏覽量高達 2.2M。

圖源：https://x.com/karpathy/status/1937902205765607626

很多人搞不懂提示工程和上下文工程的區別，之前，LangChain 發表的一篇博客提到了兩者的關系：可以將提示工程視為上下文工程的一個子集。

在傳統的提示工程中，開發者通常側重于精心設計提示語，以期得到更好的答案。然而，隨著應用復雜度不斷增加，單純依賴提示已無法滿足現代智能體的需求。如今，提供完整且結構化的上下文信息比任何巧妙的提示詞更為重要。上下文工程就是為此誕生的。

感興趣的讀者可以參考《提示詞工程、RAG 之后，LangChain：上下文工程開始火了！》《登上熱搜！prompt 不再是 AI 重點，新熱點是 Context Engineering》。

除了這些已經有名字的概念，其實 Karpathy 平時的一些推文也讓一些問題得到業內關注，比如他在一個帖子中指出，未來大家會把 99.9% 的內容都交給 AI 去讀，這是一種不可逆的趨勢，所以從現在開始大家就應該注重文檔的「可讀性」，轉變寫文檔的方式，比如 Markdown 可能就是一種理想的格式。這種從「為人類優化」轉向「為 AI 優化」的提議得到了很多人的贊同。

你還記得 Karpathy 提出或帶火的哪個概念？歡迎在評論區留言指出。