Figma MCP 與 AI 自動化設計系統教學:Design Tokens 同步到程式碼的完整流程
設計系統的痛點
如果你在一個有設計系統的團隊裡工作過,你一定體會過那種痛苦:設計師在 Figma 裡更新了一個顏色變數,然後工程師那邊的 CSS 變數還停留在舊版本。或者更慘的是,設計師改了按鈕的圓角半徑,但工程師根本不知道改了,直到 QA 在測試時才發現畫面跟設計稿對不上。
這個問題的根源在於設計和程式碼之間缺乏一個「即時同步」的機制。傳統的做法是設計師改完之後通知工程師,工程師再手動去改程式碼裡的對應值。這個流程不但慢,而且容易出錯。尤其當你的設計系統有幾百個 Token 的時候,光是追蹤哪些改了就已經夠頭痛了。
好消息是,2026 年這個問題終於有了一個優雅的解決方案:用 MCP 協議搭配 AI Agent,讓 Design Tokens 的同步完全自動化。
MCP 協議是什麼
MCP 全名是 Model Context Protocol,中文叫模型上下文協議。簡單來說,它是一個讓 AI 模型能夠「使用工具」的標準協議。你可以把它想像成 AI 世界的 USB 接口——不管是什麼 AI 模型,只要支援 MCP,就能連接到各種外部工具和服務。
MCP 的架構分成三層:Client(通常是 AI 應用)、Server(提供特定功能的服務)、和 Transport(傳輸層)。當 AI Agent 需要讀取 Figma 的設計資料時,它會透過 MCP 協議向 Figma MCP Server 發送請求,Server 再去 Figma API 抓取資料回傳。
為什麼要用 MCP 而不是直接串 API?因為 MCP 提供了一個標準化的介面,讓 AI Agent 不需要知道每個工具的 API 細節。今天你的 Agent 連 Figma,明天可能還要連 GitHub、Slack、Notion,用 MCP 就能用同一套邏輯處理所有工具。
Figma Variables 與 Design Tokens
在聊怎麼同步之前,先搞清楚 Figma Variables 和 Design Tokens 的關係。Figma Variables 是 Figma 在 2023 年推出的功能,讓你可以在 Figma 裡面定義顏色、數值、字串等變數,然後在設計中引用這些變數。
Design Tokens 則是一個更廣泛的概念,由 W3C 制定了標準規格(W3C Design Tokens Community Group)。Design Tokens 不只存在於 Figma,它可以被轉換成 CSS 變數、iOS 的 Swift 常數、Android 的 XML 資源等等。
Figma Variables 基本上就是 Design Tokens 在 Figma 端的實現。所以我們的目標是:把 Figma Variables 讀出來,轉換成符合 W3C 標準的 Design Tokens 格式,然後再轉換成各平台需要的程式碼。
目前 Figma Variables 支援的類型包括:
- Color:顏色值,支援 RGBA
- Number:數值,像是間距、圓角、字體大小
- String:字串,像是字體名稱
- Boolean:布林值,用於條件邏輯
用 MCP 連接 Figma 和程式碼
Figma 官方和社群已經推出了好幾個 MCP Server 的實作。最常用的是 figma-mcp-server,它能讓 AI Agent 做到以下這些事:
- 讀取 Figma 檔案的結構和元件
- 讀取和修改 Variables(Design Tokens)
- 取得設計稿的截圖
- 建立和更新元件
設定的方式很簡單。以 Claude Desktop 為例,你只需要在 MCP 設定檔裡加入 Figma Server 的連線資訊,提供你的 Figma Access Token,AI Agent 就能直接存取你的 Figma 檔案了。
如果你對 MCP 在其他設計工具上的應用有興趣,可以參考 Figma 2026 Git 整合教學這篇文章,裡面也有提到版本控制相關的整合方式。
AI Agent 自動化流程
有了 MCP 的連接之後,真正有趣的部分來了:讓 AI Agent 自動完成整個同步流程。
一個典型的自動化流程長這樣:
- AI Agent 定期(或被觸發時)透過 MCP 讀取 Figma Variables 的最新狀態
- 比對目前程式碼庫中的 Design Tokens 檔案,找出差異
- 自動生成更新後的 Token 檔案(JSON、CSS、Swift 等格式)
- 建立 Pull Request 並附上變更摘要
- 通知相關的工程師和設計師
這個流程裡最關鍵的是「差異比對」和「格式轉換」。AI Agent 不能只是無腦地覆蓋整個檔案,它需要理解哪些 Token 被新增、修改或刪除了,然後只更新有變動的部分。
格式轉換的部分,目前業界比較成熟的工具是 Style Dictionary(Amazon 開源的)和 Tokens Studio。AI Agent 可以呼叫這些工具來做轉換,不需要自己從頭寫轉換邏輯。
Uber uSpec 案例
說到設計系統的 AI 自動化,不能不提 Uber 的 uSpec 專案。Uber 的設計系統叫 Base Web,規模很大,涵蓋了幾千個元件和 Token。在 2025 年下半年,Uber 開始實驗用 AI Agent 來自動維護設計規格文件。
uSpec 的做法是讓 AI Agent 直接讀取 Figma 設計稿,自動生成詳細的設計規格(包含間距、顏色、字體等所有 Token 值),然後把規格文件同步到 Confluence。工程師不用再自己從 Figma 裡一個一個抄數值了。
Uber 公開分享的數據顯示,uSpec 讓設計到開發的交付時間縮短了大約 40%,規格錯誤率也明顯降低。雖然他們的系統是內部工具,不是直接基於 MCP,但核心邏輯是一樣的:用 AI 來橋接設計和程式碼之間的鴻溝。
如果你對 AI 設計工具的比較有興趣,可以看看 Google Stitch vs Figma 比較這篇分析。
實作步驟
講了這麼多理論,來動手做吧。以下是用 Figma MCP + AI Agent 實現 Design Tokens 自動同步的完整步驟。
步驟一:準備 Figma 端
確保你的設計系統在 Figma 裡已經用 Variables 來管理所有的 Token。建議按照 W3C Design Tokens 的分類方式來組織:Primitive Tokens(基礎值)、Semantic Tokens(語意化值)、Component Tokens(元件級值)。命名規則要一致,像是 color/primary/base、spacing/md 這樣的格式。
步驟二:設定 Figma MCP Server
安裝 Figma MCP Server 並設定連線。你需要一個 Figma Personal Access Token(在 Figma 帳號設定裡產生)。把 Server 設定加到你的 AI Agent 的 MCP 配置中:
{"mcpServers":{"figma":{"command":"npx","args":["-y","figma-mcp-server"],"env":{"FIGMA_ACCESS_TOKEN":"your-token-here"}}}}步驟三:建立 Token 轉換流程
在你的專案中建立一個 tokens/ 目錄,裡面放置 Design Tokens 的 JSON 檔案和 Style Dictionary 的設定檔。AI Agent 從 Figma 讀出 Variables 之後,會把它們寫入這個目錄的 JSON 檔,然後 Style Dictionary 會自動轉換成各平台的格式。
步驟四:設定自動化觸發
你可以用幾種方式來觸發同步:手動告訴 AI Agent「幫我同步 Design Tokens」、設定定時任務每天自動檢查一次、或者串接 Figma Webhook,在設計師做了變更時自動觸發。
步驟五:建立 PR 審核流程
AI Agent 自動建立 PR 之後,還是需要人工審核。建議在 PR 描述中自動附上變更的視覺化比對(舊值 vs 新值),讓審核者一目了然。
想了解更多 Figma AI 功能的實際應用,推薦閱讀 Figma Make AI 原型生成這篇教學。
實際效益
我自己在一個中型專案裡導入這套流程之後,最明顯的改善是:設計師不用再寫一大堆 Handoff 文件了。改了什麼 Token,AI Agent 會自動偵測並建立 PR。工程師只需要審核和合併,不用再手動比對設計稿。
這套做法目前還在快速演進中。隨著 MCP 生態系的成熟和 AI Agent 能力的提升,我預期在 2026 下半年會看到更多團隊採用類似的自動化流程。設計系統的維護不再是苦差事,而是一個幾乎不需要人力介入的自動化管線。
繼續閱讀
Figma Atomic Design 元件庫建立完整教學:從原子設計到團隊共用設計系統
用 Atomic Design 方法論在 Figma 中逐層搭建設計系統,從 Atoms、Molecules 到 Organisms,打造團隊共用元件庫。
相關文章
你可能也喜歡
探索其他領域的精選好文