如何正確Vibe Coding?這是來自Anthropic編程智能體負(fù)責(zé)人大師課

編輯｜+0、Panda

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

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

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

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

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

定義「氛圍編程」

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

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

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

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

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

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

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

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

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

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

核心在于：找到你可以驗(yàn)證的抽象層！

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

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

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

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

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

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

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

Erik Schluntz 強(qiáng)調(diào)了他的一套標(biāo)準(zhǔn)前置工作流。

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

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

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

為了負(fù)責(zé)任地完成這次 merge，團(tuán)隊(duì)采取了四項(xiàng)核心策略：

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

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

進(jìn)階技巧

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

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

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

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

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

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

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

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

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

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

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

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

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

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

提問 5：關(guān)于測試驅(qū)動(dòng)開發(fā)（TDD），你有什么技巧嗎？ Claude 經(jīng)常容易在測試?yán)镌较菰缴睢?/strong>

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

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

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

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

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

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

提問 7：你有兩種工作流，一種是在終端里（Claude Code），一種是在 VS Code/Cursor 里，你通常用哪種？多久會(huì)壓縮（Compact）一次上下文？因?yàn)闀r(shí)間長了它容易脫軌。

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

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

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

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

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