編輯｜+0、Panda

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

如今，隨著 AI 強勢重塑軟件行業(yè)的規(guī)則，Vibe Coding 已經(jīng)變成了企業(yè)想要成倍提升生產(chǎn)力時，繞不開的一道必答題。

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

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

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

定義「氛圍編程」

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

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

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

為什么要擁抱指數(shù)級增長？

既然高風(fēng)險的商業(yè)環(huán)境中存在不可控因素，我們?yōu)楹芜€要推進這項技術(shù)？核心驅(qū)動力在于AI 能力的「指數(shù)級增長」

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

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

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

在生產(chǎn)環(huán)境中實踐氛圍編程的核心理念在于：忘記代碼的存在，但必須始終關(guān)注產(chǎn)品的存在。

在現(xiàn)代企業(yè)管理學(xué)中，CTO 依靠驗收測試來管理技術(shù)專家，產(chǎn)品經(jīng)理通過體驗產(chǎn)品來驗證功能設(shè)計，CEO 借助關(guān)鍵數(shù)據(jù)切片來抽查財務(wù)模型。他們都沒有深入到最底層的執(zhí)行細節(jié)中。軟件工程師也需要建立類似的、無需閱讀底層代碼即可驗證的抽象層。

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

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

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

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

值得注意的是，隨著模型能力的提升，我們能夠信任 AI 接管的代碼層級正在向下延伸。以 Anthropic 內(nèi)部近期測試的新版模型為例，AI 生成優(yōu)質(zhì)架構(gòu)的成功率正在提升，這種邊界正在發(fā)生動態(tài)變化。

做好大模型的全職產(chǎn)品經(jīng)理

要讓 AI 輸出高質(zhì)量工程代碼，開發(fā)者需要轉(zhuǎn)換思維，把自己當(dāng)成 Claude 的產(chǎn)品經(jīng)理。不要問 Claude 能為你做什么，要問你能為 Claude 做什么。

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

Erik Schluntz 強調(diào)了他的一套標準前置工作流。

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

22000 行代碼的生產(chǎn)環(huán)境合并案例

在演講中，Erik Schluntz 披露了 Anthropic 內(nèi)部的一個極限實戰(zhàn)案例。其團隊近期在強化學(xué)習(xí)代碼庫的生產(chǎn)環(huán)境中，成功合并了一次高達 22000 行的代碼修改，其中絕大多數(shù)由 Claude 編寫。

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

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

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

進階技巧

探索、測試與工具鏈協(xié)同

在長達數(shù)十分鐘的問答環(huán)節(jié)中，Erik Schluntz 針對開發(fā)者關(guān)心的實戰(zhàn)細節(jié)進行了密集解答，涵蓋了從個人成長到工具搭配的多個維度。

提問 1：在過去，我們花很多時間處理語法、庫文件或是代碼組件之間的連接問題，我們在這個過程中學(xué)習(xí)。現(xiàn)在該如何學(xué)習(xí)？如何積累足夠的知識去做好 Agent 的產(chǎn)品經(jīng)理？

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

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

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

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

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

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

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

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

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

Erik：如果能涌現(xiàn)出更多能夠?qū)崿F(xiàn)「數(shù)學(xué)證明級別正確無誤（provably correct）」的產(chǎn)品和框架，那就太棒了。比如有人能構(gòu)建出一種系統(tǒng)，后端把重要的身份驗證、支付部分都鎖死保障好，只留出一個「填空式」的前端沙盒讓你盡情去 Vibe Code。

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

提問 5：關(guān)于測試驅(qū)動開發(fā)（TDD），你有什么技巧嗎？ Claude 經(jīng)常容易在測試里越陷越深。

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

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

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

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

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

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

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

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

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

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

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

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