如何正確Vibe Coding?這是來自Anthropic編程智能體負責人大師課

編輯｜+0、Panda

如果摔斷了手、打了兩個月石膏，工作卻不能停，程序員該怎么辦？Anthropic 的研究員、《構建高效智能體》合著者 Erik Schluntz 的答案是：全權交給 Claude

如今，隨著 AI 強勢重塑軟件行業的規則，Vibe Coding 已經變成了企業想要成倍提升生產力時，繞不開的一道必答題。

幾個月前，Schluntz 帶著他被迫「全自動化辦公」的奇妙經歷走到臺前，和大家一起探討一個略帶爭議的話題：如何在生產環境中負責任地進行 Vibe Coding？

這個演講干貨十足，最近幾天又在 X 上火了起來，網友 Movez 甚至盛贊其勝過 100 門付費課程。

本著 Vibe Coding 的精神，我們也在 AI 的幫助下對 Schluntz 的演講進行了整理。

定義「氛圍編程」

很多人將重度使用 Cursor 或 Copilot 等 AI 工具生成代碼等同于氛圍編程。事實并非如此，只要開發者依然與模型保持著逐行修改與審查的緊密反饋循環，這就無法稱之為真正的「氛圍」。

Andre Karpathy 對此給出了更為精準的定義：「完全沉浸于氛圍，擁抱技術發展的指數級增長，并且徹底忘記代碼的存在。

這種工作模式徹底降低了開發門檻，讓缺乏工程背景的人群也能獨立開發完整應用。但在過去，這種開發模式的成功案例往往局限于個人游戲或低風險項目。一旦非專業人士將這套模式搬入真實的生產環境，常常會導致耗盡 API 額度、繞過訂閱驗證甚至隨意篡改數據庫等失控情況。

為什么要擁抱指數級增長？

既然高風險的商業環境中存在不可控因素，我們為何還要推進這項技術？核心驅動力在于AI 能力的「指數級增長」

目前，AI 能夠獨立處理的任務長度大約每 7 個月就會翻一倍。今天 AI 能夠穩定完成耗時 1 小時的編碼任務，開發者尚有精力逐行審查。到了明年甚至后年，當 AI 能夠一次性生成相當于人類 1 天甚至 1 周工作量的代碼時，如果依然堅持傳統的同步審查與修改，人類工程師必將成為算力爆發的瓶頸。

我們可以參考編譯器的發展史。早期的開發者可能并不信任編譯器，依然會去檢查底層的匯編代碼。隨著系統規模的擴大，開發者必須學會信任更高層級的抽象。面向未來，整個軟件工程界同樣需要提前思考：如何在生產環境中安全且負責地接納大模型直接生成的系統。

尋找可驗證的抽象層與「葉子節點」策略

在生產環境中實踐氛圍編程的核心理念在于：忘記代碼的存在，但必須始終關注產品的存在。

在現代企業管理學中，CTO 依靠驗收測試來管理技術專家，產品經理通過體驗產品來驗證功能設計，CEO 借助關鍵數據切片來抽查財務模型。他們都沒有深入到最底層的執行細節中。軟件工程師也需要建立類似的、無需閱讀底層代碼即可驗證的抽象層。

核心在于：找到你可以驗證的抽象層！

然而，目前的 AI 編碼存在一個棘手的技術阻礙，即技術債。當下除了通讀源碼，我們極難通過其他系統化手段來衡量或驗證技術債。

基于此，Erik Schluntz 提出聚焦代碼庫中的「葉子節點」（Leaf nodes）

這些節點指的是不被其他任何模塊依賴的末端功能或附加組件。在這些區域，即便產生了一定的技術債也是可以接受的，因為它們極少變動，也不會阻礙后續模塊的構建。相反，對于系統的主干與底層架構部分，工程師仍需深入理解并嚴密保護其可擴展性。

值得注意的是，隨著模型能力的提升，我們能夠信任 AI 接管的代碼層級正在向下延伸。以 Anthropic 內部近期測試的新版模型為例，AI 生成優質架構的成功率正在提升，這種邊界正在發生動態變化。

做好大模型的全職產品經理

要讓 AI 輸出高質量工程代碼，開發者需要轉換思維，把自己當成 Claude 的產品經理。不要問 Claude 能為你做什么，要問你能為 Claude 做什么。

在面對復雜的開發任務時，開發者需要像帶教第一天入職的新員工一樣引導 AI。直接拋出「實現這個功能」的指令注定會失敗。開發者需要向 AI 提供詳盡的代碼庫導航，并明確需求規格和限制條件。

Erik Schluntz 強調了他的一套標準前置工作流。

在讓 Claude 真正動手寫代碼之前，他通常會花 15 到 20 分鐘與其進行互動。這包含讓 AI 探索代碼庫、查找相關文件，并共同制定一個清晰的執行計劃。隨后將這些經過全面梳理的上下文和規范匯入一個單獨的提示詞中，再讓 Claude 去執行。在此流程下，模型的任務成功率會呈現指數級躍升。

22000 行代碼的生產環境合并案例

在演講中，Erik Schluntz 披露了 Anthropic 內部的一個極限實戰案例。其團隊近期在強化學習代碼庫的生產環境中，成功合并了一次高達 22000 行的代碼修改，其中絕大多數由 Claude 編寫。

為了負責任地完成這次 merge，團隊采取了四項核心策略：

1. 產品經理視角的深度引導：耗費數天時間進行前期的人工規劃與需求梳理。
2. 嚴格劃定修改范圍：將代碼變更嚴格限制在允許存在技術債的葉子節點上。
3. 核心區域人工介入：對于必須保證底層擴展性的核心邏輯，團隊執行了嚴格的人工審查。
4. 建立可驗證的檢查點：設計針對系統穩定性的長時間壓力測試，并確保整個系統具備極易被人類驗證的輸入和輸出標準。

通過這種方式，原本需要人類工程師耗費兩周時間逐行編寫與審查的巨大工程，被壓縮到了 1 天內完成。當開發的時間成本斷崖式下降時，工程師將有能力去推進以往由于資源限制而擱置的大規模重構與功能迭代。

進階技巧

探索、測試與工具鏈協同

在長達數十分鐘的問答環節中，Erik Schluntz 針對開發者關心的實戰細節進行了密集解答，涵蓋了從個人成長到工具搭配的多個維度。

提問 1：在過去，我們花很多時間處理語法、庫文件或是代碼組件之間的連接問題，我們在這個過程中學習?，F在該如何學習？如何積累足夠的知識去做好 Agent 的產品經理？

Erik：這是個很好的問題。確實，我們將不再經歷那些痛苦的死磕。但我認為這沒什么，就像現在的程序員不用手寫匯編代碼一樣。

樂觀的一面是，我發現借助 AI 工具，我學習新東西的速度大大加快了。很多時候我會問：「嘿 Claude，我沒見過這個庫，給我講講。你為什么選它？」擁有這樣一個永遠在線的結對程序員伙伴，意味著那些懶惰的人會蒙混過關，但只要你愿意投入時間去學，Claude 會幫你弄懂它。

此外，借助 AI 我們可以進行更多次「試錯」。原本需要兩年才能驗證的架構決策，現在六個月就能出結果。只要愿意嘗試，工程師在同樣的自然時間里能學到四倍的經驗教訓。

提問 2：在預先規劃過程中，如何平衡給它的信息量？有沒有一個標準化的模板？

Erik：這取決于你在乎什么。如果我不關心它是怎么實現的，我連一個實現細節都不會提，只給最終需求。如果我很熟悉這塊代碼庫，我會深入到具體用哪些類、參考哪個示例。

不過，當你不對模型施加過度約束時，它們表現得最好。所以我不建議花太多精力去弄嚴苛的格式模板，你就把它當成一個初級工程師去溝通就好

提問 3：如何平衡有效性和網絡安全？比如之前有報道說，很多不懂代碼的人做出的 Vibe 編程應用存在嚴重漏洞。

Erik：還是回到第一點：做好 PM。你需要懂行，知道什么是危險的、什么是安全的。媒體報道的漏洞大多是完全不懂寫代碼的人搞出來的，所以這在游戲和玩具項目里沒問題。但對于生產系統，你需要問出正確的問題去引導。我們那個 22,000 行代碼的案例，是一個完全離線運行的任務，所以我們確信沒有安全風險。

提問 4：全球懂軟件的人不到 0.5%，為了讓普通人更容易地構建軟件，同時避免泄漏 API 密鑰這類安全問題，現有的產品需要做出怎樣的改變？

Erik：如果能涌現出更多能夠實現「數學證明級別正確無誤（provably correct）」的產品和框架，那就太棒了。比如有人能構建出一種系統，后端把重要的身份驗證、支付部分都鎖死保障好，只留出一個「填空式」的前端沙盒讓你盡情去 Vibe Code。

最簡單的例子就像 Claude Artifacts，它托管在云端，只有前端，沒有權限和支付，所以怎么瞎折騰都安全。希望能有人開發出這樣能作為補充的好工具。

提問 5：關于測試驅動開發（TDD），你有什么技巧嗎？ Claude 經常容易在測試里越陷越深。

Erik：TDD 在 Vibe Coding 中極其有用。即使你看不懂測試用例，它也能幫助 Claude 變得更加自洽。

但確實，Claude 容易寫出過度依賴具體實現的「死胡同測試」。我的做法是強制規范它：「只寫 3 個端到端（E2E）測試，寫一下快樂路徑（happy path）、錯誤場景 1 和錯誤場景 2」。 引導它寫極其極簡的端到端測試，確保這連我自己也能看懂。

在 Vibe Coding 時，我通常唯一會去看的代碼就是測試代碼。測試過關了，我才覺得靠譜。

提問 6：Andre Karpathy 說「擁抱指數級增長」，這到底意味著什么？是不是模型會在我們期待的每一個維度變好？

Erik：指數級的核心不僅僅是持續變好，而是它們變好的速度遠遠超出我們的想象。 就像散點圖一樣，剛開始是平緩上升，然后突然就狂飆突進了。

回顧 90 年代搞計算機的人，從幾 KB 內存到今天的 TB 級存儲，那不是好了兩倍，而是好了數百萬倍。所以我們不該想「20 年后模型好兩倍會怎樣」，而是要想「如果它比今天聰明一百萬倍會發生什么」。這極其瘋狂，這才是所謂的擁抱「指數級」。

提問 7：你有兩種工作流，一種是在終端里（Claude Code），一種是在 VS Code/Cursor 里，你通常用哪種？多久會壓縮（Compact）一次上下文？因為時間長了它容易脫軌。

Erik：我兩邊都用。主要修改是 Claude Code 做的，我在 VS Code 里邊走邊審查代碼（或者審查測試）。

我通常在感覺到了一個「人類程序員會停下來吃個午飯」的停頓點時，就進行一次壓縮（Compact）。我的起手式通常是：先讓 Claude 找出所有相關文件并制定計劃，然后讓它把這些全寫進一個文檔里，接著我立刻進行壓縮。這樣就能丟掉制定計劃時耗費的那 10 萬個 Token，壓縮成只有幾千個干凈的 Token。

提問 8：你會同時用多個 Claude Code 會話然后合并結果嗎？面對極不熟悉的代碼庫，怎么以工程化的方式交 PR 而不是亂寫？

Erik：是的，我會用 Claude Code 起手搭建框架，然后用 Cursor 去收尾修復。對于我知道具體在哪幾行的修改，我會直接用 Cursor 手動去改。

面對陌生的代碼庫，在寫功能之前，我會先用 Claude Code 幫我探索。 我會問：「處理 Auth 的代碼在哪？」、「告訴我哪些功能和這個類似」、「列出我應該查閱的類」。在腦海中建立起全局視圖，確保我能穩妥地掌控正在發生的事情，然后再和 Claude 一起動手。