在 AI 技術(shù)席卷軟件工程的今天，我們是否真的可以僅憑“氛圍”和直覺，就構(gòu)建出可靠、安全且可維護(hù)的生產(chǎn)級系統(tǒng)？

我們今天為大家?guī)淼倪@篇文章，作者的核心觀點是：“氛圍編程（vibe coding）”與“AI 輔助的工程實踐”存在本質(zhì)區(qū)別，前者雖在創(chuàng)意激發(fā)和快速原型中具有價值，但絕不能替代結(jié)構(gòu)化的工程方法。

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

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

image.png

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

氛圍編程（vibe coding）能很好地推動開發(fā)進(jìn)程、保持勢頭，但一旦缺乏結(jié)構(gòu)化的工程方法，它在生產(chǎn)環(huán)境的嚴(yán)苛要求下就會不堪重負(fù)，最終崩潰。

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

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

image.png

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

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

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

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

務(wù)實派將其用于“技術(shù)探針”（用于快速驗證），但事后必定施加規(guī)范約束。使用 AI 應(yīng)如對待初級開發(fā)者：善用其助力，但絕不放任自流。懷疑論者則將其斥為營銷話術(shù) —— “若我能一眼識破是氛圍編碼的產(chǎn)物，這代碼便不合格”。優(yōu)秀軟件的核心標(biāo)準(zhǔn)從未改變。社區(qū)中理性的聲音認(rèn)為：氛圍編程（vibe coding）是激發(fā)創(chuàng)造力的“沙盒”，但要想實現(xiàn)規(guī)?；瘮U(kuò)展，則必須依靠嚴(yán)謹(jǐn)?shù)墓こ谭椒ā?/p>

image.png

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

二、開發(fā)工作中的自主權(quán)和自由度、相伴而生的技術(shù)風(fēng)險與不同開發(fā)者如何看待這二者

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

“競技牛仔” 在極少的限制中如魚得水，他們崇尚西部荒野式的編程風(fēng)格，具有極高的風(fēng)險承受力且極少接受監(jiān)督。他們會欣然即興地“套索”出新功能或修復(fù)方案（有時真就全靠腎上腺素驅(qū)動）?！袄Ь种械那敉健?則在嚴(yán)格的規(guī)則下運作，被僵化的約束、沉重的治理或?qū)﹀e誤的恐懼所捆綁 —— 他們行動緩慢而謹(jǐn)慎，甚至幾乎不動。而介于二者之間的，是現(xiàn)代 AI 賦能的開發(fā)者：“氛圍編程者” 被給予的自由度剛好足以讓他們產(chǎn)出不可靠、不安全、難以維護(hù)的代碼。

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

不同風(fēng)格的開發(fā)者，用 AI 的方法和敢冒的風(fēng)險也都不一樣：

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

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

關(guān)鍵在于找到平衡點 —— 給予開發(fā)者足以創(chuàng)新的自由度，但又不至于讓其（或代碼庫）被缺陷與技術(shù)債扼住咽喉。本報告后續(xù)將探討為何放任的“氛圍編程”會引發(fā)行業(yè)領(lǐng)袖與網(wǎng)絡(luò)社區(qū)的尖銳批評，以及團(tuán)隊如何更負(fù)責(zé)任地駕馭 AI 輔助開發(fā)。

社區(qū)共識很明確：氛圍編程能夠加速探索進(jìn)程，卻埋下在生產(chǎn)環(huán)境引爆的隱患。近期的社區(qū)討論也凸顯出以下這些重復(fù)出現(xiàn)的問題：

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

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

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

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

這些工具需要由資深工程師嚴(yán)密監(jiān)督，尤其在處理關(guān)鍵任務(wù)代碼時。換言之，AI 能夠加速開發(fā)進(jìn)程，但永遠(yuǎn)無法替代軟件工程所需的嚴(yán)格規(guī)范。一旦跳過這些規(guī)范，往往會導(dǎo)致系統(tǒng)脆弱不堪和大量隱性問題的堆積。

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

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

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

他們談?wù)摰氖悄男╊愋偷墓收?？CTO 們列舉了性能崩潰、安全漏洞和可維護(hù)性噩夢等案例：

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

行業(yè)領(lǐng)袖的共識是：氛圍編程會危及軟件的質(zhì)量屬性 —— 安全性、代碼清晰度、可維護(hù)性及團(tuán)隊知識傳承。

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

四、“這算不上工程實踐，只是在賭運氣?！?/h2>

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

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

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

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

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

“這算不上工程實踐，只是在賭運氣”[6]的表述（源自 ShiftMag 文章觀點的轉(zhuǎn)述）在這些討論中被反復(fù)引用。它精準(zhǔn)傳遞了這樣的觀點：未經(jīng)適當(dāng)?shù)膶彶?測試的氛圍編程無異于指望軟件靠魔法運行。許多開發(fā)者指出編程應(yīng)是工程學(xué)科，而非許愿儀式。

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

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

“上周我將一堆 Docker Compose 配置轉(zhuǎn)換為 Terraform（Opentofu） —— 邊看電視邊用 Claude 操作，花了一兩小時。若采用閱讀文檔和 Stack Overflow 的傳統(tǒng)方式，隨便都得耗上一周?！?/p>

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

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

討論中還出現(xiàn)了一些有趣的類比：“與 agentic LLMs 協(xié)作編程本質(zhì)就是項目管理[8]?！蹦愕墓ぷ鞑辉偈蔷帉懘a，而是為 AI 分解任務(wù)、驗證每個模塊并整合結(jié)果。本質(zhì)上如同管理一位非常初級（但極快）的開發(fā)者的項目經(jīng)理。有人認(rèn)為這樣會更輕松，故稱“氛圍編程”，另一些人則認(rèn)為仍需扎實的開發(fā)能力，只是應(yīng)用方式不同。成功者會完成一系列系統(tǒng)化的處理步驟，將問題拆解為可驗證的小型提示詞，通過拆分、驗證、迭代保持控制力。失敗者則向 GPT 拋出一個模糊的提示詞后直接粘貼輸出。

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

五、氛圍編程適用于哪些應(yīng)用場景？

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

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

然而，每位稱贊這類成功案例的領(lǐng)導(dǎo)者都附加了重大限制條件。Matt Cumming 曾付出代價才認(rèn)識到：沒有約束地釋放 AI 可能適得其反。他描述了自己的一個早期項目在歷經(jīng)一個月的開發(fā)后，因某些 AI 生成的代碼損壞或錯誤，在“幾分鐘內(nèi)被 AI 徹底摧毀”[5]。這次經(jīng)歷令他痛定思痛，從而建立了一套嚴(yán)謹(jǐn)?shù)墓ぷ鞣椒ǎ?/p>

“我們使用 AI 輔助編碼時，首先要與 AI 協(xié)作撰寫功能規(guī)格說明和項目文檔中的實施步驟。我吸取的另一個教訓(xùn)是：需要要求智能體對所有新增功能進(jìn)行安全檢查?！?/p>

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

另一位領(lǐng)導(dǎo)者 Featured 公司 CEO Brett Farmiloe 對此表示贊同：

“一切從零開始時，氛圍編程確實非常高效……我們使用 v0（某個 AI 工具）快速構(gòu)建并部署了網(wǎng)頁站點。但對于已定型的生產(chǎn)環(huán)境中的代碼庫，我們僅將氛圍編程組件作為起點 —— 隨后由技術(shù)團(tuán)隊成員接手完成后續(xù)工作?！?/p>

他與 Cumming 都將 AI 生成的代碼視作腳手架?？焖俅罱蚣懿Ⅱ炞C構(gòu)想，這種方法非常高效，但絕不會將搖晃的腳手架留作最終建筑，需用堅固材料替換或加固它。用軟件術(shù)語來表述：AI 生成的項目原型必須經(jīng)過人類工程師的重構(gòu)、測試并全面掌控后，才能成為永久的解決方案。

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

在此可以總結(jié) 2025 年氛圍編程最具價值的應(yīng)用場景：

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

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

image.png

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

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

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

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

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

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

規(guī)范驅(qū)動的開發(fā)方法與 Agentic 方法從以下幾個主要方面區(qū)別于初級的氛圍編程：

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

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

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

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

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

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

七、Conclusion

開發(fā)者及其開發(fā)團(tuán)隊可以通過重新引入所有在 AI 生成過程中可能被跳過的傳統(tǒng)軟件工程實踐，將氛圍編程構(gòu)建的產(chǎn)品原型轉(zhuǎn)化為健壯的軟件系統(tǒng)：進(jìn)行設(shè)計、測試、審查，并對其負(fù)責(zé)。

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

開發(fā)工具和開發(fā)方法在不斷演進(jìn)，但在 AI 輔助工程的時代，責(zé)任擔(dān)當(dāng)、工藝精神和團(tuán)隊協(xié)作依然至關(guān)重要。