AI 編程熱潮下的萬字思考 —— 規避風險，善用其利 Detail - 人工智能,知識,教程,觀點,資訊 Baihai_IDP Blog

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

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

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

作者 | Addy Osmani

編譯 | 嶽揚

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

整個軟件行業的資深工程領導者們正發出明確警告：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 工具是副駕駛，而非自動駕駛系統。"它們能協助駕駛飛機，但必須由人類飛行員規劃航線，並在遭遇湍流時隨時準備接管操控。

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

不僅是 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 融入工作流程，同時還不喪失軟件工程的嚴謹性 —— 這將是本文接下來要探討的方向。

05 氛圍編程適用於哪些應用場景？

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

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 與人類經驗結合時，它能顯著減少瑣碎工作所耗時間，但你很可能無法完全跳過人工審查與改進環節：

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

06 規範驅動的開發方法，是否能成為解決 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；在不改變代碼外部行為的前提下，對代碼內部結構進行修改和優化，使其變得更清晰、更易於理解和維護；在編寫具體代碼之前，對軟件的系統結構、模塊組成、它們之間的關係以及技術選型等進行規劃和設計；在軟件開發過程中，主動採取措施防止安全漏洞（如代碼注入、數據泄露、未授權訪問等）出現。