【讀書心得】二讀《Continuous Delivery》：從「玩什麼抽象」到 AI 時代的避坑指南

剛看完《Continuous Delivery（持續交付）》中文版。

相信在軟體工程界，這本書早就被很多前輩奉為聖經，書中的理論與概念有多重要，細節就不需要我再多做贅述。

這其實是我第二次讀這本書。

第一次讀：這到底在玩什麼抽象？
第一次讀這本書的時候，我才剛轉行做軟體工程師沒多久。坦白說，那時候讀起來非常痛苦，心裡的真實現想是：「這到底在玩什麼抽象的概念？為什麼要搞這麼複雜？」

那時的我，眼裡只有語法、API 和怎麼把畫面寫出來，根本無法理解為什麼需要那麼多流程、規範跟看似繁瑣的測試。

第二次讀：原來這是前人踩過的坑與必坑指南
過了三、四年，有了更多真實專案的實戰經驗、踩過無數次線上故障的坑之後，重新翻開這本書，體悟完全不一樣了。

我才發現，這本書根本不是什麼虛無飄渺的抽象理論，它是前人替我們踩遍所有坑之後，寫給後人的「必坑指南」。

正因為當年有人點出了這些事情的重要性，這幾年整個軟體生態系發生了巨大的變化。雖然書中提到的一些早期工具（例如早期的建置工具或版控系統）現在可能已經很少人在用了，但那些針對「痛點」所產生的現代工具與服務——版控（Git/GitHub）、TDD、雲端服務、CI/CD 自動化部署、Smoke Test、GitOps——如雨後春筍般出現並成為標配。

這讓我體會到一件很重要的事：

軟體商與工具有一天會更替，但背後解決問題的核心概念不會動，只會持續被優化。

這也完美印證了《鳳凰專案》裡提到的三步工作法精髓：先把路走通，再把路走順，最後持續優化。

快速快轉到 2026：AI 時代下的 CI/CD 思考
時間來到現在，我們顯然已經身處在這個「極度優化」後的 AI 時代。

現在有了 AI，要建立自動化流程、甚至訓練 AI 照著特定 SOP 跑都變得極度容易。只要輸入指令，AI 幾秒鐘就能生出一套自動化腳本或建好 CI/CD Pipeline。

但在這個 AI 大幅降低執行門檻的時代，身為工程師，我們的大腦反而更需要對前人踩過的坑保有極高的意識。

很多人以為 Context Window（上下文視窗）變大了、AI 變聰明了，就能把一切拋給 AI。但實際上，AI 在處理長流程時，非常容易發生「記憶稀釋」或忘記最基本該走的流程。它可能為了幫你快速寫完 Code，就自動忽略了 Smoke Test，或是跳過了最基礎的防禦性設計。

我現在的工程範式：戰略由我，細節給 AI
讀了《Continuous Delivery》後，我把它轉化成了我與 AI 協作的 Workflow 護欄：

討論構思與概念釐清（確定戰略方向與邊界）

強制 TDD（讓 AI 先寫測試案例，把邊界條件固定）

撰寫程式碼與驗證（讓 AI 在防護網內執行）

自動化部署與驗收（由我最終 Check 是否違反架構原則）

我的角色從過去「手動鋪路的人」，變成了「設定戰略方向與驗收成果的監理者」。

工具在變，AI 越強，概念反而越重要。 不懂 CD 與架構的人，更可能讓 AI 快速產生一堆難以維護的程式碼；而理解這些底層邏輯的人，才能讓 AI 成為一個高產出、有嚴格規範的頂級助手。

如果你很久以前也讀過《Continuous Delivery》且覺得抽象，帶有幾年開發經驗後重讀一次，你會發現，這依然是軟體工程裡最不退流行的經典之一。