剛剛，大神Karpathy發(fā)布全新Vibe Coding指南！

在這份指南中，Karpathy不死磕單一模型，而是集眾模之所長，總結出了一套AI編程的三層結構：

• Cursor——主要負責自動補全與小范圍代碼修改，高效傳達任務意圖。
• Claude Code/Codex——用于實現(xiàn)較大功能塊，快速原型開發(fā)和跨領域代碼嘗試。
• GPT-5 Pro——解決最棘手的bug或復雜抽象，提供深度文檔/資料支持。

這三層遞進的結構，不僅是Karpathy對編程技巧的分享，更是他對Vibe Coding概念的一次升級式售后。

讓我們看看他是怎么做的吧！

順境Cursor，逆境Claude/Codex，絕境GPT-5 Pro

總的來說，Karpathy這套三層結構源自個人編程的實戰(zhàn)經驗。

他根據(jù)工具的使用頻率和任務種類，對Cursor、Claude Code/Codex和GPT-5 Pro進行了結構化組織——

將常見、簡單、局部的補全與修改交給Cursor，將較大功能塊的實現(xiàn)交給Claude Code / Codex，當遇到它們都無法解決的問題，再求助GPT-5 Pro。

即所謂順境Cursor，逆境Claude/Codex，絕境GPT-5 Pro。

展開來說，第一層，就是最常見的情況（約75%），通過Cursor的Tab鍵自動補全代碼。

在此，Karpathy發(fā)現(xiàn)了一種和大語言模型高帶寬溝通的方式——在項目的適當位置寫下一些具體的代碼片段或注釋。

這樣做的目的很明確：通過代碼或注釋直接展示任務意圖，一次性傳遞大量、精確的信息，比單靠文字描述更快、更清晰。

（Karpathy注：有時候自動補全模型會有點煩人，注意來回切換開關）

除此之外，就是對一段具體代碼進行高亮，然后請求某種修改。

第二層，就是Claude Code/Codex等可以在Cursor側欄中配置的模型，Karpathy主要用它們來實現(xiàn)一些通過提示詞比較容易指定的大功能塊。

整體看來，這些工具非常有用，但效果嘛，就有好有壞。

先說優(yōu)點，在一些開發(fā)者比較陌生、比較Vibe Coding的領域里，它們是不可或缺的。

對于Karpathy而言，像寫Rust、SQL語句，這些他以前沒怎么做過的東西，這些工具就非常好用。與此同時，這些工具還能快速生成一次性的可視化或調試代碼，為開發(fā)者省下大量重復勞動。

在此，代碼可以隨意地創(chuàng)造刪除，不再像過去那樣珍貴。于是，大神又造了一個新詞：“代碼后稀缺時代”（code post-scarcity era）

說完優(yōu)點，我們來看看缺點：

首先，這類模型很容易跑偏，因此，Karpathy通常不用“YOLO模式”（全面托管），并且不得不常按ESC終止項目。

其次，AI寫的代碼非常容易出現(xiàn)屎山，毫無The Zen of Python的美感。

具體來說，AI編程工具一來經常濫用try/catch、讓抽象過于復雜；二來會把代碼膨脹得很大（比如用嵌套的if-else，而其實列表推導式或一行if-then-else就能解決）；三來會復制粘貼代碼塊，而不是抽出一個好用的輔助函數(shù)……

對此，開發(fā)者往往還得再手動做一輪“清理”，處理上述這些編碼風格方面的問題。

此外，Karpathy的經驗還反映了當前AI編程工具在解釋性和交互性上的局限。

例如，他想讓Claude Code在寫代碼的同時講解，但發(fā)現(xiàn)完全行不通——AI工具顯然更想“寫代碼”，而非解釋為什么這樣寫代碼。

最后一層是GPT-5 Pro，Karpathy會在最難的情況下求助于它。

比如，當Karpathy、Cursor和Claude Code卡在一個bug上10分鐘無果時，他就會把整個問題復制粘貼給GPT-5 Pro，讓它跑10分鐘，結果還真能被它找到bug。

Karpathy表示，GPT-5 Pro非常強大，能挖掘出各種深奧的文檔和論文。在處理清理抽象結構、做文獻綜述、調查研究等復雜任務中，也能返回高相關性的資源和線索。

最后，Karpathy總結道：

編程在不同“類型”的工作流和工具之間被徹底打開了各種可能性，每個都有自己的優(yōu)缺點。但這也讓人難以避免地產生某種焦慮：擔心自己沒站在“集體可能性”的最前沿。所以這就是我在周日胡思亂想的一些筆記，也帶著好奇心想知道別人都在發(fā)現(xiàn)些什么。

實際上，這也體現(xiàn)了大神總結經驗的意義：通過與開發(fā)者交流、分享使用心得，整個開發(fā)社區(qū)才能不斷迭代和進步。

值得一提的是，在4個月之前，Karpathy分享了自己的Vibe Coding指南1.0：

• 把所有相關內容塞進上下文里（在大型項目中可能需要很久。如果項目夠小，就直接把所有文件都塞進去。
• 描述我們接下來要實現(xiàn)的那個具體的、增量式的小改動。不要直接要代碼，而是要幾種高層次的思路，并分析它們的優(yōu)缺點。幾乎總是會有多種做法，而大語言模型的判斷并不總是可靠。然后（可選）再具體化。
• 選擇一種思路，請它寫出第一版代碼。
• 進入復查/學習階段：手動在瀏覽器里打開我不熟悉或沒調用過的API文檔，向模型提問解釋、澄清、修改，必要時回退并嘗試另一種思路。
• 測試。
• Git commit。
• 詢問可以接下來實現(xiàn)什么。然后重復這個循環(huán)。

可以說，自今年2月Karpathy提出Vibe Coding以來，他一直在不斷完善和實踐這一構想，避免它淪為單純的“概念游戲”。

基于此，網友們也紛紛給出了自己的嘗試和答案。

網友在線，出謀劃策

在大神的一番分享下，許多網友表示深有同感，覺得自己的經歷和大神非常類似。

基本上就是小問題直接靠AI補全，大問題靠AI工具多roll給方向，自己來監(jiān)督。

有網友表示：有時候一個模型卡在某個問題上，另一個模型卻能快速解決。

而在不同的模型之間切換，為每個任務選擇合適的模型，已然成為了一門藝術！

其他網友也是曬出了自己的心得：確保LLM生成代碼一致性的最好方法是提供詳細的需求說明和功能拆解，同時附上驗收標準，包括代碼風格和質量規(guī)范。

ps，有位網友發(fā)現(xiàn)了華點：我“雙子座”去哪了？

你的Vibe Coding神操作是什么？快來炫一波！