> ## Content Index
> Fetch the complete content index at: https://growthhackers.tw/llms.txt
> Use this file to discover other available public pages before exploring further.

# 你導入 AI 之後沒有變快，因為你只是把塞車點往後推了一格：解碼 Anthropic 的 AI 值班系統
- URL: https://growthhackers.tw/blog/ai-automation-bottleneck-shift/
- Published: 2026-09-05T01:00:00.000Z
- Updated: 2026-09-05T01:00:00.000Z
- Description: 導入 AI 後產出變多，整體效率卻沒提升？從 Anthropic 用 Claude 當 CI/CD 值班第一線的真實案例，看懂瓶頸如何往下游轉移，並套用到台灣電商的文案審核、多通路上架與客服流程：先量測瓶頸，再決定 AI 放哪一站。
- Author: Lewis wang
- Tags: AI agent, AI 自動化, Anthropic, 營運效率, 電商經營

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

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

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

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

這段出自 [Anthropic 官方部落格](https://claude.com/blog/ai-ci-cd-on-call?ref=growthhackers.tw)，作者是他們 CI 團隊工程師 Sachin Malhotra，2026 年 8 月 18 日發表。

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

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

## Anthropic 做這套，是被自己逼的

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

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

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

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

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

而且這不只發生在 Anthropic。Google 的 [DORA 2025 報告](https://dora.dev/insights/balancing-ai-tensions/?ref=growthhackers.tw)在大規模開發者調查裡看到同樣的關聯：導入 AI 之後，交付吞吐量上升，交付穩定性卻下降，而且一直降不回來。它的結論用我的白話講，每個要導 AI 的人都該貼在螢幕上：

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

![入口加寬加速之後，塞車點移到後面那個沒有跟著擴張的窄頸](https://growthhackers.tw/content/images/2026/08/inline-bottleneck-shift-v1.png)

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

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

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

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

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

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

（拉遠看，整個經濟體卡住的也不是模型，是組織消化的速度，那層我另外寫過：[AI 導入的瓶頸從來不是模型](https://growthhackers.tw/blog/ai-adoption-bottleneck-is-diffusion/)。）

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

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

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

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

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

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

![左邊是寫死的固定規則，右邊是交給 AI 的判斷，界線要自己畫清楚](https://growthhackers.tw/content/images/2026/08/inline-rules-vs-judgment-v1.png)

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

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

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

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

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

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

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

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

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

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

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

然後呢？

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

![產素材那一站被 AI 加速之後，審核、上架、客服三站原地不動，貨就堆在第二站](https://growthhackers.tw/content/images/2026/08/inline-ecommerce-bottleneck-map-v1.png)

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

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

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

## 這週可以動手的四件事

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

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

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

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

## 幾個你可能會問的問題

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

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

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

## 最後

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

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

AI agent 從「你去用的工具」變成「自己上工的同事」，我在[另一篇](https://growthhackers.tw/blog/ai-agent-triggered-not-chat/)聊過。這個案例補上了後半段：當同事變多、產出變快，你缺的不是更多同事，是有人去守那個沒人看的下游。

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

**協作聲明與免責**

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

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