目前圍繞 AI 的雜音與炒作甚囂塵上，許多焦點都放在工作被取代以及工程師可能失去什麼。我想談的是相反的一面：過去幾個月以來，我在平台團隊的日常工作中積極運用 AI agents(AI 代理) 所獲得的收穫。

我不會假裝這是魔法，AI agents 會犯錯，也無法取代下達明確指示所需的工程知識。有些與 AI agents 合作的工作，確實帶來了真正的躍進。我寫程式的速度變快了，但更大的改變在於範疇：我現在能承接過去會選擇擱置的工作。

平台團隊的難題

如果你讀過我先前那篇關於平台團隊挑戰的文章，就會了解這個背景：一個小團隊，卻要負責極大的涵蓋範圍。任何時候，我們都在維護共用服務與函式庫、橫跨 28 個專案的 micro-frontend(微前端) 架構、CI 流水線等等。

平台工作令人沮喪的現實是，最棘手的問題往往不是技術上的，而是組織上的。你可以發現有個問題需要在 20 多個專案中修正，也完全清楚該怎麼修，卻還是可能要花上數月才能完成。這是因為每個團隊都有自己的優先事項，未必與平台團隊的推動方向一致。平台團隊的挑戰，就在於彌合「這件事應該做」與「團隊有餘力去做」之間的落差。

而 AI agents 正開始以我意想不到的方式，填補這道落差。

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

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

理解既有服務

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

透過 AI agents，我得以將大部分的探索工作交出去。它遍歷了 GitLab 與 SVN 上所有使用該服務的專案，找出呼叫點，彙整服務在不同情境下的使用方式，並標示出我需要注意的邊界案例。原本可能需要花上幾天的工作，變成我只需花費一小部分時間就能檢視與延伸的成果。

它並未取代人為判斷與向受影響團隊追蹤確認的必要，但確實讓調查工作變得容易處理許多。

圖示使用與 WCAG 合規性

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

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

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

遷移與升級：不只是規劃，更要實際執行

一旦你能快速掌握問題的範圍，下一個自然的問題就是：是否也能用同樣的方式來修正它？這正是 AI agents 對我影響最大的地方，讓我們不再只是分享遷移指南，而是直接交付改動成果。

橫跨 28 個微前端的 React 升級

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

在最積極的團隊完成遷移後，仍有相當數量的專案卡住了最終發布。與其等待各團隊自行執行遷移，我利用 AI agents 逐一處理每個專案：遵循遷移指南、進行必要的設定變更、解決該專案特有的問題，並開啟 MR。對於每一個專案，AI agents 負責處理遷移中機械性的部分，團隊收到的不再是待辦請求，而是可直接合併的程式碼變更。

之前

之後

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

從「MR 已開啟」到「MR 已合併」的轉換率，遠高於從「已發送遷移指南」到「工作已完成」。團隊仍然負責審查、合併與持有程式碼，但在合併前需要做的事大幅減少。

CI 流水線重構

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

這類變更通常在各專案間的採用進度不一，團隊往往會拖到不得不做才願意導入。這種不一致會在不同專案的流水線表現不同時，造成混淆。

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

實用技巧

回顧上述範例，聽起來或許很簡單。實際上，在這些任務能穩定順利執行之前，經歷了相當多的嘗試與錯誤。自訂的 glab 技能是最大的收穫，其餘這些技巧也都來自那段實驗過程。

為你的工具定義技能

我做過最有影響力的一件事，就是為 glab CLI —— GitLab 的命令列工具 —— 撰寫自訂的 agent skill(代理技能)。技能是一個 markdown 檔案，能為 AI agents 提供清晰、明確的指示，告訴它如何完成特定任務：在這個案例中，就是如何跨專案搜尋、如何開啟 MR、如何透過 REST API 變更檔案。

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

透過 MCP(模型情境協定) 讓 AI agents 存取你的內部脈絡

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

我透過我們的設計系統 MCP 伺服器來解決這個問題。MCP 是一項開放標準，能讓你以結構化、可查詢的方式暴露內部資料與文件，供 AI agents 使用。我們的伺服器建構在 Storybook 之上，讓 AI agents 能存取元件的 props、使用指南與範例。當 AI agents 為無障礙審查圖示使用情況時，就能查詢我們設計系統中與圖示相關的元件預期該如何使用。

由於 MCP 是一項開放標準，同一個伺服器可以在不同工具間通用。不過，維護 MCP 伺服器是一筆實質的成本，並非一次性投入。對我們而言是值得的，但你也可以只是讓 AI agents 指向一些本地端的 markdown 檔案，或是如果你在 Confluence 上有內部文件，也可以使用像 Atlassian MCP 這類工具。

以稽核資料作為起點

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

我一直在嘗試一個專案，協助掃描與解析整個組織的相依套件使用情況，並透過 MCP 工具讓 AI agents 能直接查詢這些資料。

事前結構化能減少研究任務的錯誤

在平台團隊中，研究任務通常會支撐影響 20 多個專案的決策，因此準確性至關重要。遺漏邊界案例的模糊摘要不僅沒有幫助，還會導致錯誤的決策。

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

這會迫使 AI agents 有條理地工作。它逐個專案、逐個欄位地處理，每一列都有明確的完成定義。當 AI agents 面對沒有結構的開放式研究任務時，往往會以比你期望更高的抽象層級進行摘要，或提早停下來以為已經完成。

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

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

如果 AI agents 感到困惑或走錯方向，往往代表指示中存在落差或模糊之處。指南中未涵蓋的邊界案例，也會在 AI agents 於實際專案中遇到時浮現。當你在數個專案上跑過 AI agents 後，也同時對文件進行了壓力測試，讓指南對於最終需要審查變更或手動依步驟執行的團隊來說更加完善。

關於工具

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

這裡的開放標準（用於脈絡的 MCP、基於 markdown 的技能檔案用於代理行為）意味著你在某個工具上的投入，大多能轉移到其他工具上。與其過度綁定在某一種工作流程，不如記住這一點，尤其是在各家供應商與模型的價格波動之際。

這帶來了什麼改變

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

「AI 取代工程師」這種框架忽略了真正有趣的地方。我所經歷的更接近這樣：一名工程師所能承擔的上限提高了。

以前，我或許會發現一個影響 28 個專案的問題，並接受修正它需要數月的協調。現在，我可以直接修正它，讓團隊審查成果，而不是要求他們自行做出變更。以前，一項橫跨數十個儲存庫的研究任務可能需要投入一週的時間。現在，可能只需要一個下午。

這很重要，因為平台團隊相對於其負責的涵蓋範圍，幾乎總是資源不足。我們總是得艱難抉擇什麼值得去做。AI agents 正在擴大那些在經濟上可行的事項範圍，不是藉由取代其中的人為判斷，而是透過處理那些曾經讓這些任務成本高到令人卻步的機械性執行工作。

這件事還有個更個人的層面，我認為是平台工作特有的。身為平台團隊一員，持續的挫折之一是感覺與影響力之間有距離。你做出一項變更，但採用速度緩慢、推行不均，等到發現有些地方不太對勁時，已經過了數月。感覺上總是被動的：回應需求、為團隊排除障礙、等待被需要。

我注意到 AI agents 能改變這種動態。向每個使用團隊交付可直接合併的 MR，不僅更快，也意味著我能立即看到成果。阻礙在數天內而非數月後就會浮現。有一種真正端到端負責的感覺，這在過去的平台角色中很難實現，因為交付的很大一部分取決於其他團隊是否優先處理你的工作。

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

這正是我感到興奮的原因。不是對什麼會被取代的恐懼，而是對什麼變得可能的好奇。