氛圍編程將死！谷歌總監警告：只會寫Prompt的程序員，2026年將被淘汰

　　新智元報道

　　編輯：KingHZ

　　【新智元導讀】AI不止，編程不死！Chrome工程大佬Addy Osmani宣言：AI加速開發，但人類專家仍是質量守護神！

　　如果你還在懷疑AI會不會取代編程，答案可能已經悄悄寫進代碼庫了。

　　在Chrome這種影響數十億人的超級工程里，AI早就不是「幫你補幾行代碼」的玩具了。

　　它用幾分鐘生成原型。

　　它快速掃過日志，標出bug。

　　它甚至參與架構討論，提出方案備選。

　　在Anthropic，Claude Code寫下了自己約90%的代碼；在谷歌Chrome團隊，AI被系統性地引入測試、性能分析和缺陷修復流程。

　　這就是正在發生的現實。

　　一個更殘酷的問題隨之而來：當AI編程進入「下半場」，靠感覺寫代碼的Vibe Coding，還站得住嗎？

　　谷歌云AI總監、Chrome前工程負責人Addy Osmani斷言，Vibe Coding已撞南墻，而AI輔助編程即將崛起。

　　AI編程，已經進入下半場。

　　Vibe Coding，再見！

　　AI編程迎來下半場

　　Osmani并不反AI。

　　相反，他是最早、最深度使用 AI 的那一批工程負責人。

　　他見過那種場景：

　　代碼看起來能跑。但沒人知道它為什么能跑。更沒人知道，它什么時候會出事。

　　正因為如此，他對「氛圍編程」（Vibe Coding）潑了一盆冷水：

vibe coding可以玩玩，但沒有測試和明確規范就容易變成一團糟。

　　正是Addy Osmani作為工程負責人的老辣之處——在所有人都在狂歡時，他看到了系統崩潰的風險。

　　作為長期活躍在Web技術與開發工具交匯點的大牛，Osmani在接受專訪時，結合親身經歷，談到像GitHub Copilot或谷歌Gemini這樣的AI助手，正徹底改變所謂「vibe coding」（氛圍編程）。

AI正在重塑編程方式，但「氛圍編程」（vibe coding）正在成為一種風險，而不是優勢。

　　2025年的谷歌Chrome團隊，AI已深度介入自動化測試、性能分析與優化、以及bug定位與修復。

　　在合適的流程設計下，整體生產力提升約30%。

　　但他緊接著強調了一句話，幾乎是全文的「安全閥」：

AI永遠沒有質量保證。 質量，只能來自人類的專業判斷。

　　在Chrome這種超大型工程中，如果不嚴格審查AI生成的代碼，你可能要收拾AI的「爛攤子」，這些代碼

　　可能違反Web標準

　　可能引入微妙的性能下降

　　可能在極端用戶場景下失效

　　這些問題，AI看不出來，但專家一眼就能看穿。

　　這正是Osmani所說的「70%問題」：AI能在項目前70%階段如魚得水，但剩下的30%，只有經驗豐富的工程師才能搞定，尤其在如瀏覽器引擎這類龐大系統中更是如此。

　　非工程師使用AI進行編程時，往往會遇到一堵令人沮喪的墻

　　這種趨勢并不只出現谷歌。

　　觀點或許可以反駁，但數據不會撒謊。

　　2025年底，Stack Overflow的開發者調查顯示：

　　開發者對AI準確性的信任度，從往年的40%下降至今年的29%；

　　對AI的正面評價率，從去年的72%逐年降至60%。

　　因為大家發現了「AI悖論」：代碼寫得快，產品卻交付得慢，AI寫的bug得你來擦屁股。

　　另一項調查，呼應了這一發現。

　　GitLab與哈里斯民意調查機構合作，訪問了3,266名從事軟件開發、IT運維和安全工作的專業人士。

　　結果顯示，盡管團隊部署速度比以往更快，但低效流程正在消耗他們的時間，而這些問題僅靠AI無法解決。

　　70%的受訪者表示AI正使合規管理變得更困難，76%的人指出大多數合規問題在部署后才被發現。

　　73%的人遇到過「氛圍編碼」問題，即通過自然語言提示生成的代碼，缺乏對代碼的清晰理解。

　　代碼的未來關乎信任，而不僅僅是工具。

　　很多「AI輔助工程」（AI-assisted engineering）被包裝成「氛圍編碼」（vibe coding）。

　　比如美國某科技大廠團隊使用AI，總體來看，從功能提案到上線，開發速度提升了約 30%。

　　但在Addy Osmani看來，這不是「Vibe Coding」，而是典型的「AI輔助工程」。

　　與氛圍編程相比，「AI輔助工程」最大的不同是人類工程師始終牢牢掌控全局，負責系統架構，審查并理解每一行AI生成的代碼，并確保最終產品安全、可擴展且易于維護。

　　而氛圍編程優先考慮速度與探索，而非專業應用所要求的正確性與可維護性。

　　要想在實際中真正用好AI編程，只靠提示詞恐遠遠不夠。

　　AI編程不是為了更快的編碼

　　Osmani直言：現在代碼寫得更快了，可上線卻更慢了，都是因為審查環節被跳過、假設沒人驗證。

　　程序員還不會被取代，他擔心的是另一種更隱蔽的風險：

　　過度依賴AI，導致核心工程能力退化

　　不理解生成結果，只是機械接受

　　在大型系統中放大AI的偏見與幻覺

　　他提出了「AI初稿」模式：AI先出草稿，人類再加測試、提交上線。

　　傳送門：https://addyo.substack.com/p/my-llm-coding-workflow-going-into

　　使用大語言模型編程，并非一鍵式魔法——它「困難且反直覺」，要獲得出色成果需要學習新的模式。

　　批判性思維，依然是關鍵。

　　經過一年的項目實踐，他逐漸形成了一套與許多經驗豐富的開發者類似的工作流程：將大語言模型視為強大的結對編程伙伴，它需要清晰的方向、上下文和監督，而非自主判斷。

　　規劃先行：先明確規范，再編寫代碼

　　分塊迭代：將任務拆解為可管理的小模塊

　　提供充分上下文與引導

　　選擇合適的模型并靈活切換

　　在整個軟件開發生命周期中利用AI編程

　　人類必須握緊方向盤：驗證、測試、審查一切

　　善用版本控制與自動化工具：頻繁提交代碼，將版本控制系統作為安全網；絕不提交你無法解釋的代碼。

　　通過規則和示例定制AI的行為

　　把測試與自動化視為倍增器

　　持續學習與適應，用AI放大你的技能

　　特別是最后一點，將每次與AI協作編程都視為一次學習機會，而你的知識越豐富，AI能提供的幫助就越大，從而形成一個良性循環。

　　這個模式普遍適用：如果你具備扎實的軟件工程基礎，AI能將你的生產力提升數倍。如果基礎薄弱，AI反而可能放大困惑。

　　對于那些擔心使用AI會削弱自身能力的人：他的觀點恰恰相反，如果方法得當，結果會是積極的。

　　總體來看，AI工具會放大你的專業知識。

　　所以，他的建議是：「繼續磨練你的技藝，并利用AI來加速這個過程。也要有意識地定期進行不帶AI的獨立編程，以保持你原始技能的敏銳度。」

　　歸根結底，這是「1=1>2」：「開發者+AI」組合的力量遠超任何單獨一方。

　　而這個組合中的開發者這一半，必須盡到自己的本分。

　　AI真正的作用是更快地迭代和實驗，通過更快速的探索，有可能催生出更好的解決方案。

　　但這有個重要前提：我們必須堅守工程原則，將AI視為工具，而非良好軟件實踐的替代品。

　　請記?。?strong>AI編程的目標不是更快地寫出更多代碼，而是構建更好的軟件。

　　如果運用得當，AI能幫助我們實現這一目標。

　　但「更好」究竟意味著什么，以及如何實現它，最終仍取決于我們自身。

　　2026開發者必殺技

　　軟件工程，始終在不斷變化。

　　從匯編語言到高級編程，從本地服務器到云計算，如今又從手動編碼邁入AI輔助開發。

　　每一次飛躍都自動化了編程的某些方面，而每一次開發者都隨之適應，并找到了更廣闊的天地。

　　過去的創新，幾乎總是為開發者帶來了更多工作、更多增長、更多機會。

　　AI的興起，也不例外。

　　它并非讓開發者變得無關緊要，而是在重塑成功所需的能力組合。

　　編程中那枯燥的70%正變得更容易；而那富有挑戰性的30%，正成為我們價值中更為關鍵的部分。

　　AI不會來搶你的飯碗，它只是在放大人類不可替代的能力：判斷力、創造力、以及那份把握全局的直覺。

　　到了2026年，真正的核心競爭力，可能是你知道什么時候讓AI干活，什么時候該親自上場。

　　卓越的軟件工程始終關乎解決問題，而不僅僅是編寫代碼。

　　AI并未改變這一點。

　　如今，隨著軟件實現成本越來越低，軟件工程師的角色并沒有變得不重要，反而讓我們看清了什么才是一直以來真正重要的能力：對問題的深入理解。

　　你需要理解問題、從客戶和內部團隊收集足夠的上下文信息，并把工作進行清晰地拆解和結構化，因為AI是基于這些輸入來直接執行的。

　　設計的關鍵，是判斷什么重要、哪些限制存在、哪些取舍是可接受的。

　　好的產品工作，本質上是對「清晰度」的追求：什么樣的執行，才真正值得去做。

　　在這個新階段，主導并管理AI智能體的工作流程，成了一種新的「手藝」。

　　而交付的成果，過去是代碼，現在是提供給智能體的規范。

　　那些「能最快把開發需求翻譯成代碼」的人，在未來并不能脫穎而出。

　　未來真正的贏家，是那些能做到以下三點的人：

　　把模糊問題轉化為明確的執行意圖；

　　設計出讓「好結果」自然而然發生的上下文結構；

　　區分真正重要的東西，和那些「只是能跑起來」的東西。

　　這其實和商業世界的變化如出一轍

　　當分發的成本趨近于零，真正有價值的是品味和策劃；

　　當實現的成本趨近于零，真正有價值的是對問題的定義能力與判斷力。

　　軟件工程這門技藝，在變化中進化。

　　它一直如此，但它仍然是「技藝」。

　　參考資料：

　　https://x.com/addyosmani/status/2007899127925854536

　　https://x.com/karrisaarinen/status/2007534281011155419

　　https://x.com/addyosmani/status/2005768629691019544

　　https://x.com/addyosmani/status/1960034046177923457

　　https://byteiota.com/ai-tools-hit-84-adoption-but-sentiment-crashes-to-60/

　　https://betanews.com/2025/11/11/the-ai-paradox-gitlab-finds-faster-coding-is-slowing-teams-down/

　　https://newsletter.pragmaticengineer.com/p/beyond-vibe-coding-with-addy-osmani

　　https://addyo.substack.com/p/my-llm-coding-workflow-going-into

　　https://addyo.substack.com/p/the-70-problem-hard-truths-about

　　https://addyo.substack.com/p/beyond-the-70-maximizing-the-human