季度 AI Adoption Review 的投影片上，有一張分布圖。

AI Platform Users: 428

Created at least one Agent: 37
Published reusable Workflow: 6

平台 PM 翻到下一頁。六個 Workflow 裡，Customer Case Summary 過去一個月被執行了 1,842 次。

建立它的人只有 Kevin。一線客服使用者超過兩百人。

主管停在第一頁。

「只有 37 個人做過 Agent？」

「是。」

「那 Adoption 還不夠。下季每個人至少建一個。」

這個要求聽起來很合理。Builder 越多，能解的問題理論上也越多。

三個月後，數字確實變漂亮了。

Created at least one Agent: 286

只是 Customer Case Summary 有兩個新 Case Type 等了三週還沒改。

Kevin 收到的需求愈來愈多：產品線分類、特殊退款、輸出格式、Regression Case。

而他這一季的目標，是再做兩個新的 Agent。

他最後先去做第二個。

因為那個數字會出現在季度報告裡。

兩百個人沒有 Build，不代表兩百個人沒有得到價值

平台把所有使用者當成同一種人時，最容易得出一個錯誤結論：每個人都能建，才算 Adoption。

但 Customer Case Summary 的使用現場不是這樣。

客服新人每天用它整理 Case。她不會寫 Prompt，也不需要知道 Tool Schema；原本八分鐘的資料整理，現在只要確認兩三個欄位。

她是成功的使用者，只是不是 Builder。

客服主管知道退款、技術問題和合約爭議不能用同一條規則。他不會建 Workflow，但能指出：「這個條件不能這樣判。」

Kevin 把這些規則與系統接起來，讓它能跑。

再往下，還需要有人決定：這個 Workflow 要不要繼續？哪個修正優先？什麼需求不做？Kevin 不在時誰接手？

這四種工作本來就不同。

Consumer
使用既有能力完成工作

Domain Expert
提供規則、案例與判斷邊界

Builder
把需求轉成可執行 Workflow

Capability Owner
決定版本、優先度、維護與停用

企業不需要四百個人都變成 Builder。它需要的是：一個人做出的能力，能不能讓其他人穩定使用，並且有人承接之後的維護決策。

把 Builder 人數當成成果，會讓有效能力失去維護

如果 Kevin 只替自己省五小時，那他的工具當然只是個人生產力。

但當一個 Workflow 被兩百多人用在同一類工作上，問題已經變了。它不再只是 Kevin 的 Agent，而是一項共同能力。

這時候強迫每位客服各做一份，不會讓組織得到更多能力。它只會得到更多不同 Prompt、更多例外規則，以及更多沒有維護者的小工具。

平台團隊後來沒有再要求人人 Build。他們只替每個開始被他人重複使用的 Workflow 補上一張 Capability Role Map：誰使用、誰提供規則、誰能修改、誰負責決定維護與停用。

下一季，Builder 數量從 286 降到 91。

主管第一眼仍然皺眉。

平台 PM 往下翻：

Active Shared Workflows: 6 → 14
Workflows with named Owner: 3 → 12
Consumers using Shared Capability: 391 → 612

Kevin 不再是唯一維護者。客服主管成了 Domain Expert，Operations Lead 接下 Capability Owner。

新進客服第一天上班，只需要知道去哪裡使用 Customer Case Summary。

沒有人再要求她先做自己的版本。

Builder 的比例變低了。

真正被組織接住的能力，反而變多了。