AI agent 導入真正難的，是讓工作被看見

一個團隊真正開始用 coding agent，常常不是因為主管宣布「我們導入 AI 工具了」。

比較常見的畫面其實很普通。某個工程師用 CLI agent 清掉一個卡很久的小任務，開了一個 diff 不大的 PR，描述裡清楚寫著 agent 做了哪些事、他自己檢查了哪些地方、哪些測試跑過、哪些地方還不確定。

旁邊的人看完，心裡想的不是「AI 好厲害」。

他想的是：這種做法我好像也可以試試看。

這才是 agent 導入最容易被低估的地方。工具採用不是平均擴散，也不是買了帳號大家就會自然變熟。工程師會模仿自己看得懂的工作方式。看得到成果，也看得到過程，才有機會放心複製。

所以，AI agent 導入真正難的，不是 prompt 寫得多漂亮，而是讓工作被看見。

## 不要把導入想成發帳號

很多團隊談 AI coding tool，第一個問題會是選哪一套。

Codex、Claude Code、Copilot CLI，或其他新的 agent 工具。每一套都有差異，這當然值得比較。但如果討論停在工具表格，通常會錯過更大的問題：團隊到底要怎麼吸收這種工作方式？

以前的 autocomplete 很容易被當成個人效率工具。你打 code，它補幾行。你覺得有用就用，覺得煩就關掉。它對團隊流程的衝擊有限，至少不會太直接。

CLI agent 不一樣。

它可以讀一個任務描述，打開 repo，規劃步驟，改檔案，跑測試，遇到錯誤再修。有人會同時開好幾個 session。有人會把固定流程寫成 skill 或 shared instruction。更長的任務也開始被委派出去。

這時候，agent 不再只是「更聰明的補全」。

它比較像一個被委派的工作單位。既然是被委派的工作，就不能只問它最後有沒有產出 code。你要問的是：任務邊界在哪裡？它做過什麼？誰 review？失敗要怎麼停？改壞了要怎麼退？

這些問題如果沒有先被設計好，團隊很容易進入一種很尷尬的狀態：大家都在用，但每個人用法不同；PR 變多了，但 review 更累；看起來速度變快了，但沒有人知道哪些速度是真的，哪些只是把成本推到後面。

## 可見的工作，比工具宣傳有用

我覺得小團隊導入 agent，最有效的起點不是辦一場內訓。

內訓不是沒用，但它通常太乾淨。範例太剛好，任務太小，環境太配合。真正說服人的，是同事在真實 repo 裡留下來的工作痕跡。

一個好的 agent PR，應該讓 reviewer 看得懂幾件事。

它原本被交付的任務是什麼。

它讀了哪些主要檔案。

它採取了哪些步驟。

哪些修改是 agent 產生的，哪些是人類後來調整的。

測試結果是什麼。

還有哪些地方只是推測，不能當成結論。

這些資訊看起來有點瑣碎，但它們會讓工作方式變成可以學的東西。

如果一個 PR 只剩「用 AI 修好了」，旁邊的人學不到方法。他只會學到一種模糊的信念：好像可以把問題丟給 agent。這很危險，因為下一次他可能把更大的問題也丟出去，卻沒有留下足夠的檢查點。

反過來，如果一個 PR 把任務切得很清楚，diff 很小，執行紀錄也夠透明，團隊就會開始形成共同語言。

大家會知道什麼任務適合交給 agent。

什麼任務應該先請它只讀不改。

什麼情況要停下來問人。

什麼樣的 handoff note 才算可以 review。

這種共識，比「我們公司開始用 AI」重要多了。

## PR 變多，不一定代表價值變多

agent 導入後，最容易被拿來看的數字大概是 PR。

這也很合理。PR 好數，merged PR 更好數。某些研究也會用 merged PR 當作 output proxy，因為它至少是一個可觀測的工程活動訊號。

問題是，PR 數字太誘人了。

一個團隊 merged PR 變多，可能代表流程真的變快。也可能只是工作被切得更碎。可能是 agent 幫忙處理了很多小修。也可能是 reviewer 要看更多差異、更多生成痕跡、更多「看起來可以但其實不對」的邊界案例。

活動量不是產品價值。

小團隊尤其要小心這點。因為小團隊的人少，review、測試、部署、客服、回滾常常都壓在同一批人身上。你不能只看 agent 幫你多開了幾個 PR，也要看這些 PR 後面有沒有增加隱形成本。

我會比較想看幾個更無聊的問題：

- reviewer 花的時間有沒有變短

- 被退回的比例有沒有上升

- 需要人類重寫的段落多不多

- 測試失敗是 agent 自己修掉，還是丟給人收尾

- 上線後的 rollback 或 hotfix 有沒有變多

- PR 的產品影響是否清楚，還是只有技術活動增加

這些數字不一定容易整理，但方向比較對。

如果 agent 讓你多合併十個 PR，卻讓 reviewer 每天晚上多花一小時擦屁股，那不是效率提升。那只是成本換了一個地方出現。

## 長任務不是成熟，能停下來才是成熟

現在很多 agent 工具都在往更長的任務走。

這當然有吸引力。你把一件麻煩事丟出去，它跑一段時間，回來交成果。看起來很像終於可以把 backlog 裡那些沒人想碰的工作往前推。

但我對「長任務」一直有點保留。

不是因為它沒用，而是它很容易讓人失去中間狀態。任務一長，agent 就會讀更多上下文、做更多假設、改更多檔案、遇到更多錯誤再自己修。最後你拿到一包結果，表面上很完整，實際上很難 review。

成熟的 agent workflow，不是一次讓 agent 跑八小時。

成熟的是把八小時級的工作拆成幾個可以停的小段。每一段都有清楚輸入、預期輸出、驗收方式和停止條件。

例如：

- 先只盤點問題，不改檔

- 再提出三種修法，列出影響範圍

- 選一種修法後，只改最小可驗證範圍

- 跑指定測試，不要自行擴大重構

- 如果測試失敗兩次，停下來交代卡點

這種做法看起來沒有那麼神奇。

但它比較像工程。

因為真正讓人放心的不是 agent 能不能一路跑到底，而是它在跑偏之前能不能被看見、被打斷、被接手。

## shared skill 的價值不是 prompt 詞彙

很多團隊開始寫 shared prompt 或 skill 時，會很自然地把注意力放在語氣和格式上。

請你扮演資深工程師。請你輸出清楚。請你遵守 best practice。請你避免 overengineering。

這些句子不是完全沒用，但價值有限。因為團隊真正需要共享的，不是「請 agent 聰明一點」這種願望，而是工作規則。

好的 shared skill 應該寫進團隊已經學到的教訓。

哪些目錄不能碰。

哪些命令要先問。

哪些測試是最低門檻。

什麼情況不能自己繼續猜。

改到資料庫 migration 時要怎麼交代風險。

碰到 auth、金流、權限、刪除資料時要停在哪裡。

PR 描述必須留下哪些證據。

這些規則不華麗，但它們能把一個人的經驗變成團隊的護欄。

我看過最有用的 agent instruction，通常都很像老工程師留下來的便條紙：這裡不要亂改，那個 script 在 CI 跟本機行為不一樣，這個測試很慢但一定要跑，遇到這種錯誤不要照著 Stack Overflow 修，先看我們自己的 wrapper。

這才是團隊知識。

如果 shared skill 只是在修飾 agent 的語氣，那它很快會變成另一份沒人維護的文件。

如果 shared skill 寫的是團隊怎麼工作，它才會讓 agent 的輸出比較穩。

## 品質變差時，要留下證據

用 agent 久了，一定會遇到一種很煩的情況：你覺得它今天怪怪的。

昨天還可以，今天一直繞圈。

同樣的任務，這次改得特別粗。

某個模型在複雜任務上像是突然變笨。

CLI client 更新後，回應風格不太一樣。

這時候團隊最常講的話是：「今天模型品質好像變差。」

這句話通常是真的感受，但它不是可操作的證據。

如果你要知道問題出在哪裡，至少要留下幾種資料：模型名稱、工具版本、任務描述、上下文大小、主要命令、改檔範圍、測試輸出、重試次數、reviewer notes。如果工具有 token 或執行 metadata，也應該一起保存。

不是為了迷信數字。

是因為 agent 失敗可能發生在很多層。

可能是模型真的退化。可能是任務切太大。可能是上下文塞了太多不相關資料。可能是 instruction 互相打架。可能是工具 client 改了行為。也可能只是 reviewer 這次比較嚴格。

沒有紀錄，這些都會混成一句「AI 不穩」。

有紀錄，團隊才有機會做判斷：這類任務以後要拆小，這個模型不適合做大型重構，這個 skill 寫得太寬，這個 repo 要先補測試，或者這次其實是我們驗收太鬆。

這也是工作可見度的一部分。

不只是成功要被看見。失敗也要被看見。

## 好的 agent 交付長什麼樣子

我覺得團隊在導入 agent 前，可以先不急著問哪個模型最強。

更值得先問的是：在我們團隊裡，一份好的 agent 工作交付長什麼樣子？

我的答案大概會長這樣。

任務要小到可以 review。

輸入要清楚，不能靠 agent 自己猜整個產品方向。

過程要留下足夠紀錄。

diff 要能說明，不只是能編譯。

測試要有明確結果。

風險要寫出來。

如果失敗，要知道停在哪裡。

如果成功，下一個人要能照著同樣模式再做一次。

這些要求會讓 agent 看起來沒有那麼魔法。

但我反而覺得這是好事。工具越強，越需要被放回普通工程流程裡。能被同事看見、檢查、接手，必要時也能乾淨退回，這樣的 agent 工作才真的進得了團隊。

導入 AI agent 的核心問題，不是「我們有沒有用 AI」。

是「我們能不能看懂 AI 幫我們做了什麼」。

看不懂，就只是活動量。

看得懂，才有可能變成工作方式。