最近關於人工智慧的討論充斥著各種雜訊與炒作，焦點大多放在工作被取代、工程師會失去什麼。我想談的是相反的一面：過去幾個月來，我在平台團隊的日常工作中積極運用 AI 代理，究竟獲得了什麼。

我不會把它說得像魔法一樣，代理會犯錯，也無法取代為了給出清晰指令所需要的工程知識。但有些和代理一起完成的工作，確實帶來了實質的躍升。我寫程式變快了，但更大的改變在於範疇：那些原本會被我擱置的工作，現在我也能接手了。

平台團隊的難題

如果讀過我之前那篇談平台團隊挑戰的文章，就會知道背景：一個小團隊，卻要負責非常廣大的範圍。任何時候，我們同時要維護共用的服務與函式庫、橫跨 28 個專案的微前端架構、CI 流水線等等。

平台工作令人挫折的現實是，最棘手的問題往往不是技術性的，而是組織性的。你可能已經發現有個問題需要在 20 多個專案中修正，也完全清楚解法是什麼，卻還是得花上好幾個月。原因是每個團隊都有自己的優先事項，未必和平台團隊的目標一致。平台團隊的挑戰，就在於彌合「這件事應該要做」和「團隊有餘力去做」之間的落差。

代理正開始以我意想不到的方式，拉近這個落差。

研究任務：讓跨領域決策變得可行

在平台團隊中，最重要的決策往往也是最難有把握做出的。在決定棄用某個服務、替換某個函式庫，或在全組織推行新標準之前，你必須先了解會影響到誰、有哪些邊界情況。這類調查工作向來成本很高，往往導致團隊乾脆跳過，直接在資訊不完整的情況下做決定，或是因為沒人有餘力好好調查，而無限期延後決策。

釐清一個遺留服務的狀況

我們有一個已經存在多年的服務。沒有明確的負責人，文件也少得可憐，卻有個問題不斷被提起：到底誰在用這個服務，又是怎麼用的？我們認為這個服務應該要退役，但在搞清楚實際的使用情況之前，無法對遷移做出明確的決定。要找到答案，就得在 GitLab 上手動追蹤相依關係、翻找老舊的 SVN 儲存庫，再從多年前、早已離職的人所寫的程式碼中拼湊出全貌。

有了代理，我得以把大部分的探勘工作交出去。它遍歷了 GitLab 和 SVN 上所有使用該服務的專案，找出呼叫點，歸納在不同情境下的使用方式，並標示出我該注意的邊界情況。原本可能要花上幾天的工作，變成我能在極短時間內檢視並進一步處理的事情。

它無法取代人的判斷，也無法取代與受影響團隊的後續溝通，但確實讓調查工作變得容易處理許多。

圖示使用與 WCAG 合規性

另一個例子是我們評估是否符合 WCAG AA 標準的工作，其中一部分是檢視我們在各應用程式中是否一致且正確地使用圖示。為了了解問題的範圍以及該如何修正，我們需要知道哪些圖示元件正在被使用、在各自的脈絡下是否被正確使用，以及真正的 WCAG AA 落差在哪裡。

如果一個專案一個專案地手動檢查，會非常繁瑣。相反地，我利用代理，根據我們的設計系統使用數據，在脈絡中逐一評估每個圖示的使用情況，並將結果填入試算表。

我再依需要進行檢視與修正，但我投入的時間大幅減少了。更重要的是，我們得以根據實際數據來決定下一步該怎麼做。

遷移與升級：不只是規劃，更要動手完成

一旦能快速掌握問題的範圍，自然會想問：能不能用同樣的方式把它修好？這正是代理對我影響最大的地方，讓我們不再只是分享遷移指南，而是能直接交付修改後的成果。

橫跨 28 個微前端的 React 升級

如果讀過我那篇關於微前端 React 升級的文章，就會知道這類工作需要多少協調。每個專案由不同的團隊負責，各自有不同的優先事項。要讓所有團隊都去執行遷移，即使文件寫得再清楚、步驟再明確，也是一大挑戰。

在最積極的團隊完成遷移後，仍有相當數量的專案卡住了最終發布。與其等待各團隊自行處理，我讓代理逐一處理每個專案：遵循遷移指南、進行必要的設定調整、解決該專案特有的問題，然後開啟 MR。每一個專案中，代理都處理了遷移裡那些機械性的部分，團隊收到的是可以直接合併的程式碼變更，而不是一份待辦請求。

之前

之後

每一個 MR 最後都被合併了。整個推行過程中唯一遇到的問題，來自一個在我發出 MR 之前就手動完成遷移的團隊。由代理產生的變更，其紀錄反而比人工作業的更乾淨。

從「MR 已開啟」到「MR 已合併」的轉換率，遠高於從「已發送遷移指南」到「工作已完成」。團隊依然會審查、合併並擁有程式碼的主導權，只是在合併前需要做的事情變少了。

CI 流水線重構

最近一次 GitLab CI 重構也是類似的情況。我們需要把共用的流水線從已被棄用的 only 關鍵字，遷移到 rules 語法。這項變更本身並不難理解，但必須在每一個使用該流水線的專案中執行，而每個專案都有自己的特殊狀況，偶爾還會遇到需要處理的重大變更。

這類變更通常在各專案間的採用進度並不一致，團隊往往會拖到不得不做才動手。這種不一致會導致不同專案的流水線行為各異，進而造成混淆。

透過讓代理以程式化的方式找出所有受影響的專案、逐一完成遷移、處理遇到的重大變更並提交 MR，我得以用遠少於手動操作的時間，在所有專案中完成這項變更。

實用技巧

回頭看上面這些例子，聽起來或許很簡單。但實際上，在這些任務能夠穩定順利執行之前，經歷了不少嘗試與錯誤。客製化的 glab skill 是最大的收穫，其他技巧也都是從這些實驗中累積而來。

為你的工具定義一個 skill

我做過最有影響力的一件事，就是為 glab CLI——也就是 GitLab 的命令列工具——撰寫一個客製化的 agent skill。所謂 skill，就是一個 Markdown 檔案，它給代理提供清晰、帶有明確主張的操作指示：在這個例子中，就是如何跨專案搜尋、如何開啟 MR、如何透過 REST API 進行檔案變更。

沒有它，代理要不是拒絕與 GitLab 互動，就是會產生不一致、脆弱的 bash 單行指令。有了一個定義良好的 skill，它們就有了可靠的操作手冊。Agent Skills 是一項開放標準，在 Cursor、Claude Code 和 GitHub Copilot 等工具中都有支援。

透過 MCP 讓代理取得內部脈絡

開箱即用的代理對你的內部系統一無所知。它們能讀程式碼，卻不知道你的元件應該做什麼，或共用函式庫預期的 API 是什麼樣子。

我是透過我們的設計系統 MCP 伺服器來解決這個問題。MCP（Model Context Protocol）是一項開放標準，能讓你以結構化、可查詢的方式，將內部資料與文件開放給代理使用。我們的伺服器建構在 Storybook 之上，讓代理能夠存取元件的 props、使用指南和範例。當代理在審查圖示使用是否符合無障礙標準時，就能查詢設計系統中與圖示相關的元件原本該如何使用。

由於 MCP 是開放標準，同一個伺服器可以在不同工具間通用。不過，維護一個 MCP 伺服器是一筆實際的成本，並非一次性投入。對我們來說很值得，但你也可以直接讓代理去讀取本地的 Markdown 檔案，或如果你們的內部文件放在 Confluence，也可以考慮使用像 Atlassian MCP 這樣的工具。

以稽核資料作為起點

與其讓代理從零開始去發掘哪些專案使用了某個函式庫，不如直接把答案給它。我們有設計系統的使用分析數據，能精確告訴我們哪些專案正在使用哪些元件、版本為何。在任務一開始就把這些資料餵給代理，意味著它是從我們的實際使用數據出發，而不是靠猜測，這樣既更快也更準確。

我一直在透過一個專案進行實驗，協助掃描與解析整個組織中的相依套件使用情況，並為代理提供可直接查詢這些資料的 MCP 工具。

事先建立結構能減少研究任務中的錯誤

在平台團隊中，研究任務通常會影響到 20 多個專案的決策，因此準確性非常重要。一份遺漏邊界情況的模糊摘要，不只是沒有幫助，還會導致錯誤的決策。

對於研究任務，我發現事先花時間定義輸出格式是值得的。與其叫代理「去研究我們各專案中的圖示使用情況」，不如給它一個試算表範本，每個專案一列，並指定好要填寫的欄位。

這會迫使代理更有條理地工作。它逐一專案、逐一欄位地完成，每一列都有明確的完成標準。當代理面對一個開放式、缺乏結構的研究任務時，往往會以比你預期更高的抽象層次來總結，或因為自認已完成而提早停下來。

還是要寫遷移指南，並把它當作提示

對於平台團隊來說，無論如何你都會撰寫遷移指南來向使用方團隊說明變更。而我發現，把同一份指南餵給代理，本身就是一個很有用的驗證步驟。

如果代理感到困惑或走錯方向，往往代表指南中的指示存在缺口或語意不清。那些指南中未涵蓋的邊界情況，會在代理於真實專案中遇到時浮現出來。當你讓代理跑過幾個專案後，也等於對文件進行了壓力測試，這會讓指南對於最終需要審查變更或手動依步驟操作的團隊來說更加完善。

關於工具

這類工作我主要使用 Cursor，同時也在 Claude Code 和 GitHub Copilot 上做過一些嘗試。老實說，工具之間的差異，遠不如你提供給它們的脈絡品質來得重要。一個定義良好的 skill 和一個好的 MCP 伺服器，能帶你走得比不斷更換工具更遠。

這裡的開放標準（用於提供脈絡的 MCP、用於定義代理行為的 Markdown skill 檔案）意味著你在某個工具上的投入，很大程度上可以轉移到其他工具上。隨著不同供應商與模型的價格波動，與其被單一工作流程綁死，不如記住這一點。

這帶來了什麼改變

代理會犯錯。它們需要清晰的脈絡和定義明確的任務。你仍然需要檢視輸出、理解它們做了什麼，並運用自己的判斷。有些任務它們處理得不太好，我在規劃階段也仍需要經過幾次反覆調整，才能得到想要的結果。

「AI 取代工程師」這樣的框架，忽略了真正有趣的地方。我的實際體驗更接近這樣：單一工程師能夠承擔的工作上限提高了。

以前，我可能會發現一個影響 28 個專案的問題，然後接受要花數個月的協調才能修好。現在，我可以直接把它修好，再讓團隊來審查，而不是請他們自己去改。以前，一個橫跨數十個儲存庫的研究任務，可能意味著一整週的投入。現在，可能一個下午就夠了。

這很重要，因為平台團隊的人力相對於所負責的範圍，幾乎永遠都是不足的。我們總得做出艱難的取捨，決定什麼值得去做。AI 代理正在擴大那些在經濟上可行的事項範圍，靠的不是取代其中的人類判斷，而是接手那些過去讓這些任務成本過高、難以執行的機械性工作。

這件事還有一個更個人、我認為是平台工作特有的面向。在平台團隊中，一個揮之不去的挫折感是覺得自己離影響力很遠。你做了一個改動，但採用速度很慢、推行也不平均，等到發現有哪裡不太對勁時，已經過了好幾個月。感覺上總是被動的：回應需求、幫團隊排除障礙、等待被需要。

我注意到的是，代理可以改變這種動態。向每個使用方團隊交付可直接合併的 MR，不只是更快，也意味著我能立刻看到成果。阻礙在幾天內就會浮現，而不是幾個月。有一種真正端到端負責的感覺，這在以往的平台角色中是很難實現的，因為交付的成敗有太多取決於其他團隊是否優先處理你的工作。

有一種說法認為，AI 主要就是為了削減成本，用更少的人做同樣的事。在某些情境下或許是如此。但以我的經驗來說，更有趣的故事在於去做那些以前不值得做的事：涵蓋更廣的範圍、維持更高的標準、接手那些否則會永遠躺在待辦清單上的遷移，並最終在平台決策與實際成果之間形成完整的閉環。

這才是讓我感到興奮的地方。不是恐懼什麼會被取代，而是好奇什麼變得可能了。