作者丨 Gergely Orosz & Addy Osmani

譯者丨明知山

策劃丨褚杏娟

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

回顧 2022 年 11 月，ChatGPT 首次問世，這是大語言模型（LLM）開始被廣泛運(yùn)用的開端。盡管 LLM 的構(gòu)建方式出人意料地簡(jiǎn)單，但它們?cè)诟鱾€(gè)領(lǐng)域都取得了令人印象深刻的結(jié)果。編寫代碼無疑是它們的強(qiáng)項(xiàng)之一。這并不令人感到驚訝，因?yàn)椋?/p>

• 編程語言的語法比任何一門人類語言都要簡(jiǎn)單得多。

• 這些 LLM 有大量的高質(zhì)量訓(xùn)練數(shù)據(jù)可用，也就是那些有效的源代碼，這得益于開源軟件以及對(duì) GitHub 和其他免費(fèi)訪問的代碼倉(cāng)庫(kù)的爬取（盡管這種爬取和訓(xùn)練行為存在道德爭(zhēng)議，但此類行為仍在持續(xù)發(fā)生）。

去年，我們的 AI 工具使用情況調(diào)查發(fā)現(xiàn)，大約 75% 的開發(fā)者使用某種 AI 工具進(jìn)行與軟件工程相關(guān)的工作。然而，我們似乎仍處于工具創(chuàng)新周期的早期階段，而更復(fù)雜的方法，如軟件工程 AI 智能體，很可能成為 2025 年創(chuàng)新的核心。

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

那么我們能從 GenAI 工具重塑軟件工程這件事情中期待些什么呢？GenAI 將改變軟件工程的某些部分，但不太可能像一些之前的新聞所暗示的那樣發(fā)生戲劇性的變革。在使用這些工具兩年后，大多數(shù)工程團(tuán)隊(duì)使用它們的時(shí)間也已超過 12 個(gè)月，我們能夠?qū)λ鼈冃纬筛鼫?zhǔn)確的判斷。

Addy Osmani 是一名軟件工程師和技術(shù)負(fù)責(zé)人，處于觀察 GenAI 工具如何重塑軟件工程的絕佳位置。他在谷歌工作了 12 年，目前擔(dān)任 Chrome 開發(fā)者體驗(yàn)負(fù)責(zé)人。谷歌作為 GenAI 創(chuàng)新的前沿企業(yè)，在 2017 年發(fā)表了關(guān)于 Transformer 架構(gòu)的論文，為 LLM 奠定了基礎(chǔ)。如今，谷歌構(gòu)建了最先進(jìn)的基礎(chǔ)模型之一——Gemini 2.0，并且是 OpenAI 的最大競(jìng)爭(zhēng)對(duì)手之一。

Addy 在他的文章 《70% 問題：AI 輔助編碼的嚴(yán)峻真相》 中總結(jié)了他的觀察和預(yù)測(cè)。文章對(duì) AI 工具的優(yōu)勢(shì)和劣勢(shì)進(jìn)行了務(wù)實(shí)的剖析，即強(qiáng)調(diào)了這些工具的根本局限性，也指出了工程師們不容忽視的積極方面。它還為各個(gè)級(jí)別的軟件工程師提供了如何充分利用這些工具的實(shí)用建議。經(jīng) Addy 授權(quán)，本文對(duì)他的文章進(jìn)行了編輯，并在文末加入了很多我的想法，內(nèi)容包括：

1. 開發(fā)者現(xiàn)實(shí)中如何使用 AI。“加速器”與“迭代器”有著截然不同的使用方式，這或許也是為何一種工具不太可能對(duì)這兩類人群都同樣有效的原因？

2. 70% 問題：AI 的學(xué)習(xí)曲線悖論。一些較少被提及的 AI 挑戰(zhàn)，包括“兩步后退悖論”、“AI 速度”的隱藏成本以及“知識(shí)悖論”。

3. 真正有效的實(shí)用模式。AI 優(yōu)先草案、持續(xù)對(duì)話以及“信任加驗(yàn)證”模式。

4. 這對(duì)開發(fā)者意味著什么？從小處著手，保持模塊化，相信自己的經(jīng)驗(yàn)。

5. 智能體式軟件工程的興起。與 AI 協(xié)作的轉(zhuǎn)變、多模態(tài)能力、自主加指導(dǎo)方法以及“英語優(yōu)先”的開發(fā)環(huán)境。

6. 軟件作為工藝的回歸？拋光藝術(shù)的復(fù)興以及個(gè)人軟件的復(fù)興。

7. 額外的想法。現(xiàn)在是時(shí)候重新審視軟件工程的本質(zhì)以及 20 世紀(jì) 60 年代以來的無開發(fā)者軟件工程的夢(mèng)想。另外，未來對(duì)經(jīng)驗(yàn)豐富的工程師的需求可能會(huì)增加，而不是減少。

以下是對(duì) Addy 文章的編輯版本。

在過去的幾年里，我一直深入?yún)⑴c AI 輔助開發(fā)領(lǐng)域，并發(fā)現(xiàn)了一個(gè)很有趣的現(xiàn)象。盡管工程師們紛紛反饋，有了 AI 的幫助，他們的工作效率大幅提升，但我們?nèi)粘Ｋ褂玫能浖谄焚|(zhì)方面似乎并沒有明顯變得更好。這是怎么回事呢？

我想我知道原因，而這個(gè)答案揭示了一些關(guān)于軟件開發(fā)的基本事實(shí)，這些是我們需要正視的。讓我來分享一下我的發(fā)現(xiàn)。

我注意到在利用 AI 工具進(jìn)行開發(fā)的團(tuán)隊(duì)中存在著兩種截然不同的模式。我們可以把它們叫作“加速器”和“迭代器”模式。這兩種模式都在幫助工程師（甚至非技術(shù)用戶）有效縮短從構(gòu)思到付諸實(shí)踐（或最小可行產(chǎn)品）這一過程的距離。

開發(fā)者在現(xiàn)實(shí)中如何使用 AI

加速器：從零到最小可行產(chǎn)品

像 Bolt、v0 和截圖轉(zhuǎn)代碼這類工具正在徹底改變我們啟動(dòng)新項(xiàng)目的方式。這些團(tuán)隊(duì)通常：

• 從一個(gè)設(shè)計(jì)或初步概念開始

• 利用 AI 生成一個(gè)完整的初始代碼庫(kù)

• 在幾小時(shí)或幾天（而不是幾周）內(nèi)得到一個(gè)可運(yùn)行的原型

• 專注于快速驗(yàn)證和迭代

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

迭代器：日常開發(fā)

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

• 利用 AI 進(jìn)行代碼補(bǔ)全和建議

• 借助 AI 完成復(fù)雜的重構(gòu)任務(wù)

• 生成測(cè)試和文檔

• 將 AI 作為“結(jié)對(duì)編程”伙伴來解決問題

但這里有一個(gè)問題：盡管這兩種方法都能極大地加速開發(fā)，但它們都伴隨著一些隱藏的成本，這些成本并不會(huì)立即顯現(xiàn)出來。

70% 問題：AI 的學(xué)習(xí)曲線悖論

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

“70% 問題”揭示了當(dāng)前 AI 輔助開發(fā)狀態(tài)的一個(gè)關(guān)鍵事實(shí)。最開始的進(jìn)展感覺就像魔法一樣：你可以描述你想要的東西，AI 工具會(huì)生成一個(gè)看起來令人印象深刻的可運(yùn)行原型，但隨后現(xiàn)實(shí)的問題接踵而至。

后退兩步模式

接下來發(fā)生的情況，通常會(huì)遵循一個(gè)可預(yù)測(cè)的模式：

• 你嘗試修復(fù)一個(gè)小問題

• AI 提供一個(gè)看似合理的修復(fù)建議

• 這個(gè)修復(fù)導(dǎo)致了新問題

• 你讓 AI 修復(fù)新問題

• 這又導(dǎo)致了兩個(gè)新問題

• 如此循環(huán)往復(fù)

對(duì)于非工程師來說，這個(gè)循環(huán)尤其痛苦，因?yàn)樗麄內(nèi)鄙倮斫鈫栴}根源的認(rèn)知框架。當(dāng)一位經(jīng)驗(yàn)豐富的開發(fā)者遇到問題時(shí)，他們可以根據(jù)多年積累的模式識(shí)別經(jīng)驗(yàn)來推理潛在的原因和解決方案。沒有這樣的背景，你基本上就是在玩打地鼠游戲，與你并不完全理解的代碼作斗爭(zhēng)。

“AI 加速”的隱藏成本

當(dāng)你看著資深工程師使用像 Cursor 或 Copilot 這樣的 AI 工具時(shí)，就像魔法一樣。他們可以在幾分鐘內(nèi)構(gòu)建好整個(gè)功能，包括測(cè)試和文檔。但如果仔細(xì)觀察，你會(huì)注意到一個(gè)關(guān)鍵點(diǎn)：他們并非一味照搬人工智能的建議，而是持續(xù)不斷地：

• 將生成的代碼重構(gòu)為更小的模塊

• 添加 AI 遺漏的邊緣情況處理代碼

• 增強(qiáng)類型定義和接口

• 質(zhì)疑架構(gòu)決策

• 添加全面的錯(cuò)誤處理

換句話說，他們運(yùn)用多年積累的工程經(jīng)驗(yàn)來重塑和約束 AI 的輸出。AI 加快了實(shí)現(xiàn)過程，但他們的專業(yè)知識(shí)才是保持代碼可維護(hù)性的關(guān)鍵。

初級(jí)工程師往往會(huì)忽略這些關(guān)鍵步驟。他們更容易直接接受 AI 的輸出，從而導(dǎo)致我所說的“紙牌屋代碼”——看起來完整，但在現(xiàn)實(shí)世界的壓力下不堪一擊。

知識(shí)差距

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

• 使用 AI 進(jìn)行快速原型設(shè)計(jì)

• 花時(shí)間理解 AI 生成的代碼

• 在使用 AI 的同時(shí)學(xué)習(xí)基本的編程概念

• 逐步積累知識(shí)基礎(chǔ)

• 將 AI 作為學(xué)習(xí)工具，而不僅僅是代碼生成器

但這需要耐心和奉獻(xiàn)精神，恰恰與許多人使用 AI 工具所期望達(dá)到的目的背道而馳。

知識(shí)悖論

這是我發(fā)現(xiàn)的最反直覺的一件事情：AI 工具對(duì)經(jīng)驗(yàn)豐富的開發(fā)者幫助更大，而不是初學(xué)者。這似乎反過來了。難道 AI 不應(yīng)該使編碼變得民主化嗎？

現(xiàn)實(shí)情況是，AI 就像團(tuán)隊(duì)中的一個(gè)非常熱心的初級(jí)開發(fā)者。他們可以快速編寫代碼，但需要不斷的監(jiān)督和糾正。你了解得越多，就越能更好地指導(dǎo)它們。

這就產(chǎn)生了我所說的“知識(shí)悖論”：

• 資深人員使用 AI 來加速他們已經(jīng)知道如何做的事情

• 初級(jí)人員試圖使用 AI 來學(xué)習(xí)該做什么

• 結(jié)果大相徑庭

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

• 快速原型化他們已經(jīng)理解的想法

• 生成他們可以進(jìn)一步提煉的基本實(shí)現(xiàn)

• 探索已知問題的替代解決方案

• 自動(dòng)化常規(guī)編碼任務(wù)

與此同時(shí)，初級(jí)人員常常：

• 接受錯(cuò)誤或過時(shí)的解決方案

• 忽略關(guān)鍵的安全和性能考量

• 難以調(diào)試 AI 生成的代碼

• 構(gòu)建他們并不完全理解的脆弱的系統(tǒng)

這里存在一個(gè)更深層次的問題：AI 編碼工具對(duì)非工程師來說容易上手，它們能夠?yàn)槟闾幚韽?fù)雜性，但實(shí)際上可能會(huì)阻礙學(xué)習(xí)。當(dāng)你不理解 AI 生成的代碼的原理時(shí)：

• 你無法提高調(diào)試技能

• 你錯(cuò)過了學(xué)習(xí)基本模式的機(jī)會(huì)

• 你無法推理架構(gòu)決策

• 你難以維護(hù)和改進(jìn)代碼

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

對(duì)未來的影響

這個(gè)“70% 問題”表明，我們目前最好是將 AI 編碼工具視為：

• 經(jīng)驗(yàn)豐富的開發(fā)者的原型加速器

• 那些希望理解開發(fā)原理的人的學(xué)習(xí)輔助工具

• 快速驗(yàn)證想法的最小可行產(chǎn)品生成器

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

好消息是，隨著工具的改進(jìn)，這一差距很可能會(huì)縮小。但就目前而言，最務(wù)實(shí)的方法是利用 AI 來加速學(xué)習(xí)，而不是完全取代學(xué)習(xí)。

真正有效的模式

在觀察了數(shù)十個(gè)團(tuán)隊(duì)之后，我發(fā)現(xiàn)以下這些方法始終行之有效：

“AI 初稿”模式

• 讓 AI 生成基本的實(shí)現(xiàn)

• 手動(dòng)評(píng)審并重構(gòu)，增強(qiáng)模塊化

• 添加全面的錯(cuò)誤處理

• 編寫詳盡的測(cè)試

• 記錄關(guān)鍵決策

“持續(xù)對(duì)話”模式

• 為每個(gè)不同的任務(wù)開啟新的 AI 對(duì)話

• 保持上下文專注和精簡(jiǎn)

• 頻繁評(píng)審和提交變更

• 保持緊密的反饋循環(huán)

“信任加驗(yàn)證”模式

• 使用 AI 生成初始代碼

• 手動(dòng)評(píng)審所有關(guān)鍵路徑

• 對(duì)邊緣情況進(jìn)行自動(dòng)化測(cè)試

• 定期進(jìn)行安全評(píng)審

這對(duì)開發(fā)者來說意味著什么？

盡管面臨這些挑戰(zhàn)，我對(duì) AI 在軟件開發(fā)中的作用持樂觀態(tài)度。關(guān)鍵在于理解它真正擅長(zhǎng)什么：

• 加速構(gòu)建已知的東西。AI 在幫助我們實(shí)現(xiàn)已經(jīng)理解的模式方面表現(xiàn)出色，它就像一極具耐心且打字速度極快的配對(duì)程序員。

• 探索可能性。AI 非常適合用于進(jìn)行快速原型設(shè)計(jì)和探索各種方法。它就像一個(gè)沙盒，讓我們能夠快速驗(yàn)證概念。

• 自動(dòng)化常規(guī)任務(wù)。AI 大幅減少了在樣板代碼和常規(guī)編碼任務(wù)上耗費(fèi)的時(shí)間，讓我們能夠?qū)Ｗ⒃谟腥さ膯栴}上面。

如果你剛開始使用 AI 進(jìn)行輔助開發(fā)，可以看看我的建議：

從小處著手

• 使用 AI 處理獨(dú)立且明確定義的任務(wù)

• 評(píng)審生成的每一行代碼

• 逐步構(gòu)建大型功能

保持模塊化

• 將所有東西分解成小而專注的文件

• 維護(hù)好組件之間的接口

• 記錄模塊的邊界

相信你的經(jīng)驗(yàn)

• 使用 AI 來加速，而不是取代你的判斷

• 對(duì)感覺不對(duì)的生成代碼提出質(zhì)疑

• 保持工程技術(shù)標(biāo)準(zhǔn)

軟件工程智能體的興起

隨著 2025 年的到來，AI 輔助開發(fā)的格局正在發(fā)生巨大變化。盡管當(dāng)前的工具已經(jīng)改變了我們的原型設(shè)計(jì)和迭代方式，但我認(rèn)為我們正處于一場(chǎng)更重大變革的邊緣：軟件工程智能體的興起。

我所說的“智能體”是什么？這些系統(tǒng)不只是簡(jiǎn)單地對(duì)提示詞做出響應(yīng)，而是能夠以越來越自主的方式去規(guī)劃、執(zhí)行和迭代解決方案。

我們已經(jīng)看到了這種進(jìn)化的初步跡象：

從響應(yīng)到協(xié)作

目前的大多數(shù)工具只是在等待我們的指令，但看看 Claude Anthropic 對(duì)計(jì)算機(jī)的使用，或 Cline 自動(dòng)啟動(dòng)瀏覽器并運(yùn)行測(cè)試的新功能，它們不僅僅是高級(jí)的自動(dòng)補(bǔ)全，它們實(shí)際上是在理解任務(wù)并主動(dòng)解決問題。

對(duì)于調(diào)試，這些智能體不僅僅是建議修復(fù)，它們還可以：

• 主動(dòng)識(shí)別潛在問題

• 啟動(dòng)并執(zhí)行測(cè)試

• 檢查 UI 元素并截取屏幕截圖

• 提出建議并進(jìn)行修復(fù)

• 驗(yàn)證解決方案是否有效

多模態(tài)的未來

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

• 視覺理解（UI 截圖、草圖、圖表）

• 口頭對(duì)話

• 環(huán)境交互（瀏覽器、終端、API）

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

自主加指導(dǎo)

我從使用這些工具中獲得的關(guān)鍵見解是，AI 在未來并不是要取代開發(fā)者，而是成為一個(gè)越來越有能力的協(xié)作者，它可以在接受人類指導(dǎo)和專業(yè)知識(shí)的基礎(chǔ)上主動(dòng)采取行動(dòng)。

2025 年最高效的團(tuán)隊(duì)可能是那些學(xué)會(huì)：

• 為 AI 智能體設(shè)定清晰的邊界和指導(dǎo)

• 建立強(qiáng)大的架構(gòu)模式，讓智能體能夠在其中高效工作

• 在人類和 AI 能力之間創(chuàng)建有效的反饋循環(huán)

• 在利用 AI 自主性的同時(shí)保持人類的監(jiān)督

英語優(yōu)先的開發(fā)環(huán)境

正如 Andrej Karpathy 所說的：

“最熱門的新式編程語言是英語。”

這是我們?cè)谂c開發(fā)工具交互方式上的一次根本性轉(zhuǎn)變。清晰的思考和用自然語言進(jìn)行精確溝通的能力正變得和傳統(tǒng)編程技能一樣重要。

這種向智能體輔助開發(fā)的轉(zhuǎn)變要求我們提升技能：

• 更強(qiáng)的系統(tǒng)設(shè)計(jì)和架構(gòu)思維

• 更好的需求規(guī)范和溝通

• 更多關(guān)注質(zhì)量保證和驗(yàn)證

• 增強(qiáng)人類和 AI 能力之間的協(xié)作

軟件工藝的回歸？

盡管 AI 讓快速構(gòu)建軟件變得前所未有地容易，但我們卻面臨著失去一些至關(guān)重要的東西的風(fēng)險(xiǎn)：創(chuàng)造真正精致、具有消費(fèi)者品質(zhì)體驗(yàn)的藝術(shù)。

演示品的陷阱

這正逐漸形成一種模式：團(tuán)隊(duì)利用 AI 迅速構(gòu)建令人印象深刻的演示品，理想路徑運(yùn)行得非常完美，投資者和社交網(wǎng)絡(luò)都為之驚嘆，但當(dāng)真正的用戶開始點(diǎn)擊操作時(shí)，問題便開始浮現(xiàn)。

我親眼目睹了這種情況：

• 錯(cuò)誤信息讓普通用戶完全看不懂

• 邊緣情況導(dǎo)致應(yīng)用程序崩潰

• 混亂的用戶界面

• 完全忽視了可訪問性

• 在較慢的設(shè)備上存在性能問題

這些不只是 P2 級(jí)別的小問題，而是人們勉強(qiáng)湊合使用的軟件和真心熱愛的軟件之間的關(guān)鍵分水嶺。

遺失的打磨藝術(shù)

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

• 對(duì)錯(cuò)誤信息的精心設(shè)計(jì)

• 在慢網(wǎng)絡(luò)連接條件下進(jìn)行測(cè)試

• 優(yōu)雅地處理每一個(gè)邊緣情況

• 使功能易于發(fā)現(xiàn)

• 讓真正的、非技術(shù)用戶參與測(cè)試

這種對(duì)細(xì)節(jié)的關(guān)注或許無法由 AI 生成，它源于同理心、經(jīng)驗(yàn)以及對(duì)工藝的深切關(guān)懷。

個(gè)人軟件的復(fù)興

我相信我們將迎來個(gè)人軟件開發(fā)的復(fù)興。隨著市場(chǎng)充斥著 AI 生成的最小可行性產(chǎn)品，那些能夠脫穎而出的將是那些由以下開發(fā)者構(gòu)建的產(chǎn)品：

• 對(duì)自己的工藝感到自豪

• 關(guān)注小細(xì)節(jié)

• 專注于完整的用戶體驗(yàn)

• 考慮到各種邊緣情況

• 創(chuàng)造真正自助式的體驗(yàn)

頗具諷刺意味的是，AI 工具實(shí)際上可能促成這一復(fù)興。AI 可以處理常規(guī)的編碼任務(wù)，讓開發(fā)者能夠?qū)Ｗ⒂谧钪匾氖虑椋捍蛟煺嬲?wù)于用戶并令用戶滿意的軟件。

底線

AI 并沒有讓我們的軟件明顯變得更好，因?yàn)檐浖|(zhì)量并非主要受限于編碼速度。軟件開發(fā)中真正困難的部分——理解需求、設(shè)計(jì)可維護(hù)的系統(tǒng)、處理邊緣情況、確保安全性和性能——仍然需要人類的判斷。

AI 讓我們能夠更快速地迭代和實(shí)驗(yàn)，這種更快速的探索可能會(huì)帶來更好的解決方案。但這只有在我們保持工程紀(jì)律并將 AI 當(dāng)作工具而非良好的軟件實(shí)踐的替代品時(shí)才會(huì)實(shí)現(xiàn)。記住：我們的目標(biāo)并不是更快地編寫更多代碼，而是構(gòu)建更好的軟件。明智地運(yùn)用 AI 可以幫助我們達(dá)成這一目標(biāo)，但歸根結(jié)底仍然需要我們自己去明確“更好”所代表的含義以及如何將其付諸實(shí)踐。

我的額外想法

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

關(guān)于 AI 工具在軟件工程中的應(yīng)用，大部分都集中在代碼生成能力上，這是有道理的。AI 工具在根據(jù)提示詞生成可運(yùn)行的代碼或在構(gòu)建軟件時(shí)提供代碼建議方面確實(shí)令人印象深刻，但在構(gòu)建軟件的過程中，編碼環(huán)節(jié)究竟占多大比例呢？大約 50 年前，F(xiàn)red Brooks 認(rèn)為編碼約占總時(shí)間的 15% 至 20%。以下是 Brooks 在《人月神話》中描述的觀點(diǎn)：

“多年來，我一直運(yùn)用以下的經(jīng)驗(yàn)法則來合理安排軟件開發(fā)任務(wù)的時(shí)間，并取得了顯著的效果：三分之一用于規(guī)劃六分之一用于編碼四分之一用于組件測(cè)試和早期的系統(tǒng)測(cè)試四分之一用于系統(tǒng)測(cè)試，此時(shí)所有組件均已就緒。”

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

• 20% 用于規(guī)劃

• 40% 用于編碼（編寫代碼 + 編寫測(cè)試）

• 20% 用于代碼評(píng)審（評(píng)審他人的代碼）

• 20% 用于準(zhǔn)備生產(chǎn)發(fā)布 + 上線 + 上線期間的小修小補(bǔ) + 監(jiān)控 + 告警

當(dāng)然，構(gòu)建出色的軟件還涉及許多其他環(huán)節(jié)：

1. 確定做什么：弄清楚要構(gòu)建什么。這可能涉及頭腦風(fēng)暴、設(shè)計(jì)、用戶測(cè)試、與產(chǎn)品經(jīng)理和業(yè)務(wù)利益相關(guān)者合作等。對(duì)于初創(chuàng)公司，這一階段可能耗時(shí)很少（“先構(gòu)建出來看看效果如何！”）。而對(duì)于成熟的公司，這一階段可能比構(gòu)建本身耗時(shí)更多（“我們需要確保構(gòu)建的東西不會(huì)讓現(xiàn)有客戶感到困惑！”）。

2. 確定怎么做：制定構(gòu)建產(chǎn)品、功能、服務(wù)的計(jì)劃。考慮架構(gòu)的影響、依賴關(guān)系、如何測(cè)試產(chǎn)品等。初創(chuàng)公司可能會(huì)跳過這一環(huán)節(jié)，團(tuán)隊(duì)直接進(jìn)入規(guī)劃階段。但對(duì)于擁有眾多服務(wù)和依賴關(guān)系的大型公司，跳過規(guī)劃環(huán)節(jié)最終會(huì)帶來麻煩。因此，大多數(shù)團(tuán)隊(duì)都在使用設(shè)計(jì)文檔、RFC 或 ADR 等進(jìn)行某種形式的規(guī)劃。

3. 構(gòu)建：實(shí)現(xiàn)功能或產(chǎn)品：編寫代碼，并確保能夠正常運(yùn)行。

4. 驗(yàn)證：在部署到生產(chǎn)環(huán)境之前，再次檢查是否按預(yù)期運(yùn)行。在上線風(fēng)險(xiǎn)較大時(shí)，這一點(diǎn)尤為重要。例如，向銀行應(yīng)用程序推送回歸更新可能會(huì)對(duì)客戶和業(yè)務(wù)造成財(cái)務(wù)上的損失！

5. 上線：合并變更并推送給客戶，有多種策略可用于將變更部署到生產(chǎn)環(huán)境，我們?cè)凇癝hipping to production”一文中介紹了其中的幾種策略。

6. 監(jiān)控和待命：監(jiān)測(cè)產(chǎn)品是否出現(xiàn)了問題，一旦出現(xiàn)故障，盡快解決，并確保類似的故障不再發(fā)生。我們?cè)凇癏ealthy oncall practices”和“Incident review and postmortem best practices”中探討了這些常見方法。

7. 維護(hù)：聆聽客戶投訴和反饋，確定哪些錯(cuò)誤需要修復(fù)，哪些功能需要優(yōu)先處理，并弄清楚哪些反饋可以忽略。

8. 遷移：如果產(chǎn)品發(fā)生重大變化，或者技術(shù)棧出現(xiàn)重大變化——比如引入新的框架——可能就需要進(jìn)行遷移。

如今的 AI 工具可以在“構(gòu)建”環(huán)節(jié)提供很大幫助，那么問題來了：它們對(duì)于軟件工程的其他七個(gè)階段有多大用處呢？

無需開發(fā)者：20 世紀(jì) 60 年代以來的夢(mèng)想

自 20 世紀(jì) 60 年代以來，非技術(shù)人員無需依賴軟件開發(fā)者就能創(chuàng)建可運(yùn)行軟件一直是人們夢(mèng)寐以求的目標(biāo)。編碼本質(zhì)上是將人們的需求（客戶、業(yè)務(wù)利益相關(guān)者、產(chǎn)品經(jīng)理等）轉(zhuǎn)化為計(jì)算機(jī)能夠理解的內(nèi)容。大語言模型為我們提供了一個(gè)更高層次的抽象，我們可以將英語轉(zhuǎn)化為代碼。然而，這種新的抽象并沒有改變軟件的構(gòu)建方式和軟件的本質(zhì)，即：

AI 工具沒有改變流程，但它們確實(shí)使部分編碼環(huán)節(jié)變得更加高效：

在技術(shù)發(fā)展的歷史長(zhǎng)河中，一些創(chuàng)新曾承諾能夠讓業(yè)務(wù)人員繞過“技術(shù)”環(huán)節(jié)，直接用高級(jí)的提示詞獲得可運(yùn)行的軟件：

• 20 世紀(jì) 60 年代：高級(jí)編程語言 COBOL，即“通用的商業(yè)語言”，其目標(biāo)是讓沒有編程背景的業(yè)務(wù)人員也能夠使用它。

• 20 世紀(jì) 90 年代：Visual Basic。這是一種旨在降低學(xué)習(xí)曲線的編程語言，它還提供了一個(gè)可視化的編程環(huán)境，可以通過拖放創(chuàng)建表單。

• 2010 年代后期：無代碼。無代碼解決方案，如 Bubble，通過模板和可視編輯提供了一種構(gòu)建軟件應(yīng)用的方法。

一些 GenAI 編碼初創(chuàng)公司也有著相同的目標(biāo)：讓任何人都能夠使用英語來構(gòu)建軟件。過去已經(jīng)一些成功的簡(jiǎn)單用例。例如，無需任何編碼知識(shí)也能創(chuàng)建網(wǎng)站：非技術(shù)人員可以使用 Wix.com、Webflow、Ghost 或 WordPress 等視覺編輯器和服務(wù)來實(shí)現(xiàn)。

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

“這些語法的發(fā)展通常會(huì)遇到表達(dá)問題：一旦它們簡(jiǎn)化到易于快速掌握的程度，便難以在眾多場(chǎng)景中充分表達(dá)軟件的復(fù)雜功能和精細(xì)邏輯。反之，一些語言具備定義領(lǐng)域特定語言（DSL）的能力。然而，這些語言很少在廣大的開發(fā)社區(qū)中真正取得成功，主要是因?yàn)樗鼈冇质故虑樽兊脴O其復(fù)雜。”

對(duì)于復(fù)雜的軟件，很難想象不需要軟件工程師參與規(guī)劃、構(gòu)建和維護(hù)，而且 AI 工具越是降低非技術(shù)人員構(gòu)建軟件的門檻，需要維護(hù)的軟件就越多。

AI 智能體：一個(gè)重大承諾，但也是 2025 年的一個(gè)巨大“未知數(shù)”

在大語言模型推出兩年后，我們中的許多人已經(jīng)相當(dāng)熟練地使用它們來增強(qiáng)編碼和軟件工程工作。它們非常適合用于原型設(shè)計(jì)、切換到不太熟悉的語言，以及那些可以驗(yàn)證其正確性并指出幻覺或錯(cuò)誤輸出的任務(wù)。

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

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

AI 智能體在延遲和成本（計(jì)算結(jié)果花費(fèi)的時(shí)間更長(zhǎng)，多次運(yùn)行提示詞，這些初創(chuàng)公司稱之為“思考”）與準(zhǔn)確性（基于提示詞獲得更好的結(jié)果）之間做了權(quán)衡。關(guān)于這種延遲加成本的權(quán)衡會(huì)帶來多大的準(zhǔn)確性提升，以及哪些用例會(huì)因此顯著提高生產(chǎn)力，仍有一些值得探討的問題。

對(duì)經(jīng)驗(yàn)豐富的軟件工程師的需求可能會(huì)增加

未來，對(duì)經(jīng)驗(yàn)豐富的軟件工程師的需求可能會(huì)比今天更大。我們看到的 AI 工具的共同特點(diǎn)是，經(jīng)驗(yàn)豐富的工程師可以更高效地使用這些工具，因?yàn)樗麄兡軌蚋玫亍懊闇?zhǔn)”目標(biāo)。當(dāng)你知道什么才是“出色的輸出”，你就可以更好地提供提示詞，當(dāng)代碼生成出現(xiàn)錯(cuò)誤時(shí)能夠及時(shí)停止，而且你知道何時(shí)停下來直接轉(zhuǎn)而修改源代碼。

我們將看到更多由這些 AI 工具生成的代碼，更多的人和企業(yè)開始構(gòu)建自己的解決方案。當(dāng)這些解決方案達(dá)到一定復(fù)雜度時(shí)，需要引入專業(yè)人士來應(yīng)對(duì)這種復(fù)雜性：這種復(fù)雜性需要經(jīng)驗(yàn)豐富的工程師來處理。現(xiàn)有的科技公司幾乎肯定會(huì)使用 AI 工具生成更多的代碼：它們將依賴經(jīng)驗(yàn)豐富的工程師來應(yīng)對(duì)隨之而來的復(fù)雜性。

作為一名軟件工程師，掌握 AI 輔助開發(fā)工具將使你更具生產(chǎn)力，也更有價(jià)值。現(xiàn)在正是投身這一領(lǐng)域的時(shí)刻：我們正處在一個(gè)工具創(chuàng)新加速的時(shí)代。我們確實(shí)需要花時(shí)間去弄清楚如何“馴服”現(xiàn)有的工具，實(shí)現(xiàn)自身生產(chǎn)力的最大化。所以，一定要去嘗試使用它們！

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

聲明：本文由 InfoQ 翻譯，未經(jīng)許可禁止轉(zhuǎn)載。

AICon 2025 強(qiáng)勢(shì)來襲，5 月上海站、6 月北京站，雙城聯(lián)動(dòng)，全覽 AI 技術(shù)前沿和行業(yè)落地。大會(huì)聚焦技術(shù)與應(yīng)用深度融合，匯聚 AI Agent、多模態(tài)、場(chǎng)景應(yīng)用、大模型架構(gòu)創(chuàng)新、智能數(shù)據(jù)基建、AI 產(chǎn)品設(shè)計(jì)和出海策略等話題。即刻掃碼購(gòu)票，一同探索 AI 應(yīng)用邊界！！

今日薦文

你也「在看」嗎？