在 AI 技術席卷軟件工程的今天，我們是否真的可以僅憑“氛圍”和直覺，就構建出可靠、安全且可維護的生產級系統？

我們今天為大家帶來的這篇文章，作者的核心觀點是：“氛圍編程（vibe coding）”與“AI 輔助的工程實踐”存在本質區別，前者雖在創意激發和快速原型中具有價值，但絕不能替代結構化的工程方法。

文章通過多個維度深入探討了這一觀點：從 FAANG 團隊的實際工作流程切入，指出真正的 AI 輔助的工程實踐是在嚴格的設計、審查和測試框架內使用 AI 作為“效能倍增器”。繼而以維恩圖形象對比了“氛圍編程者”、“競技牛仔”和“困局囚徒”三類開發者原型，警示過度自由或過度約束都將阻礙可持續開發。最后還結合 CTO 調研和社區討論，指出盲目依賴 AI 生成的代碼可能導致安全漏洞、性能崩潰與可維護性災難，并提出了“規范驅動開發”和“Agentic AI”等更負責任的工作流程建議。

氛圍編程（vibe coding）并不等同于 AI 輔助的工程實踐。近期一則 Reddit 帖子[1]描述了某 FAANG 團隊如何使用 AI，由此引發了一場重要討論：“氛圍編程”與專業化的“AI 輔助的工程實踐”。

image.png

雖然該帖子被包裝成前者的范例，但它詳細描述的流程 —— 包含技術設計文檔、嚴格的代碼審查和測試驅動開發 —— 在我看來恰恰是后者的一個清晰例證。將它們區分非常重要，因為將二者混為一談既會貶低工程學科的專業性，也可能讓新人誤以為構建健壯的生產級軟件無需嚴謹流程，這種認知極其危險。

氛圍編程（vibe coding）能很好地推動開發進程、保持勢頭，但一旦缺乏結構化的工程方法，它在生產環境的嚴苛要求下就會不堪重負，最終崩潰。

需要明確的是：“氛圍編程”是指完全沉浸于與 AI 合作協同的創造性流程（通過高層級的提示詞），本質上不再過多關注代碼本身的細節。這種方式不經深入審查就直接采納 AI 提供的建議，并專注于快速、迭代式的實驗。這使得它非常適合用于構建產品原型、最小可行產品（MVP），學習研究以及進行 Karpathy 所說的“周末練手項目”。這種方法（氛圍編程）是開發者建立編程直覺、初學者降低編程學習難度的有效途徑。它優先追求速度和探索性，而非專業應用所要求的正確性和可維護性。

在完全隨性的氛圍編程與稍加規劃、遵循規范驅動開發、提供充分上下文等做法之間存在過渡的區間，而貫穿整個軟件開發生命周期的“AI 輔助的工程實踐”則屬于另一維度。

image.png

與那篇帖子的觀點相反，Reddit 帖子中描述的流程實際上是將 AI 系統化集成到成熟的軟件開發生命周期的方法。這才是真正的“AI 輔助的工程實踐” —— 人工智能在這里扮演的是強力協作伙伴的角色，而并非要取代基本的工程原則。在這種模式中，開發者將 AI 作為“效能倍增器”，用以處理諸如生成模板代碼或編寫初始測試用例等任務，但這些操作始終被約束在一個結構化的框架之內。最根本的區別在于人類工程師始終牢牢掌握控制權。他們負責系統架構設計，審查并理解 AI 生成的每一行代碼，并確保最終產品具備安全性、可擴展性和可維護性。帖子中提到的開發速度提升 30%，是強化和優化了原有扎實流程的結果，而不是拋棄了這個流程。

對于工程師而言，將這種紀律嚴明的、使用 AI 增強的工作流稱為“氛圍編程”，是對其中所涉及技能和嚴謹性的錯誤描述。對于剛入行的新人來說，這會造成一種危險且錯誤的印象，讓人以為不需要理解底層代碼或工程基礎，僅靠寫提示詞就能做出可用的產品。若想正確運用 AI 進行開發，請從扎實的工程設計開始，讓所有產出物都經過嚴格的人工審查，并只將 AI 視為工程工具箱中一種無比強大的工具，而非取代工程所需專業知識和經驗的魔法棒。

一、氛圍編程者、競技牛仔與困局中的囚徒

目前技術社區中各派的立場分裂：樂觀主義者試“氛圍編程”為革命，懷疑論者則認為這是換湯不換藥的牛仔式編程（譯者注：指的是一種無組織、無紀律、不受約束的軟件開發方式。）。樂觀主義者將“氛圍編程”稱為下一個抽象層 —— 這就像從匯編語言躍升到 Python 的變革。外部力量將不斷推動其發展直至成熟。

務實派將其用于“技術探針”（用于快速驗證），但事后必定施加規范約束。使用 AI 應如對待初級開發者：善用其助力，但絕不放任自流。懷疑論者則將其斥為營銷話術 —— “若我能一眼識破是氛圍編碼的產物，這代碼便不合格”。優秀軟件的核心標準從未改變。社區中理性的聲音認為：氛圍編程（vibe coding）是激發創造力的“沙盒”，但要想實現規模化擴展，則必須依靠嚴謹的工程方法。

image.png

福雷斯特·布雷澤爾（Forrest Brazeal[2]）用一張有趣的維恩圖，以“繩索”（比喻自由與約束）為隱喻，對比了 AI 輔助時代的三種工程師人格 —— “氛圍編碼者”、“競技牛仔”和“困局中的囚徒”。每種原型都代表了一種極端的工作方式，而這些方式都難以產出生產級的軟件。

二、開發工作中的自主權和自由度、相伴而生的技術風險與不同開發者如何看待這二者

在軟件開發中，“繩索”這個比喻象征著開發者在構建軟件時被授予（或自我賦予）的自由度和風險承受水平。

“競技牛仔” 在極少的限制中如魚得水，他們崇尚西部荒野式的編程風格，具有極高的風險承受力且極少接受監督。他們會欣然即興地“套索”出新功能或修復方案（有時真就全靠腎上腺素驅動）。“困局中的囚徒” 則在嚴格的規則下運作，被僵化的約束、沉重的治理或對錯誤的恐懼所捆綁 —— 他們行動緩慢而謹慎，甚至幾乎不動。而介于二者之間的，是現代 AI 賦能的開發者：“氛圍編程者” 被給予的自由度剛好足以讓他們產出不可靠、不安全、難以維護的代碼。

他們通過自然語言的“氛圍提示詞”快速生成代碼，并盲目信任輸出結果，往往既沒有充分理解也不測試其可靠性。

不同風格的開發者，用 AI 的方法和敢冒的風險也都不一樣：

• 氛圍編程者 —— 這類開發者以自由流動的對話方式與大語言模型（LLM）協作，他們用自然語言描述自己想要實現的功能，然后讓 AI 來填充具體的實現代碼。這種自由程度令人振奮 —— “只需告訴 AI 添加登錄頁或修復這個 bug”。其優勢在于速度與創造力。氛圍編程者更像指揮家而非手動編碼者，他們關注創意勝過語法。他們的劣勢是缺乏控制力。他們通常在沒有安全保護的情況下運作：極少的代碼審查、稀疏的測試、以及對 AI 輸出的盲目信任。換言之，充足的自由卻缺乏引導，最終可能導致代碼庫變得脆弱而晦澀。有工程師指出，不做代碼審查的“氛圍編程”就像電工把一堆電線胡亂塞進墻里，而不是進行規范布線[3]。剛開始可能能用，但墻體背后早已埋下無數隱患。
• 競技牛仔 —— 經典的“牛仔程序員”在軟件工程領域并非新事物，在 AI 時代這類人格依然存在（有時會被 AI 增強，有時則不會）。競技牛仔是指那些以驚人速度、幾乎無視流程就將代碼推送到生產環境的開發者 —— 他們會在生產環境直接進行原型開發、凌晨兩點熱修復線上系統，通常為了追求速度而甘冒風險。他們（競技牛仔）具備高風險承受能力（與氛圍編碼者相同），但相比 AI 更依賴自身的直覺和經驗。如果說氛圍編碼者是被 AI 的“聲音”引導，那么競技牛仔則是追隨自己的直覺。他們確實會被一些繩索約束（就像牛仔競技也發生在有圍欄的場地內），但往往獲得的自由空間剛好足以讓他們險些自縊。這兩種風格的交叉點顯而易見：當氛圍編碼者開始將 AI 生成的代碼直接部署到生產環境，試圖大顯身手時，他們就變成了競技牛仔。其結果可能是驚人的成功……也可能是災難性的失敗。
• 困局中的囚徒 —— 在另一個極端，存在著被流程、官僚主義或自我強加的過度謹慎所束縛，以至于幾乎無法動彈的工程師。這些“囚徒”可能工作在受到嚴格監管的行業或遺留系統中，在那里每一行代碼的修改都像是一場艱苦的戰斗。他們（囚徒型開發者）幾乎沒有任何自由度 —— 他們受到嚴格的限制、強制性的審批流程，或許還對 AI 輔助持懷疑態度甚至明令禁止。這種思維模式雖然確保了安全性和可預測性，但也扼殺了創新。囚徒型開發者可能只能在場邊旁觀 AI 革命，由于組織規則或對未知的恐懼而無法參與其中。他們不會因為“繩索”而自縛手腳（因為他們從未被給予過任何松動的余地），但他們也可能無法交付任何新穎的或令人興奮的成果。有趣的是，“困局囚徒”和“氛圍編程者”有一個共同特質：都被無形之聲所支配。對囚徒而言，這些聲音是流程清單、工單系統或官僚政策 —— 它們指揮著每一個動作。而對氛圍編程者來說，這個聲音則是 AI 的建議。兩者實際上都未能真正掌控全局。

現實中的工程師并非二元標簽 —— 同一個人可能因項目與壓力差異，同時具備三種人格的特質。該維恩圖的精髓在于：三種極端路徑都終將失效，過度自由與過度約束都會阻礙可持續的工程實踐。

關鍵在于找到平衡點 —— 給予開發者足以創新的自由度，但又不至于讓其（或代碼庫）被缺陷與技術債扼住咽喉。本報告后續將探討為何放任的“氛圍編程”會引發行業領袖與網絡社區的尖銳批評，以及團隊如何更負責任地駕馭 AI 輔助開發。

社區共識很明確：氛圍編程能夠加速探索進程，卻埋下在生產環境引爆的隱患。近期的社區討論也凸顯出以下這些重復出現的問題：

• 安全漏洞[4]：將高度敏感的 API 密鑰直接以明文形式硬編碼在源代碼里；對用戶輸入的數據沒有進行任何驗證、過濾或轉義處理，就直接使用或存入數據庫；實現了脆弱、不健全、容易被繞過的身份驗證或授權檢查邏輯
• 調試工作極其脆弱[3]：當即使微小的改動也會引發連鎖故障時，非專業工程師（或缺乏工程背景的人）就會陷入困境、寸步難行。

三、你難道打算僅憑這種“氛圍編程”，來構建最終要上線運行的生產級軟件嗎？

整個軟件行業的資深工程領導者們正發出明確警告：AI 輔助的“氛圍編程”在生產代碼庫中引發問題的速度可能遠快于其解決問題的速度。Canva 首席技術官 Brendan Humphreys[4] 直言不諱地表達了這一觀點：

“不，你不可能靠氛圍編程來構建最終要上線運行的生產級軟件 —— 除非你放棄對質量、安全性、安全防護與長期可維護性的要求。”

這些工具需要由資深工程師嚴密監督，尤其在處理關鍵任務代碼時。換言之，AI 能夠加速開發進程，但永遠無法替代軟件工程所需的嚴格規范。一旦跳過這些規范，往往會導致系統脆弱不堪和大量隱性問題的堆積。

最新的調查結果印證了這些警告。在 Final Round AI[5] 于 2025 年 8 月的調研中，18 位 CTO 被問及氛圍編程時，16 位報告稱遭遇過由 AI 生成代碼直接導致的生產事故。這些技術領導者沒有炒作趨勢的動機 —— 他們的觀點來自實戰中的慘痛教訓。正如某位總結者所言[4]：

“AI 曾承諾讓我們都成為擁有 10 倍效能的開發者，現實卻把新人變成提示詞工程師，讓資深開發者淪為清理 AI 爛攤子的代碼保潔員。”

當交付的功能漏洞百出以至于需要凌晨兩點緊急搶修時，所謂快速交付的能力就失去了意義。

他們談論的是哪些類型的故障？CTO 們列舉了性能崩潰、安全漏洞和可維護性噩夢等案例：

• 某位 CTO 講述的性能災難：他目睹 AI 生成的數據庫查詢在測試中完美運行，卻在生產環境中拖垮系統。該查詢語法正確（無顯性錯誤），開發者便認為一切正常。但它在規模化場景下效率極低 —— 這本該由經驗豐富的工程師或規范的代碼審查發現。“它適用于小數據集，但一旦遭遇真實流量，系統就陷入癱瘓。”團隊耗費了一周的時間來調試這個應用卡頓問題 —— 若代碼經過周密設計，本可避免這種浪費。這揭示了一個關鍵風險：除非你明確引導 AI，否則它無法理解你的系統架構和非功能性需求。它生成的代碼可能表面良好并通過了基礎測試，卻可能在真實場景下崩潰。正如另一位技術領導者所說，氛圍編程會制造一種成功的假象，直到“系統在工作負載下開始搖晃” —— 然后毫無預警地徹底崩潰。
• 某架構師發現 AI 編寫的認證模塊存在致命漏洞：初級開發者通過復制粘貼 AI 建議和 Stack Overflow 上的代碼片段“氛圍編碼”出用戶權限系統。它通過了初始測試甚至 QA 審核。但上線兩周后，他們發現一個致命的缺陷：已停用賬戶的用戶仍能訪問某些管理工具。AI 錯誤地顛倒了真值檢查（例如誤用否定邏輯），這一細微漏洞被遺漏。由于沒有人深入理解自動生成的代碼，問題未被察覺。“當時看起來一切正常，”開發者曾這樣解釋。這是典型的 AI 生成錯誤 —— 人類自行編寫時可能發現的邏輯顛倒，但 AI 寫出來被當作黑箱處理，最終導致嚴重的安全漏洞。一名資深工程師花費了兩天的時間在浩如煙海的 AI 代碼中排查這個單行 bug。該架構師稱之為“信任債[5]” —— “它迫使資深工程師成為一名永久的代碼偵探，為了發布穩定的版本更新而反向解讀“氛圍”驅動的代碼邏輯。”換言之，每次未經驗證就信任 AI 輸出，都是在累積債務，終需有人梳理代碼來真正理解和修復代碼。
• 一個關于可維護性與復雜性的噩夢，源自某個AI生成功能的真實案例：該功能最初運行良好……直到需求發生變化。某團隊允許開發者用 AI 氛圍編碼整套用戶認證流程，短短幾分鐘內縫合了隨機 npm 包和 Firebase 規則。起初“表面一切順利——客戶滿意，團隊慶功，”某位工程經理說。但當團隊后續需要對現有的用戶認證/授權功能進行修改和增強時，“它徹底崩潰了。沒有人能理清組件間的關聯關系。中間件散落在六個文件中。沒有心智模型，只有氛圍。”最終他們不得不徹底重寫，因為調試 AI 產生的意大利面條式代碼“如同進行考古工作[5]”。這說明 AI 的輸出內容結構散亂、缺乏統一規范，只會留下一團亂麻，根本無法維護。
• 錯誤的安全感是另一個隱蔽的危險。AI 生成的代碼通常看起來非常整潔甚至符合語言規范。它可能通過你編寫的單元測試，于是開發者便會放松警惕。某 CTO 指出氛圍編程最危險的特征是代碼“看似能夠完美運行，直到出現災難性崩潰[5]”。AI 生成代碼讓團隊笑著放入生產環境，然后狠狠反噬。甚至代碼審查也可能失效：審查 1000 行 AI 編寫的 PR 并不比從頭編寫容易多少 —— 尤其當審查者假設代碼基本正確時。若 AI 還輔助代碼審查（確實存在這種情況），就成了盲人引導盲人 —— 正如某位評論者所言“這就是用機器驗證機器[6]”。可維護性因此受損，因為無人真正掌握代碼的邏輯內核。

行業領袖的共識是：氛圍編程會危及軟件的質量屬性 —— 安全性、代碼清晰度、可維護性及團隊知識傳承。

這些行業領袖并非抗拒新技術的勒德主義者 —— 他們才是對系統穩定運行負責的人。他們傳遞的信息雖然尖銳但具有建設性：利用 AI 作為輔助工具，而非放棄職責。代碼依然需要人類判斷力，尤其是將要部署到線上生產環境的代碼。正如一位資深開發者所言："AI 工具是副駕駛，而非自動駕駛系統。"它們能協助駕駛飛機，但必須由人類飛行員規劃航線，并在遭遇湍流時隨時準備接管操控。

四、“這算不上工程實踐，只是在賭運氣。”

不僅是 CTO 和思想領袖在敲響警鐘 —— 2025 年以來，一線開發者社區（那些日常與 AI 工具打交道的實戰派）也在就氛圍編程展開激烈辯論。在 Reddit[7] 和 Hacker News[8] 上，相關話題獲得了數百次點贊，資深開發者們分享著血淚教訓與對其的尖銳批評，間或夾雜少數成功案例。整體輿論氛圍傾向于對在重要項目中使用未經審查的 AI 代碼保持高度懷疑，但氛圍編程對特定場景內的應用持有限樂觀態度。

批評聲中，開發者們講述氛圍編程如何負面影響其工作流程與團隊協作。某 Reddit 熱帖[9]的最高贊評論慨嘆：

“我只希望人們別再在 PR 里 @ 我 —— 他們自己明顯都沒讀過代碼，卻指望我審查上千行完全陌生的氛圍編程出來的功能，這玩意甚至連 CI 都沒通過。”

這種挫敗感顯而易見：如果代碼作者自己都不理解 AI 生成的代碼或懶得運行測試，代碼審查就成了鬧劇。它將責任轉嫁給毫不知情的同事。另一位評論者回應[9]稱此舉“遠低于專業素養的最低標準”，就像工人草率施工讓他人收拾殘局。當開發者未盡應盡的職責就將 AI 的輸出丟給他人時，同行評審機制與團隊信任便土崩瓦解。

沒有人愿意與這樣的“工程師”共事，其貢獻只是從 ChatGPT 復制粘貼，并在出問題時聳肩推諉。

“這算不上工程實踐，只是在賭運氣”[6]的表述（源自 ShiftMag 文章觀點的轉述）在這些討論中被反復引用。它精準傳遞了這樣的觀點：未經適當的審查/測試的氛圍編程無異于指望軟件靠魔法運行。許多開發者指出編程應是工程學科，而非許愿儀式。

然而在批評聲浪中，技術社區也涌現出相反的觀點和稍微不一樣的觀點。并非所有人全盤否定氛圍編程。部分實踐者發現其在某些場景中優勢顯著。某 Hacker News 高贊評論[8]借用經典的“創新者窘境”[8]理論框架：今天有專家視氛圍編程為玩具，明天它就可能進化并顛覆舊有的方法。雖多數回應不認同這種必然性，但該討論開啟了一個樂觀的視角：或許我們正處于 AI 編碼的早期階段，未來 AI 或方法論的改進將解決現有缺陷。

某 HN 用戶分享了一個成功案例[11]：他用氛圍編程極速地開發了一款定制的內部工具。

“上周我將一堆 Docker Compose 配置轉換為 Terraform（Opentofu） —— 邊看電視邊用 Claude 操作，花了一兩小時。若采用閱讀文檔和 Stack Overflow 的傳統方式，隨便都得耗上一周。”

該開發者構建的并非面向客戶的產品，而是在自動化一項繁瑣的基礎設施任務。在此場景下，氛圍編程大獲全勝：既節省時間，而且生成的代碼對于他控制的內部工具來說也“足夠好用”。許多人紛紛附和，認為對于小規模或一次性的腳本和膠水代碼，氛圍編程可以極大提升生產效率。這是經典的 80/20 權衡 —— 若需快速實現且唯一利益相關者是自己時，AI 可在數分鐘內產出解決方案。

關鍵在于，這個案例中的開發者清楚邊界：他將 AI 視為加速自身工作的助手（甚至邊編碼邊娛樂），并大概率也驗證了 AI 的輸出。這符合行業內多次討論中的共識：“若你清楚自己在做什么，它就是絕佳的時間節省器。”言下之意是：經驗豐富的開發者可以像使用動力工具那樣運用氛圍編程加速繁瑣工作的進行，但仍需架構設計、過程引導與結果復核。若缺乏經驗，同樣的動力工具會造成嚴重破壞。

討論中還出現了一些有趣的類比：“與 agentic LLMs 協作編程本質就是項目管理[8]。”你的工作不再是編寫代碼，而是為 AI 分解任務、驗證每個模塊并整合結果。本質上如同管理一位非常初級（但極快）的開發者的項目經理。有人認為這樣會更輕松，故稱“氛圍編程”，另一些人則認為仍需扎實的開發能力，只是應用方式不同。成功者會完成一系列系統化的處理步驟，將問題拆解為可驗證的小型提示詞，通過拆分、驗證、迭代保持控制力。失敗者則向 GPT 拋出一個模糊的提示詞后直接粘貼輸出。

社區的基本共識是：氛圍編程并非銀彈。資深開發者大多將其視作原型設計和自動化完成瑣碎任務的有趣工具，而非復雜系統[8]中嚴謹工程實踐的替代品。“LLMs 將編寫所有軟件”的炒作正在遭受質疑。與此同時，大家也承認 AI 編碼助手將長期存在，若審慎使用[4]，可帶來巨大的效率提升。目前的討論焦點正轉向如何將 AI 融入工作流程，同時還不喪失軟件工程的嚴謹性 —— 這將是本文接下來要探討的方向。

五、氛圍編程適用于哪些應用場景？

若純粹的氛圍編程對生產環境有風險，它是否仍有價值？行業領袖與實踐者的答案都是肯定的：氛圍編程在某些特定場景下表現卓越，尤其在快速原型設計、探索性項目及作為創意輔助工具時，但必須知曉何時停止“氛圍營造”并開始工程化實踐。

FinalRound 調查[5]中多位 CTO 承認他們并不“完全否定氛圍編程”，而是通過劃分使用場景來實現最大效益。LittleHelp 創始人 Matt Cumming 分享道[5]，他可以“在一天內無故障創建并部署一個功能性的微型 SaaS 網絡應用，這堪稱瘋狂”。他利用一個周末時間，借助 AI 來完成繁重的工作，將創意轉化為一款可以上線的產品。這種速度前所未有，將可能需要 2-3 周完成的 MVP 構建壓縮至 48 小時。對于黑客松、演示項目、內部工具及快速驗證產品與市場的匹配度而言，氛圍編程可能改變游戲規則。它讓小團隊（甚至獨立開發者）在功能輸出上實現遠超團隊規模的表現。

然而，每位稱贊這類成功案例的領導者都附加了重大限制條件。Matt Cumming 曾付出代價才認識到：沒有約束地釋放 AI 可能適得其反。他描述了自己的一個早期項目在歷經一個月的開發后，因某些 AI 生成的代碼損壞或錯誤，在“幾分鐘內被 AI 徹底摧毀”[5]。這次經歷令他痛定思痛，從而建立了一套嚴謹的工作方法：

“我們使用 AI 輔助編碼時，首先要與 AI 協作撰寫功能規格說明和項目文檔中的實施步驟。我吸取的另一個教訓是：需要要求智能體對所有新增功能進行安全檢查。”

換言之，需要利用 AI 協助規劃與審查，而非僅僅將其作為代碼生成器。通過讓 AI 先勾勒設計框架，他確保了自己對系統架構有自己的思考。通過要求 AI 對輸出進行安全分析，他為漏洞防范增設了自動化的基礎檢查。他的團隊還將氛圍編程嚴格限定在“一次性的項目與產品原型，而非需要擴展的生產系統”上。通過氛圍編碼構建的應用僅作為概念驗證（Proof of Concept）存在，后續可能需要重寫或強化才能投入實際使用。

另一位領導者 Featured 公司 CEO Brett Farmiloe 對此表示贊同：

“一切從零開始時，氛圍編程確實非常高效……我們使用 v0（某個 AI 工具）快速構建并部署了網頁站點。但對于已定型的生產環境中的代碼庫，我們僅將氛圍編程組件作為起點 —— 隨后由技術團隊成員接手完成后續工作。”

他與 Cumming 都將 AI 生成的代碼視作腳手架。快速搭建框架并驗證構想，這種方法非常高效，但絕不會將搖晃的腳手架留作最終建筑，需用堅固材料替換或加固它。用軟件術語來表述：AI 生成的項目原型必須經過人類工程師的重構、測試并全面掌控后，才能成為永久的解決方案。

另一獲認可的應用場景是遺留代碼重構[4]。某分析指出，部分公司允許 AI 將舊代碼片段用新框架或新編程語言重寫，以此作為“起步助力”。由于這些代碼最終需要經過全面審查與測試，所以使用 AI 完成暴力翻譯或機械性工作可以節省時間。類似地，AI 能協助修復已知的代碼缺陷：例如“解決代碼中的這 5 個特定缺陷” —— 這是給 AI 一個非常具體、明確的任務，而非全權委托 AI 生成。此類場景中，范圍受限且輸出經過驗證，更貼近 AI 輔助編程而非盲目的氛圍編程。

在此可以總結 2025 年氛圍編程最具價值的應用場景：

• 快速原型設計與黑客松：需要在明天之前演示一個項目想法？使用 AI 生成代碼能極其快速地實現一個可運行的產品原型。即使代碼雜亂也無妨，只要它能展示核心概念。在此階段，編碼速度與迭代次數比代碼健壯性更重要。氛圍編程讓你能在一天內嘗試三種不同方案，而這是傳統編碼方式永遠無法實現的。
• 一次性的腳本代碼與內部工具：若代碼無需長期維護且僅作者本人使用，風險相對較低。編寫快速數據分析腳本、轉換文件格式、自動化編寫服務器配置文件 —— 此類任務通常可安全采用氛圍編程，因為若出現故障，編寫者（借 AI 之力）可自行修復，且外部影響有限。個人項目或自動化腳本是氛圍編程的沃土，能將工程師從瑣碎的工作中解放。
• 從頭開始新項目（需謹慎）：從零啟動新項目比將 AI 集成到復雜的舊系統中更易采用氛圍編程。當項目尚處于空白階段時，約束條件更少且無需遵循既定的代碼風格。團隊可能會采用氛圍編程方式快速實現新微服務或前端應用的初版以趕超緊迫的截止日期，后續再對其進行優化完善。

然而在所有場景中，都默認有一個前提：經驗豐富的開發者參與決策循環、處于核心流程之內。那些通過氛圍編程取得成功的人，依然會運用自己的判斷力來有效引導 AI 并驗證其輸出。他們將其視為與一位不知疲倦但容易出錯的初級開發者進行結對編程。與此形成鮮明對比的是，新手可能認為 AI 是跳過學習過程的魔法捷徑 —— 這種方式往往以挫折和失敗告終。如果初學者過度使用氛圍編程，可能會繞過必要的學習階段，培養出簡歷上有亮眼項目但缺乏基礎技能的畢業生 —— 這是教育工作者指出的另一個長期風險。最終，當 AI 與人類經驗結合時，它能顯著減少瑣碎工作所耗時間，但你很可能無法完全跳過人工審查與改進環節：

image.png

氛圍編程作為一項創意的激發與加速工具還是十分有價值的，但氛圍編程出來的代碼如果真的要用于正式項目，絕不能直接使用。它必須只是一個初稿或原型，需要經過后續的工程化處理。用它實現從零到項目演示階段的突破，或生成樣板代碼，或探索多種方案。隨后迎來最關鍵的階段：將 AI 生成的代碼或原型轉化為符合生產要求的、健壯的代碼。如何有效實現這一過渡將是我們接下來的焦點。

六、規范驅動的開發方法，是否能成為解決 AI 編程中“提示詞混亂”問題的有效方案？

針對氛圍編程的缺陷，一個充滿前景的發展方向是規范驅動和“agentic” AI 編碼方法[12]的興起。這些方法旨在保留 AI 代碼生成的生產力優勢，同時引入更多明確的開發流程和代碼規范、設計與架構思考，以及代碼審查、測試、安全檢查等質量保障措施 —— 本質上是為自由散漫的氛圍編程過程添加護欄。

使用開發規范驅動 AI 開發意味著在編寫代碼前，首先要明確開發規范或項目設計文檔（通常與 AI 協作創建）。工程師不會直接發送給 AI 一句“幫我構建個功能”，而是告訴 AI “協助我規劃該功能的需求與模塊設計”。通過制定明確規范（無論是一段文字、一份正式的設計文檔，還是一個簡單的步驟列表和函數列表），開發者能確保自己與 AI 對目標達成共識。這就像先編寫偽代碼或用戶故事（譯者注：是敏捷開發中的需求描述方式，格式通常為“作為[某角色]，我想要[完成某事]，以便[實現某價值]”。它從用戶視角定義功能價值。）。此舉解決了氛圍編程的一大缺陷：缺乏方向性。與 AI 共同撰寫功能規范能使團隊保持不脫離正軌，約束其輸出必須嚴格符合預設的目標，從而避免產生“聰明但無用”的復雜代碼。

在實踐中，開發規范驅動的工作流可以包含：首先引導 AI 生成高層級規劃、接口定義甚至測試用例，并持續迭代這些內容，直至人類認可該方案的合理性，隨后才要求 AI 實施具體計劃。這類似于優秀工程師指導初級開發者的方式 —— 你不會讓初級開發者第一天就獨立編寫整個子系統，而是會先共同商定項目設計。面對 AI，我們要學會采用相同的方式：將它視為需要詳細藍圖的初級伙伴。早期證據表明，這種方法比臨時性的提示詞能產生更好的結果。

Agentic AI 方法更進一步，使 AI 不僅能遵循規范，還能執行部分自主行動（例如運行代碼、進行測試和持續優化。）。此處的“Agentic”指 AI 智能體可接受高層級目標，并在限定范圍內以自主迭代的方式實現目標。例如，部分工具允許 AI 執行所編寫的代碼、觀察結果并修復錯誤 —— 全程無需用戶在每一步驟都發出明確指令。

規范驅動的開發方法與 Agentic 方法從以下幾個主要方面區別于初級的氛圍編程：

• 前瞻性規劃 vs. 事后補救：與先寫代碼再試圖去理解（或單純指望其僥幸工作）不同，規范優先的開發方法從一開始就明確編碼意圖。AI 的輸出結果會依照明確的目標進行評判，從而減少“技術層面實現了要求，但實際效果不符合預期”的意外（這在提示詞不夠具體時尤為常見）。
• 小步迭代 vs. 大包大攬：Agentic 工作流程鼓勵小而可測試的增量開發。不同于一次性要求生成千行程序，而是先要求一個函數，看到它通過測試后再繼續。這本質上模仿了測試驅動開發（TDD），只不過是由 AI 根據你的測試描述來編寫代碼實現。如果說氛圍編程像是用一句提示詞寫一整本小說，規范驅動則像是與 AI 合著，逐章推進并持續進行審校。
• 人機協同 vs. 人類單干：有趣的是，Agentic 方法在某些方面反而能減輕人類負擔 —— 例如將繁瑣的驗證工作交給 AI 處理。舉個例子，如果每個由 AI 生成的拉取請求（PR）都必須附帶修改說明，那么就可以讓 AI 智能體先草擬說明初稿，再由開發者編輯來確保準確性，從而確保任何代碼合并時都帶有上下文。實際上，這類方法試圖將 AI 融入軟件開發最佳實踐的體系中，而非取代它們。它們不是忽略測試與審查（如氛圍編程常做的那樣），而是將部分測試、審查工作自動化。

實踐中，探索這些方法的團隊常采用如下策略：

• 為所有由 AI 生成的主要組件編寫設計文檔（哪怕只有一頁，也可借助 AI 完成），以確保充分考慮該組件如何融入系統。
• 使用 AI 為自己生成的代碼生成單元測試或基于屬性的測試（property-based tests），及時捕捉明顯的錯誤。
• 鎖定依賴庫、注重安全：例如要求 AI 只使用已批準使用的庫，并嚴格執行安全掃描。值得一提的是，有個團隊甚至以受控的方式故意用氛圍編程生成不安全的代碼，借此研究和改進安全掃描器 —— 讓 AI 充當滲透測試工具而非生產代碼編寫者。
• 優先選用集成式 AI 工具（如 Cursor 或 VS Code Copilot），而非從 ChatGPT 復制粘貼。集成環境讓開發者能在完整上下文中查看代碼差異、即時運行，降低無意引入隱蔽問題的概率。
• 保持人類在決策環節的主導權：例如，AI 可提議代碼變更，但必須經人工批準方可合并。這類似于持續集成（CI）系統中自動化工具運行測試和檢查，但最終仍由開發者審核 PR。此時 AI 扮演的是 CI 助手，而非能自行部署到生產環境的自動機器人。

這些措施都是試圖以實際的工程嚴謹性削弱“直覺式編程”的風險。它們承認大語言模型非常有用，確實能理解用戶意圖并為各種任務生成可行代碼，但只有在清晰的指引和明確的邊界下才能發揮最佳效果。若放任自流，它們很容易偏離正軌，或生成表面可用卻在邊界場景失效的解決方案。

本質上，規范驅動方法與 Agentic 方法都旨在融合 AI 與人類的優勢：人類擅長定義問題、理解語境和做出判斷。AI 擅長快速探索解決方案、編寫樣板代碼，甚至在經過適當配置后能協調任務執行。AI 輔助工程的未來很可能在于這種中間路線 —— 既非純靠提示詞與祈禱的氛圍編程，亦非完全自動化，而是通過增強型工作流實現用 AI 放大人類設計能力，同時以人類約束 AI 的過度發揮。

最佳方案是采用混合模式。在沙盒階段：自由地進行氛圍編碼，測試項目創意，構建項目原型。在生產階段：則需運用工程規范 —— 通過運行程序或代碼片段，來驗證其行為是否符合預期、是否沒有 Bugs；在不改變代碼外部行為的前提下，對代碼內部結構進行修改和優化，使其變得更清晰、更易于理解和維護；在編寫具體代碼之前，對軟件的系統結構、模塊組成、它們之間的關系以及技術選型等進行規劃和設計；在軟件開發過程中，主動采取措施防止安全漏洞（如代碼注入、數據泄露、未授權訪問等）出現。

七、Conclusion

開發者及其開發團隊可以通過重新引入所有在 AI 生成過程中可能被跳過的傳統軟件工程實踐，將氛圍編程構建的產品原型轉化為健壯的軟件系統：進行設計、測試、審查，并對其負責。

快速完成產品初稿并無不可，甚至值得稱贊。只要所有人都明白，之后必須跳出“氛圍模式”，切換到“工程模式”。高效的開發團隊很可能會培養出一種直覺，知道何時該駛入 AI 快車道，何時該回歸到經過測試和審查的穩定道路上。最終的目標始終如一：交付可運行、安全且能被團隊維護的軟件。

開發工具和開發方法在不斷演進，但在 AI 輔助工程的時代，責任擔當、工藝精神和團隊協作依然至關重要。