Figma MCP 把設計檔案的結構化資料透過 Model Context Protocol 餵給 AI agent，取代「截圖丟給模型」這種做法。差別不在便利性而在資訊種類：截圖只有像素，agent 必須用視覺推測間距與層級；MCP 給出的是變數名稱、auto layout 參數、元件實例，以及——若設定了 Code Connect——該元件在你的 codebase 裡對應哪一支檔案與哪一組 props。
理解整件事的關鍵在於一個分工，官方文件講得很清楚：MCP server 只負責提供設計脈絡，寫程式的是你的 agent。因此產出品質是三個因素的乘積——脈絡的品質、模型的能力、以及提示的清晰度。這個框架決定了本專欄大部分篇幅的去向：多數人以為要調的是模型或提示，實際上投報率最高的是脈絡那一項，而脈絡品質取決於你的 Figma 檔案怎麼組織、有沒有做 Code Connect。
版本變動快，請核對日期
Figma MCP 在 2026 年經歷了結構性改變：從本機限定變成以遠端為主、從唯讀變成可雙向寫回畫布。本專欄所有資料的查證日期為 2026-11-01，以 developers.figma.com 官方文件為主要來源。哪些是官方文件所載、哪些是我的判斷或社群用法，全部列於 主張 vs 可佐證。
名稱的變化本身是個線索
它最初叫 Dev Mode MCP server，現在官方文件一律稱 Figma MCP server。這不只是改名——原本的定位是「Dev Mode 裡的一個功能」，現在的定位是「Figma 與 agent 之間的通用介面」。
看到文章寫「Dev Mode MCP server」並教你去偏好設定開啟本機伺服器，那是 2025 年的寫法。 現在官方明確建議用遠端伺服器，本機版本被描述為「for specific organization and enterprise needs」。
能力階段
把 Figma MCP 的能力分成四階，依導入難度與投報率排序。多數團隊停在第一階，而第二階才是價值開始顯現的地方。
| 階段 | 做什麼 | 需要什麼 | 投報率 |
|---|---|---|---|
| 一、讀取設計 | 選一個 frame，生出大致對得上的程式碼 | 連上 MCP server 即可 | 低——與截圖餵圖差距不大 |
| 二、對上設計系統 | 產出使用你既有的元件與 token，而非每次重生 | Code Connect ＋ 變數 ＋ 檔案結構 | 最高 |
| 三、固化工作流 | 用規則檔讓 agent 每次都照同一套流程做 | custom rules、skills | 中高 |
| 四、雙向同步 | 從程式碼或實際網頁反向寫回 Figma 畫布 | 遠端伺服器、Full seat、beta 功能 | 視團隊而定 |
第一階到第二階的落差，是整個主題最值得投入的地方。 第一階很容易達成也很容易令人失望——agent 會生出一份「看起來像、但每個 class 都是新寫的」程式碼。真正把它變成生產力的是 Code Connect，官方文件直接稱其為讓 agent 重用你真實元件的「the most effective way」。
學習地圖
一、先建立正確的心智模型
二、接起來
三、讓產出真的能用
四、組成完整流程
五、務實面
「我想用它做到…」索引
| 我想做到 | 看哪一篇 |
|---|---|
| 搞懂它和「截圖丟給 AI」差在哪 | 與截圖餵圖的差別 |
| 在 Claude Code 裡接上 Figma | Claude Code |
| 在 Cursor／VS Code 裡接上 | 各 client 設定 |
| 知道它到底提供哪些工具 | 工具拆解 |
| 選一個 frame 生出程式碼 | 基本流程 |
| 讓它生 SwiftUI／Vue 而不是 React | 指定框架 |
| 讓產出的間距色彩忠於設計 | 忠實度 |
| 讓它用我既有的元件而非重寫 | Code Connect |
| 把 Figma 變數帶成我的 design token | 變數對應 |
| 把 design→dev handoff 自動化 | handoff 自動化 |
| 從實際網頁反向生成 Figma 設計 | 寫回畫布 |
| 讓 agent 每次都照同一套流程做 | 規則檔 |
| 估算會不會撞到用量上限 | 限額 |
「我卡在…」問題索引
| 遇到的問題 | 看哪一篇 |
|---|---|
| 工具在 client 裡載入不出來 | 連不上的排查 |
| 選了大 frame 之後就卡住或出錯 | 大型 frame |
| 明明要 SwiftUI 卻一直給我 React | 指定框架 |
| 它每次都重寫一套新元件 | 為何要做 Code Connect |
| 產出的顏色是硬編碼不是變數 | 變數 |
| agent 挑錯工具 | 明確指定工具 |
| 圖片／SVG 連結失效 | 資產處理 |
| 一天沒用多久就被擋 | 限額 |
如何使用本專欄
只想先試一次：02 → 04。接起來、選一個小元件、生一次。不要第一次就選整頁的 frame，那是最常見的失敗起手式，原因見 09。
要認真導入團隊：01 → 05 → 06 → 08。Code Connect 與檔案結構是成敗關鍵，而這兩件事都不是工程師單方面能決定的——需要設計師一起改作業方式。
在評估值不值得：01 的分工框架 → 09 的限額一節 → 10 的證據分級。限額那一節常常直接改變結論：Professional 方案每天 200 次呼叫、每分鐘 10 次，對一個密集使用的團隊而言是會撞到的。
與其他專欄的連結
- Handoff（交接）深入解說 — 設計→工程交接 — Figma MCP 本質上是在自動化這一條交接路徑。該篇講的「交接品質＝資訊損耗率」正是理解 MCP 價值的框架：MCP 降低的是損耗，不是取代交接。
- Engineering AI Coding Methodology — 「AI 能生成程式碼，槓桿在方法論而非生成物」這個核心主張，在 Figma MCP 上表現得特別明顯：接上很容易，用得好取決於設計系統與規則怎麼建。
- Light／Dark 主題 — Figma 變數對應到 CSS 自訂屬性的實作問題，該專欄有完整的主題切換架構。
- MCP 與工具整合 — MCP 協定本身的通用知識。
🔍 待解問題 / 持續追蹤
- 官方沒有公開的忠實度量化指標。 「產出貼近設計」是官方與社群共同的主張，但我找不到任何官方或第三方的量化評估（例如像素差異、token 命中率）。本專欄因此不給出任何忠實度百分比。
get_variable_defs的實際輸出格式官方未載明。 官方的「變數沒有正確帶入程式碼」頁只處理了「agent 挑錯工具」這一個成因，沒有說明變數名稱與 codebase token 名稱不一致時該怎麼辦——而這是實務上最常見的狀況。- Code Connect 的對應演算法未公開。 官方只描述輸出（以
<CodeConnectSnippet>標記包起來），沒有說明它如何判定某個 Figma 元件對應到哪一支程式碼元件。 - 寫回畫布仍是 beta，品質未知。 官方自述「may need manual review and cleanup」，並明確警告要先在複本或草稿檔測試。免費期結束後會變成按用量計費，價格未公布。
- 本機伺服器的未來不明朗。 官方現在把它描述為「for specific organization and enterprise needs」，Figma for Government 則只支援本機版且工具受限。本機版是會長期並存還是逐步收斂，沒有官方說法。
- 各 MCP client 的支援程度差異大且沒有統一說明。 官方有一張 client 對照表（桌面／遠端／寫回畫布／plugin 四欄），但表格內容會變動，且部分功能標註為「select clients」而未列出是哪些。
🕒 更新紀錄
- 2026-11-01 — 專欄建立。工具清單、端點、各 client 設定指令、方案與限額、Code Connect 整合、檔案結構建議、寫回畫布的要求與限制，全部取自
developers.figma.com與 Figma help center 官方文件（2026-11-01 查證）。能力四階段、工作流設計與導入順序為我的歸納，已於 主張 vs 可佐證 標示為判斷而非事實。