Figma 官方白話拆解 MCP：為什麼設計稿的品質，決定 AI 寫出什麼樣的 code

AI 寫 code 的工具這一年爆發性成長，但很多設計師實際用過之後都有類似的體感：AI 生成的畫面總是「差一點點」——顏色接近但不是 brand color；card 看起來對，但不是團隊用過幾十次的那個版本；表單被 flatten 成單一元件。原因很直接：AI 工具看你的 Figma 檔，看到的是截圖——它看得到結果，看不到背後的決策。

MCP（Model Context Protocol）就是解這個問題的協定。Figma 官方 4/15 刊出的 "The TL;DR on MCP" 用最白話的口吻回答：為什麼 MCP 不只是工程師話題，設計師、PM、整個產品團隊都該一起懂。對正在學 Figma、想進產品設計的讀者來說，這是一份能立刻落地的 context。

MCP 全名是 Model Context Protocol，去年橫空出世之後，短時間內就變成 AI 圈最熱的協定話題。講白話一點，它建立了一個通用的方式，讓 AI 工具可以從你團隊正在用的工具、資料來源裡，把 context 拉進來。

但對設計師、工程師、PM 真正有影響的問題是：MCP 和 Figma 結合之後，你的工作流到底會怎麼改？ Figma 這篇文章不談底層 protocol，它直接跳到「每個團隊角色在 MCP 之後要怎麼調整」。下面拆成五個重點看完。

產品開發已經不再是線性的——過去「設計稿 → 工程實作 → QA → 上線」的流程，現在被打散成更流動的協作。團隊會在不同階段之間跳躍、從任何階段開始、工作過程中反覆來回。MCP 支援的就是這種工作方式：它把設計 context 送進 code 裡，而 code-to-canvas 工具又能把實作好的 UI 送回 Figma 畫布。

AI 工具在沒有 context 的情況下看設計稿，效果等同「只看截圖」。它會選一個跟品牌色接近的藍色、但不知道被對應到哪個 token；會看到一張 card、然後從零重建一張，不會去拉團隊已經用了幾十次的 component。表面看起來沒錯，但每個畫面都累積一點偏差，整個 design system 就慢慢漂離原本的規則。

你做的設計系統，一直以來都在維持產品的一致性。現在，它也在形塑 AI 寫出的 code——從早期 prototype 一路到 production。你怎麼建檔，就決定 AI 會生成什麼。 AI 會大量且高頻地產出，你做的每個小決定都會被複製、放大、擴散到每一個觸及的畫面。

另一面是：錯誤也會被放大。在 AI 之前，一份亂糟糟的 Figma 檔只是局部問題，工程師實作時會順手清理；但 AI 工具直接從檔案大量生成程式碼，一個小瑕疵不再只是小瑕疵——它會被 AI 學起來、複製到每一個 build 出來的元件上。從 one-time fix 變成 systemic issue。

MCP 讓 code 和 canvas 一路保持連動：工程師在 code 裡 build 出來的東西，設計師可以帶回畫布補完狀態、精修細節，不用從頭重做一份。

AI coding tools 已經加速了工程師寫程式的速度，但在沒有設計 context 的情況下，他們其實還在「猜」。把設計稿翻成 production code，過去意味著大量的手動解讀——量間距、在 codebase 裡翻找對的 component、來回對齊 Figma 和 code 之間的 token 命名。

MCP 改變了這件事。帶著 context 的 AI agent，可以直接 reference codebase 裡的真實 component、套用對的 token、產出一開始就能 build 的程式碼。翻譯成本下降，工程師多出來的時間能投到真正需要工程判斷的事情上。

而且翻譯不再是單向。越來越多工程師是從 code 開始——先起一個 working prototype，然後用 generate_figma_design 這類工具把成品送回 Figma 畫布。MCP 把設計 context 帶在流程裡，送回畫布的東西，是整個團隊真的能繼續 build 的東西。

原文用一個具體情境示範 MCP 怎麼改變團隊協作。工程師在做 checkout 流程時撞到 edge case——以前的選項是自己猜一個解法、或等設計師出新 mockup；現在他可以用 code-to-canvas 能力，把當前的 UI push 回 Figma 畫布。

設計師打開畫布，能看到流程斷在哪一步、用真實 component 在 context 裡探索解法；PM 在 Figma 裡並排兩個版本，確認體驗沒有偏離團隊最初的意圖；團隊對齊後，工程師再把更新過的設計拉回 code——MCP 一路把 context 帶著——然後上線。

Figma MCP server 靠兩個互補的工具撐起這個 loop：generate_figma_design 把 live app、網站的 HTML 翻成可編輯的 Figma layer，用在設計與實作脫節時把最新 UI 帶回畫布；use_figma 則讓 AI agent 直接在畫布上、用你 team 的真實 component 和 variable，建立或修改設計。一個是「code 回到 canvas」，一個是「agent 在 canvas 上 build」。

MCP 只能靠你給的 context 做事——設定越用心，output 越好。原文給了五個起手式。

第一，用 skills 指揮 agent。 skills 是 plain language 寫的 markdown 檔，告訴 agent 要用哪些 component、遵循什麼規範。特別是 figma_use 這個 foundational Figma skill，沒它的話 agent 可能用對 component、但用法不對。

第二，投資你的 design system。 AI 沒辦法自己推理出團隊的默契——什麼時候用哪個相似 component、品牌的間距規範、特殊情況的例外。把這些隱性知識寫明確，AI 就不用猜。

第三，檔案要建得讓 AI 讀得懂。 layer 名稱要有意義（card、nav-bar，不是 Frame 1337）；用 auto layout 讓 AI 讀出 responsive 行為；用 library 的真實 component 和 token、不要 detach；要表達互動意圖的地方補上 annotation。

第四，給 variables 加 code syntax。 這告訴 MCP 每個 variable 在 codebase 裡實際怎麼寫——不是 pass 「brand-blue」這個名字，是 pass 工程師真正會寫的 color-brand-blue。小改動，output 準確度差很多。

第五，用 Code Connect 把 code 和 Figma 接起來。 它告訴 MCP 哪個 code component 對應哪個 Figma component、在哪裡。沒接的話，MCP 只能告訴 AI「這邊用的是 card」，AI 還是得在 codebase 裡搜哪個 card 才是對的。

MCP 表面看起來是一個工程議題，但它實際在解的問題不是 AI 技術本身——是設計與工程之間、長期存在的翻譯成本。

對正在學 Figma、準備轉職設計的讀者而言，這篇文章值得記住的一點是：你在 Figma 裡做的每個小決定，現在不只影響設計本身，還會被 AI 放大到整個 codebase。把檔案建乾淨、把 design system 投資到位，這些原本就該做的事情，在 AI 時代不是 nice-to-have，是前提。

QUOTE · 原文金句

現在投資 MCP 的團隊，不只會跑得更快——他們會 build 得更好。

FURTHER · 延伸學習

Figma 全攻略｜從零到產品上線

完整建好 design system、auto layout、variables、token 的檔案結構——也是 MCP 能發揮價值的前提。轉職設計師最扎實的起手式。

了解課程內容 →

SUBSCRIBE · 訂閱方案

AI 設計覺醒｜RAR 設計攻略訂閱方案

• ▸ 每日 Figma 官方文章譯介與觀點
• ▸ AI 工具實戰與工作流分享
• ▸ 設計師角度的 Prompt 技巧

了解訂閱方案 →