今天小編分享的财經經驗：氛圍編程師崛起：年薪87萬，一天15小時，歡迎閱讀。
Vibe Coding（氛圍編程），如今成為矽谷最新流行語。
首次提出這一概念的 AI 大神 Karpathy，再度分享了自己的編程新姿勢——用 Swift 編寫首個完整卡路裡追蹤的 iOS 應用。
令人驚訝的是，他完全沒有 Swift 編程經驗，也沒有翻閱任何文檔。
通過與 ChatGPT 的多輪對話，Karpathy 僅用 1 小時完成整個開發過程，并成功部署到手機上。
不僅如此，在氛圍編程爆火之後，各路網友紛紛開發各種遊戲、網頁等各類應用，甚至就連科技公司也挂上招聘 " 氛圍編程師 " 的職位。
一則 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 編碼如同在暗藏技術雷區的迷宮中探索，需要持續積累直覺經驗。
一句話總結就是，" 氛圍編程 " 值得所有 " 段位 " 的開發者親身投入體驗。
