Anthropic把內部CI/CD的第一線值班交給了Claude，內部代號叫Claude Tag。8月18日公開的這份說明裡，最能說明問題的數字有兩個：工單開出來之後，Claude發出第一份有憑有據的分析，中位數耗時14分鐘；順利的話，4分鐘就能在初始報告裡點出根本原因。
促成這件事的背景寫得很直白——工程師人均每季度交付的程式碼量，漲到了原本的8倍。產出翻上去之後，建置失敗、測試不穩定、部署回滾這些事的絕對數量也跟著漲，而排查一次往往要花上一個多小時，還經常落在非上班時段。
Claude手上握著哪些鑰匙
這套系統能跑起來，靠的是權限設定而非模型本身。Claude透過MCP連接器拿到一組存取權：Grafana和日誌儲存用來看指標和堆疊，Datadog補足監控，GitHub用來讀提交、看差異、開提交請求，Kubernetes用來給出叢集層級的處置建議，PagerDuty和幾個Slack群組用來收警示、發結論。它有自己獨立的服務帳號，行為可稽核。
警示要不要叫醒人，判斷規則直接寫成自然語言。文章舉的例子是：錯誤率超過2%且持續超過5分鐘，同時不在已知的發布時段內，就呼叫值班人員。這類門檻以前躺在監控系統的設定檔裡，改一次要走發版流程；寫成Claude能讀的規則之後，調整成本降到改一行文字就好。除了自動警示，團隊成員和內部事件頁面也能手動觸發。
分流階段是並行跑的
故障一進來，Claude會啟動一個協調代理，再由它派出多個子代理並行去查不同的依賴：一個讀日誌，一個比對最近的提交，一個看指標曲線。這套「動態工作流程」的產物，就是那份14分鐘的分析。
支撐判斷的是兩類檔案。一類是技能檔案，按故障類型寫成調查手冊，其中一份專門講某一類難纏bug的排查路徑，長度617行。另一類是lessons.md，每次事件結束後由Claude自己追加內容，下次遇到相似模式會先查這裡。這兩類檔案都放在GitHub裡，跟程式碼走同一套審查流程。
修復環節還是留給人
修復環節留了人的位置。最常見的產出是一份提交請求，等工程師審查後再決定要不要部署；逐步放量靠功能旗標控制流量。涉及叢集的部分，Claude給出排空、隔離或擴容的建議，執行由人拍板。改完之後，它會用同一套工具把修復再驗證一遍。
Anthropic明確保留了幾件事給人：中長期的架構改進；在共享模式下和Claude一起補假設，因為它不見得每次都一次判斷正確，需要人的直覺把它拉回來；提交請求的審查關卡；還有溝通口吻——狀態報告的格式來回改了好幾輪才符合團隊的胃口，這部分自動化沒能吃下來。
交接也被產品化了。每週有彙總報告，每天有摘要，另外還有一個叫ci-weather的代理，把多起事件編成對外可見的狀態說明。
一筆容易被忽略的帳
8倍這個數字，放在「為什麼要做」和「做完之後怎麼樣」這兩頭，意思並不一樣。一方面，它是壓力來源：團隊規模沒變，交付量卻漲了8倍，故障工單的數量不會原地踏步。另一方面，它也是這套值班系統能夠成立的前提——要是程式碼還是人一行一行敲出來的，故障的樣態、頻率和可解釋程度都會更貼近工程師的直覺，AI分流的邊際效益就不會這麼明顯。等到AI大量參與寫程式碼之後，讓AI來做第一層排查，這條鏈路是接得上的。
導入的門檻也寫得很清楚：需要Claude的Team或Enterprise方案，工具連接和權限設定初期得花上幾個小時。對多數團隊來說，難的地方大概不在接線本身，而在敢不敢把一個能開提交請求、能操作叢集的服務帳號交出去。
參考來源：Anthropic官方部落格、CocoLoop；中位數14分鐘的分流時間、最快4分鐘的根本原因定位、季度交付量8倍、技能檔案617行，均依公司公開說明核對。