Figma 把 AI 代理拉進畫布

Figma 這次很直接。AI 代理可以直接寫進畫布。它透過 beta MCP server 開放這件事。

更猛的是，這段 beta 目前免費。之後才會改成用量計費。講白了，Figma 給團隊一個試跑窗口，看代理到底能不能真的照著設計系統做事。

這次更新還綁上 Figma MCP server 的 skills。它們是 markdown 指令。用來告訴代理，怎麼在檔案、元件、變數裡工作。

Figma 到底開了什麼權限

這次不是只讀橋接。Figma 用新的 use_figma 工具，讓代理能直接建立和修改設計資產。它會吃團隊既有的元件和變數。這代表代理不必從零亂猜。

你可能會想問，這有什麼差。差很多。很多 AI 生成畫面看起來怪，就是因為它不知道團隊怎麼定義層級、間距、字級和互動規則。模型會畫。它不一定懂你的系統。

Figma 的做法，是把畫布變成可編輯的上下文。不是把設計當成截圖。也不是把設計當成交付終點。代理可以直接在同一套結構裡動手。

• beta 現在免費，之後會改成用量計費。
• 可搭配 Claude Code、Codex、Cursor。
• Figma 說之後會補齊更多能力，先從圖片和自訂字型開始。
• 範圍也涵蓋 FigJam、Figma Draw、Code Connect。

為什麼 skills 比新 API 更重要

這次最有意思的，不是傳輸層。是 skills。Figma 把它做成 markdown 檔。內容會定義代理該怎麼做事。步驟順序、規則、限制，都能寫進去。

這聽起來很樸素，但很實用。因為代理就算看得到檔案，也還是要知道團隊怎麼看待層級、可讀性、無障礙、元件重用。skills 的價值，就是把這些知識變成可讀規則。

Figma 也推了一個內建 skill，叫 /figma-use。另外還有社群範例。內容包含元件生成、token 同步、間距規則、無障礙規格，還有多代理工作流。

“Teams at OpenAI use Figma to iterate, refine, and make decisions about how a product comes together,” says Ed Bayes, design lead at Codex. “Now, Codex can find and use all the important design context in Figma to help us build higher quality products more efficiently.”

這段話很直白。重點不是 AI 會不會畫。重點是它能不能找到正確上下文。沒有上下文，代理就只是在湊 UI。看起來像樣，實際上很空。

跟其他 AI 設計工具比，差在哪

很多 AI 設計工具是從零生圖。速度快。問題也很快出現。它們常常不知道 token、元件、可及性規範。結果就是一個看起來不錯，但很難落地的 mockup。

Figma 的路線不一樣。它不是叫模型自己幻想一個介面。它是要模型在既有系統裡工作。這比較難，但也更接近真實產品團隊的日常。

Figma 也提到舊的 generate_figma_design 工具。它能把 live app 或網站的 HTML 轉成可編輯的 Figma layers。新的 use_figma 更進一步。它能直接用團隊元件和變數去改設計。

• 一般圖片生成： 很快，但常和設計系統脫鉤。
• Figma MCP + skills： 設定較多，但能貼著真實元件和規範走。
• Code-first 代理： 寫程式很強，但常要補設計上下文。
• 人工流程： 判斷最好，但重複改版很花時間。

還有一個現實面。Figma 說這套能力是原生接在 MCP server 上，不是單純掛個外掛。這對權限、檔案完整性、和行為可預測性都比較重要。企業團隊會在意這個，不是只看 demo 漂不漂亮。

對設計團隊和工程團隊的影響

如果你是設計師，這件事不是叫你下班。它是叫你把規則寫清楚。元件結構、變數命名、間距標準，這些會變得更重要。因為代理真的會去讀，也真的會去改。

如果你是工程師，這會讓 code 和 canvas 的距離更短。Figma 說，團隊可以從 code、Figma、或 command line 開始，再在不同介面間切換。上下文不容易掉。這點很實際。

如果你在做產品流程，問題就變成一個：你的設計規則夠不夠明確。規則寫得越清楚，代理越能幫忙。規則都藏在腦袋裡，那就只能一直人工補洞。

Figma 也給了幾個例子，像 /create-voice、/apply-design-system、/sync-figma-token。這些不是炫技。它們是在處理重複工作。重複改字、重複套 token、重複對齊版型，這些才是日常。

產業脈絡：這波不是單點事件

Figma 這次踩進來的，其實是 AI 與工作流整合的大方向。過去一年，很多工具都在做同一件事。把模型從聊天框拉進真正的工作環境。像是編輯器、雲端文件、設計軟體、內部知識庫。

原因很簡單。LLM 很會補字。可是真正的工作，不是補字而已。它還要懂結構、懂權限、懂版本、懂團隊慣例。MCP 這類協定，就是在補這個洞。它讓模型不只會說，還能碰得到資料和工具。

從台灣團隊的角度看，這件事很實際。很多新創和產品團隊都在做 design system。也很多團隊同時用 Figma、GitHub、Cursor、Claude。若工具能共享上下文，來回溝通就少很多。少掉的不是一句話，是一堆修正工時。

但我也不想講得太浪漫。代理一旦能直接改檔案，風險也會上來。權限控管、審核流程、版本回溯，這些都要跟上。否則代理不是幫忙，是幫你製造更多待辦事項。

接下來值得盯的事

Figma 說接下來會擴充圖片支援和自訂字型。它也會把 skills 做得更好分享。這代表設計流程可能會開始像套件一樣流通。不是只分享元件，連工作方法都能分享。

我的判斷很直接。接下來 3 到 6 個月，真正重要的不是 demo 多炫。是團隊會不會拿它做重複任務。像是批次改文案、同步 token、補 accessibility 標記、更新多頁介面。這些才是能量化的地方。

如果 Figma 能讓代理穩定改檔，還不把設計系統搞爛，那它就不只是多一個 AI 功能。它會變成設計流程裡的一個新入口。你覺得呢，你們團隊的設計規則，現在夠不夠讓代理直接照做？