當 AI 從助手進化為基礎設施
Anthropic 產品工程師如何運用 hooks、多 Agent 協作與自動化 CI 流程，重新定義開發者工作流程
Claude Code Meetup Taipei 吸引了超過 400 名開發者，渴望了解 Anthropic 工程師如何在正式環境中使用 Claude Code。活動僅開放 200 個名額，報名人數卻遠超預期，這股熱潮反映出產業正在經歷的重大轉變：開發者不再只是問「AI 能不能幫我寫程式」，而是開始思考「如何設計系統架構，讓 AI 成為開發基礎設施的一部分」。
兩位 Anthropic 產品工程師 Dickson Tsai 與 Oliver Wang 分享的見解，挑戰了 AI 輔助開發的傳統思維。他們的核心訊息很明確：未來的重點不在於讓 AI 替你寫程式，而在於讓 AI 融入整個軟體開發生命週期。本文將萃取他們的關鍵技術洞見，並探討實現這個願景的架構模式。
Context 持久化問題：為什麼你的 AI 總是在遺忘
每位深度使用 AI 程式助手的開發者，都曾體驗過 Context 流失的挫折感。你花了三十分鐘建立專案脈絡、說明程式慣例、解釋架構決策，結果 Context Window 一壓縮，AI 就把一切都「忘光了」。Dickson Tsai 直接點出這個痛點，並透露即使是 Anthropic 內部團隊也面臨同樣的挑戰。
Tsai 解釋，解決方案不是等待更大的 Context Window，而是把 Context 當作基礎設施來經營。當 Claude Code 執行壓縮作業以管理 token 上限時，關鍵的專案資訊可能隨之流失。工程上的回應方式是將 Context 外部化至持久儲存，並在需要時自動重新注入。這麼做能將一次性的對話轉變為具有狀態的開發環境。
Anthropic 建議的模式是使用 Session start hooks，也就是在每次 Claude Code 工作階段啟動時自動執行的腳本。這些 Hooks 會讀取專案文件，在任何使用者互動開始前注入必要的 Context。實作上需要建立 Hook 設定檔，參照專案的 CLAUDE.md、架構決策紀錄（ADR）與程式規範文件。當壓縮發生後，下一次工作階段會自動恢復原本可能流失的基礎 context。
這種做法代表思維上的根本轉變：與其對抗 context 限制，工程師應該假設 context 必定會流失，並據此建立恢復機制。最終成果是更具韌性的開發流程，能在 token 壓力下優雅降級。
權限的兩難：在自主性與控制之間取得平衡
這場聚會討論最熱烈的痛點之一，是頻繁的權限提示打斷了 Claude Code 的自主運作。預設情況下，每次檔案寫入、每個 shell 指令、每次外部 API 呼叫都需要明確核准。對於追求心流狀態的開發者而言，這些中斷令人抓狂。
Tsai 坦承，安全與效率之間的張力沒有完美解法。權限系統的存在是因為自主執行程式碼確實有風險，包括意外刪除檔案、非預期的系統變更，或敏感資料外洩。然而，對於理解這些風險並在適當環境中工作的開發者，Anthropic 提供了彈性機制。
auto-accept hooks 模式讓開發者能建立自訂邏輯，自動核准特定類別的操作。hook 可以檢查待執行的操作，根據預設規則進行評估，並在無需使用者介入的情況下授予核准。舉例來說，hook 可以自動核准特定目錄內的所有檔案寫入，但對該範圍外的操作仍要求確認。
對於願意承擔全部責任的開發者，dangerously-skip-permissions 旗標可完全移除核准流程。這個旗標刻意取了嚇人的名字，作為持續提醒使用者正在做出的取捨。Tsai 強調，這個選項只應在隔離環境中使用，例如容器化的開發設定、可拋棄式虛擬機，或任何錯誤影響範圍受到控制的 CI 流程。
這裡的啟示不僅限於 Claude Code：隨著 AI 系統能力日益強大，人類監督與機器自主之間的介面成為關鍵的設計考量。AI 程式工具中浮現的模式，很可能影響我們在各領域思考 AI 自主性的方式。
YOLO Push：讓 AI 進駐你的 CI 流程
Oliver Wang 的演講介紹了或許是當天最具話題性的概念：YOLO Push。這個名稱刻意呼應「你只活一次」的魯莽哲學，但底層架構其實相當嚴謹。
Wang 的團隊在 Anthropic 每天處理數百筆大型程式庫的 commit。他們的 CI 流程通常需要五到十分鐘完成，而最常見的失敗都是容易修復的小問題：變數名稱打錯字、未使用的 import 觸發 linter 錯誤、格式不一致，或輕微的型別不符。這些失敗並非程式邏輯錯誤，而是任何稱職的開發者坐在鍵盤前幾秒鐘就能修好的機械性問題。
處理這類失敗的傳統流程相當痛苦：等 CI 失敗、複製錯誤訊息、貼到 Claude、等待修正建議、commit 變更、再次 push，然後再等五到十分鐘看修正是否成功。將這個過程乘上開發者人數與 commit 數量，累積的摩擦成本相當可觀。
Wang 的解法徹底翻轉這個流程。當 CI 失敗時，pipeline 本身會安裝 Claude Code，並將失敗的 context 傳給它。Claude 讀取錯誤輸出、辨識問題、產生修正並 commit 變更，全程無需人工介入。Pipeline 接著重新執行失敗的檢查。若通過，commit 繼續進行；若再次失敗，Claude 會再嘗試一次，直到達到設定的最大重試次數。
讓這個機制安全運作的關鍵，是嚴格界定 Claude 可以自主修復的範圍。Wang 的團隊維護一份明確的允許清單，涵蓋可修復的問題類型：lint 錯誤、型別錯誤、格式問題、未使用的 import，以及類似的機械性問題。同樣重要的是拒絕清單：安全漏洞、機密外洩、授權邏輯、合規相關程式碼，以及任何涉及身分驗證或資料存取的部分。這些類別一律需要人工審查，無論修正看起來多麼明顯。
實作上運用了官方的 Claude Code GitHub Action，它提供在 GitHub Actions workflow 中執行 Claude Code 所需的基礎設施。這個 Action 處理驗證、環境設定，以及 Claude 輸出與 GitHub commit 機制之間的整合。團隊可以自訂 prompt 來指定各自的允許清單與拒絕清單，max-turns 參數則能防止無限迴圈。
Wang 表示，這種模式已在大型科技公司成為主流，儘管具體實作各有不同。共通點在於認知到：某些類別的 CI 失敗代表已知的機械性問題，具有確定性的解法，正是應該自動化的工作類型。
微深度論述 YOLO Push 與 Claude Code 非同步 DevOps Agent
什麼是 YOLO Push？
「YOLO」是「You Only Live Once」（人生只活一次）的縮寫，在軟體開發者的文化中，「YOLO push」代表一種「先推上去再說」的開發心態。開發者不在本地端做太多驗證，而是直接把程式碼推送到遠端儲存庫，讓 CI/CD 流程來驗證程式碼是否正確。這種做法雖然看似冒險，但在某些情境下確實能加速開發流程，尤其是當本地環境與 CI 環境存在差異時，有時候直接推上去測試反而更有效率。
與 Claude Code 協作時的斷點問題
當我們與 Claude Code 一起進行開發工作時，整個工作流程通常會在兩個關鍵點「中斷」或遇到阻礙。第一個斷點發生在 Claude Code 協助撰寫程式碼的階段，這個階段其實問題不大，因為開發者與 Claude Code 之間是即時互動的，任何問題都可以當場溝通並修正。
真正痛苦的是第二個斷點：當程式碼被推送到 GitHub 並觸發 CI 流程時。這個階段經常會發現各種在本地端沒有出現的問題，例如 ESLint 或 Prettier 的格式檢查失敗、單元測試無法通過、TypeScript 型別檢查錯誤、相依套件版本衝突、環境變數遺漏，或是 E2E 測試失敗等等。當這些問題發生時，開發者必須手動介入：先查看 CI 的錯誤紀錄，然後把程式碼拉回本地端，嘗試重現問題並修復，接著再次推送，然後等待 CI 重新執行。如果還是失敗，就得重複這整個循環，這個過程非常耗時且令人沮喪。
解決方案的核心概念
這段內容提出的解決方案是：讓 Claude Code 也運行在 GitHub Actions 上。當 CI 流程中發生任何錯誤時，不是由開發者手動介入修復，而是直接請運行在 CI 環境中的 Claude Code 來自動修復問題。這個概念的核心在於，Claude Code 不再只是開發者本地端的助手，而是成為 CI/CD 流程中的一個自動化 Agent，能夠即時回應並處理建置過程中的錯誤。
實現這個概念的技術關鍵是 CC SDK（Claude Code SDK）。CC SDK 是 Claude Code 提供的軟體開發套件，它允許開發者將 Claude Code 的能力以程式化的方式嵌入到任何應用程式或自動化流程中。透過 CC SDK，我們可以在 GitHub Actions 的工作流程中呼叫 Claude Code，讓它分析錯誤訊息、定位問題所在的檔案、進行必要的程式碼修改，然後自動提交修復並重新觸發 CI 流程。
實際運作流程
在這個新架構下，開發者的工作流程會變得非常簡潔。開發者只需要將程式碼推送到 GitHub，然後就可以去做其他事情。GitHub Actions 會在背景自動執行 CI 流程，如果一切順利，程式碼就會被部署到正式環境。如果 CI 過程中發生錯誤，內嵌在 GitHub Actions 中的 Claude Code Agent 會自動接手：它會分析錯誤紀錄、理解問題的根本原因、找到需要修改的檔案、進行修復、提交變更，然後重新觸發 CI 流程。整個過程完全不需要開發者介入，開發者只會在最後收到一個通知，告訴他 PR 已經成功修復並通過所有測試。
進階應用：E2E 測試 Agent
這個概念還可以進一步延伸到前端的 Smoke Test 和 E2E 測試領域。開發者可以建立一個專門執行端對端測試的 Agent，這個 Agent 結合了 Playwright 這類瀏覽器自動化工具與 CC SDK。當預覽環境部署完成後，這個 E2E Agent 會自動啟動，模擬真實使用者的操作流程，例如登入、瀏覽商品、加入購物車、結帳等等。如果任何測試場景失敗，Agent 不只是回報錯誤，它還會讓 Claude Code 分析失敗的原因（甚至可以擷取當時的螢幕截圖作為分析素材），然後自動修復前端程式碼中的問題。這意味著前端的 E2E 測試不再只是「發現問題」，而是「發現問題並自動解決問題」。
非同步 DevOps Agent 的意義
將這個架構稱為「非同步 DevOps Agent」是有其深意的。在傳統的開發模式中，開發者與 CI 流程之間是同步的關係：開發者推送程式碼後，必須等待 CI 執行完成，如果失敗就要手動修復，這個過程中開發者的注意力被 CI 流程所「綁定」。而在這個新架構中，開發者與 CI 流程變成了非同步的關係：開發者推送程式碼後就可以完全轉移注意力到其他任務上，所有的錯誤處理和修復工作都由 Agent 在背景自動完成。這不只是節省時間，更重要的是解放了開發者的認知資源，讓他們可以專注在更有創造性的工作上。
公式總結
因此這段內容最後總結出一個簡潔的公式：CC SDK 加上 GitHub Actions 等於 Async DevOps Agent。CC SDK 提供了將 Claude Code 能力程式化的介面，GitHub Actions 提供了自動化執行的平台和觸發機制，兩者結合就創造出一個能夠在背景持續運作、自動處理 CI/CD 問題的智慧型 Agent。這個 Agent 不只能修復 Lint 錯誤或測試失敗這類簡單問題，透過與 E2E 測試工具的整合，它甚至能處理更複雜的前端整合問題，真正實現「推上去就不用管」的 YOLO Push 理想。
潛在挑戰與注意事項
當然這個架構也有其限制和需要注意的地方。首先是 API 成本的考量，頻繁呼叫 Claude Code API 會產生費用，需要在效率和成本之間取得平衡。其次是修復品質的問題，AI 自動生成的修復不一定是最佳解，對於重要的變更仍然需要人工審查。安全性也是一個重要考量，API Key 必須透過 GitHub Secrets 安全存放，避免洩漏。此外，某些複雜的架構性問題可能超出自動修復的能力範圍，這時還是需要開發者介入處理。最後，E2E 測試的有效運作需要穩定的預覽環境，這也需要額外的基礎設施支援。儘管如此，這個架構仍然代表了一個令人興奮的發展方向，展示了 AI 如何能夠更深入地整合到軟體開發的工作流程中。
多 Agent 程式碼審查：以信賴度評分進行品質控管
這場聚會也揭露了 Anthropic 內部自動化程式碼審查的架構，實作為官方 Claude Code repository 中的 code-review 外掛。這套系統解決了長年困擾自動化程式碼分析的難題：假陽性問題。
傳統靜態分析工具以產生雜訊著稱。它們標記的潛在問題，經人工檢視後往往發現是刻意的設計決策或可接受的取捨。開發者學會忽略警告，真正的問題也因此淹沒在雜訊中。Anthropic 的做法是讓多個專門化的 Agent 平行運作，並結合信賴度評分來過濾結果。
當 code-review 指令執行時，會同時啟動四到五個獨立的 Claude 實例。其中兩個專注於 CLAUDE.md 合規性，檢查程式碼變更是否遵守專案文件中記載的標準。這種冗餘設計是刻意的，讓兩個 Agent 獨立評估合規性可降低遺漏違規的機率。第三個 Agent 專精於錯誤偵測，只檢查變更程式碼中的明顯錯誤。第四個 Agent 分析 git 歷史與 blame 資訊，以理解變更的脈絡。
各 Agent 獨立產出發現後，進入獨立的評分階段。每個被辨識的問題會根據證據強度與驗證狀態，獲得零到一百的信賴度分數。針對 CLAUDE.md 合規性問題，評分器會驗證相關規範是否明確涵蓋被標記的行為。預設門檻為八十分，只有信賴度達到或超過此門檻的問題才會出現在最終報告中。
這個架構體現了一個延伸至程式碼審查之外的原則：當 AI 系統產出不確定的結果時，量化並傳達這種不確定性能促成更好的人為決策。與其將所有發現呈現為同等有效，信賴度評分幫助審查者將注意力集中在最可能是真正問題的項目上。
這個外掛與 GitHub 的 pull request 流程整合，發布附有相關程式碼位置直接連結的審查評論。若未發現高信賴度問題，外掛會完全略過發布，避免困擾許多自動化審查系統的通知疲勞。
多工作階段協作：跨 Claude 實例共享 Context
Wang 介紹了另一個解決同時使用多個 Claude Code 工作階段挑戰的模式。當開發者平行執行多個工作階段時（例如一個探索重構方案，另一個實作新功能），每個工作階段都是獨立運作的。在某個工作階段獲得的知識不會自動轉移到其他工作階段。
Shared-Context 資料夾模式提供了一個輕量級解法。開發者建立一個指定目錄，作為所有工作階段都能存取的知識庫。當某個工作階段遇到 bug、發現陷阱，或辨識出不應立即處理的技術債時，它會將筆記寫入 Shared-Context 資料夾。其他工作階段可透過 add-dir 指令從這個資料夾讀取，將累積的知識納入自身的 context。
這個模式在功能開發期間管理技術債時特別有價值。當 Claude 遇到應該重構但會讓當前 PR 過於龐大的程式碼時，可以在 Shared Context 中記錄這個問題。另一個獨立的工作階段（或未來的開發 sprint）就能有系統地處理累積的債務。
這個流程為 AI 輔助開發創造了一種組織記憶。工作階段不必每次都從零開始，而能繼承前任工作階段的學習成果。這反映了人類開發團隊的運作方式：透過文件、程式碼註解與團隊討論進行知識共享。shared-context 模式為 AI 工作階段提供了類似的機制。
品味問題：為什麼程式規範難以自動化
兩位工程師都聚焦在一個關於 AI 輔助開發限制的細膩觀點：程式規範涉及的是品味，而非僅僅是正確性。這個區別對團隊思考如何自動化程式碼品質有深遠影響。
語法錯誤是客觀的錯誤：程式碼無法編譯或會拋出執行階段例外。型別錯誤同樣是二元的：型別不是符合就是不符合。但一個函式是否應該抽取為輔助函式、一段註解是增添價值還是製造雜訊、某個抽象層是否過度設計，這些問題涉及的判斷會因團隊與情境而異。
Tsai 指出，Claude 的訓練資料來自許多具有不同慣例的 repository。在新創公司快速迭代的程式庫中算是好風格的寫法，放到安全關鍵的金融系統可能並不適當。某個團隊奉為圭臬的 DRY 原則（Don’t Repeat Yourself），可能被另一個重視程式碼局部性與可讀性的團隊刻意違反。
實務上的意涵是：AI 程式碼審查應專注於客觀問題，同時將風格議題標記出來交由人工判斷。CLAUDE.md 檔案在此扮演關鍵角色，它以 Claude 能參照的格式記載團隊的特定品味。但即使有詳盡的風格指南，品味的最終仲裁者仍應是理解程式庫完整脈絡與團隊價值觀的人類審查者。
Wang 提出了更激進的重新框架：或許對人類可讀程式碼的強調需要重新思考。乾淨程式碼實踐的歷史正當性圍繞在可維護性，程式碼被閱讀的次數遠多於被撰寫的次數，因此為可讀性最佳化能隨時間獲得回報。但在 AI Agent 處理大部分程式碼閱讀與修改的未來，這個算式可能會改變。對 AI 處理最佳化的程式碼，可能與對人類理解最佳化的程式碼有所不同。
這個觀察並非建議今天就放棄可讀性標準，但它確實凸顯了我們當前實踐多麼深刻地預設人類讀者的存在。隨著 AI 能力進步，其中某些預設可能值得重新檢視。
2026 年的 Context 新局
Tsai 提到 Anthropic 預期在 2026 年前，context 處理與注意力機制將有重大突破。這個時程表暗示，目前討論的某些變通方案（session start hooks、shared-context 資料夾、積極撰寫文件）可能會變得不那麼必要，因為模型將能更有效地原生處理更長的 context。
然而，現在建立的模式即使在 context 能力改善後仍可能保有價值。將設定外部化至檔案而非依賴對話 context，能產出更具可重現性、可版本控制的流程。為 context 恢復而設計的韌性，無論底層模型能力如何都能使系統受益。而清楚界定 AI 能與不能自主執行什麼的紀律，則直接對應到治理與合規要求。
當前的限制正迫使開發者仔細思考 AI 整合架構。當這些限制放寬時，架構思維仍將適用。現在發展出健全模式的團隊，將比那些只是繞過當前限制而未深入思考的團隊，更有能力善用未來的新功能。
如何開始採用這些模式
對於有意採用這些模式的團隊，起點是 Anthropic 的官方 repository。Claude-Code repository 包含外掛系統，其中 code-review 外掛實作了具備信賴度評分的多 Agent 審查。claude-code-action repository 則提供 GitHub Action，支援 YOLO Push 等 CI 整合模式。
先從文件模式開始，因為它們不需要基礎設施變更。在 repository 根目錄建立 CLAUDE.md 檔案，記載程式規範、架構決策與專案特定慣例。這份檔案作為人類開發者與 AI Agent 都能參照的單一真相來源。
接著試驗能自動載入這些 context 的 session start hooks。hooks 系統允許在 Claude Code 工作階段啟動時執行任意 shell 指令，為壓縮後的 context 恢復提供注入點。
對於 CI 整合，採取保守策略起步。設定 Claude Code GitHub Action 只處理最機械性的失敗：linting 與格式問題，這類修正是確定性的，錯誤變更的風險極低。隨著信心增長，逐步擴大自動化修正的範圍，同時對敏感程式碼路徑維持嚴格的拒絕清單。
在整個過程中追蹤自動化成效的指標：CI 失敗中有多少比例被自動解決？自動化修正多常引入新問題？相較於人工介入節省了多少時間？這些指標能引導信賴度門檻與範圍邊界的校準。
是基礎設施，不是魔法
Claude Code Meetup 最重要的洞見並非任何單一技術或模式，而是將 AI 視為基礎設施而非魔法的整體框架。演講的工程師不把 Claude 當作能按需產出完美程式碼的萬能解答者，而是視其為強大但可能出錯的元件，需要謹慎整合、明確邊界與持續校準。
這個觀點與產業過往採納變革性技術的方式一致。資料庫在交易語意與備份系統成熟前，不被信任處理關鍵資料。雲端運算在安全實務跟上腳步前，不被用於敏感工作負載。AI 輔助開發正走在類似的軌跡上，隨著安全整合模式的浮現，組織逐步擴大 AI 自主的範圍。
聚會中分享的模式（透過 hooks 達成 context 持久化、透過允許清單界定自主範圍、透過信賴度評分進行品質控管）代表這些安全整合實務的當前前沿。它們會隨著能力演進與組織累積運作經驗而發展。但將 AI 整合視為工程問題而非部署勾選項的底層紀律，無論具體技術如何變化都將保持相關。
對於關注這個領域的開發者與工程主管，參與的時機就是現在。今天建立的模式將形塑 AI 輔助開發在未來數年的運作方式。透過實際動手實驗來發展內部專業知識的組織，將更有能力在掌握生產力效益的同時管控風險。而那些等待完美解方的組織，可能發現自己永遠在追趕那些擁抱不完美但務實做法的同業。
未來不是 AI 替我們寫程式，而是 AI 與我們一起寫程式：嵌入我們的流程、受我們的標準約束，並透過展現的可靠性逐步贏得更大的信任。這場聚會讓我們一窺這個未來在實務中的樣貌，而它比許多人想像的更近了。
參考資料與資源
- 官方 Repository
- Claude Code：https://github.com/anthropics/claude-code
- Claude Code Action：https://github.com/anthropics/claude-code-action
- 官方外掛：https://github.com/anthropics/claude-plugins-official
- 技術文件
- GitHub Actions 整合：https://code.claude.com/docs/en/github-actions
- 記憶與 Context：https://code.claude.com/docs/en/memory
- 外掛開發：https://code.claude.com/docs/en/plugins
- 重點外掛
- code-review：具備信賴度評分的多 Agent PR 審查
- pr-review-toolkit：針對評論、測試、錯誤、型別的專門化 Agent
- ralph-wiggum：長時間執行支援
本分析基於 Claude Code Meetup Taipei 的筆記、官方 Anthropic 文件與公開原始碼。如需最新資訊，請查閱 Anthropic 官方管道。
