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

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

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

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

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

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

在科研領(lǐng)域，不要小看「命名」的力量。正如 Gemini 所總結(jié)的，命名是「創(chuàng)造知識的奠基行為」，精確的命名是用于分類的「地址」、一個可供全球科學(xué)家共同對焦的「穩(wěn)定靶標(biāo)」。 

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

軟件 2.0、軟件 3.0

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

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

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

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

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

總結(jié)來說，軟件 1.0 是經(jīng)典代碼時代，借助 Python 或 C++ 等，要求開發(fā)人員精確地理解語法和邏輯，以便逐步指導(dǎo)計算機。

軟件 2.0 是神經(jīng)網(wǎng)絡(luò)時代，開發(fā)人員不再需要手動編寫規(guī)則，而是通過輸入數(shù)據(jù)來訓(xùn)練模型。這些代碼成為模型的權(quán)重，通過優(yōu)化而非明確的指令進行改進。

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

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

來源：https://www.latent.space/p/s3

Karpathy 還強調(diào)了軟件 3.0 的幾個關(guān)鍵特點：

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

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

氛圍編程

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

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

來源：https://x.com/karpathy/status/1886192184808149383

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

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

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

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

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

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

細菌式編程

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

來源：https://x.com/karpathy/status/1941616674094170287

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

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

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

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

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

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

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

一次轉(zhuǎn)發(fā)，帶火上下文工程

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

其實這一術(shù)語并不新鮮，近兩年很多智能體構(gòu)建者一直在關(guān)注這個事情，只是一直不溫不火的。經(jīng)過 Karpathy 轉(zhuǎn)發(fā)并點評后，迅速火出圈，現(xiàn)在相關(guān)帖子瀏覽量高達 2.2M。

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

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

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

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