AI 幫你修 CI，聽起來很像一個很單純的省時間功能。
Workflow 紅了，log 一大串。你按一下 Fix with Copilot，agent 去看錯誤、改檔案、跑驗證，最後把修復推回 branch 或開一個 PR。這種流程很迷人，尤其是那種大家都知道很煩、但又不得不修的 lint、測試、snapshot、dependency 小爆炸。
可是我覺得真正危險的地方不在「AI 會不會改錯」。
真正危險的是，它改完以後，團隊沒有人說得清楚為什麼這樣叫做修好了。
以前 CI 紅燈通常是人在看：誰 push 的、哪個 job 掛了、是不是 flaky、要不要 rerun、該改測試還是改產品程式碼。這些判斷很多時候沒有寫成規則，只是藏在工程師的習慣裡。
現在問題來了。當 CI failure 可以直接變成 agent task，那些沒有寫下來的習慣，就會突然變成流程漏洞。
GitHub 最近把 Copilot cloud agent 往兩個方向推進。
一個是可以透過 REST API 啟動 agent task。也就是說，agent 工作不一定要從 IDE 或聊天視窗開始，也可以從公司內部 portal、script、release 工具、issue 流程，甚至其他自動化系統觸發。
另一個是從失敗的 GitHub Actions log 直接進入一鍵修復流程。失敗的 workflow 旁邊出現一個入口，讓 Copilot cloud agent 看 log、調查 repo、修改程式，完成後再叫使用者 review。
這兩件事合在一起看，重點不只是「AI 又更會寫 code 了」。
重點是 CI failure 開始變成一種可以委派的工作單位。
這很有用。但也因為太有用，所以更需要邊界。你不能只把一段錯誤訊息丟給 agent，然後期待它自然知道團隊的工程標準。
一個紅燈至少要被拆成幾個問題：
如果這些沒有先講清楚，AI repair 很容易變成一種看似完成、其實更難 review 的自動化。
CI 從紅變綠，只是結果之一。它不是完整的驗收證據。
假設前端 build 掛在 ESLint。
錯誤訊息很普通：某個 hook dependency 沒補，某個 type 太寬，某段測試 mock 沒跟新版 API 對齊。這種問題看起來非常適合交給 AI。人類看了也只是嘆一口氣，打開檔案，補一補，跑一下檢查。
但 agent 的修法有很多種。
它可以補正確 dependency。也可以把 rule disable 掉。
它可以把型別收窄。也可以塞一個 any。
它可以修測試資料。也可以把 assertion 改得比較鬆。
它可以只修那個 job。也可以順手重構旁邊三個元件，讓 diff 看起來「更乾淨」。
對 CI 來說，這幾種做法最後可能都會變綠。對工程品質來說，它們差非常多。
所以 AI 修 CI 的第一個契約，不能只寫「請修好」。
比較合理的任務描述應該像這樣：
只修復這次
frontend-ciworkflow 在 commitabc123的 lint failure。允許修改產品程式碼與對應測試，但不要調整 lint rule，不要使用 ignore comment，不要擴大到無關重構。完成後重跑原本失敗的 job，並在 PR description 說明 root cause、修改檔案與驗證結果。
這段話不漂亮，但它有工程價值。它把「修 CI」變成可驗收的工作。
沒有這層約束，agent 其實是在猜你的團隊文化。
很多人對 AI repair 的期待，是讓人類少看一點。
我覺得比較務實的說法是：它讓人類少做第一輪機械修補，但不會取消 review。甚至在某些情況下，review 會更重要。
因為人類 reviewer 看的不只是「CI 有沒有綠」。
Reviewer 要看 agent 有沒有把測試放鬆到失去意義；有沒有用 any、@ts-ignore、disable rule 之類的方法把錯誤蓋掉；有沒有把一個小失敗擴大成一個不好回滾的 refactor；有沒有改到原本不該碰的模組。
尤其是測試失敗。測試掛掉時，最差的修法不是修不動，而是把測試改到不會再抓到問題。
這也是為什麼 AI repair 的 PR description 不能只寫「fixed failing workflow」。
至少要交代四件事：
這些資訊不是給 AI 展示用的。它是讓人類可以快速判斷：這個修復能不能進主線。
AI 可以幫你把紅燈變成一個修復提案。能不能 merge，還是工程責任。
還有一件事很容易被忽略：AI repair 不是免費飄在 CI 外面。
GitHub 的 Copilot cloud agent 會在 GitHub Actions-powered 的環境裡工作，可以調查 repo、修改 branch、跑測試與 linter。Copilot code review 的 agentic 能力也會牽涉 GitHub Actions runner，而且從 2026-06-01 起，相關 review runs 會消耗 Actions minutes。
這代表 AI review、AI repair、CI job、preview deploy，最後都可能進到同一個自動化資源池。
小團隊最常見的錯誤，是把 trigger 開太大。
每個 PR 都 review。每次 push 都 repair。Bot 開的 PR 又觸發另一個 AI review。失敗了再自動修。看起來很聰明，實際上可能是在製造 runner queue、quota 壓力和更難追蹤的自動化迴圈。
Self-hosted runner 也不是免費。它只是把 GitHub-hosted minutes 換成機器維護、權限隔離、secrets 管理、排隊策略、安全邊界和平台團隊的待辦。
所以 CI repair policy 裡也應該有成本規則：
這些問題不酷，但很實際。
AI repair 一旦進入 CI，就不只是開發者便利功能。它也是基礎設施政策。
如果一個團隊要開始試 AI 修 CI，我不會建議一開始就開到所有 workflow。
先從低風險、容易驗收的地方開始。
例如 lint、typecheck、單元測試、文件建置、小型前端 build。先不要讓 agent 自動碰 production deploy、database migration、權限、billing、安全設定，除非團隊已經有很清楚的 review 與 rollback 機制。
第一版規則可以很短：
這些規則看起來保守，但保守是好事。
因為這個階段真正要驗證的，不是 agent 到底多聰明，而是你的團隊能不能把一個 CI failure 變成清楚、可執行、可驗收、可回滾的工作單位。
如果做不到，先不要怪 AI。
它只是把你原本沒有寫下來的流程假設，放大到 branch 和 runner 上。
我不反對 AI 修 CI。相反地，我覺得這會變成很常見的工程流程。
簡單、重複、明確的 CI failure，本來就不該消耗太多人類注意力。讓 agent 先處理一輪，再讓工程師 review 變更意圖與驗證結果，這個方向很合理。
但成熟的用法，不是把紅燈交給 AI 就結束。
成熟的用法，是先把紅燈整理成 AI 可以嘗試、工程師可以驗收的工作單位。
AI repair 的重點不是「它能不能把 CI 變綠」。那只是最低標準。
真正該問的是：它修了什麼、為什麼這樣修、驗證了什麼、誰看過、如果錯了怎麼退。
這些問題有答案，AI 修 CI 才是工程能力。
沒有答案，它只是另一個會把紅燈變成 PR 的按鈕。
ryanvale
iThome鐵人賽
看影片追技術