來源 | 新智元
編輯 | 桃子 好睏
Vibe Coding（氛圍程式設計），如今成為矽谷最新流行語。
首次提出這一概念的AI大神Karpathy，再度分享了自己的程式設計新姿勢——用Swift編寫首個完整卡路里追蹤的iOS應用。
令人驚訝的是，他完全沒有Swift程式設計經驗，也沒有翻閱任何文件。
透過與ChatGPT的多輪對話，Karpathy僅用1小時完成整個開發過程，併成功部署到手機上。
一則YC招聘啟示中，一則YC招聘啟示中，明確提出工作內容中的50%程式碼，均是由AI完成，年薪高達120k美金（87萬元）。
職位介紹中，每天工作12-15小時，卻成為了全網的華點。
如果AI真的提高了生產力，為啥還會有人每天狂幹12-15個小時呢？
400行程式碼，ChatGPT化身程式設計導師
Karpathy如何用嘴，迅速完成一個iOS應用的開發？
推文中，他具體分享了自己與ChatGPT對話的四次過程：啟動應用；功能增強；使用AppStorage持久化資料；部署到手機。
在啟動應用階段，Karpathy從0開始，告訴ChatGPT自己的需求：剛剛下載了Xcode，希望用SwiftUI構建一個iOS應用。
ChatGPT在接下來開啟了「手把手」教學。
首先安裝和啟動Xcode，就這個環節已經細緻到，開啟點選具體某個選項。然後配置專案，包括命名、介面、程式語言等選擇。
接下來，ChatGPT還提供了基礎程式碼，包括SwiftUI的介面佈局和邏輯實現，幫助Karpathy快速搭建了一個可執行的原型。
上下滑動檢視
有了原型之後，便開始實操了——構建一個體脂追蹤的計時器APP。
Karpathy就像一位產品經理一樣，給出了自己的具體要求：「計時器」主要體現隨時間變化而自然消耗的熱量，用大號數字顯示在螢幕中央，還要每秒更新一次消耗的熱量。
ChatGPT按照指令，給出了分佈構建過程，以及下一步建議。
上下滑動檢視
接下來，Karpathy還要求其給出不同按鍵對應的功能程式碼搭建過程，以及每秒更新的配置。
第二部分，在基礎版本完成之後，就是去做功能增強。
比如，支援明暗模式切換，簡單的加減按鈕、觸覺反饋和動畫等，ChatGPT均提供了具體的程式碼片段和實現建議。
為了讓資料在應用關閉後依然儲存，Karpathy還向ChatGPT詢問了如何使用AppStorage。
ChatGPT詳細講解了AppStorage的使用方法，並幫他將卡路里資料儲存到UserDefaults中。
最後一步，Karpathy需要將這款應用部署到iPhone上，ChatGPT指導他完成了Xcode配置、證書設定、裝置部署的步驟，並最終讓應用成功執行在手機上。
經過1小時的對話，卡路里計時器的應用完成了。
下面是計時器的主要功能，一共200行程式碼，只有幾個UI元素和一些簡單的邏輯。
第二天，Karpathy又透過與ChatGPT的3次對話，為應用添加了一些新功能：動畫環、將固定值顯示在 [-3500, 3500] 區間內。
剛剛，他還為其添加了日誌、為+100/-100新增小字說明並隱藏BMR兩個功能。
截至目前，這款應用程式碼也僅有400行。
網友瘋狂整活
隨著氛圍程式設計越來越火，圈內大佬Min Choi也總結了一波效果拔群的案例。
開發者Luke Van In用大約1萬行Claude編寫的程式碼構建了一款遊戲。
他認為，當前程式碼庫的複雜庫已經接近可控的極限，Claude已經能夠重構20%程式碼，並自動添加了武器後坐力和鏡頭抖動的效果。
對於貼花系統，Luke又藉助了Grok進行了一些手動調整。
xAI工程師kache設定了一種方法，可以動態重新載入客戶端和伺服器邏輯，無需使用者重新整理頁面，就可以即時更新和迭代。
他還特意強調，如果自己清楚想要做什麼，氛圍程式設計才能發揮其優勢。
還有一位開發者Louie Bacaj僅用Claude 3.7+o1 Pro，在幾個小時內透過氛圍程式設計做出一個益智遊戲。
還有角色扮演的小遊戲，也是透過氛圍程式設計就能完成。
還有人用兩條提示，就能讓遊戲中NPC駕駛飛機。
不是所有AI輔助程式設計都是「氛圍程式設計」
值得注意的是，並不是所有用上AI輔助的程式設計，都能稱之為「氛圍程式設計」。
在最近的一篇部落格中，知名web框架Django的共同作者Simon Willison，就對這一概念進行了非常詳盡的解釋。
並且，還獲得了「發明人」Karpathy的大加讚賞：
就個人體驗而言，當我處於類似下面這條狗的狀態時，就會稱之為「氛圍程式設計」——比如昨晚開發iOS應用時的場景。
但實際開發中，我很少徹底放任AI自由發揮，更多時候保持著漸進式迭代：審閱生成程式碼、分階段增加複雜度、透過持續提出澄清問題來逐步理解模組間的互動邏輯。
氛圍程式設計正當時
自從Andrej Karpathy在2月3日首次提出「氛圍程式設計」後，這一概念隨即登上各大主流媒體，並引發無數線上討論。
為了避免偏離初衷，這裡必須強調——氛圍程式設計絕不等同於藉助LLM編寫程式碼，而是在不審查LLM產出程式碼的情況下構建軟體。
「氛圍程式設計」可以你完全沉浸在氛圍中，擁抱指數級進步，甚至忘記程式碼本身的存在。這是因為LLM（例如Cursor Composer搭配Sonnet）已經變得足夠優秀。我甚至可以只用SuperWhisper與Composer進行對話，幾乎無需摸鍵盤。
我會提出最基礎的要求，比如「將側邊欄的內邊距減半」。並且總是點選「全部接受」，而不去檢視程式碼差異。遇到報錯，就直接複製到對話方塊中讓LLM去修復。程式碼的複雜程度已超出我的日常認知，真要理解必須逐行細讀。有時LLM無法修復bug，我就直接繞過或隨機調整直到問題消失。
對於週末隨便做的專案來說，可謂是充滿趣味。只是觀察、口述、執行、複製貼上，結果居然大部分都能跑通。
作為天賦異稟的資深程式設計師，Andrej本無需AI輔助。他選擇這種程式設計方式，是因為嘗試瘋狂的創意充滿樂趣，且LLM的程式碼生成速度比最頂尖的人類程式設計師快幾個數量級。
對於低風險的原型開發，何不放手讓它發揮？
使用LLM寫程式碼≠氛圍程式設計
與專業軟體工程師使用LLM的方式相比，這種「忘記程式碼存在」的開發方式有著本質差異。
首先，軟體工程師需要構建的是符合多重標準的系統——不僅要可驗證執行，還需具備人類可讀性（及機器可解析性），並能支撐長期迭代開發。
其次，軟體工程師需要在同時考慮顯性需求與隱性約束的情況下，從數十種潛在方案中篩選出最優解，進而實現效能、可訪問性、安全性、可維護性、成本效益等指標之間的平衡。
第三，軟體工程師還需要對程式碼進行審查。生產環境AI輔助開發鐵律是：任何無法向其他人精確解釋工作原理的程式碼，都禁止進入版本庫。
不難看出，當LLM生成程式碼後，軟體工程師會完整地執行審查、測試，以及確保可解釋性這一系列流程。也就是說，這本質上仍是傳統軟體開發正規化。工具鏈中是否包含LLM，並不改變工程實踐的屬性。
氛圍程式設計的價值
雖然氛圍程式設計≠用LLM進行程式設計，但這並不意味著它是一種不負責任的開發方式。
這種突破性的程式設計形式，實則蘊含著改變世界的潛能——讓數百萬沒有計算機學位或經過程式設計培訓的普通人，也能借助工具，讓計算機完成高度定製化任務，打造屬於自己的個性化工具。
如此一來，那些原本和程式設計沒什麼交集的人可能會因此點燃熱情，並最終成長為專業開發者。這個行業的最大壁壘——如同攀登懸崖般的初始學習曲線——將被氛圍程式設計徹底剷平。
而資深的工程師們，也可以藉此訓練自己對模型能力邊界的認知。正如此前所論述的，使用LLM編碼如同在暗藏技術雷區的迷宮中探索，需要持續積累直覺經驗。
一句話總結就是，「氛圍程式設計」值得所有「段位」的開發者親身投入體驗。
參考資料：
https://x.com/karpathy/status/1903671737780498883
https://x.com/karpathy/status/1903870973126045712
https://x.com/minchoi/status/1903895144413159516
技術交流群邀請函
△長按新增小助手
掃描二維碼新增小助手微信
請備註：姓名-學校/公司-研究方向
（如：小張-哈工大-對話系統）
即可申請加入自然語言處理/Pytorch等技術交流群
關於我們
MLNLP 社群是由國內外機器學習與自然語言處理學者聯合構建的民間學術社群，目前已經發展為國內外知名的機器學習與自然語言處理社群，旨在促進機器學習，自然語言處理學術界、產業界和廣大愛好者之間的進步。
社群可以為相關從業者的深造、就業及研究等方面提供開放交流平臺。歡迎大家關注和加入我們。
掃描二維碼新增小助手微信
關於我們