Karpathy：AI時代細節(jié)可以外包但理解不能外包，人類必須理解系統(tǒng)結構

Andrej Karpathy 說，他已經記不清上次修改 AI 生成的代碼是什么時候了。

Karpathy 參與創(chuàng)建了 OpenAI，在 Tesla 領導過 Autopilot 視覺團隊，去年一條推文發(fā)明了“憑感覺編程”（Vibe Coding）這個詞，后來被 Collins 詞典選為2025年度詞匯。

2026年4月，Karpathy 在 Sequoia Capital 的 AI Ascent 現(xiàn)場接受合伙人 Stephanie Zhan 的訪談。這場30分鐘的對話覆蓋了他對編程范式劇變的親身感受、Software 3.0的實質、AI 為什么在某些地方極強而在另一些地方離譜地弱，以及“憑感覺編程”之后更嚴肅的下一步是什么。

要點速覽

• 2025年12月是 Karpathy 個人的轉折點：AI 輸出從“有幫助但常要修補”變成“直接可用”，他進入完全憑感覺編程的狀態(tài)。

• Software 3.0的關鍵不是“用自然語言寫代碼”，而是通過 prompt 和 context 操作 LLM 這個新的信息處理解釋器。

• MenuGen 案例讓 Karpathy 意識到，一些 AI 應用不是會被做得更快，而是會被模型原生能力直接吞掉。

• LLM 的能力高度不均勻：它可以重構10萬行代碼、找零日漏洞，卻可能在“去50米外洗車該走路還是開車”這種常識題上犯錯。

• Vibe Coding 抬高所有人做軟件的下限；Agentic Engineering 則是在使用 Agent 提速時，保住專業(yè)軟件的質量、安全和責任門檻。

• 人類不必再記住每個 API 細節(jié)，但必須理解系統(tǒng)結構、底層機制和質量標準，否則無法監(jiān)督 Agent。

• Karpathy 用“幽靈”形容 LLM：它不是動物式智能，而是由人類文檔、預訓練統(tǒng)計和強化學習獎勵塑造出的鋸齒狀實體。

• 智能變便宜后，教育的重點不是抵制外包思考，而是確保理解仍然進入人的大腦。

2025年12月：一個程序員的投降

Zhan 問：你幾個月前說，自己從未像現(xiàn)在這樣覺得作為程序員落后。這是興奮還是不安？

Karpathy 說兩者都有。

過去一年他一直在用 Cursor 等智能體編碼工具。早期這些工具有用，可以生成一些代碼塊，但經常出錯需要修改。真正的轉折出現(xiàn)在2025年12月。那段時間他正好休假，有更多時間折騰 side project，明顯感覺到最新模型生成的代碼塊開始“直接能用”。

一開始，他只讓模型寫一點。結果不錯，就繼續(xù)讓它寫更多。再往后，他發(fā)現(xiàn)自己已經很久沒有親自糾正模型輸出了，信任感不斷增加。最后他進入了自己后來稱為 Vibe Coding 的狀態(tài)。

我記不得上一次我需要糾正它是什么時候了。然后我就越來越信任這個系統(tǒng)。

這里的 Vibe Coding，不適合硬譯成“氛圍編程”。更準確地說，它是一種“憑感覺讓 AI 寫代碼”的開發(fā)方式：人用自然語言持續(xù)提出意圖，模型生成、修改、調試代碼，人不再像過去那樣逐行寫、逐行讀 diff。Karpathy 2025年2月在 X 上提出這個詞時，描述的是一種“放棄對代碼本身的直接控制、順著感覺讓模型往前走”的開發(fā)體驗。

但這場訪談里，Karpathy 的重點已經不只是 Vibe Coding。他強調，很多人對 AI 的印象還停留在“一個類似 ChatGPT 的東西”上：你問一句，它答一句。到2025年底以后，值得重新看的是 Agentic coherent workflow——一種更連貫的智能體工作流。模型不只是回答問題，而是能連續(xù)規(guī)劃、寫代碼、調試、執(zhí)行、根據(jù)環(huán)境反饋繼續(xù)修正。

很多人去年體驗到的 AI，還是一個類似 ChatGPT 的東西。但你真的必須重新看一眼，而且要看12月之后的版本。

過去程序員的速度主要取決于他能寫多少代碼、記住多少 API、怎樣調試。現(xiàn)在，速度越來越取決于他能否正確地指揮一組強大但會犯錯的 Agent。

Software 3.0：給 Agent 復制粘貼一段文字，這就是編程

Zhan 問：你說 LLM 是一種新計算機，不只是更好的軟件。如果一個團隊真的相信這一點，它會怎樣不同地構建產品？

Karpathy 從自己那套軟件分期講起。

Software 1.0是傳統(tǒng)軟件：人寫顯式代碼，計算機按規(guī)則執(zhí)行。

Software 2.0是神經網絡時代：人不再直接寫所有規(guī)則，而是設計數(shù)據(jù)集、目標函數(shù)和神經網絡架構，通過訓練得到模型權重。Karpathy 早在2017年就寫過《Software 2.0》，把神經網絡視為一種新的軟件開發(fā)方式。

Software 3.0則是大語言模型時代。LLM 經過大規(guī)模任務訓練之后，變成一種可編程的計算機。你不再只是在代碼編輯器里寫函數(shù)，而是在 prompt、context window、文件、工具調用和外部環(huán)境之間，組織一段給模型執(zhí)行的“上下文程序”。

context window 可以理解為模型一次調用中能看到的全部信息：指令、歷史對話、文件、錯誤日志、代碼片段、圖片、工具返回結果。Karpathy 的說法是，這個上下文窗口成了人操縱 LLM 解釋器的“把手”。

他舉了一個安裝 OpenCL 的例子。傳統(tǒng)做法是寫一個 shell script，讓它適配各種機器、平臺和環(huán)境。隨著目標環(huán)境變多，腳本會不斷膨脹，最后復雜到很難維護。但在 Software 3.0里，安裝說明本身可能就是一段可以復制給 Agent 的文本。Agent 會讀取你的機器環(huán)境，執(zhí)行步驟，遇到錯誤再調試。

現(xiàn)在的問題變成：哪一段文字應該復制給你的 Agent？這就是新的編程范式。

這句話的重點不是“程序員以后只需要寫提示詞”。Karpathy 要表達的是，程序邊界擴大了。過去的程序是代碼文件。現(xiàn)在，程序可能是一段說明、一個上下文窗口、一組工具權限、一個測試環(huán)境，外加模型內部已經學到的大量統(tǒng)計結構。

MenuGen：這個 App 不應該存在

Karpathy 接著講了自己的 MenuGen。

這個 App 的想法很簡單：人在餐廳拿到菜單時，通常看不到菜品圖片。很多菜名，尤其是陌生菜系里的菜名，光看文字不知道是什么。Karpathy 想做一個應用：拍一張菜單照片，App 識別菜單上的菜名，再為每個菜品生成一張大致圖片，最后重新渲染菜單，讓用戶看到“這些菜大概長什么樣”。

用舊范式做這個 App，需要好幾層中間步驟：上傳照片，OCR 識別文字，抽出菜名，調用圖像生成器生成菜品圖，再把結果重新排版，部署到 Vercel 上。Karpathy 用 Vibe Coding 把這個 App 做了出來。

然后他看到了 Software 3.0版本。

做法變成：直接把菜單照片交給 Gemini，然后說，讓 Nano Banana 把這些菜品圖疊加回菜單上。Nano Banana 返回的不是結構化數(shù)據(jù)，也不是一組組件，而是一張新的圖片：原菜單仍在，但對應菜品的位置已經直接渲染進了圖片。

【注：Nano Banana 是 Google Gemini 的圖像生成和編輯能力名稱，支持用文本、圖像或兩者結合進行對話式生成與編輯。】

Karpathy 認為他原來寫的 MenuGen 是多余的，因為它還停留在舊范式里。

我的整個 MenuGen 都是多余的。它還停留在舊范式里。那個 App 不應該存在。

這個例子是整場訪談里最關鍵的商業(yè)判斷之一。

很多 AI 應用公司以為自己在做“更快的軟件”。比如過去一個任務要10個步驟，現(xiàn)在 App 幫你壓成3個步驟。但在 Software 3.0里，模型本身的輸入輸出可能直接覆蓋這個任務，中間 App 的結構就失去必要性。

Karpathy 進一步說，這種變化不只發(fā)生在代碼里。傳統(tǒng)代碼擅長處理結構化數(shù)據(jù)：表格、數(shù)組、數(shù)據(jù)庫字段、明確規(guī)則。但 LLM 可以處理更一般的信息重組。比如他的 LLM Knowledge Bases 項目：把文章、文檔和事實重新編譯成個人或組織 wiki。這不是傳統(tǒng)程序天然擅長的東西，因為它要求模型理解文本之間的關系、重新排序信息、生成新的知識結構。

更令人興奮的不是把已有東西做得更快，而是那些以前根本不可能存在的東西。

神經計算機：CPU 變成協(xié)處理器

Zhan 問：把這種進展外推到2026年，什么是今天大部分人還沒建出來、回頭看會覺得理所當然的東西？

Karpathy 提出了一個更大膽但也更不確定的設想：未來可能出現(xiàn)一種完全的“神經計算機”。

今天的計算機仍然以 CPU、操作系統(tǒng)、傳統(tǒng)程序為中心。神經網絡運行在現(xiàn)有計算機之上，像是一個被虛擬化出來的能力模塊。但 Karpathy 設想，未來有可能反過來：神經網絡成為 host process，也就是主流程；CPU、傳統(tǒng)代碼和工具調用變成協(xié)處理器，負責一些確定性任務。

他舉的想象場景是：一個設備接收原始視頻或音頻，神經網絡理解當前場景，再用擴散模型為這一刻生成一個獨特的 UI。用戶看到的界面不再是固定組件拼出來的，而是由模型根據(jù)上下文實時生成。

他也很快給這個判斷加了限制：這種外推看起來很怪，具體路徑仍然 TBD，不會一夜之間發(fā)生，而會一塊一塊地到來。

“神經網絡成為主進程”不是一個已經發(fā)生的產品事實，更像是他用來解釋方向感的心智模型。

LLM 能重構10萬行代碼，卻讓你走路去洗車

Zhan 問：如果 AI 更容易自動化可驗證領域，哪些工作會比人們想象中更快移動？哪些看起來安全的職業(yè)，其實高度可驗證？

Karpathy 沒有直接列職業(yè)。他轉向解釋“可驗證性”。

他的核心判斷是：

傳統(tǒng)計算機容易自動化你能寫進代碼的東西；這一代 LLM 容易自動化你能驗證的東西。

傳統(tǒng)軟件自動化的前提，是人能把規(guī)則精確寫出來。比如稅率計算、排序、數(shù)據(jù)庫查詢、訂單狀態(tài)流轉。只要規(guī)則清楚，就能寫代碼。

LLM 的自動化邊界不同。它不一定需要你把規(guī)則全部寫出來，但它需要某種方式判斷輸出好壞。數(shù)學題可以驗證答案。代碼可以跑測試。某些安全問題可以通過漏洞復現(xiàn)判斷。這樣的任務能進入強化學習（RL）環(huán)境：模型嘗試解題，系統(tǒng)給獎勵或懲罰，模型在大量樣本中優(yōu)化行為。

所以，模型在數(shù)學、代碼和相鄰領域能力提升很快，并不只是因為“模型整體更聰明了”。Karpathy 認為，這和前沿實驗室如何訓練模型有關。實驗室構造了大量可驗證任務，把它們放進訓練和強化學習流程里，模型就在這些地方形成高峰能力。

這也解釋了 LLM 的“鋸齒狀智能”（jagged intelligence）：能力曲線不是平滑上升，而是有高峰和斷崖。有些任務強得驚人，有些任務弱得荒誕。

Karpathy 說，現(xiàn)在更好的例子是洗車題：我要去50米外的洗車店洗車，應該開車還是走路？最先進的模型可能會說，走路，因為很近。這個回答忽略了問題的關鍵：你要洗的是車，所以車必須到洗車店。

一個最先進的模型可以重構10萬行代碼、找到零日漏洞，卻告訴我應該走路去洗50米外的車。

【注：零日漏洞指尚未公開或尚未修補的安全漏洞。】

如果一個任務落在模型訓練和 RL 覆蓋過的能力回路里，它可能表現(xiàn)得像專家。如果落在數(shù)據(jù)分布外，即使人類覺得很簡單，它也可能出錯。

**這對使用者的要求很高。**你不能因為模型在代碼上很強，就默認它在所有工程判斷上都強。你也不能因為它犯了洗車題這種錯誤，就斷定它整體沒用。更準確的做法是：探索它的能力邊界，找出哪些任務在“能力高峰”里，哪些任務在“斷崖”旁邊。

能力不是自然進化，和實驗室的數(shù)據(jù)決策相關

Karpathy 提到一個細節(jié)：從 GPT-3.5到 GPT-4，國際象棋能力提升非常大。很多人以為這是能力的自然進化，但實際上是因為有人在 OpenAI 決定把大量國際象棋數(shù)據(jù)加進了預訓練。數(shù)據(jù)進了分布，能力就跟著上去了。

這把一個看起來“模型變強”的故事，重新解釋成了一個“實驗室在做產品決策”的故事。

某種程度上，我們完全受制于實驗室給模型喂了什么數(shù)據(jù)。如果你的場景剛好落在 RL 訓練覆蓋的“能力回路”里，模型就會帶你起飛；但一旦超出了這個數(shù)據(jù)分布，它就會覺得極其吃力。

**實操含義：**如果你的應用場景在覆蓋的能力回路里，開箱即用；如果在外面，你需要自己做微調，不要指望 LLM 一上來就會。

創(chuàng)業(yè)機會：找一個還沒被 RL 覆蓋的可驗證領域

Zhan 問：如果創(chuàng)業(yè)者今天想解決一個可驗證的問題，但大模型實驗室已經在數(shù)學、代碼等最明顯領域加速了，創(chuàng)業(yè)者該怎么辦？

Karpathy 的回答沒有給出具體賽道，但給出了一種找機會的方法。

在當前技術范式下，可驗證性讓一個問題變得“可解”。如果你能構造大量、多樣的強化學習環(huán)境，能讓模型嘗試、失敗、獲得獎勵，那么即便大實驗室沒有把這個領域作為重點，你也可能通過自己的微調和訓練獲得優(yōu)勢。

他說到這里時，幾乎要舉一個自己認為很有價值的領域，但停住了。

我不想直接給出答案……抱歉，我不是有意在臺上發(fā)含糊推文的。

臺下笑了。

這個停頓本身也說明了他的判斷：機會不是“再做一個 AI Agent”這樣泛泛的方向，而是找到某個可構造獎勵環(huán)境的具體問題。

他還補了一句更激進的話：幾乎所有事情，最終都可能在某種程度上變得可驗證。寫作、設計這類看似主觀的任務，也可以想象用一組 LLM judges，也就是模型評審團，形成某種近似評價。

這句話需要謹慎理解。Karpathy 并不是說所有任務都能被完美自動驗證。他說的是“程度”和“難易”。數(shù)學和代碼比較容易，因為答案或測試相對明確。寫作、審美、戰(zhàn)略判斷則要困難得多。

Vibe Coding 抬高下限，Agentic Engineering 保住上限

Zhan 問：去年你提出 Vibe Coding。今天我們進入了一個更嚴肅的世界，更像 Agent engineering。二者的區(qū)別是什么？

Karpathy 的區(qū)分非常清楚。

**Vibe Coding 抬高的是下限。**更多人可以用自然語言和 AI 做出軟件。不會寫代碼的人可以做小工具，會寫代碼的人可以更快做 side project。軟件創(chuàng)造的入口變寬了。

**Agentic Engineering 保住的是上限。**它面對的是專業(yè)軟件：不能因為用了 AI 就引入安全漏洞，不能因為模型寫得快就降低質量門檻，不能因為代碼是 Agent 生成的就沒人負責。

Vibe Coding 抬高的是所有人能做軟件的下限；Agentic Engineering 要保住的是專業(yè)軟件過去已有的質量門檻。

Agentic Engineering 可以譯作“智能體工程”。它不是一個具體工具，而是一種工程紀律：如何設計、協(xié)調、監(jiān)督一組 AI Agent，讓它們在不犧牲質量、安全、可維護性的情況下加速開發(fā)。

Karpathy 說，這些 Agent 是“spiky entities”——有尖刺的實體。它們能力很強，但會犯錯，有隨機性，不穩(wěn)定。工程師的工作不是盲目信任它們，而是把它們放進合適的流程里：讓它們生成方案、寫代碼、跑測試、互相檢查，讓系統(tǒng)有邊界、有驗證、有回滾。

Karpathy 還提到一個更強的判斷：過去軟件行業(yè)喜歡說“10x engineer”，也就是效率遠超普通人的工程師。但在 Agentic Engineering 里，他看到的加速幅度可能遠不止10倍。

10x 不是你獲得的加速倍數(shù)。

真正熟練的人，能把多個 Agent、工具、測試和上下文組織起來，產出速度會被放大得更厲害。

AI-native 工程師：不是會刷題，而是能把大項目做安全

Zhan 問：如果觀察兩個使用 AI coding 工具的人，一個普通，一個真正 AI-native，區(qū)別會是什么？

Karpathy 先說，AI-native 工程師會充分利用可用工具，并投資自己的工作流設置。就像過去工程師會花時間配置 Vim、VS Code、命令行、快捷鍵和開發(fā)環(huán)境，現(xiàn)在也要花時間配置 Cursor、Claude Code 或類似工具，讓它們真正適合自己的工作方式。

但他很快把話題轉到招聘。

他認為，很多公司還沒有重構面試流程。如果仍然給候選人一組小 puzzle，讓他們現(xiàn)場解算法題，這還是舊范式。它測不出一個人是否會在 Agentic Engineering 里高效工作。

更好的測試應該是大項目。比如讓候選人做一個 Twitter clone：不僅要能跑，還要做得好、做得安全。然后再用多個 Agent 去攻擊這個網站，嘗試破壞它，看看系統(tǒng)能否經得住。

面試本該是這樣的：甩給候選人一個極大的項目，比如做個給 Agent 用的 Twitter 仿盤，要求做得絕對安全。然后，我掛上10個 Cursor 當作“紅隊”，放開手腳去攻擊你做出來的這個網站。

**這套評估方式的核心，不是看候選人能不能手寫某個算法，而是看他能不能：**把模糊目標變成清晰規(guī)格；指揮 Agent 完成大規(guī)模實現(xiàn)；識別安全和架構風險；設置測試與驗證；在模型生成的大量代碼里保持質量判斷；讓最終系統(tǒng)經得起外部攻擊和壓力。

Agent 能寫代碼，但還會把付款綁到錯誤郵箱上

Zhan 問：Agent 做得越多，什么人類技能會變得更有價值？

Karpathy 的答案是：品味、判斷、審美、監(jiān)督，以及規(guī)格設計。

他把當前 Agent 比作實習生。這個比喻很準確，但不能過度擬人化。Agent 不是真的有人類動機的員工，它只是執(zhí)行能力越來越強，同時會在一些人類覺得顯而易見的地方犯錯。

Karpathy 舉了 MenuGen 的一個實際問題。用戶用 Google 賬號登錄，但購買 credits 時使用 Stripe 賬號。Google 和 Stripe 都有郵箱地址。Agent 在實現(xiàn)購買邏輯時，試圖用 Stripe 郵箱去匹配 Google 郵箱，把購買的 credits 歸到對應用戶身上。

這聽起來好像合理，但在工程上是危險的。一個人完全可能用一個郵箱登錄 Google，用另一個郵箱付款。如果系統(tǒng)用郵箱關聯(lián)資金，就可能出現(xiàn)購買記錄無法歸屬、資金錯配或賬戶混亂。正確做法應該是使用系統(tǒng)內部穩(wěn)定的 persistent user ID 來綁定用戶身份和支付記錄。

你為什么要用郵箱地址來交叉關聯(lián)資金？它們可以是任意的，你可以用不同的郵箱。這種做法太奇怪了。

這類問題沒有語法錯誤，代碼可能能跑，測試可能還過，但系統(tǒng)設計是錯的。Agent 沒有真正理解身份、支付和資金歸屬的風險。

所以 Karpathy 說，人必須負責 spec，也就是規(guī)格。你要告訴 Agent：所有資金和用戶狀態(tài)必須綁定到內部唯一用戶 ID，而不是綁定到外部郵箱。你要負責頂層設計、約束條件和判斷標準。Agent 可以填補實現(xiàn)細節(jié)，但不能替你理解系統(tǒng)邊界。

他接著舉了一個更技術的例子。現(xiàn)在他已經不再記 PyTorch、NumPy、pandas 之間很多細碎 API 差異，比如 keepdims 還是 keepdim，dim 還是 axis，reshape、permute、transpose 分別怎么寫。這些細節(jié)可以交給 Agent，因為模型記憶很好。

但他仍然強調，人必須理解底層概念。比如張量（tensor）是什么，view 和 storage 的關系是什么，什么時候只是改變同一塊內存的視圖，什么時候會復制數(shù)據(jù)。如果不懂這些底層機制，就可能讓模型寫出低效甚至錯誤的代碼。

這給“什么值得學”提供了一個非常具體的答案：**細節(jié)可以外包，理解不能外包。**API 名稱可以忘，但概念結構不能丟。

模型寫出的代碼能跑，但有時“很丑”

Zhan 追問：taste 和 judgment 會不會隨著模型進步而越來越不重要？

Karpathy 沒有把話說死。他希望模型會進步，也認為沒有什么根本原因阻止它們在品味、審美和簡潔性上變好。但他指出，至少現(xiàn)在，這些能力還沒有被很好地訓練出來，可能因為它們沒有進入足夠好的 RL 獎勵環(huán)境。

他看模型生成的代碼時，有時會“心臟病發(fā)作”。代碼能跑，但不一定好。它可能很臃腫，有很多復制粘貼，有別扭的抽象，結構脆弱，維護起來很難。

有時我看到它寫出來的代碼，會有一點心臟病發(fā)作的感覺。它能跑，但真的很惡心。

他還提到 MicroGPT 項目。他想把 LLM training 簡化到極致，讓訓練過程盡可能小、清晰、可理解。他不斷要求模型“再簡化一點”，但模型做不到。那種感覺像“拔牙”一樣困難。

我不斷地讓 LLM“再簡化一點”，它就是做不到。你能感覺到你在 RL 回路之外。就像在拔牙。

Karpathy 的解釋是，這個任務可能走出了模型被 RL 覆蓋的能力回路。模型擅長生成常見工程形態(tài)，卻不擅長極簡、克制、優(yōu)雅的抽象壓縮。

我們不是在造動物：Karpathy 說我們召喚的是“幽靈”

Zhan 問：你寫過一篇關于 animals vs ghosts 的文章，核心意思是我們不是在造動物，而是在召喚幽靈。這個框架為什么重要？

Karpathy 說，他寫這篇文章，是因為自己也在試圖理解這些模型到底是什么。如果你對模型是什么有一個更好的心智模型，你就會更擅長使用它。

“幽靈”這個詞聽起來神秘，但 Karpathy 的意思并不玄學。他是在對比兩種智能來源。

動物智能來自進化、身體、環(huán)境互動、內在動機、好奇心、樂趣、持續(xù)學習。動物會在世界中行動，被后果塑造，會在生命過程中不斷適應。

LLM 不是這樣。今天的前沿 LLM，首先來自大規(guī)模預訓練：模型在海量人類文檔上學習統(tǒng)計結構。然后再疊加強化學習、偏好數(shù)據(jù)、工具調用等后訓練過程。它們不是動物式智能，而是由人類文檔、統(tǒng)計模式和獎勵函數(shù)塑造出的模擬實體。

在訪談里，他把這個比喻落到一個很樸素的使用原則上：**不要把 LLM 當動物。**你對它大喊大叫，不會讓它因為害怕而更努力。你鼓勵它，也不是在激發(fā)它的內在動機。模型沒有動物式情緒。它的行為來自統(tǒng)計模擬、上下文、工具、訓練數(shù)據(jù)和獎勵機制。

如果你對它大吼，它不會因此工作得更好或更差，也沒有任何影響。

Karpathy 也承認，“幽靈”框架有哲學化的一面。他沒有說它能直接產出五條系統(tǒng)優(yōu)化建議。它更像一種防止誤用的提醒：不要籠統(tǒng)地問“AI 聰不聰明”，要問它在哪些訓練分布里強，哪些獎勵信號塑造了它，在哪些任務上可能出現(xiàn)鋸齒狀斷崖。

Agent-first 基礎設施：一句話構建并部署 MenuGen

Zhan 問：當 Agent 不只聊天，而是擁有權限、本地上下文，并能代表人采取行動時，世界會變成什么樣？

Karpathy 說，幾乎一切都要重寫。今天的工具、文檔、服務和設置流程，仍然主要是為人設計的。

比如一個框架的文檔會告訴你：去某個 URL，點擊某個設置，復制某個 key，打開某個菜單，配置某個 DNS。Karpathy 的反應是：為什么還在告訴我該怎么做？我不想做這些事。我想知道的是，哪一段東西可以復制給我的 Agent，讓它自己去做。

為什么還有人在告訴我該做什么？我什么都不想做。“給我復制粘貼給 Agent 的東西是什么？”

這不是懶，而是范式變化。Agent-first infrastructure 的目標，是把世界拆成 Agent 能讀懂的輸入，以及 Agent 能安全調用的動作接口。

在軟件基礎設施里，這意味著文檔、API、權限、日志、部署、配置、賬單、回滾，都要變得更適合 Agent 使用。不是讓 Agent 模擬人去點網頁，而是讓 Agent 直接理解狀態(tài)、調用動作、收到反饋。

Karpathy 又回到 MenuGen。他說，做 MenuGen 最麻煩的部分其實不是寫代碼，而是部署：在 Vercel 上部署，連接各種服務，進入不同設置頁面，配置 DNS，把所有東西串起來。

他希望未來的測試標準是：給 LLM 一句 Build MenuGen，它不僅能寫代碼，還能完成部署，上線到互聯(lián)網，配置好依賴服務，而且整個過程不需要人去一個個菜單里操作。

更遠一點，他設想每個人、每個組織都可能有自己的 Agent representation。以后安排會議、處理細節(jié)、協(xié)調事項，可能變成“我的 Agent 和你的 Agent 去談”。

智能變便宜后，最貴的是理解

Zhan 最后問：當智能變得便宜，什么仍然值得深入學習？

Karpathy 引用了一句話：

你可以外包你的思考，但不能外包你的理解。

這句話容易被寫成勵志格言，但 Karpathy 的解釋很具體。

他仍然是系統(tǒng)的一部分。信息必須進入他的腦子里。他覺得自己正在變成瓶頸：要知道到底在建什么，為什么值得做，怎樣指導自己的 Agent。思考步驟可以讓模型跑很多遍，但如果人沒有理解，就無法判斷哪條路線是對的，無法寫出好的規(guī)格，也無法發(fā)現(xiàn) Agent 在身份綁定、系統(tǒng)結構、代碼質量上的錯誤。

我感覺自己正在變成瓶頸：我要知道我們到底在建什么，為什么值得做，以及怎樣指導我的 Agent。

這也是他對 LLM knowledge bases 感興趣的原因。他喜歡把文章、資料、事實重新投影成 wiki，因為不同的信息組織方式能幫助他獲得洞見。對他來說，這不是讓 AI 代替理解，而是用 AI 增強理解。

這一點和前面的工程例子連在一起：

• Agent 可以記 API 細節(jié)，但人要理解 tensor、view、storage 和內存效率；

• Agent 可以寫支付邏輯，但人要理解用戶身份和資金歸屬；

• Agent 可以生成大量代碼，但人要判斷抽象是否臃腫、結構是否脆弱；

• Agent 可以幫你思考很多方案，但人要知道目標是否值得做。

所以，**智能變便宜之后，學習不是不重要了，而是學習的重心變了。**更少時間花在機械記憶和低層執(zhí)行上，更多時間花在系統(tǒng)理解、問題定義、質量判斷、因果關系和領域直覺上。

Q&A 速覽

問：2025年12月發(fā)生了什么？ 答：最新模型生成的代碼不需要修改了，可靠性在持續(xù)的項目中也保持住了。

問：Software 3.0和以前有什么不同？ 答：以前的代碼處理結構化數(shù)據(jù)，現(xiàn)在你可以處理任意信息。以前做不了的東西現(xiàn)在可以了。這不是加速，是新的可能性。

問：為什么最先進的 AI 模型在簡單任務上犯低級錯誤？ 答：能力分布取決于 RL 訓練覆蓋的領域和實驗室的數(shù)據(jù)選擇。可驗證的領域能力飆升，其余領域可能很弱。

問：Vibe Coding 和 Agentic Engineering 的區(qū)別？ 答：Vibe Coding 是提升所有人的下限，Agentic Engineering 是保持專業(yè)標準的前提下利用 Agent 加速。

問：什么時候人的品味和判斷會不重要？ 答：可能會，但前提是實驗室把審美獎勵納入 RL 訓練目標。目前 Agent 的代碼經常“能跑但很難看”。

【最后】

這場訪談里，Karpathy 的判斷有幾個值得注意的張力。

第一，他一邊說 Agent 寫出的代碼丑得讓他心臟病發(fā)作，一邊說他自己已經停止修改了。“信任并沒有解決品味的問題”——能跑的代碼和好代碼不是一回事。可這種“用著丑的，但用著”的狀態(tài)，可能比任何 hype 都更接近真實的 Vibe Coding 現(xiàn)狀。

第二，他暗示有“被低估的 RL 機會”領域卻不愿公開。一個不愿在臺上發(fā)含糊推文的人主動回避，本身是個信號：窗口期還沒關。值得注意的是，他的公司 Eureka Labs 做的是 AI 教育，而教育恰好是一個輸出可以被評估、可以被標準化考核的領域。

第三，他給“動物 vs 幽靈”這個框架自己降了級別，又用“你可以外包思考，但不能外包理解”給整場對談收束。把這兩件事放在一起讀：他的判斷是，**真正稀缺的不是任何一個具體技能，而是判斷“我們到底要做什么、為什么值得做”的能力。**如果“幾乎所有領域最終都能被驗證”這個判斷成立，那么瓶頸最終不在執(zhí)行端，而在目標設定端。

但這里有一個隱含的時間問號。Karpathy 自己也承認，品味和判斷之所以暫時不可替代，原因只是“實驗室還沒做”。如果這個判斷成立，那么所謂人類不可替代的部分，不是因為人類獨一無二，而是因為訓練方法還沒到位。這就把“外包思考但不能外包理解”這句話的有效期打了一個問號。

未來6-12個月值得盯三個具體信號：

1. 前沿實驗室在編程/數(shù)學之外，往哪些領域注入 RL 數(shù)據(jù)——那里的能力會突然冒出來

2. Agent-first 的基礎設施（部署、auth、payments）會不會有第一波收斂——MenuGen 部署的痛苦如果還在，“自動化社會”的路就長得多

3. 模型的下一代更新是否包含審美和代碼質量相關的 RL 目標

原始視頻：

https://www.youtube.com/watch?v=96jN2OCOfLs