🌏 Read this article in English
CI 失敗。
你盯著螢幕。進度條卡在「Running tests」。
五分鐘。
你起身倒咖啡。回來，還是五分鐘。
複製錯誤訊息。貼給 AI。等它修正。再 push。
再等五分鐘。
然後？
又失敗了。
你滑開 Slack，同事傳了一則訊息：「好了沒？我在等 merge。」
你回：「CI 又掛了。」
卡的不是你。是流程。
上個月在台北 Meetup，Anthropic 的工程師分享了他們的做法。
現場討論很熱烈。大家不再問「AI 能不能幫我寫程式」。
大家問的是：「如何設計系統架構，讓 AI 成為開發基礎設施的一部分。」
Context 流失：記憶需要被工程化管理
每位深度使用 AI 程式助手的開發者，都經歷過這種時刻。
你花了三十分鐘，建立專案脈絡、說明程式慣例、解釋架構決策。
你覺得 AI 懂了。
然後，context window 一壓縮。
它就把細節「忘光了」。
Context 不是 AI 的記憶體，是你的基礎設施。
Anthropic 的做法很簡單：把 context 寫成檔案，每次開工自動讀回來。
聽起來土法煉鋼？但這就是工程。
你不會期待 RAM 記住昨天的事，你會把它存到硬碟。Context 也一樣。
具體怎麼做？一個 session start hook。
每次 Claude Code 開工，自動把 CLAUDE.md、ADR、規範讀回來。
就這樣。
不是跟 context 限制硬碰硬。是假設它一定會掉，然後設計怎麼撿回來。
一個值得考慮的設計前提，是把 context 流失視為常態，並建立恢復機制。
Key Insight 1: Context 不是 AI 的記憶體，而是你的基礎設施。主動管理 context 的持久化，比依賴模型的自然記憶更可靠。
權限的兩難：在自主性與控制之間取得平衡
你在心流裡。
Claude 跳出來：「要我寫這個檔案嗎？」
你按 yes。
三秒後又跳一次。
再三秒，又一次。
但問題是：安全與效率，從來不是非黑即白。
權限系統的存在，是因為自主執行程式碼確實有風險。包括意外刪除檔案、非預期的系統變更，或敏感資料外洩。
當 repo 已隔離、操作範圍清楚、回滾成本可控時，可以考慮更高自動化權限。
auto-accept hooks 模式，讓開發者能建立自訂邏輯，自動核准特定類別的操作。hook 可以檢查待執行的操作，根據預設規則進行評估，並在無需使用者介入的情況下授予核准。
想像你給實習生一張白名單——這幾個資料夾隨便動，其他要叫我。
舉例來說，hook 可以自動核准特定目錄內的所有檔案寫入。但對該範圍外的操作，仍要求確認。
對於願意承擔全部責任的開發者，dangerously-skip-permissions 旗標可完全移除核准流程。這個旗標，刻意取了嚇人的名字，作為持續提醒使用者，正在做出的取捨。
在 production repo？老老實實一個一個按。
在隔離容器跑實驗？開 dangerously-skip，反正壞了砍掉重來。
差別不在工具，在你願不願意承擔錯誤的代價。
Key Insight 2: 權限控制不是「開」或「關」的二元選擇，而是「在什麼範圍內自動，在什麼範圍內人工」的分層設計。auto-accept hooks 是平衡效率與安全的最務實解。
YOLO Push：讓 AI 進駐你的 CI 流程
然後是 YOLO Push。名字很欠揍。架構意外嚴謹。
10 個工程師。每人每天 10 次等 CI。每次 5 分鐘。
一天 8 小時，沒了。你以為在開發，其實在等。
他們的解法，徹底翻轉這個流程。
CI 掛了。Pipeline 自己裝 Claude Code。把失敗的 context 傳給它。
Claude 讀錯誤、找問題、修、commit。
沒人介入。
重跑一次。過了，繼續。沒過，再試一次，直到次數用完。
聽起來很冒險？關鍵在「Claude 能動什麼」這條線怎麼畫。
允許清單寫死：lint 錯誤、型別錯誤、格式問題、unused import。
拒絕清單也寫死：安全、機密、授權、合規。碰到身分驗證、碰到資料存取——一律人工審。
這條線怎麼落地？用官方的 Claude Code GitHub Action 在 workflow 裡跑，prompt 把允許/拒絕清單塞進去。
自動修的不是 bug，是等待。
這不只是工具的問題。這是工程師如何定義自己價值的問題。當機械性工作被自動化，你的判斷力在哪裡？
Key Insight 3: YOLO Push 的核心不是「讓 AI 寫程式」，而是「讓 AI 處理確定性的機械性錯誤」。透過允許/拒絕清單機制，將 AI 的自主權限制在低風險、高頻率的場景中。
多 Agent 程式碼審查：把 reviewer 分工
單一模型 review，問題不是它不夠聰明，是它同時要看邏輯、安全、風格——人也做不到。
邏輯一個 Agent。安全一個 Agent。風格一個。
這種做法，避免了單一模型的盲點，也減少了假陽性與假陰性的風險。
你 review 過 AI 寫的 PR，會發現它對邏輯敏感但對風格無感。所以分工合理。
單一 reviewer 的盲點不靠更聰明的模型解，靠分工。邏輯、安全、風格各派一個 Agent，最後合議——這才是 review 該長的樣子。
向上管理：如何讓主管接受這個改變？
如果你想在團隊推動 YOLO Push 或 auto-accept hooks，主管的第一反應通常是：「這安全嗎？」
先承認一件事：這確實有風險。
但問題是：你現在的人工審查，真的能擋住所有錯誤嗎？
人工審查在特定情境有效，但對高頻、低風險錯誤，邊際效益下降。
主管把責任與風險放第一，是合理考量。
你可以這樣跟主管說：
「我想在這個小功能上試試看。如果出問題，我負責。兩週後我給你數據。」
這句話讓主管知道：你是在把風險範圍、責任邊界與衡量方式說清楚。
先挑一個影響範圍清楚、回滾成本低的內部工具。把允許清單寫死——只能改 lint、format、unused import。其他一律擋掉。
然後，觀察數據。
CI 失敗率有沒有下降？開發者的等待時間有沒有減少？
用數據說話，比用理念說服更有效。
主管要的不是保證，是責任邊界。
兩週後，CI 失敗率會回答。不是你回答，也不是主管回答。
Sources
- Claude Code GitHub Repository — Claude Code 官方實作與工具參考
- Anthropic Documentation — 模型能力與 API 使用規範
- Claude Code GitHub Action — GitHub Actions 整合與參數說明
- Anthropic Engineering Blog — Anthropic 工程團隊相關技術文章
你今天的十分鐘，花在哪裡？
是花在等 CI，還是花在修那些 AI 能在允許清單內自動處理的機械性修正？