大家好，我是袋鼠帝。

上周五，我買了一張高鐵票，耗時7小時，從昆明趕到了成都。

這是我第一次受冷總（@冷逸）邀請，去參加沃垠AI一周年線下活動，做一個關于Vibe Coding的分享。

說實話，接到邀請時我還有點忐忑，我是個I人，是那種小時候被老師點名起來回答問題，都會發抖的人。

現在倒是啥都無所謂了，但是臨場的語言表達還是稍弱。

不過，我內心是有點興奮的。

前幾天，看到一位朋友的朋友圈，我特別認同其中一句話：體驗世間的未知，才是生而為人的樂趣。

我覺得人生在于體驗，我很愿意跳出自己的舒適區嘗試新東西，當初從深圳裸辭回昆明all in AI，也是這股勁兒在推著我。所以，干了再說。

而且冷總給的選題（我的Vibe Coding實操與見解）我非常喜歡，不僅是因為我經常分享AI編程的文章，還因為25年也是AI編程飛速發展的一年（最近各大廠商也在瘋狂卷AI IDE）

于是，跟冷總一拍即合，就有了這次成都之行。

在正式開始之前，我先給大家看了一個我最近用MiniMax Agent折騰的小項目。

這是一個有完整核心功能的虛擬商品平臺，有前端，有后端，有數據庫，甚至還打通了用戶注冊、登錄和Stripe支付的全流程。

從一個想法，到一個能在線收款的電商網站，我只花了一個多小時，耗費100多￥。

這，就是Vibe Coding的魅力。

我偶然再次翻到，24年3月份靠ChatGPT Vibe Coding出來的一個小應用

再看了看最近用MiniMax Agent跑出來的電商平臺

我才驚覺，這一年多以來，AI編程進化之神速，真是翻天覆地的變化！！

一、什么是Vibe Coding？

在展開之前，我們還得先弄明白，到底什么是Vibe Coding。

這個詞最早是OpenAI的聯合創始人，前特斯拉AI主管Andrej Karpathy在今年2月份提出的。我專門翻了一下他那篇X的推文。

翻譯下來就是：

有一種全新的編程方式，我稱之為：“氛圍編程（vibe coding）”。在這種模式下，你完全沉浸于感覺（意識流），擁抱技術的指數級爆發，甚至徹底忘記代碼的存在。

這之所以能實現，是因為像 Cursor Composer (搭配Sonnet模型) 這樣的大語言模型已經強到離譜了。而且我基本上是用 SuperWhisper 語音輸入和 Composer 對話，幾乎都不用碰鍵盤。我會提一些懶到極致的要求，比如“把側邊欄的內邊距減少一半”，因為我真的懶得自己去找那行代碼。

我總是無腦點“全部接受”，早就懶得看代碼差異（diffs）了。遇到報錯信息，我連一個字都不加，直接就復制粘貼回去，通常這樣問題就解決了。代碼的體量會增長到超出我日常能理解的范圍，我得花點時間才能真正讀懂它。有時候大模型也修不好一個 bug，那我就繞開它，或者隨便提些亂七八糟的修改，直到那個 bug 莫名其妙地消失。

這種玩法對于周末隨便搞搞、用完就扔的小項目來說還不賴，而且真的挺有樂子的。我雖然在做一個項目或網頁應用，但這感覺其實不算在寫代碼——我只是在看、在說、在運行、在復制粘貼，然后大部分時候，它就這么成了。

聽起來是不是有點玄學，像意識流編程。

核心就一句話：通過自然語言指揮AI完成開發任務，忘掉代碼本身，專注于想法，和創造。

你不需要成為一個逐行敲代碼的碼農，就能徹底放飛你的想法和創造力，只需要關注"為什么"做和"做什么"，至于"怎么做"，那是AI這個工具人操心的事兒。

當然，我要明確一點，Vibe Coding≠AI編程。

我認為AI編程的范疇更廣（包含Vibe Coding），它需要關心統的架構設計，關心代碼的擴展性和可維護性。而Vibe Coding，特指的是完全不需要關心代碼的這種更徹底、更放飛自我的開發范式。

Vibe Coding這種新范式，和我們熟悉的傳統開發流程，差異非常大。

傳統開發中，一個項目啟動，先拉上產品、設計、前后端、運維，開一場漫長的會議。產品的需求，在不同角色間來回傳遞，信息不斷失真，效率極速下降。前后端聯調，更是每個項目上線前的坎，有時候可能一個簡單的接口參數命名不一致，就夠兩個人排查一下午。

我們大部分精力，都耗費在了解決人與人之間的溝通問題，和修補工具與工具之間的兼容問題上。

Vibe Coding的出現，直接把中間這些工作，壓縮到了極致。

理論上，現在只需要一個人，一個大腦，就能和一個AI編程工具配合，就能快速完成過去一個小團隊才能完成的工作。

開發者在這個過程中的角色，也發生了根本性的轉變。

從一個代碼的實現者，變成了AI的指導者。你的核心技能，不再是精通各種語法和框架，而是如何精準地描述需求，定義架構，以及有效的向AI提問。

所以，未來最流行的編程語言將是自然語言。

這個轉變聽起來很Nice，但實際操作起來，你可能又會發現，想用AI寫好代碼，也并不是一件容易的事。

很多人用AI寫代碼，感覺像在開盲盒，結果全憑運氣。AI經常會誤解你的意思，寫的代碼bug一堆，甚至把你的項目越改越亂。

那到底該怎么做？

PS：這篇不僅講Vibe Coding，也講AI編程

二、AI編程的見解

接下來分享的一些見解，并不完全是Vibe Coding的經驗，也涉及到AI編程，因為會涉及到一些代碼層面的經驗（而Vibe Coding是要忘掉代碼本身）

在分享現場，我給大家提了一個建議：要轉變思維，不要當一個"只會提需求的甲方"，而要做一個"帶徒弟的師傅"。

你想一哈，一個剛招進來的新兵蛋子，空有技術，但對項目一無所知。你是直接甩給他一句給我做個電商網站，還是會先跟他講清楚項目的背景，需求細節，以及團隊的技術規范？

答案顯而易見。一句話需求，連人類都覺得頭疼，更何況是AI呢？

想要AI能高效、準確地完成任務，你需要至少給它提供三大支持要素。

第一個要素，是告訴它做什么，也就是對齊需求。

最有效的辦法，就是給它寫一個清晰的README或者需求文檔，把項目目標，核心功能，技術棧，甚至設計風格，都交代清楚。

當AI接收到需求之后，你要讓它復述一遍，并向你確認。

這是最重要的第一步，給AI提供了完整的上下文，而不是讓它空中閣樓。

第二個要素，是給它設定規則，規范動作。

比如在類Cursor這樣的工具里，你可以配置一些開發約定，比如告訴它必須用Axios替代fetch，后臺必須用Python，修改bug時，千萬不要影響到其他現有功能等等。

這些規則，能約束它的行為，讓它生成的代碼符合你的預期。

第三個要素，是監督指導：要小步快跑，及時糾偏。

千萬不要讓AI一次性生成整個復雜的應用，翻車的概率很高。

可以先讓它把復雜任務拆解得足夠細，先建目錄結構，再寫單個功能模塊，每一步都進行驗證。這樣你才能牢牢掌控開發過程，避免AI自由發揮導致項目失控。

當然，除了這些要素，還有一些更具體的操作。

比如，如果你的項目用到了一些開發框架（比如Java的springboot，mybatis等等），可以給AI搭配一個叫Context 7的MCP工具，它能讓AI在寫代碼時，查閱官方文檔和示例，大大提高生成代碼的準確性和質量。

還有一個很重要的點，就是善用AI編程工具（比如Claude Code）的計劃模式。

對于復雜的需求，先別著急讓它寫代碼，先讓它拆解需求，制定一個詳細的執行計劃。

你跟它幾輪對話后，把思路和計劃都對齊了，再讓它動手，成功率會高很多。

另外，今天有個朋友問了我一個問題：

這個問題太經典了。

不要反復在有問題的代碼上修修補補，要不然bug會越改越多，甚至到最后項目基本上就改廢了..

有幾個建議：

1.采用小步迭代的方式：每次只修改少量代碼，便于快速定位和解決問題。

2.及時回滾：如果修改后問題更嚴重，要及時回滾到之前的版本，避免問題擴大化。

3.限制修改范圍：限制AI的修改范圍，只針對出現問題的部分進行修改，減少引入新問題的風險。

4.追問：在AI給出代碼后，追問它選擇該方式的原因、是否有其他方案及可能產生的影響，有助于理解它思考過程并、激發發現潛在問題。

5.模塊化與低耦合：遵循單一職責原則，將函數和模塊設計為只做一件事，以便于bug修改時影響范圍小，同時AI也更容易理解和處理。

6.提供精準上下文：不僅要指出bug位置，還需提供完整錯誤日志、詳細報錯信息和相關截圖；清晰描述期望效果與當前實際情況，幫助AI理解并修復bug。

如果一個bug，你讓AI反復修改了三次還沒解決，那就果斷回滾代碼，重新調整修補策略。

這說明你或者AI，對bug的根源理解出了問題。

回退代碼后，重新給AI提供更充足的上下文，比如完整的錯誤日志，報錯截圖，清晰地描述期望效果和實際情況的差異，甚至可以追問AI的修改思路，讓它自己審視會不會引發新的問題。

三、模型、AI編程工具選擇

模型這塊該怎么選呢？放張PPT的圖吧

現在市面上的大模型太多了，大家經常會糾結，我這個任務，到底用哪個模型效果最好。但這本來不應該是用戶操心的事。

我覺得，未來的趨勢是智能匹配模型。

上周阿里新發布的AI IDE：Qoder就采用了這種方式，不過有點難受的是它不讓用戶看到內置了哪些模型，以及它內部的切換策略。

下面這個表格是我整理的，用過的部分主流AI編程工具對比（僅供參考）

我個人的建議是：

如果預算有限，或者小白剛接觸AI編程，推薦Trae或者現在免費的Qoder

如果預算充足，推薦MinMax Agent

有一定技術能力，推薦Claude Code

AI編程工具現在很多了，也可以都試試，找到適合自己的就行。

四、Vibe Coding的局限性

前面我們聊了很多它的好處。但任何事物都有兩面性，Vibe Coding也不例外。

目前它最大的局限性在于，對于企業級的，嚴肅的，大型復雜項目來說，Vibe Coding還不夠看。

AI生成的代碼，可能沒有經過良好的設計，結構混亂，難以維護。

AI也可能在你看不到的地方，埋下隱藏的bug和安全漏洞。

長遠來看，這種憑感覺快速開發出的項目，可能會積累大量的技術債（長期代碼混亂，形成"屎山"），和及認知債：也就是團隊里沒人真正懂這些代碼是怎么回事，以后誰都不敢動。

只能像下圖這樣??，這讓人有點難受..

軟件工程專家Dave Farley尖銳的提出："Vibe Coding是2025年最糟糕的想法！我們正在培養一代不會編程的開發者。"

目前來說Vibe Coding還不是銀彈，它更像一把雙刃劍。它在加速創造的同時，也在加速制造技術垃圾（當然，這個是用在企業內部核心項目的情況）。

目前Vibe Coding還主要適用于需要快速試錯的初創企業或者個人MVP項目、以及概念驗證（PoC）

但這歸根結底還是模型的問題，不過后續應該可以通過工程優化（AI IDE）在一定程度上彌補上述的缺陷。

五、AI編程是銀彈嗎？

剛剛講了Vibe Coding還并不適用于企業內重要項目使用。

那AI編程是否能成為企業中軟件工程的銀彈呢？

前幾天看了@云中江樹寫的一篇公眾號純文字內容：AI編程時代，軟件工程真的沒有銀彈嗎？

他表示在TRAE的活動現場，有嘉賓提到軟件工程的真正瓶頸：

是想清楚做什么(設計思考)，而不是把想好的東西做出來(編碼實現)。過去幾十年所有的技術進步，包括現在的AI，都只是在優化編碼這個次要任務，對設計思考這個根本任務的幫助有限。

這個觀點，在過去四十年里，幾乎是顛撲不破的真理。

但是，AI真的不能進行設計思考嗎。

那篇文章里面，江樹分享了一個Vibe Coding的真實案例，讓我挺震撼的：

"有大佬的公司已經在用AI做架構設計，最終設計出的架構難以理解，也難以實現，但是硬著頭皮去做，最終實現了30%，已經牛逼的不行了，根本無法想象完整的做出來會是怎樣。"

我覺得AI能設計思考，至少現階段，工程師可以跟AI多輪對話，思維碰撞后，極有可能產生比人類自己設計更牛逼的架構設計。

所以我認為AI編程是能成為銀彈的。

但現階段的Vibe Coding不能。

不過隨著AI的能力會越來越強，以及工程優化（比如AI IDE的優化），帶著Vibe Coding的上限也會越來越高，期待有一天，我們僅靠Vibe Coding就能完成非常復雜的大型企業項目。

本文轉載自??袋鼠帝 AI 客棧??，作者：袋鼠帝 AI 客棧?