--- title: "Design Pattern 在 AI 時代還有用嗎？" date: 2026-01-28T00:00:00+08:00 publishDate: 2026-01-28T00:00:00+08:00 lastmod: 2026-01-26T21:55:50+08:00 tags: ["AI","Design Pattern","Software Engineering","軟體開發"] toc: true permalink: "https://blog.aotoki.me/posts/2026/01/28/design-pattern-in-ai-era/" language: "zh-tw" --- 你是否發現 AI 生成的程式碼，每次整合都要花大量時間重新改寫？自從 Coding Agent 被推出，就不斷有會聽到軟體工程師會被取代的聲音。然而，最近跟同事協作的過程中，整體還是符合「剩下專業的人留下」這樣整體的現況。 可能有人會認為有 Coding Agent 後「不用學習軟體開發」但沒有意識到，許多高階的軟體開發知識，都不是「實作」的問題，更多是怎麼「設計」或者「架構」 ## 可維護性{#maintainability} 在我的開發經驗中，大部分軟體開發的知識都是在解決「如何維護軟體」這個問題，如果用非常簡單的說法，其實就是「怎樣更好修改」 舉例來說，寫測試是為了修改的時候不會加入 A 功能，但原本的 B 功能就不能正常使用，測試會確認兩個功能在範圍內（如：單元測試的範圍）都能正常運作。 同樣的重構（Refactoring）大多也是為了往後的修改而準備，架構理論也是要讓長期擴充功能更容易，基本上大部分軟體交付品質的判斷，很高機率都跟「能不能繼續修改」有關，就算是 Design Pattern 也是把常見的設計方式整理起來，終究還是回到「容易修改」的問題上。 回過頭看 Coding Agent 的表現，雖然可以用遠超人類的速度產生程式碼，即使現在的「正確性」已經達到大多數工程師都會說「交給 AI 實作就好」這樣的評價，但軟體的設計、架構仍然只是隨機拼湊的，不一定總是容易修改、維護。 ## 基礎能力{#foundations} 在 AI 時代中，身為軟體工程師的能力不再是「背誦」的性質，我們不需要了解所有程式語言的語法是怎麼使用、每一種軟體開發的理論的實作細節。 但是，對於 SOLID 原則、Design Pattern、Clean Architecture 以及所有關於軟體設計的理論，至少要熟悉到在對應的情境時可以馬上想到「這裡很像這個」或者「這裡該使用這個」才足夠對應軟體開發所需的能力。 以工作當作案例，我跟同事個別負責兩個不同的專案，但是最終需要整合在一起進行驗證。我們都有使用 Coding Agent 來進行開發，但是一直困擾我的是每一次拿到新的檔案，我必須讓 Coding Agent 重新改寫過一遍才能使用。 如果只是在 Vibe Coding 或者利用 ChatGPT 或 Gemini 的 Canvas（畫布）製作小工具，這可能還在接受範圍，但是以打造產品來說，這樣做就失去了原本 AI 幫助我們快速開發的意思，這變成我只是拿到一份 80 分的文件，重新實作一遍。 所以我跟同事花了一點時間，做了一些調整 - 確認介面 - 抽象處理 聽起來似乎不難，但這都是軟體開發基本功的應用。在規格中，我跟同事的實作只會有 `Get` 和 `Create` 兩種情境，但之前「曝露細節」太多給我，確認介面就是在區分每一個設計哪些應該「封裝」起來不被外部使用。 接下來我們需要處理應用情境，因為我負責的是一個檢驗的系統，用來確認同事的實作跟設計一致，這樣才能繼續部署到正式環境，為此我們需要檢驗環境的特殊行為，前面確認介面的地方再次發揮作用，因為我們可以利用依賴注入（Dependency Injection）來抽換用於驗證還是正式服務的行為。 在更近一步，因為同事的實作對我來說只能有 `Get` 和 `Create` 被暴露，所以我們應用了 Design Pattern 中 Factory 的 Creation Method 提供一個非常簡單的 `build_local_runtime(...)` 方法來讓驗證專案的整合變得簡單。 > 這部分看起來非常像寫測試，但我們的專案也是跟 AI 領域有關的，所以不太能使用傳統的方式測試，因此採用了不同的機制處理 很明顯的，如果只是讓 Coding Agent 直接去實作，如果缺乏事前的設計或者引導，是很難將這些細節處理完善的，這也是軟體開發的基本功即使在 AI 時代仍是非常有價值的原因，一定程度上也能減少大量 AI 反覆修改的頻率，畢竟原本就能很好的提升人類開發的速度，搭配上 AI 就能更大地提高速度。 ## 設計驅動{#design-driven} 在 AI 時代之前，軟體開發有很大一部分是由開發時程決定上限，因此寫得又快又好的工程師幾乎是最理想的，但現在速度上限是人類的狀況下，好的設計反而更有價值。 還記得在去年的時候，我跟同事分享「內聚（Cohesion）」可能是未來一個很重要的概念，以往我們只關注「耦合（Coupling）」的問題，努力在避免耦合，卻很少關心我們是否把相關的實作內聚在一起。 為什麼要內聚呢？因為這樣更適合 Coding Agent 修改，假設我們的設計達到非常理想的狀況，每一次讓 AI 做修改時都會剛好的根據規格找到特定的檔案，檔案中又剛好包含所有需要修改的部分，就很自然的可以在較少的步驟（搜尋、讀取）完成編輯。 當大家都很快的時候，這類小細節反而能夠成為更快的要素。這也變成一個很有趣的現象，過去我們不願意花時間思考、討論去釐清，是因為被時間追著跑需要不斷往前推進，但現在花更多時間釐清跟討論，可以得到一個開發更快、更穩定的系統，因為好的設計對 Coding Agent 來說也更不容易出錯、修改也更容易可控。 這也是為什麼像是 Design Pattern 這類基本功非常重要的原因，如果我們對這些知識足夠熟悉，只需要判斷在怎樣的時機引入適當的設計，就可以非常接近以往人類花費大量精力製作的高品質軟體，但又變得更快更省力。 這一切的前提，都還是在對該領域的專業有足夠的認識，單純依靠 AI 擁有的知識仍不足夠。專業的人留下，正是因為這些基本功無法被取代。