--- schemaVersion: 1 slug: mp-230-20260330-figma-figma-ai-agent-canvas ticketId: MP-230 lang: zh-tw title: Figma 把畫布打開給 AI agent 了 — 現在可以直接在 canvas 上做設計 summary: Figma 透過 MCP server 的 use_figma 工具，讓 Claude Code、Codex 等 AI agent 可以直接在畫布上建立和修改設計，並用 skills（markdown 指令檔）引導 agent 遵守團隊的設計系統與慣例。這不只是又一個 AI 功能，而是把設計決策的脈絡直接交給 agent 操作。 originalDate: 2026-03-24 translatedDate: 2026-03-30 source: Figma Blog sourceUrl: https://www.figma.com/blog/the-figma-canvas-is-now-open-to-agents/ author: null authorshipNote: null canonicalUrl: https://gu-log.vercel.app/posts/mp-230-20260330-figma-figma-ai-agent-canvas status: published replacementTicketId: null replacementUrl: null --- # Figma 把畫布打開給 AI agent 了 — 現在可以直接在 canvas 上做設計 > **來源:** [Figma Blog](https://www.figma.com/blog/the-figma-canvas-is-now-open-to-agents/) 每個管過 design system 的人都有同一個噩夢：設計師改了 Figma 裡的顏色，code 裡還是舊的。工程師更新了 spacing，Figma 沒跟上。兩邊各自演化三個月，直到上線前 QA 截圖一比——「欸，這個按鈕跟 spec 長得不一樣。」 這個噩夢的根源不是工具不好，是 **design context 活在人的腦袋裡，而不是活在工具裡**。 Figma 最新這步棋，就是在處理這件事。透過 [MCP](https://gu-log.vercel.app/glossary#mcp) server，AI [agent](https://gu-log.vercel.app/glossary#agent) 現在可以直接在 Figma file 裡面工作——不是亂畫，是接上團隊的 component library、讀 variable、用 auto layout。Figma [之前的 code-to-canvas](https://gu-log.vercel.app/posts/mp-92-20260217-figma-claude-code-to-canvas/) 只是單向把程式碼轉成設計稿，現在 `use_figma` 這個新工具讓 [agent](https://gu-log.vercel.app/glossary#agent) 雙向操作整個畫布。 但真正有意思的不是工具本身——而是 Figma 選擇不自己做 AI，改開一道門讓所有 agent 走進來。 > **Mogu OS：** > > 以前 AI 幫忙做設計，就像請一個完全不認識公司的外包，丟一句「做一個登入頁面」就叫他動手。現在 Figma 等於把這個外包直接拉進 design system、讓他看到所有 component library、讀到 style guide，然後才讓他開工。而且不是 Figma 自己硬幹一個 AI — 他們用 [MCP](https://gu-log.vercel.app/glossary#mcp) 開了一道門，[Claude Code](https://gu-log.vercel.app/glossary#claude-code)、[Codex](https://gu-log.vercel.app/glossary#codex)、Cursor 都走同一個入口。跟當年 plugin 生態一模一樣的策略，只是這次走進來的不是 plugin 開發者，是 coding agent。 ## 舊工具搭新主角：一個拉現實進來，一個在裡面創作 Figma MCP server 裡面有兩個核心工具，關係像助教跟教授。 **`generate_figma_design`** 是助教——負責把「外面跑著的東西」帶回教室。Live app 的 UI？它轉成可編輯的 Figma layer。Code 跟 design 不同步了？助教先把現實拉進來，大家看著實際的東西再討論要改什麼。這工具之前就有，但搭上新主角之後用途完全不同。 **`use_figma`** 是教授——這次的新功能。[Agent](https://gu-log.vercel.app/glossary#agent) 直接在畫布上操作，而且是照團隊定義好的方式來。不是拿空白筆亂畫，是打開 component library、讀 variable 名稱、遵守 auto layout 規則。 搭配起來很自然：助教把 live UI 拉進 Figma 當底，教授用正確的 component 和規則在上面改或做新設計。一個負責「把現實帶進來」，一個負責「用正確的方式創作」。 > **Mogu 內心戲：** > > 這個分工暗示了一個很深的產品賭注：Figma 不打算讓 AI 從零開始畫圖。它要 AI 在已經建好的系統裡面工作。這跟那些「一句 prompt 生一整個 app」的工具走的是完全不同的路線 — 那些工具把 AI 當創作者，Figma 把 AI 當「團隊裡最聽話的設計師」。哪條路在企業裡比較站得住腳？老闆會不會接受一個跟品牌完全脫鉤的設計，答案很明顯。 ┐(￣ヘ￣)┌ --- ## Skills：把不成文的規矩變成 agent 聽得懂的指令 好，[agent](https://gu-log.vercel.app/glossary#agent) 進畫布了。但問題來了。 它怎麼知道「按鈕間距都是 8px 倍數」？怎麼知道 primary color 叫 `--brand-500` 不叫 blue？怎麼知道新 component 該放哪個 page？靠經驗？它沒有。靠猜？猜錯了修的時間比自己做還久。 這就是 **skills** 在幹的事——markdown 檔案，裡面寫了一堆指令，告訴 agent 在 Figma 裡該怎麼執行特定工作流程。步驟、順序、慣例全部寫死。但巧妙的地方在於，skill 不只是 checklist，更像 onboarding doc 混 SOP——同時告訴 agent「做什麼」和「做得好長什麼樣」。 Anthropic 的 [Claude Code](https://gu-log.vercel.app/glossary#claude-code) 產品負責人 [Cat Wu](https://gu-log.vercel.app/glossary#cat-wu) 講得到位： > _“Skills teach Claude Code how to work directly in the design canvas, so you can build in a way that stays true to your team’s intent and judgment.”_ 直譯大概是「Skills 教會 Claude Code 怎麼直接在設計畫布上工作，讓能用忠於團隊意圖和判斷的方式來建構。」但這邊的 vibe 更像是在說：**團隊那些不成文的規矩，現在可以被寫下來，然後 agent 會真的照做。** 最底層有一個基礎 skill 叫 `/figma-use`，所有其他 skill 都建立在它上面——新人入職前要先讀的 onboarding doc，agent 版。 > **Mogu 歪樓一下：** > > 寫 skill 不需要寫 code、不需要做 plugin。這一點非常關鍵——Design Lead 和 PM 也能直接定義「agent 該怎麼做事」，不用什麼都等工程師。某種程度上，skill 就是「可執行的 design guideline」：以前寫完 guideline 只能祈禱團隊照做，現在寫完 skill，agent 就是會照做。人不一定會讀 wiki，但 agent 會。跟 [Claude Code 的 CLAUDE.md](https://gu-log.vercel.app/posts/gp-2-20260129-claude-code-vs-codex/) 概念一模一樣 — 把規則寫成 agent 看得懂的格式，它就乖乖聽。Figma 只是把這套搬到了設計領域。 ┐(￣ヘ￣)┌ --- ## 九個 Skills 解決的三種痛 Figma 一口氣放了九個 example skills，來自內部團隊跟社群實踐者。但一個一個列沒意思——仔細看會發現，這些 skill 其實在攻擊三種完全不同的痛。 **第一種痛：設計資產正在腐爛，而且所有人都知道。** 每一個管過 design token 的人都有同樣的噩夢——開頭那個場景。設計師改了 Figma 的顏色，code 裡還是舊的；工程師更新了 code 裡的 spacing，Figma 沒跟上。兩邊各自演化，直到 QA 在上線前發現「欸按鈕怎麼長不一樣」——通常太遲了。Firebender 的 **`/sync-figma-token`** 正面攻擊這個問題：在 code 和 Figma variable 之間同步 design token，而且附帶 drift detection。同一條線上，Edenspiekermann 的 **`/apply-design-system`** 更直接——那些沒接上 design system 的散裝設計稿，[agent](https://gu-log.vercel.app/glossary#agent) 幫忙一個一個接回去。講白了就是自動化的技術債償還。 > **Mogu OS：** > > Design token drift 就像兩個人各自編輯自己那份 Google Doc，一個月後才發現「啊靠，我們在改不同版本」。有了 drift detection，至少每次改 token 都能自動檢查兩邊有沒有飄掉。這不是什麼花俏新功能——這是在止血。 (ง •̀\_•́)ง **第二種痛：該做的事情永遠排不進 sprint。** Uber 的 Ian Guisard 做了 **`/create-voice`**：從 UI spec 自動生成螢幕閱讀器規範，包括 VoiceOver、TalkBack、ARIA。Accessibility spec 是每個團隊都知道該做、但永遠找不到時間排的東西——因為那個「有空的 sprint」永遠不會來。現在 agent 在每次設計完成後自動補上 a11y spec，不用等人的良心發現。另一個是 **`/figma-generate-library`**，方向是 code → design：直接從 codebase 建立 Figma component，專門給那些「code 已經跑了三年但 Figma 裡什麼都沒有」的團隊。以前回補這些是設計師兩週的苦力活，現在 agent 讀完 code 就幫忙建好。 **第三種痛：想要更多，但也有點怕。** Augment Code 的 **`/multi-agent`** 跑平行 workflow——多個 [agent](https://gu-log.vercel.app/glossary#agent) 同時在不同 frame 上動工。聽起來很美好。但如果有跟三個設計師同時編輯同一個 Figma file 的經驗，就知道那種混亂。現在把設計師換成 agent，平行度再乘以三？只能說：大膽。(╯°□°)╯ --- ## Self-healing loop：做完了自己檢查，不及格自己重來 前面講的 skill 解決了「agent 怎麼做」的問題。但做出來的東西對不對？ 這裡才是整篇最讓人驚豔的設計：skill 不只定義 agent 怎麼生成東西，也定義 agent 怎麼**回頭檢查和修正自己的 output**。生完一個畫面之後，agent 可以截圖、跟預期的結果比對，然後自己去修不對的地方。 而且因為操作的是真正的結構——component、variable、auto layout——修的時候是在修結構，不只是在修像素。動一個 spacing token 的值，所有用到這個 token 的地方都跟著改。 Figma 在文章裡也坦承了一個重要的現實：**AI model 天生是 non-deterministic 的，同一個 prompt 跑兩次可能會跑出不一樣的結果。** Skills 就是要讓這個行為變得更可預測——透過編碼具體的步驟、guideline 和規則來降低隨機性。設計慣例不再是靜態文件了，而是 agent 工作時真的會遵守的規則。 > **Mogu 想補充：** > > 大部分 [agent](https://gu-log.vercel.app/glossary#agent) 都是 fire-and-forget：生完就丟過來，好不好是別人的事。Figma 讓 agent 自己跑一個 QA loop，實務上會省掉大量來回修改的時間。有趣的是，[Codex 的 sandbox 哲學](https://gu-log.vercel.app/posts/20260301-codex-cli-sandbox-philosophy/)也在做類似的事 — 讓 agent 在隔離環境裡執行、驗證、再交付。Codex 在 code 層面做，Figma 在 design 層面做。殊途同歸——但 Figma 的版本更狠，因為設計錯誤比 code 錯誤更難被自動測試抓到。截圖比對是目前最實際的解法。 --- ## 一個入口，九家 agent 排隊進 到這裡，故事的格局開始浮現：這不只是 Figma 多了一個 AI 功能，而是 Figma 正在把自己從「設計師的工具」變成「所有人（包括 AI agent）做產品決策的共享空間」。 OpenAI 的 [Codex](https://gu-log.vercel.app/glossary#codex) 設計負責人 Ed Bayes 在文章裡說： > _“Teams at OpenAI use Figma to iterate, refine, and make decisions about how a product comes together. Now, Codex can find and use all the important design context in Figma to help us build higher quality products more efficiently.”_ 不管產品工作是從 coding agent 開始、在 Figma 裡開始、還是從 command line 開始，Figma 想要成為那個「所有東西最後匯合的地方」。 因為這個能力是原生建在 [MCP](https://gu-log.vercel.app/glossary#mcp) server 裡的，它可以吃到 Figma 既有的安全性和穩定性，同時也打開了 Code Connect、Figma Draw、FigJam 等表面的存取權限，都透過 [Plugin](https://gu-log.vercel.app/glossary#plugin) API。[MCP 作為連接 agent 與外部工具的標準協定](https://gu-log.vercel.app/posts/gp-180-20260423-anthropic-mcp-production-agents/)，在這裡扮演的角色很明確：一個入口、多個 agent 共用。目前文章明確列出的 MCP client 有：Augment、[Claude Code](https://gu-log.vercel.app/glossary#claude-code)、[Codex](https://gu-log.vercel.app/glossary#codex)、Copilot CLI、Copilot in VS Code、Cursor、Factory、Firebender、Warp。 九家。同一道門。 --- ## 商業模式：先上癮，再收費——但帳怎麼算？ Figma 很直接地交代了：**beta 期間免費，之後變 usage-based 付費 API。** 但接下來那句話才是真正有意思的地方——他們說還在搞清楚怎麼在 paid seat 的架構裡計算 agentic behavior 的用量。 這不是客套話。想想看：人類設計師一天工作八小時，一個 seat 很好算。但 [agent](https://gu-log.vercel.app/glossary#agent) 可能五分鐘就跨十個檔案、改三百個 component。算一個 seat？十個 seat？按 API call 算的話，跑一次 self-healing loop 可能就燒掉一大堆 call。**Seat 這個計價單位，是為人類設計的。當使用者不再是人，計費模型本身就需要重新發明。** 未來的 roadmap 方向很明確：讓 agent 在 Figma 裡能做更多事、把畫布本身加上原生 AI 功能、讓 skill 更容易分享。技術面繼續朝 Plugin API 完整覆蓋邁進，近期優先是圖片支援和自訂字型。 > **Mogu 插嘴：** > > [Teddy Riker 最近也在講同一件事](https://gu-log.vercel.app/posts/gp-183-20260426-teddy-riker-designing-for-agents/)——當產品開始 design for agents 而不只是 for humans，連計費模型都要跟著重新想。Figma 至少很誠實地說「我們還在搞清楚」，比那些假裝 agent 可以直接塞進 per-seat 模型的公司好多了。這場定價實驗的結果，搞不好會比 `use_figma` 本身更有長期影響。 ┐(￣ヘ￣)┌ --- ## 結語 回到開頭那個噩夢。 設計師改了 Figma 的顏色，code 裡還是舊的。工程師更新了 spacing，Figma 沒跟上。三個月後 QA 截圖一比——完了。 Figma 這次做的事，本質上就是讓這個噩夢多了一條出路：不是靠人的紀律（那永遠靠不住），而是讓 [agent](https://gu-log.vercel.app/glossary#agent) 帶著 design system 的 context 直接進場工作，做完自己檢查，token drift 自動抓。`use_figma`、skills、self-healing loop、未來往 Plugin API parity 走的方向——全部擺在同一條路線上。 但這裡有一個 Figma 沒有明講、卻藏在整篇文章背後的前提：**這一切的前提是團隊的 design system 本身是乾淨的。** [Token](https://gu-log.vercel.app/glossary#token) 有人維護、component 命名有規則、variable 結構清楚——agent 進來之後才能發揮。反過來說，如果 design system 一團亂？那 agent 只會把混亂放大十倍。 > **Mogu OS：** > > 所以最大的贏家不是「想要 AI 幫忙做設計的人」，而是「已經花力氣把 design system 整理好的團隊」。那些認真定義 token、整理 component、寫 guideline 的團隊，剛剛發現過去的投資有了一種全新的回報方式——不只是人在用，agent 也在用。以前跟老闆說「我們需要花時間整理 design system」，老闆覺得是自嗨的內部專案。現在可以說「不整理的話，AI agent 也跑不動」。老闆終於聽得懂了。跟 [MCP + Codex + Claude Code 那篇](https://gu-log.vercel.app/posts/gp-52-20260212-codex-mcp-claude-code/)同一個道理：工具再好，context 垃圾進垃圾出。 ╰(°▽°)╯