編輯 | 聽雨
出品 | 51CTO技術棧（微信號：blog51cto）
“AI寫代碼的時代，工程師還需要懂工程嗎？”
Google Chrome 開發者體驗負責人 Addy Osmani 給出了截然不同的答案。
“Vibe Coding 并不等同于 AI 輔助工程。我們不能因為AI的出現，就貶低了工程這門學科本身的嚴謹性。”
在最新一期《The Pragmatic Engineer》播客中，Addy 詳細闡述了他的新書《Beyond Vibe Coding》的核心觀點——AI能幫你提速，但無法替你思考。
他指出：AI 工具可以快速完成70%的工作，但剩下那關鍵的30%，必須靠真正理解系統的工程師完成。
圖片
Addy Osmani帶領 Chrome 團隊專注于提升網頁構建的性能、開發工具，以及整體的開發者體驗。如果你曾打開過 Chrome 的開發者工具欄，那么你幾乎一定用過由 Addy 參與設計或構建的功能。
小編為大家整理了這期播客的精華內容，你將了解到：
- Vibe Coding 和 AI輔助工程的區別
- Addy是如何使用AI工具的
- AI 如何重塑軟件工程工作流
- 為什么“理解AI生成的代碼”依然至關重要
- 工程經理（EM）和產品經理（PM）的角色將如何變化
- 新角色的出現與開發者教育的轉變
干貨滿滿，建議收藏細讀，enjoy！
Vibe Coding 和 AI輔助工程的區別
主持人:你寫過不少書，尤其是關于如何帶領高效工程團隊的那本，差不多一年前出版。而你最近的新書叫《Beyond Vibe Coding》。你在 Substack 上也寫了很多關于Vibe Coding以及AI 輔助工程（AI-assisted engineering）的心得。在你看來，Vibe Coding具體是什么意思？它和AI 輔助工程又有什么異同？
Addy Osmani:
是的，我常常跟人說，我認為Vibe Coding和AI 輔助工程并不是一回事。這個區別非常關鍵——我們不能因為 AI 的出現，就貶低了工程學本身的價值，否則會讓新人誤以為構建一個可用于生產的軟件系統是件很簡單的事。
我大概有兩個定義。Vibe Coding 是一種“完全投入與 AI 的創意流”的狀態。它更注重高層次提示，在某種意義上甚至“忘記了代碼的存在”。這概念最早可以追溯到 Andrej Karpathy 的定義——它強調接受 AI 的建議而不必深度審查，注重快速、反復的實驗性迭代。
我個人覺得這種方式非常適合原型、MVP（最小可行產品）和學習階段。很多生產團隊也發現，當他們需要快速驗證一個想法、摸索一個組件或產品雛形時，Vibe Coding 的確非常有用。
它追求的重點是速度與探索，而不是結構化與可維護性。后者才是我們在面向大規模生產時真正要關心的。所以在我看來，Vibe Coding 和AI 輔助工程其實是一條光譜的兩端。前者更偏向自由探索，后者則更接近傳統的軟件工程方式——需要規劃、需求說明、上下文完整性。
而在AI 輔助工程的模式中，AI 是一個強大的協作伙伴，但絕不是工程原則的替代品。它可以在整個軟件開發生命周期中為你加速：生成樣板代碼、調試、部署等等，但核心的控制權仍在工程師手中。你要負責架構設計、代碼審查，并且要理解 AI 生成的大部分內容。最終你要確保產品是安全、可擴展、可維護的。AI 可以幫你提速，但絕不意味著你可以“甩鍋”給它。說到底，我認為很多人都覺得 AI 是個倍增器，但實際上，你的專業水平越高，AI 工具的效果越好。相反，如果你是新人或初級開發者，可能還沒經歷過一些傳統工程最佳實踐。
而如果你真在乎生產級質量，就不應該提交那些你無法完整解釋的代碼。因為你不能指望 AI 在未來幫你“解開混亂”。那往往行不通。
Addy是如何使用AI工具的
主持人：
那你個人是怎么使用這些工具的？包括 Vibe Coding 和 AI 輔助工程。
Addy Osmani:
最近我更多地在實踐規范驅動開發（spec-driven development），也就是在開始寫之前，就非常清晰地知道自己要構建什么。
當然，我仍會在一些場合使用 Vibe Coding：比如做個人小工具、一次性腳本。過去如果產品經理或工程師有個新點子，我們會畫個線框或草圖；而現在，我可以直接用 Vibe Coding 做出一個能運行的原型，甚至直接在 Pull Request 或聊天里給團隊演示——“看，這就是我想的樣子”。
這真的非常有力量。我很喜歡 Vibe Coding 帶來的這種高質量表達想法的方式。
主持人：
Vibe Coding 現在確實很火。輸入一段提示語，幾乎馬上就能跑起一個應用，感覺像魔法一樣。但它沒考慮一個關鍵因素——團隊的上下文與積累的知識。每個提示都只基于你告訴它的內容，而不是團隊已經知道的。
真正的產品開發恰恰相反：它是集體經驗的積累。比如：每個功能背后都有客戶請求的歷史、每個 PR 都與團隊路線圖相關、每個文檔都埋著討論痕跡。
而簡短的提示語無法讓 AI 理解這些“隱性上下文”。像 Linear 的 Agents 就是試圖彌補這一點——它們在你的開發系統內部運行，能看到正在阻塞沖刺的 issue、項目目標、過往討論、設計文檔，甚至客戶的反饋。當你讓它生成一個 PR 或實現某個功能時，它不是“即興發揮”，而是基于整個團隊的語境。這才是真正的AI 驅動開發：不是“快”，而是“有意圖地構建”。
Addy Osmani:
是的。但這并不意味著我們可以直接把 Vibe Coding 的原型代碼塞進生產系統。一旦你明確了組件或功能的愿景，就應該開始寫下：“我們的實際期望是什么？我們把哪些算作需求？”這能讓你從模型中獲得更高質量的輸出。
如果你只是“跟著 vibe 走”，那其實就等于把架構和實現細節都交給了 AI。這在創意階段可以，但在產品工程階段絕對不夠。對我來說，“規范驅動開發”一直很重要。
我還非常重視測試。如果你愿意用測試去驗證 AI 生成代碼的正確性，那會極大降低風險。哪怕你用的是最先進的模型，也有可能生成出看似合理但實則混亂的代碼。有了測試，你能立刻發現問題在哪。我發現這能幫助項目持續保持在“綠色狀態”。順便提一句——我們團隊剛剛發布了Chrome DevTools MCP。
我對質量非常看重。過去幾年，我看到很多工程師在遇到 Bug 時，就直接說：“嘿，LLM，看起來這個按鈕不對勁，幫我修一下。”這其實又是一種“跟著 vibe 走”的行為。
但如果你能讓 AI 工具真正“看到”頁面，比如通過瀏覽器上下文（MCP 就是為此而生的），AI 就能識別哪些地方渲染錯了、有哪些控制臺報錯，從而改進反饋循環。因此我對 MCP 很興奮——它讓我們能更自然地把其他工具整合進工作流中。除此之外，我發現要真正用好這些工具，仍需要持續投入學習。每當有新模型、新平臺出現，我都會去試，并鼓勵團隊互相分享經驗。這種“一起學習”的文化其實很關鍵，它能讓團隊在這個快速變革的時代保持心理安全感。
人類監督和代碼審查變得更重要
主持人：
你在谷歌這樣的大公司里工作，想了解一下，你看到其他團隊是如何使用這些 AI 工具的？有沒有一些出乎意料的成功或失敗案例？
Addy Osmani:
在像 Google 這樣的公司，我們有一套長期打磨出的“大規模工程體系”。AI 的出現并沒有讓這些原則失效，我們依然重視質量、驗證和盡職審查。
有趣的是，我們在大公司看到的趨勢，其實和初創公司類似：比如“提示詞工程”的重要性、以及最近興起的“上下文工程”，也就是如何構建最佳上下文，讓模型輸出更可靠。
我們花了很多時間確保每個項目都能提供正確的描述、文件、示例等上下文，這些往往不在模型的訓練數據中。我個人在過去幾年幾乎在生活的各個方面都嘗試使用 AI，這讓我對哪些場景真的能帶來生產力提升、哪些地方還不夠成熟，有了更清晰的認識。
我也鼓勵團隊在嘗試之前先問自己：“如果把這個問題交給 AI，它會幫我更快解決嗎？還是會拖慢我？”即使只是思考這個問題，也能幫助我們更好理解 AI 的邊界與潛力。很多傳統軟件工程師其實對 AI 并不熟悉。我讓團隊的負責人去深入了解模型評測、基準測試、以及像 RAG 和微調這些核心概念。因為我們做的不只是開發工具——AI 還會影響用戶體驗、產品設計和工程流程。所以我們需要理解這兩端之間的聯系。
最大的體會之一是：人類監督永遠不能缺席。我們也遇到過很多外部貢獻者，用 LLM 自動生成 PR，出發點是好的，但卻給維護者帶來了巨大負擔。
主持人：對，我看到 Hashimoto 也在社交媒體上抱怨這個問題。很多人出于好意提交 AI 生成的代碼，但結果讓維護者壓力更大。
Addy Osmani:
是的。我很喜歡研究不同開發者群體如何看待 AI。最近有份研究指出：當團隊引入 AI 之后，代碼產出速度會大幅提升，但人工審查會成為新的瓶頸。PR 數量增加了，可誰來審查？
所以一些團隊開始探索讓 AI 來做代碼審查，但這其實很危險——如果寫代碼的是 AI、審代碼的也是 AI，而人類并未仔細理解代碼內容。那我們就無法確定最終到底上線了什么。
我個人也在使用許多工具，比如 Kline、Cursor、Copilot、VS Code。我喜歡去查看這些工具在生成解決方案時的思考過程：它做了什么決策？用了什么邏輯？生成了哪些部分？我會在 PR 之前仔細閱讀這些內容。因為最終，我可能要維護那段代碼。
就在昨晚，我遇到一個 bug。代碼看上去沒問題，但功能無法正常工作。我多次請模型去排查，它也不斷修改，但依舊沒解決核心問題。今晚我得親自上手調試。如果我當初沒認真讀懂那段代碼，現在就像被扔進叢林一樣無所適從。
主持人：
是啊，這就是專業工程師和“只會提示詞工程師”的區別。任何人都能輸入提示，但不是每個人都能理解系統、修復問題、解釋原理。在任何行業中，真正的專業人士都是懂原理的人。否則，如果你完全不知道代碼如何運行，那公司為什么還需要你？Addy Osmani:
沒錯。隨著 Claude Code、Gemini CLI、Open Code 等終端工具興起，大家又開始討論“多智能體并行”——讓多個 AI 同時協作完成任務。
表面聽起來很酷，但現實是：如果缺乏人工審查，你只是在加速技術債的累積。短期內或許沒事，但遲早要還。這也讓我提出了一個觀點：我稱之為“70%問題”（the 70% problem）。
AI只能做到70%，剩下30%得靠你自己
主持人：
能不能請你先解釋一下：什么是“70%問題”？你是怎么發現這個現象的？自從六個月前你寫那篇介紹文章以來，它有沒有什么變化？Addy Osmani:
當然。模型質量和工具的質量都在不斷提升。但所謂“70%問題”，其實說的是這樣一個現象：大語言模型通常能在極短時間內生成一個大約70%可用的應用程序雛形，但它們往往在最后30%的環節上卡殼。
那最后的30%，可以理解為“最后一公里問題”。它包含很多開發者都會遇到的情況，比如我常說的“兩步退回模式”：你可能用幾個提示詞讓AI逐步搭建出某個功能，但你再給它一個新指令時，它突然“跑偏”，可能整個UI被重寫了，或者組件的邏輯被徹底改動。
這其中隱藏著很多可維護性成本和責任模糊地帶——當你不夠具體，把決策權交還給模型時，你往往會遇到收益遞減。這在 Hacker News 上屢見不鮮：各種安全漏洞、API密鑰泄露、XSS攻擊……這些問題很多都出現在開發者只顧著“有感覺地寫代碼（go with the vibes）”，而沒有系統性地思考整個問題的時候。所以說，“憑感覺寫出來”的原型，用在MVP或者原型階段沒問題，但一旦要落地進團隊代碼庫、面向真實用戶，它就必須重寫——要用生產級的質量標準去構建。安全性與質量問題都在提醒我們：無論AI多強，人類都必須保持在環（human-in-the-loop）。
主持人：
是的，我們現在經常聽到這樣的故事：產品經理或者非技術型創始人，靠AI做出了一個原型，很興奮，覺得很快就能上線，但最后要么卡住，要么進度被拖得極長。他們原本以為“一兩天能搞定”，結果變成“十天、二十天甚至三十天”。
你在“70%問題”那篇文章里還提到，經驗豐富的工程師能比較容易地完成那最后30%，但經驗不足的工程師反而會陷入困境，甚至會被AI帶來一種“虛假的自信感”。
Addy Osmani:
完全正確。那最后30%的部分，很多初級工程師、新人、實習生都會表現得很掙扎。他們通常只會一遍又一遍地讓模型“再試試”“修一下”，但當AI無法修復問題時，他們可能就無從下手了——缺乏調試、分析、定位問題的能力。
這其實說明，批判性思維和系統性問題解決能力仍然是計算機科學最核心的素養。任何人都可以用高層次的prompt讓AI輸出看似能跑的代碼，但那不代表可以信任它上生產。我們已經看到太多案例，一開始看起來沒問題，后來徹底崩潰。
主持人：這讓我想起AI工具出現之前的一個故事。當年我在Uber帶一個新人，他來自一個小型創業公司。入職一周后我問他感覺怎么樣，他非常焦慮地說：“太難了，我正在讀整個代碼庫。”我驚呆了：“你要讀Uber全部后端代碼？那可是幾百萬行啊！”他說：“我每換一家公司都會把代碼全讀一遍，這樣我能理解所有東西。”我其實很佩服他的出發點——想從根本上理解系統。但我告訴他：“你不用讀完所有代碼，你只需要理解結構、知道東西在哪里。”這讓我想到，如果你把這種理解能力外包給AI，那你最終就會被AI“反綁架”。當模型上下文窗口裝滿，或者那天模型“狀態不對”，你就會陷入困境。你唯一的選擇可能就是換模型、清空上下文，或者干脆重啟。但那種狀態讓人感覺自己根本不再掌控局面。
Addy Osmani:
沒錯，你說得非常準確。無論你是資深工程師還是Vibe Coder，都應該記住幾件事，這些能幫你保持掌控感。
如何與自動化Agents協作
主持人：你剛才提到“保持最佳結果”，這讓我想到一個很現實的問題：AI和Vibe Coding確實能極大地提高開發速度，你能更快地上線功能。但“速度”不等于“精度”——你可能只是更快地做錯事。你怎么知道自己做的東西真的有效？這個功能是否提升了轉化率？是否幫助留存？沒有精確的度量，你就像在盲目決策。
Addy Osmani:
沒錯。要想高效使用AI，你必須理解模型的限制，比如它的上下文窗口是有限的。這意味著你需要像項目經理一樣思考：把任務拆解成小的、可驗證的塊；保持需求清晰，反復迭代；不要妄想“一發入魂”能出完美結果。
這種分解思維其實很像寫偽代碼、規劃Sprint。它能避免上下文丟失和錯誤累積。
其實，很多傳統的軟件工程最佳實踐依然永不過時。比如：寫模塊化、可測試的代碼；嚴格執行Code Review；明確輸入輸出約束；給模型足夠上下文。
AI能幫你提速，但人類的審慎仍然是系統成功的關鍵。越是把責任交給AI，你出錯的風險就越高。
主持人：我聽到一位工程師（Flask作者 Armin Ronacher）說過一個很有趣的觀察。他說：那些對自己工作掌控感強、信心足的工程師，往往在AI協作中表現更好；反而是那些被任務推動、缺乏掌控感的人，對AI的到來更焦慮。
這其實讓我想到我們聊到的主題——你一直強調：保持主導、理解系統、對工具有信心。只要你知道自己可以不用AI也能搞定，只是速度慢一點，那AI就會變成一個強力助推器，而不是依賴。
Addy Osmani:
完全同意。AI只是工具箱里的一件新工具。軟件工程一直在演化，每一代都讓開發體驗更好一些。
我記得當年剛能下載網頁模板的時候，我興奮得不行——“哇，別人已經寫好了，我只要改一改就能用！”后來有了更強的命令行工具、腳手架系統，我們不再為“從哪里開始”而煩惱。
AI現在就像是又一次升級：它讓我們更容易“起步”，但仍然需要你理解你在向用戶交付什么。AI不是用來取代責任的。
過去兩年，我經常提醒自己要回到工程第一性原理。我最近在和Google DeepMind團隊合作Gemini的編程能力，這讓我重新思考：這些模型背后的訓練數據是什么？
大多數訓練數據都來自GitHub等開源代碼，許多是“夠用但不完美”的公共代碼。這些代碼的模式往往只是“能跑”，但未必最安全、最高效、最易維護。
所以，當你記住這一點后，你的期望自然會調整：AI確實比“復制粘貼 Stack Overflow 答案”強，但它輸出的代碼仍然需要人工審查與打磨，才能達到生產級。
主持人：這讓我想起10年前大家都用Stack Overflow的時代。比如要驗證郵箱格式，我們會搜“email validation regex”，然后直接復制點贊最高的答案。
那時候確實方便，但后來我們才發現——很多答案其實不安全，或漏了邊界情況。我覺得現在AI生成代碼也是類似的，只是規模更大。
Addy Osmani:
完全正確。現在我常聽到人問：“既然AI能寫代碼，我還需要第三方庫嗎？”這就像當年復制粘貼Stack Overflow答案。但資深工程師會立刻想到：那維護責任誰來承擔？
如果你手寫功能，就得負責安全修復、平臺兼容、未來更新。而使用庫，則可以共享修復。這就是權衡（trade-off）的本質。
主持人：說到底，這就是工程：取舍。你要么承擔維護風險，要么依賴外部組件，每個選擇都有代價。
產品經理和工程經理的角色變化
主持人：
那你覺得現在AI帶來的新工作流里，有哪些是以前的軟件工程根本做不到的？
Addy Osmani:
我覺得最令人興奮的是“異步后臺AI代理（asynchronous background coding agents）”。比如讓AI在后臺幫你改測試、遷移依賴庫、加暗黑模式。如果能做到無沖突合并、可驗證結果，那將非常強大。
但真正的挑戰在于：當你同時指揮多個AI代理（像一個樂隊指揮），什么是合理的控制界面？人類注意力是有限的，即使我能同時開20個終端跑不同模型，真正能高質量review的任務量其實很少。所以要像管理Sprint那樣，保持聚焦。
另一個趨勢是“Vibe Designing”——設計師也在進入AI驅動的協作模式比如Figma、Shopify都在探索讓設計師用AI生成交互原型，再交給工程師進行“生產化（productionize）”。
主持人：我聽說Shopify有個團隊，所有設計師都在用Cursor。他們先做出Figma設計，然后用Cursor讓AI生成可運行的原型，再拿給工程師討論。不是直接上線，但相比靜態設計圖，這是一次巨大的協作升級。
Addy Osmani:
我也很佩服Shopify團隊，他們的實踐說明AI協作是可行的。當然，仍需要清晰的邊界：什么是原型，什么是生產代碼。但能把靜態視覺稿變成半功能原型，已經是革命性的進步。
我覺得接下來變化最大的角色，會是產品經理（PM）和工程經理（EM）：PM要花更多時間在問題定義、指標和AI策略上；EM要在評估、安全和AI治理上花更多心思。AI不會改變他們的“結果責任”，但會讓“品味”成為新的競爭力。因為當每個人都能用prompt實現同樣的功能時，真正的差異在于：誰能做出更有品味、更有判斷的產品。AI會讓“新手更快上手”，同時也會讓“高手更有杠桿”。能寫spec、拆任務、懂架構、會審查的高級工程師，價值只會越來越高。整體來看，我對AI在工程領域的未來謹慎樂觀。樂觀的是工具進步很快；謹慎的是，人類監督仍然是核心。
“三人編程”的協作模式可能會出現
主持人：現在我回想最優秀的資深工程師——他們的一天其實很像“多智能體協作”：他們帶幾個中級開發者、幾個實習生，不斷在 Slack 上被@：“請幫我解個 bug”“能幫我審下代碼嗎？”他們來回切換上下文、做評審、提建議、安排工作、開會指導。某種意義上說，高級工程師早就在做“智能體編排”這件事了。所以如果問我：未來誰最適合管理多個AI代理？毫無疑問，是資深開發者。新手當然也能用AI，但缺少經驗，很難駕馭這種多線程協作。資深開發者之所以能做到，是因為他們理解代碼庫，知道“好代碼”長什么樣，而且他們在評審中非常嚴格。
Addy Osmani:
我完全同意你的看法。而且我認為，開發者教育與團隊培養方式也必須隨之進化。
我記得當年剛入行時，大家強調“結對編程”。而未來，也許我們會看到“三人編程”——由一個新手、一個資深開發者，加上一個AI組成。
資深開發者可能會要求新人解釋AI生成的代碼，或引導他們理解代碼如何與系統其他部分聯動。AI 會成為幫助新人建立自信、理解全局的“教學助理”。
我們也開始看到一些有趣的討論，比如團隊角色可能會進一步細化或重新定義。像“前線部署工程師（forward-deployed engineer）”這樣的角色正在重新受到關注，他們通常更接近產品或用戶場景，可能會成為未來“AI輔助開發協作”的關鍵橋梁。
未來教育體系也會隨之調整：高中、大學是否會教授“Prompt 工程”“上下文工程”的最佳實踐？我們是否還能保持“系統設計思維”？這些問題都值得期待。
