你導入 AI 之後沒有變快，因為你只是把塞車點往後推了一格：解碼 Anthropic 的 AI 值班系統

晚上十點，Slack 跳出一則訊息：新服務上有大約 44 個測試沒有跑。

換作以前，值班工程師的下場你我都猜得到。合上正在看的影集，開電腦，嘆一口氣，然後花一個小時查。

這次他做的事只有一件：把 @Claude 拉進對話，問它看到什麼。

Claude 回報，測試是在當天早上某個 feature flag（功能開關）打開後消失的，而且評估過可以安全關回去。他請同事關掉開關，三分鐘後 Claude 主動回來說：跳過規則已移除，錯誤率回到基準線。

這段出自 Anthropic 官方部落格，作者是他們 CI 團隊工程師 Sachin Malhotra，2026 年 8 月 18 日發表。

看到這裡，大部分人的結論是「哇，AI 可以當值班人員了」。

如果你問我，這篇文章真正值錢的地方完全不在這裡。

Anthropic 做這套，是被自己逼的

那篇文章的最後，作者說了實話：他們的工程師產出暴增，而「跟上 agentic coding 的唯一辦法，就是 agentic CI」。

換句話說，這套 AI 值班系統是下游的補丁，不是前瞻性的升級。

我順手去點了它引用的那個數字來源，Anthropic Institute 的頁面，發現案例文自己轉述得不太精準。原始說法是：2026 年第二季，典型工程師每天合併的程式碼行數，是 2024 年的 8 倍。不是「每季」，基準也不是「2021 到 2025」。而且 Anthropic 自己就加註了：行數是很爛的度量，8 倍幾乎確定高估了真實的生產力增幅。

但同一頁還寫了一句更關鍵的話：人工程式碼審查，已經變成新的瓶頸。

產出端裝了渦輪，塞車點就整個往下游擠。擠到審查，擠到測試，擠到事故處理。所以他們才需要一個 AI 去守 CI。

而且這不只發生在 Anthropic。Google 的 DORA 2025 報告在大規模開發者調查裡看到同樣的關聯：導入 AI 之後，交付吞吐量上升，交付穩定性卻下降，而且一直降不回來。它的結論用我的白話講，每個要導 AI 的人都該貼在螢幕上：

AI 沒有消滅程式碼審查與驗證的工作量，它只是把那些工作量搬到下游，而多數交付流程當初根本沒有被設計來吸收這個量。

這就像把產線上某一站換成三倍速的機器

我在雨傘產業做通路那幾年，最常看到的畫面就是這個。

公司決定加開產線、多備貨，工廠端效率確實拉起來了。結果呢？百貨專櫃的人力沒加、倉庫收貨流程沒改、櫃上能陳列的面積就那麼大。貨堆在倉庫，檔期照樣賣不動。

把一站換成三倍速，整條線不會快三倍。它只會讓下一站的半成品堆得更高。

這就是限制理論最老派、也最好用的一句話：整條線的產出，由最慢的那一站決定。

AI 就是現在那台三倍速機器。它便宜到你會忍不住每一站都想裝，最後卻只裝在最好裝的那一站。

（拉遠看，整個經濟體卡住的也不是模型，是組織消化的速度，那層我另外寫過：AI 導入的瓶頸從來不是模型。）

拆系統：哪一段給死規則，哪一段才給 AI 判斷

回到 Anthropic 那套系統。撇開「AI 好聰明」的表層，它有三個設計是台灣團隊真的抄得動的。

第一，告警是死規則，升級才有 AI 判斷。

原文寫得很清楚：告警流程是 deterministic（決定性的、寫死的），只有值班升級這一段同時保留了死規則路徑和 agentic（代理式）路徑。

這條界線畫得極好。什麼數值算異常，用寫死條件；「這件事現在要不要吵醒一個人」，才交給 AI 判斷。像是「錯誤率超過 2% 持續 5 分鐘，而且不在已知部署時段，就叫人」。

他們甚至讓 Claude 在新服務上線的頭幾天分析資料，回頭建議該加什麼規則、哪些門檻太寬或太窄。

第二，一份報告換掉一整天的打斷。

他們做了一個叫 ci-weather 的 agent，把各事故頻道、build 指標、合併佇列、部署延遲彙整起來，用新聞編輯室的口吻發到全公司都看得到的公開頻道。工程師想知道「CI 現在到底怎樣、我該不該先別合併」，自己去看就好，不用來敲值班的人。

原文還附了一句我很喜歡的誠實話：Claude 可以一次就寫出產生報告的技能，但讓報告變得可讀的是團隊自己的品味。這是人類溝通，不是水管工程。

第三，它會把每次事故的教訓寫回檔案。

Claude 自己維護一份 lessons.md，每次調查都從讀它開始。這種「讓 agent 把經驗寫回檔案」的記憶設計，我在解碼 Anthropic 的 Memory 與 Dreaming 那篇談過，這裡不重複。

只講一條。Claude 在那份檔案裡寫過一則關於人類的教訓，因為作者自己犯過：「先查資料，再提理論。設定檔告訴你什麼可能出錯，指標告訴你什麼真的出錯了。」

記住這句，等一下的行動建議第一條就是它。

台灣電商團隊的塞車點，不在 CI

你可能會說，我又不跑 CI/CD，這跟我有什麼關係。

關係大了。同一個結構已經在你的團隊裡發生，只是換了個位置。

想像一下你們家的雙 11。行銷部用 AI 一個下午產出 80 組廣告文案、40 張主視覺變體、每個檔期商品都配好三種標題。產出端效率確實翻了好幾倍，我完全相信。

然後呢？

• 這 80 組文案要有人審宣稱用語，化妝品、保健食品的法遵標示不能出錯
• 主視覺要一張一張確認有沒有跑版、有沒有用到過期的價格
• 每個商品要分別上蝦皮、momo、自有官網，三邊的規格欄位、圖片尺寸、活動標籤都不一樣
• 流量真的進來，客服訊息量跟退換貨處理量跟著一起放大

以前你的瓶頸是「想不出文案」。現在你的瓶頸是「審不完、上不完、回不完」。

而且新瓶頸比舊的更難受。你知道為什麼嗎？舊瓶頸卡在創意，產不出來至少不會出事。新瓶頸卡在把關，一鬆手就是錯價、錯標、廣告被下架、客訴上社群。

簡報上那個漂亮的產出效率數字，跟檔期實際交期完全對不起來。錢花了，人更累了，壓力全部跑到下游那兩三個人身上。

這週可以動手的四件事

► 第一，先查資料，再提理論。 就是 Claude 寫的那句。拿最近一次檔期，把「創意發想 → 文案產出 → 審核 → 上架 → 開賣 → 客服」每一站的實際耗時列出來，抓大概的工作天就好。你八成會發現最慢的那一站，跟你原本以為的不是同一站。動那一站，而不是最好自動化的那一站。

► 第二，先做「不吵人」的那一半。 別急著讓 AI 做決定。學 ci-weather，先讓它每天早上把「昨天賣了什麼、哪些品項庫存要爆、哪幾則客訴重複出現」整理成固定格式的日報，丟到大家都看得到的群組。光是砍掉互相打斷的次數就很有感。

► 第三，把死規則跟 AI 判斷的界線畫出來。 會員價、成本價、法遵禁用字、上架必填欄位，這些一律寫死，用檢查清單擋，不要交給 AI 自由心證。真正該讓 AI 做的是判斷題：這則客訴要不要升級給主管、這組素材跟過去被下架的那幾組像不像。

► 第四，準備一份會被寫回去的教訓檔。 每次檔期結束、每次出包，把「發生什麼、根因、怎麼修、下次要注意的坑」寫進同一份文件，並且規定下一次啟動時第一件事就是讀它。這件事跟你用不用 AI 無關，但你一旦開始用 AI，它的價值會放大很多倍。

幾個你可能會問的問題

Q：導入 AI 應該從哪個環節開始？ 從最慢的那一站開始，不是最容易自動化的那一站。這兩者常常不同，後者才是多數團隊直覺會選的。

Q：哪些事該交給 AI 判斷，哪些必須留死規則？ 判準是「錯了會不會有人受傷」。價格、法遵、庫存扣減、金流，寫死。要不要升級、像不像、值不值得看一眼，交給 AI。

Q：小團隊沒有工程資源，這套抄得動嗎？ 架構抄得動，工具不用抄。Anthropic 接的是 Datadog、Grafana、PagerDuty，你接的可能只是一張 Google Sheet 跟一個 LINE 群。他們把設定包開源在 oncall-kit，但那是給工程團隊看的。你要抄的是那三個設計：死規則與 AI 判斷分開、用廣播取代打斷、教訓要寫回檔案。

最後

產出端 AI 化是一道單向門。不少同業已經用 AI 在產素材，你不可能退回去比誰手打得快。

既然回不去，那就要有心理準備：下游遲早要補。差別只在你是現在有計畫地補，還是等某個檔期爆掉之後手忙腳亂地補。

AI agent 從「你去用的工具」變成「自己上工的同事」，我在另一篇聊過。這個案例補上了後半段：當同事變多、產出變快，你缺的不是更多同事，是有人去守那個沒人看的下游。

先去把你的瓶頸量出來。今天下午就能起一版。

協作聲明與免責

這篇文章由王董與 AI 一起整理製作完成。文中引用的第三方資料、研究或工具都會標註來源名稱；若原始出處有公開連結，會以 [來源名稱](URL) 形式附上，方便你進一步查找。若文中內容與原始出處有任何出入，請以原文為準。

內容僅供參考與學習交流，不構成任何專業、商業或投資建議，請依自身情況判斷並自行承擔行動風險。文中提及的工具功能、數據與平台政策可能隨時間異動，請以各官方最新公告為準。