最危險的導入報表，不一定是數字不好看。
有時候剛好相反。數字太好看，才麻煩。
100 個工程師都開過 coding agent。CLI 安裝率 90%。每週 prompt 次數成長三倍。內部 demo 也很熱鬧。這些畫面很容易讓人以為公司已經跨過某個門檻，彷彿只要更多人試用，生產力就會自然出現。
我不太相信這件事。
使用率只能證明工具被碰過。它沒有告訴你工作有沒有被拆對，agent 的輸出能不能被 review，錯誤有沒有被發現，人類最後花了多少時間修正。更不會告訴你，這些 agent run 到底是讓團隊變快，還是只是把原本看得見的工程時間，換成比較難統計的驗收時間。
公司導入 coding agent，不是「讓大家都開始用 AI」的專案。
它比較像是重新設計工程工作流的專案。
很多 rollout 都會先量最容易量的東西。
有多少人啟用帳號。多少人裝了 CLI。多少人跑過第一次任務。每個部門的 prompt 次數。這些數字不是完全沒用，它們至少可以看出教育訓練有沒有觸達、工具安裝有沒有卡住、某些團隊是不是完全沒碰。
但它們太淺。
第一次使用通常只是好奇心、同事推薦、主管要求或內部活動的結果。這不是壞事，只是不能把它當成成功。真正要看的，是誰在一兩週後留下來，留下來的人把 agent 用在哪些任務，哪些任務反覆出現，哪些任務一開始看起來適合，最後卻被丟回人類手上。
Microsoft 早期 CLI coding agent rollout 的研究有一個有意思的點：第一次使用會受到社交網絡影響，留存卻更接近真實 coding activity。這很合理。你可能因為旁邊的人都在試而打開工具，但你會不會繼續用，取決於它有沒有真的塞進你的日常工作。
所以 adoption dashboard 至少要拆成兩層。
第一層是接觸。誰知道這個工具，誰開過，誰裝得起來。
第二層才是工作。誰把它放進實際任務，多久用一次，用完之後輸出去了哪裡，有沒有被合併，有沒有被退回，有沒有被重寫。
只看第一層，很容易得到一個漂亮但沒什麼用的答案：大家都試過了。
Microsoft 那篇 rollout 研究裡，adopters 合併的 PR 大約比 counterfactual estimate 高 24%。這個數字當然值得看。它比「prompt 次數」接近工程輸出，也比「帳號啟用」更難被內部宣傳活動灌水。
但 merged PR 仍然只是 proxy。
PR 變多，可能代表團隊真的切出更多可交付工作。也可能代表小 patch 變多、review 壓力上升、瑣碎修補增加。更麻煩的是，PR 數量不會自動反映品質、維護成本、事故風險或需求價值。
我會把 PR 指標放在報表裡，但旁邊一定要放幾個比較不漂亮的問題：
如果只有 PR 數字上升，其他東西都看不到，那不是成功指標。
那只是你知道東西變多了，還不知道它們變好還是變吵。
Coding agent 進團隊後，第一個成熟指標不是「會不會用 prompt」。
是團隊能不能把工作切成可委派的形狀。
這件事比想像中難。很多工程任務平常靠人類默契運作：你知道這個 repo 的怪地方，知道哪個測試不能信，知道哪個老模組不要碰，知道某個設定檔看起來相關但其實是 legacy。這些背景如果沒有被寫成 instructions、scope、stop condition，agent 不會自動理解。
所以我會量幾個很土的東西。
任務大小。一次 agent run 平均碰幾個檔案？跨幾個模組？如果大多數 run 都是跨模組大改，表示團隊可能還不會切任務。
任務類型。哪些任務留下來了？補測試、修 lint、整理 migration、改文件、產生 scaffold、查 regression，各自的成功率不同。把它們混在一起看，報表會失真。
重用程度。團隊有沒有把常見任務做成 reusable instructions 或 skills？還是每個人每天都在重新口頭交代同一套規則？
停止行為。Agent 碰到不確定的邊界時，是會停下來交回問題，還是硬猜一個 patch？
Codex 使用研究裡提到的方向很值得注意：agentic AI 的使用正在從單次對話，往多人同時管理多個 agents、使用 skills/instructions 的模式移動。這不是單純工具升級。這代表工程工作開始有新的包裝單位。
以前你交辦的是 ticket。
現在你還要交辦一段可執行、可檢查、可停止的工作。
我看過很多 agent output 最大的問題，不是 code 明顯錯。
明顯錯很好處理。Build 掛了，測試紅了，型別不過，大家知道要退。
麻煩的是它看起來像對的。
Summary 寫得很順。Diff 看起來合理。測試也有跑。可是 reviewer 心裡還是要重新判斷：它真的讀懂 issue 嗎？它有沒有順手改到旁邊的行為？它說跑過測試，是跑了哪個測試？它說沒有風險，這句話是證據還是安慰？
所以 rollout metric 裡一定要有可審查性。
每個 agent work 至少要交回幾樣東西：任務範圍、touched files、核心 diff 意圖、實際跑過的命令、沒跑的驗證、剩下的風險。不是為了讓流程變官僚，而是讓 reviewer 不必從零開始猜。
對 frontend 或 UI agent 任務，這件事更明顯。你不能只收一包 component diff，還要知道它參考了什麼互動模式、產出哪些狀態、哪些畫面需要人工看。若團隊要整理 Generative UI、agent-rendered interface 或 UI code generation 的參考素材，像 生成式 UI 資源合集 這類索引可以當作研究入口，但最後仍然要回到團隊自己的 artifact standard：截圖、狀態清單、互動限制、可回歸的測試。
Agent 可以很快交出東西。
但能不能快一點相信它，是另一個問題。
很多公司會自然地從 PR 或 bot account 量 agent adoption。
這很直覺，也很不夠。
開源 repo 的 agent trace 研究提醒了一件事：只看單一通道，會漏掉大量 agent activity。真實使用不一定會以「AI PR」的形式出現。有人用本機 CLI 修完再自己 commit。有人只用 agent 找檔、跑測試、整理錯誤，最後 diff 是人類手動改的。有人把 agent patch 拆開，混進正常工作流。
這時候 adoption dashboard 會變得很荒謬。
你以為某個團隊沒有使用 agent，因為沒有 AI label。實際上他們每天都用，只是痕跡在本機 session、commit pattern、PR body 或 task note 裡。你以為某個模組都是人類手改，實際上 agent 已經常常碰設定檔、測試和 build script。
這不是要抓人。
這是治理問題。團隊如果不知道 agent 介入哪裡，就很難判斷哪些成果可信、哪些地方要加 review、哪些模組已經需要新的權限邊界。
成熟的量測方式不會只問「有幾個 AI PR」。
它會問：這週有哪些工程判斷，有 agent 參與？那些參與有沒有留下足夠的收據？
Agent 失敗不一定是災難。
更多時候，它只是一直讓人修。
讀錯專案脈絡。忘記限制條件。進度回報太樂觀。把小問題改成大重構。說自己完成了，其實跳過了關鍵驗證。這些事情不一定會造成事故，但會吃掉信任。
Developer-agent misalignment 的研究把這種成本講得很清楚：很多 visible failures 最後仍然需要使用者明確介入修正。這跟我的體感接近。Agent 最常浪費人的地方，不是把 repo 炸掉，而是產出一個「差一點可以」的東西，逼你花腦力判斷要修、要退、還是乾脆重做。
所以我會在 rollout 指標裡加一個很直接的欄位：manual correction time。
不要只記 agent run 花了幾分鐘。也要記人類花了多久收尾。Review 幾輪？改了多少行？哪些地方是 agent 自己說完成但實際沒完成？哪些 failure mode 重複出現？
如果一個任務 agent 跑 8 分鐘，人類修 45 分鐘，它不一定沒價值。
但你不能把它報成「8 分鐘完成」。
如果要讓 coding agent 真正進公司流程，我會先少談一點模型，多談 artifact。
每種可委派任務都應該有交付標準。
修 bug 要交 issue interpretation、diff、測試結果、剩餘風險。改 UI 要交狀態覆蓋、截圖或預覽、互動邊界、無障礙注意事項。寫文件要交目標讀者、變更範圍、已同步的相關頁面。準備 release 或工程文章素材時，也要把文字、截圖、社群預覽圖這些東西分開驗收；如果最後需要發到 Instagram，像 Resize Image for Instagram 這種瀏覽器本機處理的尺寸工具，可以只是最後的輸出步驟，而不是讓 agent 自己拿一張圖到處亂傳。
這段聽起來很雜，但它其實是同一件事。
Agent work 必須變成可驗收的 artifact，而不是一段漂亮的聊天紀錄。
有了 artifact standard，團隊才知道什麼任務適合交給 agent。也才知道什麼輸出可以直接進 review，什麼輸出只能當草稿，什麼輸出需要人類先判斷方向。
如果今天我要幫一個工程團隊設計 coding agent rollout dashboard，我會把使用率放在最上面，但不會讓它當主角。
真正的主角會是這些：
這些指標沒有安裝率漂亮。
但它們比較接近真相。
它們會逼團隊面對一件事：coding agent 不是採購完、開帳號、辦 workshop 就會自然產生價值的工具。它需要任務切分、審查格式、紀錄習慣、權限邊界和失敗回收。
這些都是工程管理。
我不反對量使用率。
我反對只量使用率，然後把它包裝成導入成功。
成熟的 coding agent 導入，不是把 agent 塞進每個人的終端機。也不是讓每個工程師每天都 prompt 幾次，報表就算健康。
成熟一點的做法，是讓團隊慢慢知道幾件事。
哪些工作適合委派。哪些輸出可以被相信。哪些輸出必須被拆小。哪些任務會製造太多修正成本。哪些 agent traces 必須留下來。哪些權限不能碰。哪些 metrics 只是熱鬧。
最後你會發現，真正有價值的 adoption 數字通常不會太浮誇。
它會比較像一張工程流程的體檢表。
不只告訴你大家有沒有用 agent，也告訴你：這個團隊有沒有能力把一段非人類工時，變成可委派、可審查、可追蹤、可修正成本的工作。
這才是 coding agent 進公司後真正該量的東西。
ryanvale
iThome鐵人賽
看影片追技術