編輯 | 燕珊
“有一種全新的編碼方式，我稱之為“vibe coding”（氛圍編碼）。你完全沉浸在氛圍裡，擁抱指數式增長，甚至忘記程式碼本身的存在。這之所以可行，是因為大模型（比如 Cursor Composer 搭配 Sonnet）已經強大到離譜了。” ——Andrej Karpathy
這個由前 OpenAI 研究員 Andrej Karpathy 在今年 2 月提出的概念——“Vibe Coding”，如今正在矽谷乃至更廣泛的技術圈中持續走紅。
據矽谷知名創業孵化器 Y Combinator (YC) 的最新訊息顯示，在 2025 年冬季（W25）這一批 YC 創業公司中，有四分之一的初創團隊表示其 95% 的程式碼都是 AI 生成的。YC 管理合夥人 Jared Friedman 昨天在一檔討論 Vibe Coding 的播客節目中公開了這個數字。
值得一提的是，這些創始人並不缺乏技術背景，過去也能從零開始編寫產品，“但如今，他們更願意直接把絕大部分編碼都交給 AI。”
YC CEO Garry Tan 在播客中更是直接指出：“Vibe Coding 不是一陣風潮，也不會消失；它是編碼的主流方式，如果你不這麼做，就可能被落在後面。”
過去一年裡，許多專注 AI 輔助程式設計的初創公司（如 Bolt.new、Codeium、Cursor、Lovable、Magic）紛紛獲得大額融資，也反映了市場對這一領域的強烈興趣。
“我只是在看到什麼就說什麼，執行，複製貼上，然後基本能跑起來。如果發生錯誤，就把錯誤資訊再塞給 AI，接受它的改動，試試看能不能行，然後反覆這個流程。”這是 Karpathy 此前在帖子中對 vibe coding 過程的描述。
顯然，vibe coding 與傳統軟體開發的最佳實踐——如嚴格規劃、測試和深入理解實現細節——截然不同。Karpathy 當時在帖子中也帶著幽默的口吻承認，這種方式適合追求極致“懶人體驗”的程式設計師——“我會提一些很簡單的需求，比如‘把側邊欄的內邊距縮小一半’，因為我懶得去找那段程式碼了。我只管點 ‘全部接受’，都不再看 diff。”
“vibe coding 的方式對於那些有創意但程式設計能力不強的人幫助很大，對於有較強程式設計能力的人來說也是有效的。”正馬軟體 CTO 沈凎近日在 InfoQ 的一場直播上提到，他最近在做一個研究專案，涉及到一個複雜的前端介面模擬。雖然他並非前端工程師，但透過 AI 工具，他只需簡單描述，工具就能快速生成前端介面，如此一來，驗證其他部分想法時就能更加高效。
“對於有一定工程素養的人來說，描述清楚後，AI 可以在半小時到一小時內完成整個介面的生成，這種方式對探索新事物和創意實現非常方便。”沈凎說道。
微軟工程師 Peter Yang 最近也在一條 X 帖子中演示了 vibe coding 的應用。透過一系列對話式提示輸入給 Cursor 和 Claude 3.7 Sonnet，做出了一個簡單的 3D 第一人稱射擊喪屍遊戲。Yang 還用了語音轉文字應用，以便他能直接用口述來描述需求，並在不斷迭代中完善原型。
無論如何，從本質上說，vibe coding 能讓只具備基本溝通能力的人，至少在做一些小專案時，變成“用自然語言程式設計”的開發者。
不過，在當前的大模型裡，能夠一次性處理多少程式碼（即上下文大小）仍是限制之一，意味著使用 vibe coding 創作的專案規模有一定上限。如果專案太複雜，使用者就需要主動扮演更高層的專案管理角色，將 AI 生成的程式碼片段拼裝到更大的架構中。隨著每一代 AI 大模型的技術限制逐漸放寬，這種束縛或許終有一天會消失。
在 vibe coding 所帶來的高效與隨性背後，也暗藏了除錯和維護難度的坑。
當初創公司僅有數十或數百使用者時，Vibe Coding 效率驚人。但如果產品迅速積累數百萬乃至上億使用者，如何保證系統的穩定性就成了嚴峻挑戰。
YC 的 Garry Tan 認為，到了那時候，如果 AI 不能很好地幫你除錯，你還是要下到底層去看。你需要知道那些程式碼到底在幹什麼。他表示，創始人如果希望產品能走得更遠，就需要具備傳統的編碼訓練背景。
YC 合夥人 Diana Hu 亦指出，目前很多大模型在系統除錯能力上仍顯不足。即使開發者或產品創造者高度依賴 AI，他們仍需具備一項重要技能：閱讀程式碼並發現 bug。“你必須有足夠的訓練和對程式碼質量的判斷力，知道大模型吐出來的是好東西還是壞東西。要想做好 ‘vibe coding’，你依舊需要能分辨好壞的‘品味’與知識。”
開發者 Ben South 在 X 上調侃 vibe coding 很有趣，可一旦需要“vibe debug“就是另一回事了
獨立開發者兼 AI 研究者 Willison 最近在其部落格中提到，如果 AI 程式設計工具出現“幻覺”並生成不存在的東西倒也沒那麼可怕，因為程式碼工具帶有“內建事實核對”：如果有虛構的程式碼，執行就會報錯。
但是，vibe coding 在專業環境中的風險回報比要複雜得多。個人或小規模專案可以容忍，然而對於企業來說，程式碼的可維護性與可靠性會有更高要求，而 vibe coding 生成的程式碼往往難以滿足這些標準。如果程式碼無法如預期般工作，要想修復就必須瞭解它在做什麼——這正是 vibe coding 通常跳過的環節。
談到如何劃定什麼是真正的 vibe coding，Willison 做了一個重要區分：
“如果你讓 LLM 寫了所有程式碼，但你還是對它進行了審閱、測試並理解了其原理，那並不算 vibe coding——那其實只是把 LLM 當成一個打字助手。相反，vibe coding 是在沒有充分理解程式碼如何工作的情況下就直接接受。”
儘管最初可能只是 Karpathy 的半開玩笑提法，vibe coding 卻可能反映了一部分開發者思路的轉變——他們更看重速度與實驗，而不再執著於深入的技術理解。
Willison 還強調說，開發者還是必須為自己產出的程式碼承擔責任：“我一直堅信，作為開發者，你得為自己編出的程式碼負責——如果你要署上自己的名字，那就得對它如何執行、為什麼這樣執行有把握，最好到能講解給他人的程度。”
那麼，vibe coding 會不會讓人類程式設計師面臨失業？從本質上說，程式設計始終是告訴計算機如何執行。具體的方法雖然一直在演變，但總有人在“精確指令”這件事上比別人更擅長——即便是藉助自然語言。某種意義上，這些擅長與 AI 溝通的人，可能會成為新時代的“程式設計師”。
回顧歷史，在 20 世紀 70 年代末到 80 年代初，很多專家曾預測，要想有效使用計算機，每個人都需要程式設計技能，因為當時幾乎沒有現成的軟體可用。於是世界各地的教育體系都開始普及“計算機編碼”課程。可沒過多久，人們開發了足夠多的應用軟體，讓非程式設計師也能輕鬆使用電腦——無需程式設計。即便如此，程式設計師也依然沒有消失，他們反而藉助這些應用去編寫更龐大、更復雜的軟體。或許， AI 程式設計工具也會經歷同樣的過程。
類似地，就像自動駕駛儀使超音速飛行更安全、更高效，AI 在程式設計領域也讓人類可以“抽象掉”一些繁瑣的手動編碼環節，進而探索更復雜或更創新的軟體體驗。
可是，到那個時候，人類還能理解並除錯那些由 AI 生成的大規模程式碼嗎？也許不能。到時候，我們也許會對 AI 工具產生全面依賴。
至於 “vibe coding” 能否長期在程式設計領域佔據一席之地，抑或只會停留在原型開發階段，更多取決於組織在程式碼質量、可維護性和技術債上願意承擔多大風險，而不僅僅由 AI 模型的技術能力來決定。就目前來看，vibe coding 更像是 AI 與人類開發者之間又一次“既合作、又實驗”的互動——或許還談不上全自動，但的確逐漸模糊了“誰才是真正程式設計師”的界限。
參考連結：
https://techcrunch.com/2025/03/06/a-quarter-of-startups-in-ycs-current-cohort-have-codebases-that-are-almost-entirely-ai-generated/
https://www.youtube.com/watch?v=IACHfKmZMr8
今日好文推薦
隨著 Data + AI 時代的到來，資料架構如何演進以支撐即時分析與智慧決策？3 月 10 日晚 20:00 直播，4 位來自阿里、位元組和 StarRocks 的專家，帶你深入解析 Lakehouse 的演進路徑、落地實踐，助力企業釋放資料價值！