最近蠻多人問我：「你是怎麼推動整個團隊做 AI 轉型的？」 我想了一下，其實這件事情不是一兩句話可以回答，所以我想把整個過程記錄下來。

背景

我們有個團隊在負責一個很大的專案，大概有二十幾個 module，跑了很多年，整個團隊有快二十人，有各種角色PM、Dev、QA 等角色一起開發。

AI 出現之後，我非常鼓勵大家開始使用 AI。很快我就觀察到一件事情：那些本來就有好奇心、願意嘗試新工具、會一直思考怎麼改善自己工作流程的人，AI 用得非常好，產出速度也快非常多。

但是另外一群人，沒那麼會用 AI，或者不知道怎麼把 AI 放進自己的工作流程。於是整個團隊開始出現蠻明顯的的能力落差，也帶出一個問題：能力累積在個人身上，而不是累積在整個團隊身上。有人變得很強，做事很快，但團隊沒有一起變強。

第一個嘗試：打造團隊知識庫

在 LLM Wiki 這些概念還沒出來之前，我就已經開始做這件事情。我先把整個專案的知識建立成一個 LLM Knowledge Base，再串上一個 Bot。大家有任何專案上的問題，都可以直接問 Bot。 這知識庫包含了專案所有背景，Jira ticket, Confluence, 所有repositoires的source code 這是我做的第一件事，這件事幫助很大。因為人腦根本記不住二十幾個 module 的所有細節，很多歷史背景、Domain Knowledge、設計原因，以前需要人去考古的，都可以直接問 Bot快速得到答案。

但是後來我開始思考另外一件事情：知識有了，可是團隊的工作流程，有沒有辦法一起加速？ 我自己不少 Side Project。在那些 Project 裡面，我花了一些時間打造自己的 AI Workflow。每次我要開一個新的 Project，AI Agent 會自動幫我建立 Issue Board、建立環境、設定所有東西。我只需要在 Discord 跟 AI agent 討論我要做什麼，後面就是 Bot 自己開發、測試、部署。

那時候我就在想：如果我一個人可以這樣跟AI agent工作，我能不能複製這套給團隊用？團隊缺的不是 AI，而是沒有一致的 Workflow 跟能力。每個人都在用 AI，但是每個人跟 AI 合作的方法完全不一樣。

第二個嘗試：盤點團隊工作流

所以，我做的第二件事情不是導入 Agent，而是先盤點整個團隊到底平常怎麼工作。 我沒有一次找全部的人；我先把各個 角色的Lead 找過來，一起開始把整個團隊平常工作的流程盤出來。不是個人的 Workflow，而是整個團隊真正的 Workflow。 以我們軟體開發來說，從需求進來到上線，整串的flow是怎樣，先盤點清楚 PM 怎麼開 Spec；Developer 怎麼Review ticket，怎麼Design，怎麼開發、怎麼做 Code Review；QA 怎麼 Review Spec、怎麼驗證功能、怎麼測試。全部盤一次。

而這裡面，還有一個很重要的前置作業是建立共用的 Domain Knowledge & Rule。 大型專案一定會有很多 Domain Knowledge：很多專有名詞、很多跨 Module 的關係、不同模組之間的關係，以及很多設計背景。很多東西光看 Code 根本看不出來。 所以第一步，我要求大家先把所有共用知識整理出來，建立整個 Project 共用的 Context。

第三件事情，是建立「共用」Skill Repository。 接著，我建立了一個團隊共用的 Skill Repository。不是放 Code，而是放 Skill。 PM 去整理：怎麼寫 Spec、怎麼拆 Ticket的skill。 (P.S 這邊我們有厲害的PM主動去弄了超多skill) Developer 去整理：怎麼 Review Ticket、怎麼 Design、怎麼做 TDD、怎麼開發、怎麼 Code Review。 QA 去整理：怎麼 Review Spec、怎麼驗證功能、怎麼測試等的skill。 而且每個 Skill 都會 Reference 前面建立好的 Domain Knowledg & Rulee。這是團隊能力收攏的第二部。 Workflow中每一步，需要怎樣的Skill，每一步會有什麼產出，都先盤點出來 以我們團隊做事方式來說，最後整個workflow大概有12步

這段workflow盤點是最花時間的，也是溝通最累的時候 大家還看不到好處，有的人只覺得做這幹嘛，我把分配到給我的工作做好就好，但是有的人也很主動去嘗試改變

當所有 Skill 都建立完成之後。接下來就是把整個 Workflow 定義清楚。

例如： PM 建立 Ticket。 Ticket 必須 Reference Project Context，用團隊的Coding standard, API 標準 Ticket建立完成之後。 Developer 會用他們review spec的skill去review QA 也會有他們review spec的skill去review 全部 Review 完達成共識後後，才進入Developer 開發流程 開發過程遵循團隊的標準。比如Coding standard, API Standard, Error response standard, Error code standard

這盤點過程是要釐清 每一個角色知道自己什麼時候介入，是哪個agent?還是哪種角色 (人) 每一個階段知道應該呼叫哪些 Skill。 每一個階段的產出是什麼？如何交接給下一步

第四步：把Agent 串起來

Workflow 定義完成之後。我把Agent平台的infra建立起來，開始讓 Agent串上Chat channel。 我一直覺得要讓Agent真的在團隊發揮作用，一定要讓agent是在大家平常討論做事的地方 而這邊就會是我們的chat channel。有的團隊用line，有的團隊用slack，有的用teams 不管哪個，你一定是要讓他在chat cahnnel出現才能讓他自然地跟團隊互動 當上面都串起來後，接下來就是我們上線見真章的時候

現在我們 Chat channel 裡面有一個角色叫 G哥。 大家每天都直接跟 G哥 工作。 例如： 「G哥，幫我查xxxx現在行為是怎樣。」 「G哥，幫我根據這需求開 Ticket。」 「G哥，幫我 Code review。」 「G哥，幫我開發這張 Ticket。」

因為 G哥 完全知道我們團隊的 Workflow，也有我們整個專案的知識 他會真的按照 Workflow 去完成事情。 在叫他做事的過程中，不同角色不同人能隨時參與其中討論 像是Developer叫G哥開發東西到一半，這時PM收到客戶需求變動，PM可以直接在對應的討論串直接請G哥修改Spec，G哥會自動更新對應的ticket，然後再自動發動對應的開發修改 不跟你說你還會以為G哥就是公司的一個員工

當把Agent串上chat channel後，另外一個我想要的好處也跟著呈現出來了 由於大家現在都跟agent對話，所以大家彼此都能學習大家如何跟agent合作。不太會用的可以看到別人的互動方式自然地學習，而比較會用的人看到不太會用的人，也能直接跳進去協助

以前，一個人能力很強。能力就在他身上。 現在，知識被整理，Workflow 被標準化，Skill 被沉澱。 Agent 可以使用這些 Skill。 能力就開始累積在團隊身上。

這樣是否代表什麼事都交給Agent? 並沒有。Human in loop什麼時候要介入也是團隊要決定的 目前我們至少Agent開發完的東西，在multi agent都做完code review給pass後，最後還是需要人去做最後的 merge，但是前面已經很多agent替他把關 現在很多純Vibe coding的專案，在沒有好的規範流程下，最近也一直看各種上production的慘案而整個改不動要重寫 因此我們現在經手的大型專案，縱使開發工作都是AI在協助開發，最後一步人還是要做最後的審核者，為的都是不要在prdoudction出包造成客戶跟我們自己麻煩 不要小看這步，我看團隊在Review agent寫的東西的時候，縱使前面多個agent都說pass了，Developer還是抓到AI過度設計或是做不該做的東西 我看Developer跟agent的互動也蠻有趣的。Dev看完後留個code review comment，接著AI agent就再繼續回去自己改自己修了，自己做完code review，再去tag developer複審

雖然現在我們還是讓人介入，但是在模型越來越聰明後，未來是不是還需要人審核，這就是個有趣的議題了 目前我們現在也在嘗試自動把 Ticket 依照複雜度分級。 低複雜度的 Ticket。每個人或是Agent自己都可以直接 Trigger agent自動開發，自動merge

最後總結我大致做了什麼

  1. 打造團隊LLM Knowledge base
  2. 推動團隊共用skill
  3. 盤點定義團隊工作流
  4. 打造AI agent infra

很多人以為 AI Transformation 最難的是技術。 我反而覺得不是。我覺得最難的是三件事情。

第一，是人的心態。 有些人會覺得： 「我把別人派給我的事情做完就好了。」 這很正常。 不同位置，想法不同

第二，是有沒有人願意站出來做整合。 很多人會把自己的技術磨得很好。 但是不多人願意去做那些不屬於自己工作的事情。 例如： 盤點Workflow。 整理 Skill。 建立工具。 分享知識。 做這些事情。 薪水沒有變高。但是整個團隊會因此變強。 如果你的團隊有主動願義做這些事的人。 請一定把他們留下來。 因為他們帶來的影響力，遠遠超過他們自己完成多少事情。

第三：實際的結果不停的調整優化 打造這整套花的時間可能不多，但是只於LLM本來就不是固定的產出 後面實際使用，後續是需要不停的調整 隨著模型的進步，很多原本做的harness可能也不需要 這段，就是一個長跑過程，這中間會不停的試錯，但是團隊要心態上要能接受他很強大，但是不會完美，如果有問題，是大家要想辦法優化，而不能期待有人自己幫你修好

這幾個月的時間，非常的累。 每天白天就是一堆Office operation, 客戶會議，開不完的會，也還要不停跟大家溝通，平常白天的瑣事加鳥事，就讓我累得像狗一樣 這些東西都是晚上才有時間額外來弄 累歸累，但是看到大家使用成果，然後在打造起來的地基上看到一些同仁自己開始去持續優化，還是感到很欣慰跟開心

如果今天你是公司的老闆。 我強烈建議你自己要大量用 AI，甚至自己 Build 一些東西。你才知道 AI 真正可以做到什麼。 因為你知道可以做到什麼，推動改革，也會容易很多。 而你的位置，你對整間公司的context掌握度也比別人多，更能看到哪些地方能讓AI發揮價值 如果你自己用的不多。 那至少要找到一個真的很會用 AI，而且“會”跟團隊溝通的人，給他足夠的權限，讓他去推動。

AI 轉型，最後改變的是人。 而改變人，一直都是最難的事情。