主管願意支持，資源也投入之後，接下來就會碰到另一個問題：怎麼知道這些投入，有沒有帶來效益？工具選得合不合適、省了多少時間、花了多少成本，這些都需要看。但跟著先鋒小隊走了一段時間，我開始留意到，用 AI 比較容易做出成果的人，往往有一些相似的工作習慣：他們不一定最熟悉工具，也不一定有技術背景，但在交付工作和判斷結果這兩件事上，通常比較有自己的方法。這些觀察，還不能直接證明導入有沒有效益，卻讓我開始理解：同樣的工具交到不同人手上，為什麼會出現不同的結果。

把事情交出去之後，還知道怎麼顧好

第一種能力，跟帶人很像。

當 AI 開始承接工作，自己要做的事，也會跟著改變。除了動手完成，還要能把目標與脈絡講清楚，理解 AI 正在做什麼，分辨哪些地方需要介入，以及最後怎麼確認結果。我習慣把這件事想成「像主管一樣工作」。但它跟有沒有主管職稱，沒有必然關係。有些同仁沒有帶團隊，平常卻很習慣協調事情：知道怎麼交代需求、抓住重點，也知道交出去之後要怎麼確認。這樣的人，上手 AI 時，通常比較容易找到合作的方式。在先鋒小隊裡，表現比較好的同仁，常常就有這些習慣。他們能看出結果哪裡不符合期待，再把問題講清楚，讓 AI 繼續調整。所謂抓大放小，也需要建立在這個判斷上：知道什麼會影響工作結果，才知道哪些細節可以交出去。

熟悉上下游，才知道「做好」是什麼意思

第二種能力，是對工作上下游的掌握。

這一塊，我自己的經驗最深。如果我只停在需求與功能的層次，即使知道怎麼驗收需求，也未必能判斷整件事是不是做得好。我先是在和工程師不斷溝通的過程中，理解了技術。後來，我跟著一位做過百萬用戶級產品的主管做產品，他帶我理解使用者中心的思考：使用者真正需要的是什麼、怎麼形成好的體驗，又怎麼用最小的方式解決問題。這讓我開始看見，功能完成之後，還有使用者能不能順利完成事情的問題。有了技術上的理解，再加上使用者的角度，我也逐漸知道，一個需求要真正做出來，中間有哪些限制，後續又會遇到哪些維護問題。我也參與過行銷工作，知道數據怎麼進來，以及它怎麼跟產品連結。這些經歷，原本分散在不同階段。到了跟 AI 協作的時候，卻一起派上用場。

多理解一個環節，就多一個判斷的依據

像是用 AI 協助開發一個東西，我會先想一輪使用者怎麼操作，哪些地方可能卡住。功能做出來之後，也會一起考慮，接下來要怎麼修改與維護。過去的行銷經驗，則幫助我思考資料怎麼收進來、怎麼跟產品行為連結，以及最後要拿來回答什麼問題。這些事情，不一定每個細節都要由我親自完成。但因為對上下游有一些理解，我比較能判斷 AI 交出來的東西：哪裡已經夠用、哪裡需要補，以及哪個問題值得繼續投入。品質檢驗也是一樣，知道要檢查什麼，才有辦法確認工作是否完成，而不只是看見 AI 產出了一個看起來完整的結果。我不是每個環節的專家，但多理解一個環節，就多一個可以用來判斷的依據，也比較知道什麼時候需要找其他人一起確認。

這些能力，可以從真實工作裡慢慢長出來

這兩個觀察，也讓我重新思考先鋒小隊可以怎麼帶。有人已經很會使用工具，卻還不習慣把需求講清楚，也許就可以從他正在做的事情開始，練習定義目標與驗收標準。有人能把自己這一段做好，卻不熟悉下一個環節，也可以讓他多了解：這份產出會交給誰？對方拿到之後要做什麼？什麼樣的結果，才真的接得下去？這樣的方向，也延續了前面從卡點補上工程思維的做法。能力可以在工作裡逐步建立，不需要等到什麼都懂了，才開始使用 AI。

效益要看成果，支持要看人卡在哪裡

回到一開始的問題，評估 AI 導入，最後還是需要看實際工作有沒有改變。有沒有省下時間？品質是否穩定？省下來的力氣，會不會又花在反覆確認和修改上？這些都要回到使用之後的結果。而人的工作習慣，幫助我理解的是：為什麼成果會有差異，以及接下來該提供什麼支持。是交代得不夠清楚？不知道怎麼驗證？還是對上下游的理解不足，以至於做出了東西，卻接不進原本的工作？跟著先鋒小隊走到這裡，我愈來愈覺得，讓人把 AI 用出效益，除了教工具，也要陪他建立交付與判斷的能力。把事情講清楚，讓 AI 有機會做對；看得懂工作的前後關係，才知道它做出來的東西，究竟有沒有用。