@dotey：Karpathy 最新訪談：Vibe Coding 只是開始，真正重要的是 Agentic Engineering Andrej Karpathy 說，他…

Karpathy 最新訪談：Vibe Coding 只是開始，真正重要的是 Agentic Engineering Andrej Karpathy 說，他已經記不清上次修改 AI 生成的程式碼是什麼時候了。 Karpathy 參與創建了 OpenAI，在 Tesla 領導過 Autopilot 視覺團隊，去年一條推文發明了「憑感覺程式開發」（Vibe Coding）這個詞，後來被 Collins 詞典選為 2025 年度詞彙。 2026 年 4 月，Karpathy 在 Sequoia Capital 的 AI Ascent 現場接受合夥人 Stephanie Zhan 的訪談。這場 30 分鐘的對話涵蓋了他對程式開發範式劇變的親身感受、Software 3.0 的實質、AI 為什麼在某些地方極強而在另一些地方離譜地弱，以及「憑感覺程式開發」之後更嚴肅的下一步是什麼。 要點速覽 2025 年 12 月是 Karpathy 個人的轉折點：AI 輸出從「有幫助但常要修補」變成「直接可用」，他進入完全憑感覺程式開發的狀態。 Software 3.0 的關鍵不是「用自然語言寫程式碼」，而是透過 prompt 和 context 操作 LLM 這個新的資訊處理解釋器。 MenuGen 案例讓 Karpathy 意識到，一些 AI 應用不是會被做得更快，而是會被模型原生能力直接吞掉。 LLM 的能力高度不均勻：它可以重構 10 萬行程式碼、找零日漏洞，卻可能在「去 50 公尺外洗車該走路還是開車」這種常識題上犯錯。 Vibe Coding 抬高所有人做軟體的下限；Agentic Engineering 則是在使用 Agent 提速時，保住專業軟體的品質、安全和責任門檻。 人類不必再記住每個 API 細節，但必須理解系統結構、底層機制和品質標準，否則無法監督 Agent。 Karpathy 用「幽靈」形容 LLM：它不是動物式智慧，而是由人類文件、預訓練統計和強化學習獎勵塑造出的鋸齒狀實體。 智慧變便宜後，教育的重點不是抵制外包思考，而是確保理解仍然進入人的大腦。 【1】2025 年 12 月：一個工程師的投降 Zhan 問：你幾個月前說，自己從未像現在這樣覺得作為工程師落後。這是興奮還是不安？ Karpathy 說兩者都有。 過去一年他一直在用 Cursor 等 Agent 程式開發工具。早期這些工具有用，可以生成一些程式碼區塊，但經常出錯需要修改。真正的轉折出現在 2025 年 12 月。那段時間他正好休假，有更多時間折騰 side project，明顯感覺到最新模型生成的程式碼區塊開始「直接能用」。 一開始，他只讓模型寫一點。結果不錯，就繼續讓它寫更多。再往後，他發現自己已經很久沒有親自糾正模型輸出了，信任感不斷增加。最後他進入了自己後來稱為 Vibe Coding 的狀態。 我記不得上一次我需要糾正它是什麼時候了。然後我就越來越信任這個系統。 這裡的 Vibe Coding，不適合硬譯成「氛圍程式開發」。更準確地說，它是一種「憑感覺讓 AI 寫程式碼」的開發方式：人用自然語言持續提出意圖，模型生成、修改、除錯程式碼，人不再像過去那樣逐行寫、逐行讀 diff。Karpathy 2025 年 2 月在 X 上提出這個詞時，描述的是一種「放棄對程式碼本身的直接控制、順著感覺讓模型往前走」的開發體驗。 但這場訪談裡，Karpathy 的重點已經不只是 Vibe Coding。他強調，很多人對 AI 的印象還停留在「一個類似 ChatGPT 的東西」上：你問一句，它答一句。到 2025 年底以後，值得重新看的是 Agentic coherent workflow——一種更連貫的 Agent 工作流。模型不只是回答問題，而是能連續規劃、寫程式碼、除錯、執行、根據環境回饋繼續修正。 很多人去年體驗到的 AI，還是一個類似 ChatGPT 的東西。但你真的必須重新看一眼，而且要看 12 月之後的版本。 過去工程師的速度主要取決於他能寫多少程式碼、記住多少 API、怎樣除錯。現在，速度越來越取決於他能否正確地指揮一組強大但會犯錯的 Agent。 【2】Software 3.0：給 Agent 複製貼上一段文字，這就是程式開發 Zhan 問：你說 LLM 是一種新電腦，不只是更好的軟體。如果一個團隊真的相信這一點，它會怎樣不同地建構產品？ Karpathy 從自己那套軟體分期講起。 Software 1.0 是傳統軟體：人寫顯式程式碼，電腦按規則執行。 Software 2.0 是神經網路時代：人不再直接寫所有規則，而是設計資料集、目標函數和神經網路架構，透過訓練得到模型權重。Karpathy 早在 2017 年就寫過《Software 2.0》，把神經網路視為一種新的軟體開發方式。 Software 3.0 則是大型語言模型時代。LLM 經過大規模任務訓練之後，變成一種可程式化的電腦。你不再只是在程式碼編輯器裡寫函數，而是在 prompt、context window、檔案、工具呼叫和外部環境之間，組織一段給模型執行的「上下文程式」。 context window 可以理解為模型一次呼叫中能看到的全部資訊：指令、歷史對話、檔案、錯誤日誌、程式碼片段、圖片、工具回傳結果。Karpathy 的說法是，這個上下文視窗成了人操縱 LLM 解釋器的「把手」。 他舉了一個安裝 OpenCL 的例子。傳統做法是寫一個 shell script，讓它適配各種機器、平台和環境。隨著目標環境變多，腳本會不斷膨脹，最後複雜到很難維護。但在 Software 3.0 裡，安裝說明本身可能就是一段可以複製給 Agent 的文字。Agent 會讀取你的機器環境，執行步驟，遇到錯誤再除錯。 現在的問題變成：哪一段文字應該複製給你的 Agent？這就是新的程式開發範式。 這句話的重點不是「工程師以後只需要寫提示詞」。Karpathy 要表達的是，程式邊界擴大了。過去的程式是程式碼檔案。現在，程式可能是一段說明、一個上下文視窗、一組工具權限、一個測試環境，外加模型內部已經學到的大量統計結構。 【3】MenuGen：這個 App 不應該存在 Karpathy 接著講了自己的 MenuGen。 這個 App 的想法很簡單：人在餐廳拿到菜單時，通常看不到菜品圖片。很多菜名，尤其是陌生菜系裡的菜名，光看文字不知道是什麼。Karpathy 想做一個應用：拍一張菜單照片，App 識別菜單上的菜名，再為每個菜品生成一張大致圖片，最後重新渲染菜單，讓使用者看到「這些菜大概長什麼樣」。 用舊範式做這個 App，需要好幾層中間步驟：上傳照片，OCR 識別文字，抽出菜名，呼叫圖像生成器生成菜品圖，再把結果重新排版，部署到 Vercel 上。Karpathy 用 Vibe Coding 把這個 App 做出來了。 然後他看到了 Software 3.0 版本。 做法變成：直接把菜單照片交給 Gemini，然後說，讓 Nano Banana 把這些菜品圖疊加回菜單上。Nano Banana 回傳的不是結構化資料，也不是一組組件，而是一張新的圖片：原菜單仍在，但對應菜品的位置已經直接渲染進了圖片。 【註：Nano Banana 是 Google Gemini 的圖像生成和編輯能力名稱，支援用文字、圖像或兩者結合進行對話式生成與編輯。】 Karpathy 認為他原來寫的 MenuGen 是多餘的，因為它還停留在舊範式裡。 我的整個 MenuGen 都是多餘的。它還停留在舊範式裡。那個 App 不應該存在。 這個例子是整場訪談裡最關鍵的商業判斷之一。 很多 AI 應用公司以為自己在做「更快的軟體」。比如過去一個任務要 10 個步驟，現在 App 幫你壓成 3 個步驟。但在 Software 3.0 裡，模型本身的輸入輸出可能直接覆蓋這個任務，中間 App 的結構就失去必要性。 Karpathy 進一步說，這種變化不只發生在程式碼裡。傳統程式碼擅長處理結構化資料：表格、陣列、資料庫欄位、明確規則。但 LLM 可以處理更一般的資訊重組。比如他的 LLM Knowledge Bases 專案：把文章、文件和事實重新編譯成個人或組織 wiki。這不是傳統程式天然擅長的東西，因為它要求模型理解文字之間的關係、重新排序資訊、生成新的知識結構。 更令人興奮的不是把已有東西做得更快，而是那些以前根本不可能存在的東西。 【4】神經電腦：CPU 變成協處理器 Zhan 問：把這種進展外推到 2026 年，什麼是今天大部分人還沒建出來、回頭看會覺得理所當然的東西？ Karpathy 提出了一個更大膽但也更不確定的設想：未來可能出現一種完全的「神經電腦」。 今天的電腦仍然以 CPU、作業系統、傳統程式為中心。神經網路運行在現有電腦之上，像是一個被虛擬化出來的能力模組。但 Karpathy 設想，未來有可能反過來：神經網路成為 host process，也就是主流程；CPU、傳統程式碼和工具呼叫變成協處理器，負責一些確定性任務。 他舉的想像場景是：一個設備接收原始影片或音訊，神經網路理解當前場景，再用擴散模型為這一刻生成一個獨特的 UI。使用…