AI輔助編碼將如何改變軟件工程：更需要經驗豐富的工程師

作者丨 Gergely Orosz & Addy Osmani

譯者丨明知山

策劃丨褚杏娟

可以肯定的是，生成式 AI 將繼續改變我們開發軟件的方式。

回顧 2022 年 11 月，ChatGPT 首次問世，這是大語言模型（LLM）開始被廣泛運用的開端。儘管 LLM 的構建方式出人意料地簡單，但它們在各個領域都取得了令人印象深刻的結果。編寫代碼無疑是它們的強項之一。這並不令人感到驚訝，因為：

編程語言的語法比任何一門人類語言都要簡單得多。
這些 LLM 有大量的高質量訓練數據可用，也就是那些有效的源代碼，這得益於開源軟件以及對 GitHub 和其他免費訪問的代碼倉庫的爬取（儘管這種爬取和訓練行為存在道德爭議，但此類行為仍在持續發生）。

去年，我們的 AI 工具使用情況調查發現，大約 75% 的開發者使用某種 AI 工具進行與軟件工程相關的工作。然而，我們似乎仍處於工具創新週期的早期階段，而更複雜的方法，如軟件工程 AI 智能體，很可能成為 2025 年創新的核心。

主流媒體對軟件工程行業的描繪越來越戲劇化。3 月份，Business Insider 報導了「軟件工程師越來越接近 AI 是否會讓他們失業的真相」；9 月份，福布斯拋出疑問：「軟件工程師是否正在變得過時？」儘管這類文章廣為傳播，但它們多出自非軟件工程師之手，這些作者既不使用 AI 工具，也不瞭解這些新型 GenAI 編碼工具的效率（以及局限性）。

那麼我們能從 GenAI 工具重塑軟件工程這件事情中期待些什麼呢？GenAI 將改變軟件工程的某些部分，但不太可能像一些之前的新聞所暗示的那樣發生戲劇性的變革。在使用這些工具兩年後，大多數工程團隊使用它們的時間也已超過 12 個月，我們能夠對它們形成更準確的判斷。

Addy Osmani 是一名軟件工程師和技術負責人，處於觀察 GenAI 工具如何重塑軟件工程的絕佳位置。他在Google工作了 12 年，目前擔任 Chrome 開發者體驗負責人。Google作為 GenAI 創新的前沿企業，在 2017 年發表了關於 Transformer 架構的論文，為 LLM 奠定了基礎。如今，Google構建了最先進的基礎模型之一——Gemini 2.0，並且是 OpenAI 的最大競爭對手之一。

Addy 在他的文章《70% 問題：AI 輔助編碼的嚴峻真相》中總結了他的觀察和預測。文章對 AI 工具的優勢和劣勢進行了務實的剖析，即強調了這些工具的根本局限性，也指出了工程師們不容忽視的積極方面。它還為各個級別的軟件工程師提供了如何充分利用這些工具的實用建議。經 Addy 授權，本文對他的文章進行了編輯，並在文末加入了很多我的想法，內容包括：

開發者現實中如何使用 AI。「加速器」與「迭代器」有著截然不同的使用方式，這或許也是為何一種工具不太可能對這兩類人群都同樣有效的原因？
70% 問題：AI 的學習曲線悖論。一些較少被提及的 AI 挑戰，包括「兩步後退悖論」、「AI 速度」的隱藏成本以及「知識悖論」。
真正有效的實用模式。AI 優先草案、持續對話以及「信任加驗證」模式。
這對開發者意味著什麼？從小處著手，保持模塊化，相信自己的經驗。
智能體式軟件工程的興起。與 AI 協作的轉變、多模態能力、自主加指導方法以及「英語優先」的開發環境。
軟件作為工藝的回歸？拋光藝術的複興以及個人軟件的複興。
額外的想法。現在是時候重新審視軟件工程的本質以及 20 世紀 60 年代以來的無開發者軟件工程的夢想。另外，未來對經驗豐富的工程師的需求可能會增加，而不是減少。

以下是對 Addy 文章的編輯版本。

在過去的幾年里，我一直深入參與 AI 輔助開發領域，併發現了一個很有趣的現象。儘管工程師們紛紛反饋，有了 AI 的幫助，他們的工作效率大幅提升，但我們日常所使用的軟件在品質方面似乎並沒有明顯變得更好。這是怎麼回事呢？

我想我知道原因，而這個答案揭示了一些關於軟件開發的基本事實，這些是我們需要正視的。讓我來分享一下我的發現。

我注意到在利用 AI 工具進行開發的團隊中存在著兩種截然不同的模式。我們可以把它們叫作「加速器」和「迭代器」模式。這兩種模式都在幫助工程師（甚至非技術用戶）有效縮短從構思到付諸實踐（或最小可行產品）這一過程的距離。

開發者在現實中如何使用 AI

加速器：從零到最小可行產品

像 Bolt、v0 和截圖轉代碼這類工具正在徹底改變我們啟動新項目的方式。這些團隊通常：

從一個設計或初步概念開始
利用 AI 生成一個完整的初始代碼庫
在幾小時或幾天（而不是幾週）內得到一個可運行的原型
專注於快速驗證和迭代

其成果可能令人印象深刻。我最近看到一位獨立開發者使用 Bolt 將一個 Figma 設計幾乎在瞬間變成一個可運行的 Web 應用程序。雖然它還沒有達到生產就緒的水平，但已經足夠好，可以獲取非常初步的用戶反饋了。

迭代器：日常開發

第二類團隊使用像 Cursor、Cline、Copilot 和 WindSurf 這樣的工具來推進日常開發流程。這可能沒有那麼引人注目，但潛在的變革性可能更大。這些開發者：

利用 AI 進行代碼補全和建議
借助 AI 完成複雜的重構任務
生成測試和文檔
將 AI 作為「結對編程」夥伴來解決問題

但這裏有一個問題：儘管這兩種方法都能極大地加速開發，但它們都伴隨著一些隱藏的成本，這些成本並不會立即顯現出來。

70% 問題：AI 的學習曲線悖論

之前一條推文引起了我的注意，它完美地描繪了我所觀察到的一個現象：非工程師在使用 AI 工具進行編碼時，往往會撞上一堵令人沮喪的牆。他們能在出人意料的短時間內完成 70% 的工作，但剩下的 30% 卻變成了一場收益遞減的艱難跋涉。

「70% 問題」揭示了當前 AI 輔助開髮狀態的一個關鍵事實。最開始的進展感覺就像魔法一樣：你可以描述你想要的東西，AI 工具會生成一個看起來令人印象深刻的可運行原型，但隨後現實的問題接踵而至。

後退兩步模式

接下來發生的情況，通常會遵循一個可預測的模式：

你嘗試修復一個小問題
AI 提供一個看似合理的修復建議
這個修復導致了新問題
你讓 AI 修復新問題
這又導致了兩個新問題
如此循環往複

對於非工程師來說，這個循環尤其痛苦，因為他們缺少理解問題根源的認知框架。當一位經驗豐富的開發者遇到問題時，他們可以根據多年積累的模式識別經驗來推理潛在的原因和解決方案。沒有這樣的背景，你基本上就是在玩打地鼠遊戲，與你並不完全理解的代碼作鬥爭。

「AI 加速」的隱藏成本

當你看著資深工程師使用像 Cursor 或 Copilot 這樣的 AI 工具時，就像魔法一樣。他們可以在幾分鐘內構建好整個功能，包括測試和文檔。但如果仔細觀察，你會注意到一個關鍵點：他們並非一味照搬人工智能的建議，而是持續不斷地：

將生成的代碼重構為更小的模塊
添加 AI 遺漏的邊緣情況處理代碼
增強類型定義和接口
質疑架構決策
添加全面的錯誤處理

換句話說，他們運用多年積累的工程經驗來重塑和約束 AI 的輸出。AI 加快了實現過程，但他們的專業知識才是保持代碼可維護性的關鍵。

初級工程師往往會忽略這些關鍵步驟。他們更容易直接接受 AI 的輸出，從而導致我所說的「紙牌屋代碼」——看起來完整，但在現實世界的壓力下不堪一擊。

知識差距

我見過的最成功的使用 AI 編碼工具的非工程師採取了一種混合方法：

使用 AI 進行快速原型設計
花時間理解 AI 生成的代碼
在使用 AI 的同時學習基本的編程概念
逐步積累知識基礎
將 AI 作為學習工具，而不僅僅是代碼生成器

但這需要耐性和奉獻精神，恰恰與許多人使用 AI 工具所期望達到的目的背道而馳。

知識悖論

這是我發現的最反直覺的一件事情：AI 工具對經驗豐富的開發者幫助更大，而不是初學者。這似乎反過來了。難道 AI 不應該使編碼變得民主化嗎？

現實情況是，AI 就像團隊中的一個非常熱心的初級開發者。他們可以快速編寫代碼，但需要不斷的監督和糾正。你瞭解得越多，就越能更好地指導它們。

這就產生了我所說的「知識悖論」：

資深人員使用 AI 來加速他們已經知道如何做的事情
初級人員試圖使用 AI 來學習該做什麼
結果大相逕庭

我看到資深工程師使用 AI 來：

快速原型化他們已經理解的想法
生成他們可以進一步提煉的基本實現
探索已知問題的替代解決方案
自動化常規編碼任務

與此同時，初級人員常常：

接受錯誤或過時的解決方案
忽略關鍵的安全和性能考量
難以調試 AI 生成的代碼
構建他們並不完全理解的脆弱的系統

這裏存在一個更深層次的問題：AI 編碼工具對非工程師來說容易上手，它們能夠為你處理複雜性，但實際上可能會阻礙學習。當你不理解 AI 生成的代碼的原理時：

你無法提高調試技能
你錯過了學習基本模式的機會
你無法推理架構決策
你難以維護和改進代碼

這就產生了一種依賴，你需要不斷讓 AI 解決問題，而不是自己培養和積累處理這些問題所需的專業知識。

對未來的影響

這個「70% 問題」表明，我們目前最好是將 AI 編碼工具視為：

經驗豐富的開發者的原型加速器
那些希望理解開發原理的人的學習輔助工具
快速驗證想法的最小可行產品生成器

但它們還不是許多人所期望的編碼民主化解決方案。實現軟件生產就緒水平、可維護性和健壯性的最後 30% 工作，仍然需要真正的工程知識。

好消息是，隨著工具的改進，這一差距很可能會縮小。但就目前而言，最務實的方法是利用 AI 來加速學習，而不是完全取代學習。

真正有效的模式

在觀察了數十個團隊之後，我發現以下這些方法始終行之有效：

「AI 初稿」模式

讓 AI 生成基本的實現
手動評審並重構，增強模塊化
添加全面的錯誤處理
編寫詳盡的測試
記錄關鍵決策

「持續對話」模式

為每個不同的任務開啟新的 AI 對話
保持上下文專注和精簡
頻繁評審和提交變更
保持緊密的反饋循環

「信任加驗證」模式

使用 AI 生成初始代碼
手動評審所有關鍵路徑
對邊緣情況進行自動化測試
定期進行安全評審

這對開發者來說意味著什麼？

儘管面臨這些挑戰，我對 AI 在軟件開發中的作用持樂觀態度。關鍵在於理解它真正擅長什麼：

加速構建已知的東西。AI 在幫助我們實現已經理解的模式方面表現出色，它就像一極具耐性且打字速度極快的配對程序員。
探索可能性。AI 非常適合用於進行快速原型設計和探索各種方法。它就像一個沙盒，讓我們能夠快速驗證概念。
自動化常規任務。AI 大幅減少了在樣板代碼和常規編碼任務上耗費的時間，讓我們能夠專注在有趣的問題上面。

如果你剛開始使用 AI 進行輔助開發，可以看看我的建議：

從小處著手

使用 AI 處理獨立且明確定義的任務
評審生成的每一行代碼
逐步構建大型功能

保持模塊化

將所有東西分解成小而專注的文件
維護好組件之間的接口
記錄模塊的邊界

相信你的經驗

使用 AI 來加速，而不是取代你的判斷
對感覺不對的生成代碼提出質疑
保持工程技術標準

軟件工程智能體的興起

隨著 2025 年的到來，AI 輔助開發的格局正在發生巨大變化。儘管當前的工具已經改變了我們的原型設計和迭代方式，但我認為我們正處於一場更重大變革的邊緣：軟件工程智能體的興起。

我所說的「智能體」是什麼？這些系統不只是簡單地對提示詞做出響應，而是能夠以越來越自主的方式去規劃、執行和迭代解決方案。

我們已經看到了這種進化的初步跡象：

從響應到協作

目前的大多數工具只是在等待我們的指令，但看看 Claude Anthropic 對計算機的使用，或 Cline 自動啟動瀏覽器並運行測試的新功能，它們不僅僅是高級的自動補全，它們實際上是在理解任務並主動解決問題。

對於調試，這些智能體不僅僅是建議修復，它們還可以：

主動識別潛在問題
啟動並執行測試
檢查 UI 元素並截取屏幕截圖
提出建議並進行修復
驗證解決方案是否有效

多模態的未來

下一代工具可能不僅僅處理代碼，還可能無縫集成：

視覺理解（UI 截圖、草圖、圖表）
口頭對話
環境交互（瀏覽器、終端、API）

這種多模態能力意味著它們可以像人類一樣全面地理解和使用軟件，而不僅限於代碼層面。

自主加指導

我從使用這些工具中獲得的關鍵見解是，AI 在未來並不是要取代開發者，而是成為一個越來越有能力的協作者，它可以在接受人類指導和專業知識的基礎上主動採取行動。

2025 年最高效的團隊可能是那些學會：

為 AI 智能體設定清晰的邊界和指導
建立強大的架構模式，讓智能體能夠在其中高效工作
在人類和 AI 能力之間創建有效的反饋循環
在利用 AI 自主性的同時保持人類的監督

英語優先的開發環境

正如 Andrej Karpathy 所說的：

「最熱門的新式編程語言是英語。」

這是我們在與開發工具交互方式上的一次根本性轉變。清晰的思考和用自然語言進行精確溝通的能力正變得和傳統編程技能一樣重要。

這種向智能體輔助開發的轉變要求我們提升技能：

更強的系統設計和架構思維
更好的需求規範和溝通
更多關注質量保證和驗證
增強人類和 AI 能力之間的協作

軟件工藝的回歸？

儘管 AI 讓快速構建軟件變得前所未有地容易，但我們卻面臨著失去一些至關重要的東西的風險：創造真正精緻、具有消費者品質體驗的藝術。

演示品的陷阱

這正逐漸形成一種模式：團隊利用 AI 迅速構建令人印象深刻的演示品，理想路徑運行得非常完美，投資者和社交網絡都為之驚歎，但當真正的用戶開始點擊操作時，問題便開始浮現。

我親眼目睹了這種情況：

錯誤信息讓普通用戶完全看不懂
邊緣情況導致應用程序崩潰
混亂的用戶界面
完全忽視了可訪問性
在較慢的設備上存在性能問題

這些不只是 P2 級別的小問題，而是人們勉強湊合使用的軟件和真心熱愛的軟件之間的關鍵分水嶺。

遺失的打磨藝術

打造真正意義上的自助式軟件，即那種用戶無需與客服聯繫的軟件，需要一種全新的思維方式：

對錯誤信息的精心設計
在慢網絡連接條件下進行測試
優雅地處理每一個邊緣情況
使功能易於發現
讓真正的、非技術用戶參與測試

這種對細節的關注或許無法由 AI 生成，它源於同理心、經驗以及對工藝的深切關懷。

個人軟件的複興

我相信我們將迎來個人軟件開發的複興。隨著市場充斥著 AI 生成的最小可行性產品，那些能夠脫穎而出的將是那些由以下開發者構建的產品：

對自己的工藝感到自豪
關注小細節
專注於完整的用戶體驗
考慮到各種邊緣情況
創造真正自助式的體驗

頗具諷刺意味的是，AI 工具實際上可能促成這一複興。AI 可以處理常規的編碼任務，讓開發者能夠專注於最重要的事情：打造真正服務於用戶並令用戶滿意的軟件。

底線

AI 並沒有讓我們的軟件明顯變得更好，因為軟件質量並非主要受限於編碼速度。軟件開發中真正困難的部分——理解需求、設計可維護的系統、處理邊緣情況、確保安全性和性能——仍然需要人類的判斷。

AI 讓我們能夠更快速地迭代和實驗，這種更快速的探索可能會帶來更好的解決方案。但這隻有在我們保持工程紀律並將 AI 當作工具而非良好的軟件實踐的替代品時才會實現。記住：我們的目標並不是更快地編寫更多代碼，而是構建更好的軟件。明智地運用 AI 可以幫助我們達成這一目標，但歸根結底仍然需要我們自己去明確「更好」所代表的含義以及如何將其付諸實踐。

我的額外想法

以下是我對 AI 和軟件工程的一些額外的想法。

關於 AI 工具在軟件工程中的應用，大部分都集中在代碼生成能力上，這是有道理的。AI 工具在根據提示詞生成可運行的代碼或在構建軟件時提供代碼建議方面確實令人印象深刻，但在構建軟件的過程中，編碼環節究竟佔多大比例呢？大約 50 年前，Fred Brooks 認為編碼約佔總時間的 15% 至 20%。以下是 Brooks 在《人月神話》中描述的觀點：

「多年來，我一直運用以下的經驗法則來合理安排軟件開發任務的時間，並取得了顯著的效果：三分之一用於規劃六分之一用於編碼四分之一用於組件測試和早期的系統測試四分之一用於系統測試，此時所有組件均已就緒。」

在我看來，如今的軟件工程師的時間分配可能是這樣的：

20% 用於規劃
40% 用於編碼（編寫代碼 + 編寫測試）
20% 用於代碼評審（評審他人的代碼）
20% 用於準備生產發佈 + 上線 + 上線期間的小修小補 + 監控 + 告警

當然，構建出色的軟件還涉及許多其他環節：

確定做什麼：弄清楚要構建什麼。這可能涉及頭腦風暴、設計、用戶測試、與產品經理和業務利益相關者合作等。對於初創公司，這一階段可能耗時很少（「先構建出來看看效果如何！」）。而對於成熟的公司，這一階段可能比構建本身耗時更多（「我們需要確保構建的東西不會讓現有客戶感到困惑！」）。
確定怎麼做：製定構建產品、功能、服務的計劃。考慮架構的影響、依賴關係、如何測試產品等。初創公司可能會跳過這一環節，團隊直接進入規劃階段。但對於擁有眾多服務和依賴關係的大型公司，跳過規劃環節最終會帶來麻煩。因此，大多數團隊都在使用設計文檔、RFC 或 ADR 等進行某種形式的規劃。
構建：實現功能或產品：編寫代碼，並確保能夠正常運行。
驗證：在部署到生產環境之前，再次檢查是否按預期運行。在上線風險較大時，這一點尤為重要。例如，向銀行應用程序推送回歸更新可能會對客戶和業務造成財務上的損失！
上線：合併變更並推送給客戶，有多種策略可用於將變更部署到生產環境，我們在「Shipping to production」一文中介紹了其中的幾種策略。
監控和待命：監測產品是否出現了問題，一旦出現故障，盡快解決，並確保類似的故障不再發生。我們在「Healthy oncall practices」和「Incident review and postmortem best practices」中探討了這些常見方法。
維護：聆聽客戶投訴和反饋，確定哪些錯誤需要修復，哪些功能需要優先處理，並弄清楚哪些反饋可以忽略。
遷移：如果產品發生重大變化，或者技術棧出現重大變化——比如引入新的框架——可能就需要進行遷移。

如今的 AI 工具可以在「構建」環節提供很大幫助，那麼問題來了：它們對於軟件工程的其他七個階段有多大用處呢？

無需開發者：20 世紀 60 年代以來的夢想

自 20 世紀 60 年代以來，非技術人員無需依賴軟件開發者就能創建可運行軟件一直是人們夢寐以求的目標。編碼本質上是將人們的需求（客戶、業務利益相關者、產品經理等）轉化為計算機能夠理解的內容。大語言模型為我們提供了一個更高層次的抽像，我們可以將英語轉化為代碼。然而，這種新的抽像並沒有改變軟件的構建方式和軟件的本質，即：

AI 工具沒有改變流程，但它們確實使部分編碼環節變得更加高效：

在技術發展的歷史長河中，一些創新曾承諾能夠讓業務人員繞過「技術」環節，直接用高級的提示詞獲得可運行的軟件：

20 世紀 60 年代：高級編程語言 COBOL，即「通用的商業語言」，其目標是讓沒有編程背景的業務人員也能夠使用它。
20 世紀 90 年代：Visual Basic。這是一種旨在降低學習曲線的編程語言，它還提供了一個可視化的編程環境，可以通過拖放創建表單。
2010 年代後期：無代碼。無代碼解決方案，如 Bubble，通過模板和可視編輯提供了一種構建軟件應用的方法。

一些 GenAI 編碼初創公司也有著相同的目標：讓任何人都能夠使用英語來構建軟件。過去已經一些成功的簡單用例。例如，無需任何編碼知識也能創建網站：非技術人員可以使用 Wix.com、Webflow、Ghost 或 WordPress 等視覺編輯器和服務來實現。

抽像層次越高，就越難以明確地說明軟件應該如何運行，無代碼解決方案已經遇到了這一限制。正如顧問首席技術官 Alex Hudson 在其文章「The no-code delusion」中所寫的：

「這些語法的發展通常會遇到表達問題：一旦它們簡化到易於快速掌握的程度，便難以在眾多場景中充分表達軟件的複雜功能和精細邏輯。反之，一些語言具備定義領域特定語言（DSL）的能力。然而，這些語言很少在廣大的開發社區中真正取得成功，主要是因為它們又使事情變得極其複雜。」

對於複雜的軟件，很難想像不需要軟件工程師參與規劃、構建和維護，而且 AI 工具越是降低非技術人員構建軟件的門檻，需要維護的軟件就越多。

AI 智能體：一個重大承諾，但也是 2025 年的一個巨大「未知數」

在大語言模型推出兩年後，我們中的許多人已經相當熟練地使用它們來增強編碼和軟件工程工作。它們非常適合用於原型設計、切換到不太熟悉的語言，以及那些可以驗證其正確性並指出幻覺或錯誤輸出的任務。

然而，AI 智能體還處於初級發展階段。大多數人都還沒有開始廣泛使用它們。目前只有一個普遍可用的智能體——Devin，每月收費 500 美元，用戶反饋褒貶不一。

大量的風投將湧入這一領域。我們將看到更多 AI 編碼智能體工具出現，其價格也肯定會隨之下降。GitHub Copilot 很可能在 2025 年讓 Copilot Workspace（一種智能體）變得普遍可用。我們還可能會看到一些初創公司的產品，如由 Stripe 前首席技術官 David Singleton 創立的初創公司（/dev/agents，https://sdsa.ai/）推出的產品。

AI 智能體在延遲和成本（計算結果花費的時間更長，多次運行提示詞，這些初創公司稱之為「思考」）與準確性（基於提示詞獲得更好的結果）之間做了權衡。關於這種延遲加成本的權衡會帶來多大的準確性提升，以及哪些用例會因此顯著提高生產力，仍有一些值得探討的問題。

對經驗豐富的軟件工程師的需求可能會增加

未來，對經驗豐富的軟件工程師的需求可能會比今天更大。我們看到的 AI 工具的共同特點是，經驗豐富的工程師可以更高效地使用這些工具，因為他們能夠更好地「瞄準」目標。當你知道什麼才是「出色的輸出」，你就可以更好地提供提示詞，當代碼生成出現錯誤時能夠及時停止，而且你知道何時停下來直接轉而修改源代碼。

我們將看到更多由這些 AI 工具生成的代碼，更多的人和企業開始構建自己的解決方案。當這些解決方案達到一定複雜度時，需要引入專業人士來應對這種複雜性：這種複雜性需要經驗豐富的工程師來處理。現有的科技公司幾乎肯定會使用 AI 工具生成更多的代碼：它們將依賴經驗豐富的工程師來應對隨之而來的複雜性。

作為一名軟件工程師，掌握 AI 輔助開發工具將使你更具生產力，也更有價值。現在正是投身這一領域的時刻：我們正處在一個工具創新加速的時代。我們確實需要花時間去弄清楚如何「馴服」現有的工具，實現自身生產力的最大化。所以，一定要去嘗試使用它們！

原文鏈接：

https://newsletter.pragmaticengineer.com/p/how-ai-will-change-software-engineering

聲明：本文由 InfoQ 翻譯，未經許可禁止轉載。