AI取代不了程式設計師，明年全流程上AI！谷歌工程負責人自曝：2026年AI程式設計完整工作流程！經典軟體工程紀律沒過時，在AI時代更重要

2025年，AI 程式設計助理真正成為了改變遊戲規則的工具。

不少開發者已經擁抱了AI程式工具，例如大家熟知的Claude Code、Codex CLI、Cursor、Gemini CLI等等。但要真正有效率地駕馭它們，還需要技巧和結構化的方法。

前幾天，Google工程負責人、Chrome DevTools 和JS Patterns 的設計者Addy Osmani 結合自己一年多的專案實務經驗，總結了一套AI Coding 的工作流程。

進入2026 年，他對LLM 輔助編程的理解已經非常清晰：它不是“自動駕駛”，而是一位能力極強、但需要被正確引導的結對程式設計師。

Andy系統性複盤了自己在走向2026 的過程中，如何把AI 真正納入日常工程體系——從前期規劃，到代碼生成，再到團隊協作，幾乎覆蓋了一整套可復用的實戰方法論。

在他的實踐中，AI 並不是“寫代碼的黑箱”，而是被當作工程流程中的一環來精細管理。具體來說，這套方法包括：

在任何程式碼產生之前，先與AI 一起打磨一份足夠具體、可執行的專案方案，把需求、邊界和目標一次說清楚；

• 在prompt 中大量使用明確的註釋、約束和規則，主動限定AI 的行為，而不是被動接收結果；
• 針對不同任務選擇不同模型，而不是迷信「一個模型包打天下」；
• 保持高頻、小步的程式碼提交，避免一次性產生或修改過多程式碼，導致專案狀態失控；
• 為每一個新功能單獨創建worktree，將實驗性改動與主線程式碼嚴格隔離；
• 透過規則檔案約束AI 的程式碼風格、目錄結構和工程習慣，讓產生程式碼更像「團隊成員」而不是「臨時外包」。

他的核心結論是：經典的軟體工程紀律，不但沒有過時，在AI 時代反而更重要！

先設計、再編碼；寫入測試；用版本控制；守住標準。當AI 參與寫一半程式碼時，這些原則的價值被進一步放大。

此外，Andy也分享了一個有趣的觀點。很多人可能認為，AI Coding會加速程式設計師失業，取代程式設計師的職位，但Andy認為，用好AI才能加速你的成長。

在審AI 的程式碼、糾AI 的bug、讓AI 解釋思路的過程中，其實能夠學到大量新知識；而對於有紮實基本功的人來說，AI能讓生產力倍放大。

Andy表示，2026 年他將全面擁抱AI，但方式是審慎、由專家主導的。這是一種更自律的「AI 輔助工程」方法：在激進地利用AI 能力的同時，依然對最終產出的軟體負全部責任。

以下是他的乾貨分享，enjoy！

從清晰的計畫開始：先寫方案，再寫程式碼

不要只是把「願望」一股腦丟給LLM，應先定義問題，再規劃解決方案。

一個非常常見的錯誤，是在提示語還很模糊的情況下，直接讓AI 產生程式碼。在我的工作流程中（以及許多成熟實踐中），第一步並不是寫代碼，而是和AI 一起頭腦風暴，產出一份詳細的規格說明，然後再整理出清晰的分步計劃。

對於一個新項目，我通常會先描述整體想法，並讓LLM 不斷向我反問，直到需求、邊界條件和潛在的邊緣情況都被充分挖掘出來。最終，我們會把這些內容整理成一份完整的 spec.md，其中包含：功能需求、架構決策、資料模型，甚至是測試策略。這份規格文件會成為整個開發過程的基石。

接下來，我會把這份spec 交給一個具備推理能力的模型，讓它產生專案計畫：把實作過程拆解成邏輯清晰、粒度適當的小任務或里程碑。某種意義上，這是一個「迷你版設計文件/ 專案計畫」。我通常會多次迭代這份計劃——親自修改，再讓AI 批判性地審視、優化——直到它足夠完整、連貫，然後才進入真正的編碼階段。

這種前期投入乍看之下有點慢，但回報極高。正如Les Orchard 所說，這就像是“15 分鐘完成一次瀑布式設計”，一個快速而結構化的規劃階段，讓後續編碼變得異常順暢。

有了清晰的規格和計劃，當我們真正「釋放」程式碼產生能力時，人和AI 都非常清楚：我們要做什麼，以及為什麼要這麼做。簡而言之，先規劃能讓你和AI 站在同一頁上，避免無效反覆。很多人會跳過這一步，但如今有經驗的LLM 開發者，已經把高品質的spec / plan 當成整個工作流程的核心。

把工作拆分成小而可迭代的區塊

範圍管理是一切的關鍵：給LLM 可控的小任務，而不是一次塞進整個程式碼庫。

我學到的一個重要教訓是：不要讓AI 一次輸出大量、整體性的程式碼。相反，應把專案拆成一系列小步驟或“工單”，逐一完成。這本來就是良好的軟體工程實踐，但在引入AI 之後變得尤為重要。

LLM 在聚焦型任務上表現最好：實作一個函數、修復一個bug、增加一個小功能。例如完成規劃後，我會直接對程式碼產生模型說：「好，我們來實現計畫裡的第1 步。」完成後測試，再進入第2 步，如此循環。每一個chunk 都夠小，小到AI 能在上下文中處理乾淨，而你也能真正理解它產生的程式碼。

這種方式能有效防止模型「跑偏」。如果一次性要求太多，模型往往會迷失方向，產生一堆“糾纏在一起的程式碼垃圾”，非常難以維護。許多開發者都有類似體驗：讓LLM 一口氣產生一個完整應用，結果程式碼風格不統一、邏輯重複，「就像10 個程式設計師各幹各的，彼此完全沒溝通」。我自己也踩過這個坑，解決方法只有一個：停下來，退一步，把問題切小。

每一輪迭代，我們都在已有上下文的基礎上，增量式地推進。這也非常適合測試驅動開發（TDD）：每個步驟都可以同步編寫或產生測試（後面會詳細講）。

不少編碼Agent 工具已經明確支援這種「分塊」工作流程。例如，我有時會產生一個結構化的「prompt plan」文件，裡麵包含每個任務對應的一條提示語，讓Cursor 這類工具依序逐條執行。核心原則只有一個：避免大躍進。透過小步快跑，我們大幅降低災難性錯誤的機率，也能更快糾偏。 LLM 在快速、受限的任務上非常擅長，要順勢而為。

提供充足的脈絡和明確的指導

LLM 的品質上限，取決於你提供的上下文品質。把相關程式碼、文檔和約束條件都給它。

在處理真實程式碼庫時，我會確保AI 擁有完成任務所需的一切資訊：相關原始碼、技術約束、已知坑點、推薦或禁止的方案。現代工具在這方面已經很強了：例如Claude 的Projects 模式可以直接匯入整個GitHub 倉庫；Cursor、Copilot 會自動把目前開啟的檔案放進上下文。但我通常還會做得更多。

如果我懷疑模型缺乏某些關鍵訊息，就會透過MCP（如Context7），或乾脆手動把重要模組、API 文件黏進對話裡。資深LLM 用戶普遍強調這種“上下文打包（context packing）”的重要性，例如在編碼前來一次完整的“信息傾倒”，包括：

高層目標與不變量

• 正確解法的範例
• 明確警告那些方案不要用

如果任務本身比較棘手，我甚至會提前告訴AI 那些樸素解法性能不行，或者給它一個外部參考實作。如果使用的是冷門庫或全新API，我會直接貼官方文件或README，避免它「蒙著眼睛飛」。

所有這些前置上下文，都會顯著提升輸出質量，因為模型不需要猜測，而是基於事實和約束進行生成。

現在也有不少工具能自動化上下文整理，例如gitingest、repo2txt，它們可以把程式碼庫的關鍵部分匯出成一個文字文件，讓LLM 一次讀入。對於大型專案來說，這是救命工具。原則很簡單：不要讓AI 在資訊不完整的情況下工作。一個bug 如果涉及四個模組，就把這四個模組都給它。當然要注意token 限制，但如今前沿模型的上下文視窗已經非常大（幾萬token），合理利用即可。我通常只選取與目前任務相關的程式碼，並明確告訴AI 那些內容可以忽略，以節省上下文空間。

我個人也很看好Claude Skills 這個方向：它把原本脆弱、一次性的提示，封裝成可復用的“技能”，把指令、腳本和領域知識模組化。當請求匹配某個Skill 時，工具可以自動套用這些能力，效果遠勝於通用prompt。這讓我們從一次性交互，走向可重複使用、可沉澱的工程流程。

目前社群已經有不少Skills 集合，我很喜歡的例子是frontend-design skill，它能終結LLM UI 裡氾濫的「紫色設計風」。在官方工俱全面支援之前，也已經有一些可行的變通方案。

最後，在prompt 裡用明確的註解和規則引導AI。例如，我會在程式碼前面加一句：「這是X 的當前實現，我們需要擴展它來做Y，但一定不要破壞Z。」這種小提示非常有效。 LLM 本質上是“字面主義者”，你給什麼指令，它就照著執行。上下文越清晰，幻覺和跑偏就越少，產生的程式碼也越貼合項目實際。

為不同任務選擇最適合的模型

並不是所有編碼LLM 都一樣，要有意識地選工具，必要時中途換模型。

到2025 年，我們已經擁有大量強大的程式碼模型。在我的工作流程中，一個重要環節就是：為不同任務選擇最適合的模式或服務。有時候，我甚至會並行嘗試兩個模型，看看它們對相同問題的想法有何不同。

每個模型都有自己的「性格」。關鍵在於：如果一個模型卡住了或輸出平庸，立刻換另一個。我常常把同一個prompt 原封不動地複製到另一個服務裡，結果往往立竿見影。這種「模型輪換」在遇到盲點時非常救命。

另外，盡量用最新、最強的版本。如果條件允許，優先使用最新的Pro 級模型。是的，這通常意味著付費，但生產力提升往往物有所值。說到底，選一個「合拍」的AI 結對程式設計師也很重要。我認識一些人偏愛某個模型，只是因為它的回應風格比較順眼，這完全合理。當你要和AI 長時間對話時，體驗和語氣真的很重要。

就我個人而言，最近很多程式設計工作我會優先用Gemini，因為互動更自然，第一次就理解需求的機率更高。但我從不猶豫在必要時切換模型；有時候，「第二意見」能讓解法突然浮現。總結一句：為任務選對工具，並記住你手上有一整套AI 工具箱可用。

在整個軟體生命周期中使用AI 編碼能力

在SDLC 的各個階段引入AI，讓開發體驗全面提速。

在命令列層面，新一代AI Agent 已經出現：Claude Code、OpenAI Codex CLI、Google Gemini CLI，都可以直接在專案目錄裡對話，讀取檔案、執行測試，甚至多步驟修復問題。我也用過Google 的Jules、GitHub Copilot Agent——它們是異步的編碼Agent，會把你的倉庫複製到雲端VM，在後台完成任務（寫入測試、修bug），然後直接給你一個PR。第一次看到這種體驗時真的很詭異：你只下了一條指令，例如“重構支付模組以支援X”，過一會兒就收到一個測試通過的Pull Request。我們確實活在未來。關於這一點，可以參考《From conductors to orchestrators》。

當然，這些工具並不完美，必須清楚它們的邊界。它們非常擅長加速機械性工作，樣板​​程式碼、重複性修改、自動跑測試，但仍然高度依賴你的引導。例如，當我讓Claude 或Copilot Agent 實現某個功能時，通常會把前面整理好的計畫或待辦清單一起給它。如果工具支持，我會直接把 spec.md 或 plan.md 加進上下文，讓它嚴格地按步驟執行。

我們還遠遠沒到可以完全放手，讓AI 獨立實現完整功能並期待完美結果的階段。我的使用方式始終是「有人監督」：讓AI 產生、運行程式碼，但我隨時盯著進度，一旦有異常就介入。也有一些編排工具（如Conductor）支援並行運行多個Agent，讓不同Agent 同時處理不同任務。本質上是在「規模化AI 勞動力」。我也嘗試過這種「多Agent 並行」模式，效率驚人，但同時也非常耗費心智去監控。多數情況下，我還是選擇一個主Agent，再加一個輔助Agent 做評審。

記住：這些都是電動工具。你仍然掌控扳機。

始終讓人留在迴路中：驗證、測試、審查一切

AI 可以寫出看起來很像真的程式碼，但品質責任始終在你身上。

我有一條鐵律：永遠不要盲信LLM 的輸出。正如Simon Willison 所說，把LLM 當成一個「自信過頭、但容易犯錯的配對程式設計師」。它會以100% 的確信寫出包含bug 的程式碼，除非你指出來，否則它不會意識到問題。

因此，我把每一段AI 產生的程式碼，都當成來自初級工程師的提交：逐行閱讀、運行、測試。一定要測試。跑單測、手動驗證功能是否符合預期。對此我強烈建議閱讀《Vibe coding 不是低品質的藉口》。

事實上，我把測試直接嵌入工作流程。前期規劃時就會包含測試清單或測試策略。如果使用Claude Code 這類工具，我會明確指示它在完成任務後運行測試，並在失敗時繼續調試。只要測試存在，AI 在「寫程式→ 跑測試→ 修bug」的閉環裡表現非常出色。這也是為什麼最能榨乾coding agent 價值的人，往往也是測試做得最好的人。有完善測試套件的項目，對AI 來說就像裝了安全網；沒有測試，Agent 很容易在「看起來一切正常」的幻覺中破壞多個模組。

除了自動化測試，程式碼審查同樣必不可少——包括人工和AI 輔助審查。我經常會暫停下來，逐行審查目前產生的程式碼，甚至開一個第二個AI 會話（或換一個模型）來做review。例如讓Claude 寫程式碼，再讓Gemini 審一遍：「你能檢查這個函數有沒有潛在問題嗎？」這種方式常常能抓住一些微妙bug。 AI 寫的程式碼，反而更需要審查，因為它往往「表面上很合理」。

我也會使用Chrome DevTools MCP（這是我和上一個團隊一起做的）來增強調試和品質閉環。它相當於“給AI 裝上眼睛”，讓Agent 能看到瀏覽器實際狀態：DOM、效能追蹤、控制台日誌、網路請求。這極大減少了上下文切換的摩擦，使LLM 能夠基於真實運行數據進行UI 測試和精確修復。

忽視人類監督的代價已經有人替我們踩過。曾有開發者在趕專案時大量依賴AI 生成，結果程式碼結構混亂、邏輯重複、命名不一致。他後來意識到自己一直在“往前堆代碼”，卻從沒停下來整體審視。最終只能痛苦重構，發誓再也不讓事情失控。我把這個教訓牢記在心：無論AI 用得多狠，我始終是最終負責的工程師。

在實踐中，這意味著：只有在我真正理解程式碼之後，才會合併或上線。如果AI 產生的程式碼太複雜，我會讓它加註解解釋，或者乾脆重寫成更清晰的版本。只要感覺不對勁，就深入挖——就像對待任何人類同事的可疑提交一樣。

歸根究底是心態問題：LLM 是助手，而不是可靠的自主程式設計師。我是資深工程師，AI 是加速器，而不是判斷替代品。這種立場不僅帶來更好的程式碼，也能保護你作為開發者的長期成長。只要你始終參與其中、主動理解和審查，你不是在退化，而是在更高速度下鍛鍊判斷力。

一句話總結：保持警惕，頻繁測試，永遠審查。程式碼庫最終仍然是你的。

頻繁提交，把版本控制當作安全網

永遠不要提交你解釋不清楚的程式碼。

在AI 能快速產生大量程式碼的情況下，事情很容易失控。我的應對方式是：極端細粒度的版本控制習慣。我提交得比純手寫程式碼時代還要頻繁。每完成一個小任務或一次成功的自動修改，就立刻提交一次，提交資訊寫清楚。

這樣一來，如果AI 的下一步引入了bug 或糟糕改動，我可以迅速回滾到最近的穩定點，或者cherry-pick，而不是損失幾個小時的工作。有人把這種做法比喻為“遊戲裡的存檔點”，我非常認同。有了這種安全感，你才敢大膽嘗試AI 的激進重構。

版本控制還能彌補AI 的「記憶缺陷」。我經常翻看最近的提交記錄，來給AI（或自己）複盤發生了什麼。甚至可以直接把git diff 或commit log 黏給AI，它們非常擅長理解diff，用 git bisect 找bug 也毫無怨言——前提是你的提交歷史足夠乾淨。

另一個好處是：小提交+ 清晰訊息，本身就是文件。無論是人類還是AI 做code review，都比較容易定位問題。如果所有改動都塞在一個叫「AI changes」的巨大提交裡，基本上等於災難。所以我強迫自己遵守紀律：完成任務→ 跑步測試→ 提交。

我也會大量使用分支或git worktree 來隔離AI 實驗。一個我很喜歡的進階技巧（受Jesse Vincent 啟發）是：為每個新功能或子任務創建一個獨立worktree。這樣可以在同一個倉庫裡並行跑多個AI 會話，互不干擾。失敗了直接丟棄，成功了再合併。版本控制正是讓這種AI 協作成為可能的基礎架構。

總結一句：多提交、用好分支、把git 當成AI 時代的控制系統。

用規則和範例客製化AI 的行為

透過風格指南、範例，甚至「規則檔」來引導AI，前期一點調校，能換來長期高品質輸出。

我學到的一點是：你完全不必接受AI 的預設風格。你可以強力引導它。我自己維護了一個 CLAUDE.md 檔案（用Gemini CLI 時也有 GEMINI.md），裡面寫的是流程規則和偏好，例如：

遵循專案程式碼風格

• 透過lint 規則
• 禁用某些函數
• 偏好函數式而非OOP

每次會話開始時把這個檔案餵給模型，效果非常好，能顯著減少「跑偏」。這就像Jesse Vincent 說的：它能讓模型始終沿著既定軌道前進。

即使不用規則文件，你也可以透過自訂指令或system prompt 達到類似效果。 Copilot、Cursor 都支援專案層級的行為配置。我通常會寫一小段說明，例如縮排規格、React 中避免箭頭函數、變數命名要求、必須通過ESLint 等。設定好之後，AI 的輸出就更像一個真正融入團隊的工程師。 Ben Congdon 曾經感慨，很少有人使用Copilot 的自訂指令，但效果卻出奇地好——我完全贊同。

另一個非常有效的技巧是：給範例。如果我希望AI 以某種方式寫函數，就先給它看一個現有實作；如果想要特定的註解風格，就先自己寫一段範例。 LLM 非常擅長模仿，一兩個例子就夠了。

社群裡還有不少「規則集」來約束模型行為，例如明確寫上「如果不確定，請提問而不是編造答案」。我自己常加一條：「修bug 時請在註解中簡要說明原因。」這樣後續review 就非常省心。

總結來說：不要把AI 當黑箱。像onboarding 新同事一樣給它規則、範例和期望。投入產出比極高。

把測試和自動化當作擴大機

CI/CD、lint、程式碼審查機器人，會讓AI 發揮最大價值。

這是前面原則的自然延伸：強自動化的工程環境，會極大放大AI 的生產力。我確保所有大量使用AI 的倉庫，都有完善的CI：自動測試、程式碼風格檢查、最好還有staging 部署。

這樣一來，AI 打開PR 後，CI 失敗的日誌就能直接餵回給AI：「整合測試失敗，錯誤是XYZ。」問題修復立刻變成一個高速回饋迴路，AI 非常擅長這種模式。

我甚至會把linter 的報錯直接貼進prompt，讓AI 修復。只要它「看到」工具回饋，就會非常努力地糾正。這也是為什麼有些Agent 會在測試全綠之前拒絕宣稱「完成任務」——這正是你希望看到的行為。

當AI + 自動化形成閉環時，你會感覺像是：一個極快的初級工程師，配上一個永不疲倦的QA。前提是，你得先把環境搭好。沒有測試和自動檢查，AI 的問題往往會被拖到很後面才會暴露。

展望2026，我計劃進一步強化AI 程式碼貢獻的品質閘門：更多測試、更多監控，甚至AI 審AI。聽起來有點悖論，但確實有效。重點很簡單：AI 友善的工作流程，一定是自動化成熟的工作流程。

用好AI，能加速你的成長

把每次AI 編碼當作學習機會，形成正向回饋循環。

使用LLM 的一個意外收穫是：我學得更多了，而不是更少。AI 讓我接觸到新的語言、框架和技巧，否則我可能不會主動嘗試。

一個普遍規律是：AI 會獎勵良好的工程基礎。有紮實基本功的人，生產力被倍增；基礎薄弱的人，困惑也會被放大。 LLM 讓你能站在更高抽象層上思考（設計、介面、架構），但前提是你本來就具備這些能力。正如Simon Willison 所說：幾乎所有「高階工程師」的核心能力，正是如今用好AI 的關鍵。

對於擔心AI 會讓人「退化」的聲音，我的看法相反：只要你始終參與審查和理解，AI 反而會加速成長。透過審AI 的程式碼、糾AI 的bug、讓AI 解釋思路，我學到了大量新知識。 AI 也成了我隨時待命的研究助理，幫我比較方案、分析權衡。

宏觀來看，AI 放大的是你的專業能力。進入2026 年，我並不擔心它“搶工作”，而是期待它把我從體力活中解放出來。當然，前提是要有紮實基礎，否則AI 可能會製造「鄧寧-克魯格效應加強版」。

一句建議：持續打磨基本功，用AI 加速這個過程。開發者+ AI 的組合，遠比任何一方單獨強大。

結論：2026年全面擁抱AI編程

進入2026 年，我已經全面擁抱AI，但方式是審慎、由專家主導的。這是一種“AI 增強的軟體工程”，而不是“AI 自動化的軟體工程”。

我的核心結論是：經典的軟體工程紀律，不但沒有過時，在AI 時代反而更重要。先設計、再編碼；寫測試；用版本控制；守住標準－當AI 參與寫一半程式碼時，這些原則的價值被進一步放大。

未來一定會繼續演進。也許會有更自主的“AI 實習生”，也許會出現全新的調試和程式碼探索範式。但無論如何，我都會始終留在迴路中，引導AI、向它學習、並負責任地放大自己的生產力。

對我來說，最終結論只有一句：AI 程式設計助手是強大的槓桿，但人類工程師仍然是導演。

那麼，祝你在2026 年，建造愉快。(51CTO技術棧)