🌏 Read this article in English
PR 速度翻倍了,rollback 次數也翻倍
上週的 retrospective,工程主管在白板上貼了兩張圖。
左邊:PR merge 數量,三個月內從每週 32 個跳到 71 個。
右邊:production rollback 次數,從每月 2 次變成 5 次。
「AI 確實讓我們寫得快了。」他說。
「那為什麼 rollback 也跟著翻倍?」一位 Senior 問。
「被 rollback 的 PR,全部都通過了 CI。」
會議室安靜了幾秒。
⸻
這不是個別案例。
很多團隊上了 AI 之後,都遇到同樣的反饋落差:
- 寫程式碼的速度上去了。
- 但 review、測試、部署這條反饋鏈,還是用三年前的密度。
差距不是工具好不好用,是「流程有沒有跟上工具的速度」。
先說清楚,SDLC 從來沒有過時
很多人聽到「SDLC」(軟體開發生命週期),覺得這是舊時代的遺物。
「現在都 Agile 了,誰還畫甘特圖?」
「DevOps 就是快,SDLC 太慢了。」
先承認一件事:SDLC 從來沒有過時。
它是一個框架。
定義了軟體從誕生到死亡的「階段」。
不管你是用 Waterfall、Agile、還是 DevOps,你依然要經歷這些階段:
- 需求分析
- 設計
- 開發
- 測試
- 部署
- 維護
DevOps 沒有取代 SDLC。
DevOps 是改變了執行這些階段的方式。
DevOps 不是工具,是文化。
想像一下蓋房子:
- SDLC 是建築流程:打地基 → 砌牆 → 裝電 → 粉刷。
- DevOps 是建築文化:工人和設計師一起開會,而不是各做各的。
- CI/CD 是自動化機械臂:自動砌牆、自動噴漆。
你不能用機械臂(CI/CD)取代流程(SDLC)。
沒有流程,自動化只會把既有瓶頸放大。
⸻
沒有流程,自動化只會把既有瓶頸放大。
這句話值得重複一遍。
因為很多團隊以為買了 Jenkins、設定了 Pipeline,就是 DevOps 了。
但現實是:
- 測試失敗了,工程師不知道怎麼修。
- 部署後,Production 環境指標異常。
- 團隊還是各做各的,Dev 抱怨 Ops 慢,Ops 抱怨 Dev 亂。
這就是「沒有 DevOps 文化的 CI/CD」。
它只是把舊流程自動化了而已。
三層架構:你的地圖
為了讓這篇文章不變成教科書,我們用一個簡單的三層模型來看清楚關係。
第一層:SDLC(定義階段)
SDLC 是「什麼」。
它回答:我們需要做哪些事?
在傳統模式下,這些階段是序列式的。
需求 → 設計 → 開發 → 測試 → 部署 → 維護在高變動的情境下,這個序列的反饋週期會拉長 — 開發完成後測試才開始,測試通過後部署才動作,使用者收到的反饋常常是幾個月之後。
但在需求穩定的情境下,這套框架依然有效。
它提供了必要的紀律。
第二層:DevOps(改變執行)
DevOps 是「怎麼做」。
它回答:我們如何打破部門牆,讓流程變快?
DevOps 的核心不是工具,是文化。
它要求開發和營運從對立走向合作。
在 DevOps 視角下,SDLC 的階段不再是孤立的島嶼,而是迭代式的循環。
需求 ⇄ 設計 ⇄ 開發 ⇄ 測試 ⇄ 部署 ⇄ 維護
↑_________________________↓
Feedback Loop這個循環的關鍵,是短週期。
一天部署多次,而不是半年一次。
第三層:CI/CD(具體實踐)
CI/CD 是「用什麼做」。
它是 DevOps 文化的具體實現。
- CI:持續整合。每次提交代碼,自動構建和測試。
- CD:持續交付/部署。測試通過後,自動部署。
CI/CD 橫跨了 SDLC 的開發、測試、部署階段。
但它不是 SDLC 的一個階段。
它是加速器。
⸻
CI/CD 不會帶來 DevOps,DevOps 才會用好 CI/CD。
很多團隊搞反了順序。
他們先買工具,再談文化。
結果工具成了負擔。
AI 如何介入這三層?
現在,我們談談 AI。
很多人問:「AI 會取代 DevOps 工程師嗎?」
不會。AI 改變的是 DevOps 工程師花時間的地方——從重複勞動轉向架構判斷。
AI 在 SDLC 和 DevOps 中的角色完全不同。
SDLC 視角:AI 優化每個階段
在 SDLC 框架下,AI 是每個階段的「超級助理」。
GitHub Copilot、Cursor、ChatGPT 這幾年的進步,把「程式碼補全」從關鍵字匹配推到語意級別 — 這在 18 個月前還辦不到。下面這張表列出 AI 在 SDLC 各階段的切入點,每個工具都有自己的甜蜜點,重點是判斷你的工作流落在哪一格。
| SDLC 階段 | 傳統痛點 | AI 介入方式 | 具體工具範例 |
|---|---|---|---|
| 需求分析 | 需求模糊,開發者誤解 | AI 輔助生成 User Story,檢查邏輯漏洞 | GitHub Copilot Chat, ChatGPT |
| 設計 | 架構決策依賴個人經驗 | AI 輔助草擬架構圖,提出候選方案 | Mermaid AI, Lucidchart AI |
| 開發 | 重複性代碼,Context Switch | AI 生成 Boilerplate,自動補全 | Copilot, Cursor, Codeium |
| 測試 | 測試覆蓋率低,邊界條件漏測 | AI 生成測試用例,提出候選修復 | Diffblue Cover, Testim |
| 部署 | 環境配置錯誤,依賴手動 | AI 生成 IaC 代碼,自動檢查配置 | Terraform + AI, Pulumi |
| 維護 | 技術債累積,沒人敢動 | AI 分析代碼複雜度,建議重構 | SonarQube + AI, CodeScene |
關鍵洞察:
AI 在 SDLC 的價值,不是『寫完整個系統』,而是『縮短反饋時間』。
在測試規格清楚、程式邊界明確時,反饋時間可從天級縮短到分鐘級草案。
以前,測試團隊要等開發完成後一週才能開始寫測試。
現在,AI 在開發的同時,已經生成了測試用例。
反饋時間從「週」縮短到「分鐘」。
這就是 AI 加速 SDLC 的本質。
DevOps 視角:AI 加速持續交付
在 DevOps 視角下,AI 是整個 Pipeline 的「優化器」。
DevOps 的核心是持續交付。
AI 讓這個循環轉得更快、更穩。
CI 階段:AI 輔助整合
傳統 CI:代碼提交 → 觸發 Jenkins → 運行測試 → 報告結果。
AI 增強 CI:
- AI 預先檢查代碼風格和潛在 Bug。
- AI 建議最佳合併策略。
- AI 自動生成 Changelog。
CD 階段:AI 輔助部署
傳統 CD:手動確認部署 → 執行腳本 → 監控日誌。
AI 增強 CD:
- AI 預測部署風險(基於歷史數據)。
- AI 輔助異常偵測與回滾建議;實際回滾仍需受 SLO、部署策略與人工授權約束。
- AI 優化資源配置(根據負載自動伸縮)。
但問題是:
很多團隊以為上了 CI/CD 就是 DevOps。
如果沒有 DevOps 文化,CI/CD 只會變成「自動化的混亂」。
常見混淆:為什麼 CI/CD 沒有發揮預期價值?
你買了 Jenkins,設定了 Pipeline,代碼自動構建、自動測試、自動部署。
看起來很完美。
但現實是:
- 測試失敗了,工程師不知道怎麼修。
- 部署後,Production 環境指標異常。
- 團隊還是各做各的,Dev 抱怨 Ops 慢,Ops 抱怨 Dev 亂。
這就是「沒有 DevOps 文化的 CI/CD」。
它只是把舊流程自動化了而已。
誤解一:CI/CD 是 SDLC 的一個階段
CI/CD 是橫跨多個階段的實踐。
它不是一個階段,而是一個流程。
誤解二:DevOps 是開發者的事
DevOps 是整個團隊的事。
如果 Ops 不參與設計,如果 QA 不參與部署,DevOps 的協作效益會受限。
誤解三:AI 會取代 DevOps 工程師
AI 會接手「重複性勞動」。
但 DevOps 的核心是判斷。
- 什麼時候該部署?
- 哪個 Bug 該優先修?
- 架構該怎麼調整?
這些判斷,AI 無法獨立完成。
AI 可以提供候選方案與風險訊號,但責任歸屬與取捨仍需要人做最後判斷。
取捨:AI 加速的代價
AI 帶速度,也帶新的判斷成本。
風險一:過度依賴 AI
如果工程師完全依賴 AI 生成代碼,他們的技術能力會退化。
Trade-off:
- 適合:快速原型、Boilerplate 代碼、學習新語言。
- 不適合:核心業務邏輯、架構設計、安全敏感模組。
判準:
如果這個代碼出錯,會影響十萬筆用戶資料,不要完全依賴 AI。
如果這個代碼只是內部工具,可以用 AI 加速。
風險二:安全漏洞
AI 生成的代碼可能包含安全漏洞。
根據 OWASP 的 AI Security and Privacy Guide,風險來源於訓練數據中的不安全範例,以及模型對惡意輸入的誤判。
Trade-off:
- 適合:快速開發,容忍一定風險。
- 不適合:金融、醫療、政府等高安全要求領域。
判準:
在高安全領域,AI 生成的代碼必須經過嚴格的人工審查。
風險三:技術債累積
AI 生成的代碼可能可維護性較低,抽象邊界與一致性需要額外審查。
如果團隊不重視代碼品質,技術債會快速累積。
Trade-off:
- 適合:短期專案、MVP。
- 不適合:長期維護的系統。
判準:
如果這個系統要維護三年以上,必須有 Code Review 機制。
AI 可以生成代碼,但不能保證代碼品質。
⸻
若缺少審查與練習機制,團隊可能降低對底層設計的敏感度。
這不是危言聳聽。
我見過幾個團隊,用了 AI 後,代碼量翻倍,但技術債也翻倍。
因為沒有人願意花時間去理解 AI 生成的代碼。
決策框架:可以從哪裡切入?
較穩妥的做法是先釐清成熟度。
用這個框架決定你的 AI 導入策略。
第一步:評估你的成熟度
| 成熟度 | 特徵 | 建議 |
|---|---|---|
| 初級 | 手動部署,無測試 | 先建立 CI/CD,再考慮 AI |
| 中級 | 有 CI/CD,但手動測試 | 用 AI 輔助測試生成 |
| 高級 | 自動化測試,頻繁部署 | 用 AI 優化 Pipeline 和架構 |
| 專家級 | 全自動化,AIOps | 用 AI 預測和自癒 |
第二步:選擇你的切入點
可以從單一痛點試點。
選一個痛點,用 AI 解決。
例如:
- 痛點:測試覆蓋率低。
- 解法:用 AI 生成測試用例。
- 預期結果:測試覆蓋率從 40% 提升到 70%。
第三步:建立反饋循環
AI 不是設定完就結束。
你需要持續監控 AI 的效果。
- AI 生成的代碼,Bug 率是多少?
- AI 輔助的開發速度,提升了多少?
- 團隊對 AI 的接受度如何?
關鍵洞察:
工具是放大器。放大的是你本來就有的能力。
如果你本來就沒有測試文化,AI 只會幫你生成更多低價值的測試。
如果你本來就沒有 Code Review 文化,AI 只會幫你生成更多缺少審查的程式碼。
三個低風險切入點
若要降低導入風險,可以先從以下三個工作流開始試點。
1. 建立 AI 輔助的 Code Review 流程
不要依賴 AI 自動 Merge。
讓 AI 生成 Review 建議,但由人類做最終決定。
具體步驟:
- 在 GitHub Actions 中加入 AI Review 步驟。
- AI 生成 Review 評論。
- 工程師審閱 AI 的評論。
- 工程師決定是否接受。
⸻
關於 Code Review 的實作細節:
我建議用 Copilot 或 CodeRabbit 這類工具。
但要注意幾件事:
- 權限控制:確保 AI 不會讀取敏感資料。
- 資料外流:確認公司政策是否允許將代碼發送到外部 API。
- 誤報審查:AI 可能會提出不合理的建議,工程師必須具備判斷力。
2. 用 AI 優化你的 CI/CD Pipeline
檢查你的 Pipeline,找出瓶頸。
- 哪個步驟最慢?
- 哪個步驟最容易失敗?
用 AI 優化這些步驟。
具體步驟:
- 用 AI 分析 Pipeline 日誌。
- AI 建議優化方案(例如:平行執行、快取策略)。
- 實施優化。
3. 建立 AI 使用的團隊規範
不要讓每個人都隨意使用 AI。
建立規範,確保品質和安全。
具體步驟:
- 定義哪些模組可以用 AI。
- 定義哪些模組不能用 AI。
- 定期審查 AI 生成的代碼。
AI 時代,工程師的價值正在從「寫程式」轉向「判斷」。
AI 能加速寫程式碼,但判斷『該不該寫、寫得對不對』的能力,還是人的。
SDLC、DevOps、CI/CD,這三層架構不是對立的。
它們是層層遞進的。
- SDLC 是基礎。
- DevOps 是文化。
- CI/CD 是實踐。
- AI 是加速器。
加速器會優先放大既有流程的優點與缺口。
你的反饋循環,現在是天還是分鐘?
給主管的話術範例
如果你需要說服團隊或主管接受這個改變,可以試試看這些話術:
情境一:解釋為什麼要用 AI
「我們把重複性工作交給 AI,讓人把時間放在架構判斷與責任承擔。」
情境二:節奏與承諾
「這不是一次性的大改造。我們先做一個可逆試點,兩週後我給你數據。如果沒效果,隨時停。」
情境三:處理安全疑慮
「AI 生成的代碼,我會當作 Junior 的 PR 來 review。加上一份 checklist,確保沒有敏感資訊外流。如果出問題,責任在我,不在 AI。」
情境四:解釋成本與效益
「AI 在快速原型和 Boilerplate 上效率最高,這部分讓它接手。核心業務邏輯這條線,還是走資深工程師的判斷。」
Sources
- AWS：使用生成式 AI 為軟體開發體驗提供支援 — —生成式AI貫穿SDLC
- Atlassian：什麼是 DevOps 文化？ — —DevOps 文化與協作定義
- Continuous Integration – Martin Fowler — Fowler 版 CI 定義與實務指南
- Agile Manifesto — 敏捷開發四大價值觀與作者
- Ron Jeffries：什麼是 Extreme Programming？ — XP 入門—小版本與整合
- OWASP AI Security and Privacy Guide — AI 防護實務、參考與標準共識
- GitHub Copilot Documentation — 官方 AI 程式助理功能、設定與管理指南
- AWS 規範指引：AIOps — AIOps 營運實踐與異常偵測
DevOps 沒有取代 SDLC。DevOps 是讓 SDLC 的階段從「接力賽」變成「橄欖球賽」。
AI 加速的是「反饋循環」,不是「決策過程」。