新智元報(bào)道

編輯：KingHZ

【新智元導(dǎo)讀】AI不止，編程不死！Chrome工程大佬Addy Osmani宣言：AI加速開發(fā)，但人類專家仍是質(zhì)量守護(hù)神！

如果你還在懷疑AI會(huì)不會(huì)取代編程，答案可能已經(jīng)悄悄寫進(jìn)代碼庫了。

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

它用幾分鐘生成原型。

它快速掃過日志，標(biāo)出bug。

它甚至參與架構(gòu)討論，提出方案備選。

在Anthropic，Claude Code寫下了自己約90%的代碼；在谷歌Chrome團(tuán)隊(duì)，AI被系統(tǒng)性地引入測試、性能分析和缺陷修復(fù)流程。

這就是正在發(fā)生的現(xiàn)實(shí)。

一個(gè)更殘酷的問題隨之而來：當(dāng)AI編程進(jìn)入「下半場」，靠感覺寫代碼的Vibe Coding，還站得住嗎？

谷歌云AI總監(jiān)、Chrome前工程負(fù)責(zé)人Addy Osmani斷言，Vibe Coding已撞南墻，而AI輔助編程即將崛起。

AI編程，已經(jīng)進(jìn)入下半場。

Vibe Coding，再見！

AI編程迎來下半場

Osmani并不反AI。

相反，他是最早、最深度使用 AI 的那一批工程負(fù)責(zé)人。

他見過那種場景：

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

正因?yàn)槿绱�，他對「氛圍編程」（Vibe Coding）潑了一盆冷水：

vibe coding可以玩玩，但沒有測試和明確規(guī)范就容易變成一團(tuán)糟。

正是Addy Osmani作為工程負(fù)責(zé)人的老辣之處——在所有人都在狂歡時(shí)，他看到了系統(tǒng)崩潰的風(fēng)險(xiǎn)。

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

AI正在重塑編程方式，但「氛圍編程」（vibe coding）正在成為一種風(fēng)險(xiǎn)，而不是優(yōu)勢。

2025年的谷歌Chrome團(tuán)隊(duì)，AI已深度介入自動(dòng)化測試、性能分析與優(yōu)化、以及bug定位與修復(fù)。

在合適的流程設(shè)計(jì)下，整體生產(chǎn)力提升約30%。

但他緊接著強(qiáng)調(diào)了一句話，幾乎是全文的「安全閥」：

AI永遠(yuǎn)沒有質(zhì)量保證。 質(zhì)量，只能來自人類的專業(yè)判斷。

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

• 可能違反Web標(biāo)準(zhǔn)

• 可能引入微妙的性能下降

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

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

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

非工程師使用AI進(jìn)行編程時(shí)，往往會(huì)遇到一堵令人沮喪的墻

這種趨勢并不只出現(xiàn)谷歌。

觀點(diǎn)或許可以反駁，但數(shù)據(jù)不會(huì)撒謊。

2025年底，Stack Overflow的開發(fā)者調(diào)查顯示：

開發(fā)者對AI準(zhǔn)確性的信任度，從往年的40%下降至今年的29%；

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

因?yàn)榇蠹野l(fā)現(xiàn)了「AI悖論」：代碼寫得快，產(chǎn)品卻交付得慢，AI寫的bug得你來擦屁股。

另一項(xiàng)調(diào)查，呼應(yīng)了這一發(fā)現(xiàn)。

GitLab與哈里斯民意調(diào)查機(jī)構(gòu)合作，訪問了3,266名從事軟件開發(fā)、IT運(yùn)維和安全工作的專業(yè)人士。

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

• 70%的受訪者表示AI正使合規(guī)管理變得更困難，76%的人指出大多數(shù)合規(guī)問題在部署后才被發(fā)現(xiàn)。

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

代碼的未來關(guān)乎信任，而不僅僅是工具。

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

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

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

與氛圍編程相比，「AI輔助工程」最大的不同是人類工程師始終牢牢掌控全局，負(fù)責(zé)系統(tǒng)架構(gòu)，審查并理解每一行AI生成的代碼，并確保最終產(chǎn)品安全、可擴(kuò)展且易于維護(hù)。

而氛圍編程優(yōu)先考慮速度與探索，而非專業(yè)應(yīng)用所要求的正確性與可維護(hù)性。

要想在實(shí)際中真正用好AI編程，只靠提示詞恐遠(yuǎn)遠(yuǎn)不夠。

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

Osmani直言：現(xiàn)在代碼寫得更快了，可上線卻更慢了，都是因?yàn)閷彶榄h(huán)節(jié)被跳過、假設(shè)沒人驗(yàn)證。

程序員還不會(huì)被取代，他擔(dān)心的是另一種更隱蔽的風(fēng)險(xiǎn)：

• 過度依賴AI，導(dǎo)致核心工程能力退化

• 不理解生成結(jié)果，只是機(jī)械接受

• 在大型系統(tǒng)中放大AI的偏見與幻覺

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

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

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

批判性思維，依然是關(guān)鍵。

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

• 規(guī)劃先行：先明確規(guī)范，再編寫代碼

• 分塊迭代：將任務(wù)拆解為可管理的小模塊

• 提供充分上下文與引導(dǎo)

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

• 在整個(gè)軟件開發(fā)生命周期中利用AI編程

• 人類必須握緊方向盤：驗(yàn)證、測試、審查一切

• 善用版本控制與自動(dòng)化工具：頻繁提交代碼，將版本控制系統(tǒng)作為安全網(wǎng)；絕不提交你無法解釋的代碼。

• 通過規(guī)則和示例定制AI的行為

• 把測試與自動(dòng)化視為倍增器

• 持續(xù)學(xué)習(xí)與適應(yīng)，用AI放大你的技能

特別是最后一點(diǎn)，將每次與AI協(xié)作編程都視為一次學(xué)習(xí)機(jī)會(huì)，而你的知識(shí)越豐富，AI能提供的幫助就越大，從而形成一個(gè)良性循環(huán)。

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

對于那些擔(dān)心使用AI會(huì)削弱自身能力的人：他的觀點(diǎn)恰恰相反，如果方法得當(dāng)，結(jié)果會(huì)是積極的。

總體來看，AI工具會(huì)放大你的專業(yè)知識(shí)。

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

歸根結(jié)底，這是「1=1>2」：「開發(fā)者+AI」組合的力量遠(yuǎn)超任何單獨(dú)一方。

而這個(gè)組合中的開發(fā)者這一半，必須盡到自己的本分。

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

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

請記住：AI編程的目標(biāo)不是更快地寫出更多代碼，而是構(gòu)建更好的軟件。

如果運(yùn)用得當(dāng)，AI能幫助我們實(shí)現(xiàn)這一目標(biāo)。

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

2026開發(fā)者必殺技

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

從匯編語言到高級編程，從本地服務(wù)器到云計(jì)算，如今又從手動(dòng)編碼邁入AI輔助開發(fā)。

每一次飛躍都自動(dòng)化了編程的某些方面，而每一次開發(fā)者都隨之適應(yīng)，并找到了更廣闊的天地。

過去的創(chuàng)新，幾乎總是為開發(fā)者帶來了更多工作、更多增長、更多機(jī)會(huì)。

AI的興起，也不例外。

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

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

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

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

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

AI并未改變這一點(diǎn)。

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

你需要理解問題、從客戶和內(nèi)部團(tuán)隊(duì)收集足夠的上下文信息，并把工作進(jìn)行清晰地拆解和結(jié)構(gòu)化，因?yàn)锳I是基于這些輸入來直接執(zhí)行的。

設(shè)計(jì)的關(guān)鍵，是判斷什么重要、哪些限制存在、哪些取舍是可接受的。

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

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

而交付的成果，過去是代碼，現(xiàn)在是提供給智能體的規(guī)范。

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

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

1. 把模糊問題轉(zhuǎn)化為明確的執(zhí)行意圖；

2. 設(shè)計(jì)出讓「好結(jié)果」自然而然發(fā)生的上下文結(jié)構(gòu)；

3. 區(qū)分真正重要的東西，和那些「只是能跑起來」的東西。

這其實(shí)和商業(yè)世界的變化如出一轍

當(dāng)分發(fā)的成本趨近于零，真正有價(jià)值的是品味和策劃；

當(dāng)實(shí)現(xiàn)的成本趨近于零，真正有價(jià)值的是對問題的定義能力與判斷力。

軟件工程這門技藝，在變化中進(jìn)化。

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

參考資料：

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