團隊推動 AI 實踐 — AI Agent 借力使力，團隊的 Agent 也是你的幫手

2026-10-31

-- Pageviews

本篇分享團隊推動 AI 的實踐經驗。目前市面上的教學大多在教個人怎麼使用 AI，這場分享換一個角度，站在主管的位置，談怎麼讓整個團隊的 AI Agent 使用能力對齊。推動的核心不是只買工具讓大家自由摸索，而是把每位成員的 AI 私人助理也當成協助主管的幫手，一起調查團隊現況、依卡點安排不同帶法，並讓好方法擴散到整個團隊。

推動的起點：只給工具，團隊會卡在哪裡？

在導入 AI 的過程中有許多探索期。市場上多半聚焦在個人使用技巧，較少從管理角度討論如何把所有人的能力拉齊。這是一套持續調整中的團隊實踐，以下會分享我們實際做過的事，以及還在規劃與改善中的問題。

只給工具的三個問題

一開始我們的做法很單純，就是直接購買、訂閱 AI 工具讓大家自由發展。經過一段時間後，我觀察到三個明顯的問題：

問題	實際現象
能力落差	有些人使用強度高，已經能把工作交給 Agent；有些人學習步調較慢，過了一段時間仍停留在問答階段，拿到答案後再自己手動處理。
結果不穩	雖然開始會使用 AI Agent 做事，但產出的品質不太穩定，成果常常不如預期。
各做各的	不同人重複做相似的工作，每個人都有自己的方法與流程，彼此較少交流，好作法沒有累積下來。

這讓我意識到，只給工具還不夠，還需要有人引導與管理。

工具使用歷程與成長速度的差異

我們團隊包含 Backend、Frontend、Mobile、SRE、QA、BA 與 HR 等不同職能。在工具演進上，我們走過三個階段：

階段	工具與使用方式
早期起步	先購買 ChatGPT 與 GitHub Copilot；Developer 用 GitHub Copilot 搭配 ChatGPT 問答，非 Developer 職能則用 ChatGPT 做問答。
探索嘗試	隨著 Claude、Codex、Gemini 等 CLI 工具陸續出現，期間我們也嘗試過不同的工具。
目前配置	團隊目前留下並同時使用 Claude 與 Codex。

不過工具本身不是重點，因為工具會一直改變。不論換哪一套工具，每個人的自學能力與摸索方式不同，往前走的速度還是差很多。觀察團隊成員使用 AI 的程度，大致可以分成四個層次：

層次	定位	實際工作方式
Level 1	主要問答	有問題才去問 AI，拿到答案之後再自己動手做事。
Level 2	交付單一任務	開始使用 Agent 代為做事，但過程中會一直守在單一 Agent 前面看推理過程、回答問題。
Level 3	處理多條工作	開始多工做事，能同時指派多個 Agent 執行任務，拿到結果後再統一檢視與回覆，不會一直停在單一 Agent 身上。
Level 4	分享可用方法	已經有整套工作流程與方法，能把能力直接放進團隊共用的 Repository 裡，讓別人的 Agent 也能學習與使用。

這是成長路徑示意，狀態會隨任務改變，不是人員排名或績效分級。同一個人換到陌生的工作場景，也可能需要重新起步。這不是誰比較好，而是自己摸索的方式與時間不同。

工具一直在變，只給工具還不夠；管理者面對的第一個問題，是不能只靠大家自己學，要怎麼把整個團隊一起往前帶。

管理目標與現況調查：把成員的私人助理變成主管的幫手

我們當然希望所有團隊成員都能達到 Level 4 的程度，但並不是每個人都跑得這麼快。對我來說，最有價值的是先把 Level 1 的成員拉到 Level 2，讓 AI Agent 真正成為能幫他們做事的私人助理，解放雙手去做其他事情。

先對齊目標，再看清楚每個人的程度

具體來說，我的目標是把全員使用 AI Agent 的能力對齊。各職能做的事可以不同，但我希望每個人都能把 AI Agent 當成真的能做事的私人助理，做到以下三件事：

能力目標	說明
交代任務	能把工作背景、目標與要求對 Agent 交代清楚。
驗收結果	能自行判斷 Agent 產出的結果是否正確。
穩定重複	同類型的任務能用穩定的流程一再完成。

跨出這一步之後，AI 的使用能力才會大幅提升。起步時，比較簡單的做法是先安排公司內部教學，讓所有人至少都會使用 AI Agent 處理日常固定的例行工作（routine）。例如 Developer 可以用來做開發與解 Bug；以 HR 為例，我設計工作流教他怎麼用 AI Agent 幫忙整理報帳資料與編輯表單，把固定重複的工作交給 AI 處理。

當大家都開始使用 AI Agent 之後，每個人的程度不同，如果用同一套方法帶，就會有人吃不飽、有人跟不上。有些人是想像力還不夠充足，不知道還有哪些情境可以使用 AI；有些人是不放心交給 AI，擔心做錯而想自己多看一遍。因此，我帶人的順序是先診斷再支持：

步驟	目標	做法說明
1. 看清程度	了解每個人在哪個層次	確認成員目前是停在問答、能交付單一任務，還是已能多工或分享方法。
2. 找出卡點	辨識卡在方法、信心或環境	釐清是不知道哪些情境可用、不敢放手交給 AI，還是缺乏環境與驗收方式。
3. 對症下藥	給適合的支持	依不同卡點安排示範、陪做或處理環境，避免用同一套方式帶所有人。

借助成員的 AI 私人助理協助調查

問題是，要怎麼看清楚每個人的程度與卡點？直接問本人，常常說不清楚；只看交付結果，又看不到過程。這件事我想了很久，直到有一次跟業界朋友吃飯聊天得到靈感，才打破「只用自己的 Agent 做事」的框架：平常陪著成員工作、最接近實際使用過程、最理解他們怎麼做事與遇到什麼問題的，不就是他們的 AI Agent 嗎？

我們的團隊橫跨 Backend、Frontend、Mobile、SRE、QA、BA、HR 等職能，許多人身邊已經有 AI Agent 當私人助理。身為主管，我把這些私人助理也當成協助我的幫手：先從部分職能開始嘗試每週問卷調查，之後再逐步擴大。我設計同一份問卷指令，請成員交給自己平常合作的 Agent，讓它從可取得的工作證據裡整理做過什麼、怎麼驗證、踩過哪些雷，以及還卡在哪裡，再把回報彙整起來，幫我看見團隊共同的問題與可分享的方法。

這件事能成立，前提是由成員本人啟動、給予必要許可，送出前自己看過，也可以選擇當次不交；如果變成主管直接去讀大家的紀錄，大家只會交出漂亮的版本。

透過每週請這些私人助理協助回顧，我們建立起看見工作經驗的固定入口與四步循環：

循環步驟	做法說明
1. 回顧事件	請成員讓平常合作的 AI Agent 協助整理當週實際做過的事、好作法、踩雷與還沒幫上忙的工作。
2. 彙整回饋	主管收集所有問卷結果後統整成報告回饋給團隊，並給出下一週能嘗試的小動作。
3. 試一件事	成員根據報告回饋，在日常任務中嘗試調整做法。
4. 下輪回查	根據上一輪反饋的結果重新設計下一輪問卷，回查建議是否有被採納與落實，持續進行循環。

平常陪成員工作、最理解他卡在哪裡的就是他的 AI Agent；在成員自主啟動與過目的前提下，每個人的私人助理也能成為協助主管了解現況的幫手。

問卷怎麼跑：讓 Agent 依證據整理並自動交回

這份問卷設計出來，不是讓團隊成員自己逐題填寫，而是讓他們丟給平常合作的 AI Agent 去回答。這樣不會花費成員太多時間，主要是消耗 Token。

問卷的三個重點與四個評分面向

Agent 會依實際的工作紀錄，整理使用者本人當週怎麼使用 AI。調查重點主要有三個：

問卷重點	Agent 整理的內容
使用過程	當週用 AI 做了哪些事、怎麼指派任務、怎麼做驗收。
遇到的問題	包含踩雷、卡點，以及還沒讓 AI 幫上忙的工作。
團隊建議	上一輪團隊給的改善建議有沒有採納、有沒有嘗試調整並記錄下來。

從調查到產生報告，我都要求 Agent 不要用瞎猜的，每件事都要附上證據；看不出來就寫看不出來，不替成員猜答案，才能看到真實的問題。

當我收到所有問卷結果後，會統整產生報告。分數不是由成員的 Agent 自己打的，而是交回後在彙整時由 AI 依公開規則產生初評，每一分都附上證據，再由彙整者逐份複核後才公開，並另依規則執行引用抽查。完整評分標準在發卷前就會公開，不會收卷後臨時換標準。先前曾採用不同維度的計分方式，後來將「證據透明」改為前置門檻、不再另外計分，因此我不會把跨輪的總分直接拿來當作成長曲線。

我們主要從四個面向來檢視作法與證據。把事情做對做好即具備基本水準，最高分則依各面向看流程是否真的重跑過、形成能執行的防線，或真的被其他人使用等證據：

評分面向	管理語言	檢視重點
任務設計與派工	交代清楚	看任務拆解、脈絡提供、邊界設定與交付工作的方式。
驗證與把關	知道怎麼驗	看怎麼做驗收、怎麼把關與確認 AI 產出的結果是否可信。
學習迴圈	教訓有落地	看踩雷教訓與上一輪給的改善建議，是否真的改變後續作法。
團隊槓桿	方法能轉移	看留下來的方法有沒有複製出來，讓團隊其他人拿得走、用得起來。

一則發卷訊息，讓 Agent 做到交回

每週五下班前，我會把問卷準備好放在 GitLab 上，並透過團隊平常用的通訊群組發送一則簡短訊息，請成員把整段文字複製貼給平常合作的 Agent，交回後再由我統一整理成週報。發卷訊息的格式如下：

1 2	幫我回答這份團隊 AI 週報問卷，從頭照指示做到最後，含交回。先完整下載，再讀原文。 <當輪問卷原文網址>

指令中特別要求「先完整下載，再讀原文」，是為了避免摘要工具把規則省掉。接著 Agent 會依序執行四個步驟：

步驟	執行內容
1. 取得問卷	Agent 到 GitLab 抓取最新問卷，開場就用一則訊息把適用的許可集中問完：讀取用量、讀取隨手記、交回方式，以及可轉移產出是否願意被收編。
2. 蒐集證據	從可讀取的工作紀錄中蒐集證據，不要求本人逐題填寫或自己評分。
3. 產生檔案	產生當週回報與用量快照；若有自製方法且同意投稿，才一併處理。
4. 確認後交回	完成後由本人看稿，必要時更正或去敏，再確認送出。同意自動交回時，Agent 會依問卷指定的分支與目錄把檔案提交回團隊 Repository；若只同意產檔或交回失敗，則留下檔案由本人處理。

由於交回的回報會具名放進團隊 Repository、全組都看得到，所以送出前一定讓本人過目，本人也可以選擇當次不交。這是一個人為介入很少的流程，但不能省略許可與送出確認。

透過標準化的問卷指令與公開評分規則，讓 Agent 依真實紀錄蒐證與交回，在不增加成員填表負擔的前提下建立持續回顧的機制。

現場觀察與不同帶法：看清卡點，給每個人適合的下一步

流程能自動跑之後，我每次產生報告時都會看上一週的改善回饋建議有沒有落實，並回頭檢查自己的推動設計有沒有讓人卡住。

回報沒落地先檢查推動設計，並建立講真話的前提

回頭看這段期間的資料，如果上一週的建議沒有落實，通常有兩種可能：

未落實的原因	實際情況	推動設計的調整
任務用不上	有些回報提到，當週的任務情境其實不適合重複之前的建議場景。	將建議改寫成日常任務就能順手完成的小動作（例如下次交付 AI 產出時，順手留下驗收方式與檢查結果），再持續從週報回查有沒有嘗試。
材料沒給齊	初期我還不確定要調查什麼，給了當時想到的題目，但 Agent 平常根本沒記錄那些事而無法調查；也曾發生發卷時漏填上一輪建議，不少人因此缺了要回查的材料。	在下一輪問卷明確請成員的 Agent 從當週開始多記錄特定項目，讓後續回饋能拿到對應證據；看到沒有落地時，管理者先檢查建議是否適合、材料是否到位、能不能在現有交付裡完成。

所有的問卷調查都非常仰賴真實情況。我們從一開始就在給 Agent 的問卷中寫清楚：記錄下來的事情必須符合現實、有足夠證據，不能憑空捏造事實或自己創造故事；如果有些事情該做卻沒做（例如開發完之後沒有補測試），也要如實記錄下來，我們才知道之後怎麼做調整。

要讓大家願意配合並講出真實情況，制度上有清楚的用途界線：

制度設計	做法說明
不進人事考核	一開始我就向團隊承諾，不會拿這些紀錄與分數做任何跟考績相關的事，只用來互相學習、改善大家使用 Agent 的方式；後來加上公開規則的具名 Scorecard，也沿用同一條界線。
回饋裡踩雷匿名	週報和分數在團隊內是具名、看得到的；但彙整回饋裡的踩雷情節會做匿名處理，讓大家可以聚焦談問題本身，因為自己遇到的問題往往也是別人遇到的問題。
沒做也能照實說	評分只看作法與證據，不看用量；誠實揭露踩雷只加分、不扣分。用得少或當週沒有適合案例，也有誠實說出來的出口。

我的管理責任是守住這個承諾。至於這些設計夠不夠讓大家安心，要看大家的反應，不是我說了算。

坐在同事旁邊，看實際工作

持續透過週報回顧一段時間後，我已經很清楚每個人的程度在哪裡，但也看到週報有漏掉的地方。週報適合看長期累積與可分享的事件，卻看不到實際操作過程：人在哪一步停下來？為什麼要一直盯著 AI？哪些地方是環境卡住？有些問題在週報裡還是一直卡在那邊無法改善。

為了更直接解決問題，我增加了現場觀察的視角，坐到每一位同事旁邊，看他們實際使用 Agent 的方式。我在旁邊以觀察者的身分做記錄，當下不會開口評價他們做得好或不好，因為每個人做事的方式都不一樣。每場觀察的私人筆記不公開，也不進週報或考核，我只私下用它來規劃每個人下一步的支持；等所有人的現場觀察都做完後，再把共同現象匿名整理成一份報告告訴大家。

知道每個人的狀況之後，坐在旁邊觀察到的事情就不太一樣了。我主要從四個角度觀察，並整理出現場看到的現象與接下來的規劃：

觀察角度	現場觀察到的共同現象	接下來的規劃
怎麼交代	不少人已經按任務分開對話，但多條工作還擠在同一個工作目錄裡，已經有人遇過彼此改到對方的檔案。	下一輪持續觀察任務與完成條件怎麼交代。
在哪裡等	有人開了多個 Agent，但實際上仍是一個接一個輪流照顧。	持續觀察人在 Pending 時到底是等在哪裡，以及哪些決定一直回到本人身上。
怎麼驗收	有些驗證方法很好，卻需要人每次手動下指令才會跑。	規劃先把能機械判定的驗證規則，逐步放進自動檢查。
如何分享	有些好方法與知識管理留在個人本地位置，其他人拿不到。	規劃把好方法放到共用位置，並確認其他人能直接使用。

學習步調背後的卡點與三種後續帶法

坐到每個人旁邊之後，很容易觀察到同樣是「還沒用起來」，背後的卡點其實不一樣。看到有人用得深、有人還在起步，不能只因為用得少就推論態度有問題，而是需要透過對話與實際任務再往下確認一層：

卡點類型	觀察到的現象	對應的支持方向
缺範例	不知道哪些事情可以留給 Agent 做，所以還一直在自己做。	先給能完成的入口，坐在旁邊陪做一小段日常例行工作。
缺信心	工作流沒有調校好，Agent 每次產出的東西都跟想像不太一樣，因此不敢放手。	講清楚決策邊界，從查資料到約定範圍一步一步培養信任。
缺環境	需要連到資料庫或測試環境卻連不過去，工具根本拿不到需要的資料。	由主管為團隊協調並補上環境與權限條件。
缺驗收方式	不知道怎麼去驗收與判斷 Agent 產出的內容到底正不正確。	由主管與團隊補上可固定的驗收與檢查條件。
缺分享管道	一直都有把工作流調校得很好，但只存在自己本地裡，沒有複製給其他人使用。	引導整理出可轉移的方法，讓好方法走到別人手上。

前面是已經做過、看過的事。針對不同程度的成員，我除了在現場陪跑，也依這些卡點排定了接下來的後續帶法與規劃：

成員狀態	後續帶法與規劃重點	具體推進步驟
還在問答階段（從問答走到派工）	先有一個能完成的入口（後續帶法規劃）：讓練習直接進到手上的真實工作，選一件小範圍、可驗收的日常例行工作，共同目標是逐漸獨立，練習題不必相同。	1. 自己的真實任務：依職能選題，開發者練習交付一小段任務；手測 QA 讓 AI 補充另一種測試思路；不寫程式的職能在職能共用專案提問，讓 AI 查程式碼與知識庫並整理成可驗收文件。 2. 陪做一小段：坐在旁邊陪跑，做一小段範例讓他試試看，留下下次可照著走的範例。 3. 下次再做一次：遇到下一個同類任務時，由他自己想怎麼做並少一點協助。
還不敢放手（從每步確認走到放手）	先講清楚決策邊界（後續帶法規劃）：Agent 會做出超出預期的事，往往是因為一開始沒給對方向；輪流照顧 Agent 也可能是驗收還靠人工或派工沒寫完成條件。我們規劃明確寫下任務、如何算完成、可自行決定的範圍與何時必須停下來問，並一起看哪些驗收可以固定下來。	1. 先查資料：請 Agent 做事之前，先從只查資料、沒有寫入動作的任務開始，確認資料正確且結果容易對照。 2. 提出方案：確認成員知道怎麼判斷結果之後，再請 Agent 提出方案。 3. 約定範圍執行：給定約束範圍，講清楚哪些是職責範圍內可自行決定、哪些不能做、何時要停下來問，逐步放大交付範圍並保留人的判斷責任。
已經用得很順（從自己用得順走到別人用得起來）	往可轉移的方法前進（後續陪跑規劃）：幫助團隊降低對單一人的依賴，也讓走得前面的人練習把判斷說清楚。這不表示用得順的人都要變成講師，只要交出小範例、流程或檢查方式即可，不必人人另外準備一場課。	1. 自己用得順：挑一個自己調校得很順的常用工作流程。 2. 別人拿得到：留下任務背景、交付要求與驗收方式。 3. 別人實際用過：安排另一位同職能同事實際照著用一次；第二個人卡住的地方，就是範例還需要補齊的地方。

看到建議沒有落地要先檢查推動設計，看到成員還沒用起來要先確認卡點；依起步、不敢放手、已經用順三種狀態給出差異化帶法，才能對症下藥。

團隊擴散與企業推動：從共用資產到跨界職能

除了有人示範與陪跑，好方法本身也要有管道走到其他人手上，並由主管補齊背後的環境與資源條件。

好方法如何進到其他人的工作

有些人的工作流調校得很順暢，但如果只留在自己的本地或自己的 Agent 記憶裡，是非常可惜的。我們在問卷調查後期加入了投稿與收編機制，讓方法循著「分享方法 → 整理共用版 → 同事實際使用 → 回饋更新」的流程擴散，並依性質放進兩個層級：

沉澱方式	適用情境	做法與好處
整理成團隊共用的 Skill	團隊共通的常用 SOP（例如 Jira 或 GitLab 的操作，可理解為 AI 能依循的工作流程）	原本有成員各自寫了類似的 Skill，我們透過投稿與收編管道把它們合併成通用的一份，萃取別人的優點、改善缺點，讓大家一起使用、一起維護，把 Skill 編輯得越來越好。
寫進各專案模組的 Repository	每個 Repository 略有落差的工作內容（例如前端專案與後端專案的工作流差異）	將常用的做事 SOP 與查問題的方法直接寫在各自維護的 Module Repository 裡落檔，讓其他人只要把 Repository Checkout 下來就能直接複用。

透過投稿機制，大家能看到彼此在做哪些事、哪些是重複的，也許別人做得比自己更好。目前團隊共用方法持續增加，其中不少收編或吸收了成員的投稿，後面也還在持續增加中。

不過我們也看到未解的問題：共用方法的實際使用仍有缺口。這提醒我，把內容放進共用位置之後，還要持續觀察取得、使用、更新的動線；有些人已經有自己習慣的同類工具，共用版並不會自然取代它。因此，接下來的安排會更重視同職能交流，讓成員直接交換做法，不必什麼都經過我轉述，這仍是接下來要改善的方向。

主管要為團隊補上的四個條件

在我們的紀錄裡，權限與環境一直是卡點。如果 Agent 拿不到資料，工作就很難完整交出去，這類問題需要主管協調資源與當責者。圍繞著團隊的真實任務，主管需要負責補上四個條件：

主管要補上的條件	具體內容
可用工具	確認帳號與方案到位、夠不夠用，以及挑選工具時團隊成員覺得好不好用、會不會用。
資料與權限	打通資料與系統權限，讓 Agent 能拿到要用的資料、協助成員查找與解決問題，並講清楚可處理的資料範圍。
驗收與責任	明確定義誰驗收、誰負責、誰做驗證稽核，以及出問題時怎麼停下來。
練習與協助時間	練習和帶人都要給時間並排進正式工作時間；請人陪做或協助別人時先調整他原本的工作量，或在導入新專案時幫大家多爭取時間轉換與嘗試。

接下來由我負責協調這些工具、權限與檢查環境的條件，排進正式工作並持續追蹤有沒有打通。

如何判斷團隊正在前進與觀察 AI 用量變化

這段期間的資料看得出大家持續回報、有人嘗試建議、開始使用共用方法；但它說不出全公司效率提高多少，也不能把改善直接算在某一項措施上。我們也曾因為補交還沒收齊，把部分數據解讀成變差，這提醒管理者看數據時要確認分母與截點，保留修正自己判斷的空間。

要判斷團隊成員到底有沒有在進步，我建議透過實際事件討論，再配合返工與交付品質，從四個觀察項目來看：

建議觀察項目	觀察重點	實際表現示意
1. 能獨立完成	從需要陪做，走到本人能自行向 Agent 交代並獨立完成一件事。	同類任務再次出現時，本人能自行把任務交代給 Agent 完成。
2. 結果驗得出來	本人能自行驗收產出結果是對還是不對，並觀察返工與交付品質。	交付時能自行判斷結果正確性，並順手留下檢查結果。
3. 同類任務再用	做出一套 SOP，讓下次遇到相同任務時能重複用一樣的方式解決。	目前不少人能做到收到 Jira Ticket 後直接貼給 Agent，由 Agent 讀取內容、修正結果並發送 MR，過程中人不需要做太多事。
4. 其他人也用得起來	把資訊與方法分享出去，實際幫到別人。	分享不是靠人傳播，而是變成 Repository 與團隊文件的一部分，讓其他人只要 Checkout 下來就能享受到好處。

除了看作法之外，我也會看大家的 AI 方案等級與週用量變化，用來作為方案與預算分配的參考訊號（依主管分類定義，不做逐人排行）：

用量階段	現象與訊號解讀	方案與管理應對
1. Standard 用不完	使用 Standard 方案，但週用量根本用不完，代表使用的情境還太少。	協助拓展可使用 AI Agent 的工作情境。
2. Standard 很快用完	開始把 Standard 用完，但用得快、產出未必跟上，多半是指令下得不對或不知道怎麼節省 Token，導致浪費較多。	引導調整指令與用法，開始想方法節省 Token。
3. 先省，再升 Premium	學會節省 Token 之後，Standard 週用量還是穩定用完、真的不夠用了。	守住「先學會省，再升級」的門檻，這時才幫他升級成 Premium 方案，避免直接升級只會浪費更多。
4. Premium 穩定用完	日常工作大量交給 Agent，已經知道怎麼省，但 Premium 的週用量依然穩定用完、還是不夠用。	進入下一階段，視需求考慮配置多個 Premium 方案。

不過用量只作參考，判斷仍以作法為主。實際對照時我發現，作法已經很成熟的人，用量不一定用滿，也有人靠多套工具分流撐住多工；所以我改成看作法，用量只拿來決定要不要升方案、預算給誰。

擴散到企業層次的六步推進建議

如果把這段團隊經驗帶到企業層次或擴展到其他部門，我建議分六個步驟推進（全程確認資料授權、驗收責任與停止條件）：

推進步驟	做法說明
1. 觀察使用	先觀察每個人實際怎麼使用 AI、中間卡在哪裡。
2. 陪跑實作	坐在成員旁邊，挑選真實工作一起做一段，且結果要能驗收。
3. 調校流程	讓大家開始調校，把做得順的作法整理成 Agent 能依循的穩定工作流。
4. 安全放行	當流程穩定、驗收方式固定之後，講清楚可以自行決定的範圍與何時要停下來問，放心安全地放行。
5. 複製能力	把每個人的能力複製出去，讓同職能、再到相鄰部門的人照著用，看看接收者卡在哪，甚至讓前端能做後端、後端能做前端或 Mobile。
6. 職能跨界	當方法夠成熟時，希望達到的目標是讓不同職能借助 Agent 跨過原本的分工（例如發現 Bug 時 QA 可以透過自己的 Agent 修掉，或不寫程式的同事也能請 AI 查程式碼與知識庫）。