Claude寫了Anthropic八成代碼後，CI任務量半年漲25倍，官方覆盤如何拆掉有狀態單點

Anthropic 近日在內部技術覆盤中揭露了一組令人矚目的數據：其大型語言模型 Claude 目前已經承擔了公司約八成程式碼的撰寫工作，然而這項效率提升卻也帶來了系統層面的巨大壓力——持續整合（CI）任務量在短短半年內暴增了 25 倍。面對 CI 佇列幾乎從未間斷的排隊狀況，官方特別針對「有狀態單點」問題進行了深度拆解，試圖在自動化效率與系統穩定性之間找到平衡點。根據團隊的分析，CI 任務量之所以急遽攀升，背後有兩個關鍵因素。首先，Claude 在生成程式碼時傾向於將改動拆分成更小、更細碎的 Pull Request（PR），每一個 PR 都會觸發一輪完整的測試流程。

由於 PR 數量大幅增加，測試次數自然跟著水漲船高。換句話說，過去由開發者手動提交的大型合併請求，如今被 Claude 自動拆解為數十甚至上百個小型變更，每個變更都必須經過嚴格的驗證，從而讓 CI 管線承受了遠超以往的負載。其次，Claude 及相關的 AI agent 可以全天候不間斷運作，夜間與週末也持續提交程式碼，這使得 CI 佇列幾乎沒有閒下來的空檔。過去開發者下班後，測試任務通常會隨之減少，但現在機器撰寫程式碼的節奏不受人類作息限制，導致總任務數量呈現指數級成長。兩個因素疊加之後，半年 25 倍的增幅便不難理解。

面對這種規模的壓力，傳統依賴單一有狀態服務的 CI 架構開始出現明顯瓶頸。所謂「有狀態單點」，指的是整個持續整合流程中，某些關鍵環節必須仰賴單一台伺服器或單一服務實例來維護執行狀態，例如排隊佇列、測試結果暫存、工件儲存等。當任務量瞬間暴增時，這個單點就容易因為排隊溢位、記憶體耗盡或請求超時而拖慢整體流程，甚至導致系統崩潰。官方覆盤指出，若要真正消除「有狀態單點」的脆弱性，必須從根本重新設計工作分配方式。具體而言，就是要讓測試任務能夠被更均勻地分散到無狀態的計算節點上。

無狀態節點各自獨立，不依賴共享的內部狀態，因此可以動態擴展，無論任務數量如何飆升，都能透過增加節點數量來承接負載，避免某個節點因為資源耗盡而成為瓶頸。Anthropic 的工程團隊在覆盤中也強調，消除有狀態單點不僅僅是技術架構的調整，更涉及 CI 流程設計思維的轉變。傳統上，開發工具鏈往往為了簡化實作而預設「有狀態」的集中式管理，但當 AI 輔助開發的滲透率達到極高水準時，這種設計的短板就會被無限放大。唯有走向完全無狀態、水平擴展的架構，才能應付機器寫程式碼時代所帶來的指數級負載。

這項經驗也反映出，當開發工作模式從「人寫程式碼、機器測試」轉向「機器寫程式碼、機器測試」時，基礎設施的升級不再是可選項，而是必備條件。Claude 雖然大幅提升了程式碼產出效率，但同時也讓測試與整合環節成為新的瓶頸。如果沒有對應的 CI/CD 架構同步演進，自動化的紅利很快就會被系統延遲所抵消。Anthropic 的內部覆盤並未停留在問題描述，而是提出了具體的工程方向：將排隊機制、測試調度、結果收集等環節全部去狀態化，採用事件驅動與訊息佇列的方式，讓每個任務都能獨立被任意的無狀態工作者消費。

這樣的設計不僅能承受任務量暴增，還能提高系統容錯能力——即使某個節點故障，其他節點可以立即接手，不會導致整個 CI 流程停擺。當然，從有狀態過渡到無狀態並非一蹴可幾。Anthropic 團隊在覆盤中坦承，部分既有服務的改寫需要時間，短期內仍須透過限流、優先級隊列、資源隔離等機制來緩解壓力。但長期目標非常明確：打造一套能夠隨著 Claude 寫碼量成長而線性擴展的 CI 基礎設施。此次覆盤不僅是 Anthropic 的內部教訓，也為整個 AI 輔助開發領域提供了重要的警示。

當越來越多的公司導入大型語言模型來加速開發，CI/CD 管線的設計者必須提前思考：機器寫出的程式碼越多，測試負載就越重，傳統的集中式架構終究會不堪負荷。唯有擁抱無狀態、水平擴展的設計哲學，才能讓自動化真正成為生產力加速器，而不是系統崩潰的導火線。觀察 Anthropic 的做法，可以發現他們並非只是被動應對問題，而是主動將這項挑戰視為系統架構升級的契機。在覆盤文件的最後，團隊強調將持續監控 CI 任務量的成長曲線，並定期檢討去狀態化的進度，以確保 Claude 的寫碼能力不會被後端的測試瓶頸所束縛。這也為其他正在擁抱 AI 開發工具的團隊提供了一條值得參考的路徑。