Figma MCP 在 2026 年已經是雙向的，這改變了工作流能長成什麼樣子。單向的時候，它只能壓縮「設計完成 → 工程實作」這一段的人工成本；雙向之後，「程式碼現況 → 回寫設計」也成立了，而後者解決的是另一個長年問題——設計檔案與線上實況隨時間分歧。本篇把可用的能力組成三條實際的流程。
📖 流程一：design → code 的 handoff 自動化
這是最常見也最成熟的一條。
① 設計完成，設計師右鍵「Copy link to selection」
└─ 連結貼進 ticket／PR 描述
② 工程師把連結給 agent，附上約束
└─「用 src/components/ui 的元件實作這個 frame，放到 X」
③ agent 先 get_metadata 取輪廓
└─ 大型設計時必要；小元件可略過
④ agent 針對需要的區塊 get_design_context
└─ 含 Code Connect 對應、變數定義
⑤ agent 產出程式碼
⑥ agent get_screenshot 比對
└─ 結構化資料說不出「看起來對不對」
⑦ 人工審查
└─ 重點看互動、響應式、無障礙（見下）
為何用連結而非選取：選取是 Figma 當下的隱含狀態，無法寫進 ticket、PR 或規則檔；連結可以，而且長期有效。這讓它能嵌進既有的交接流程，而不是另外開一條。
第 ⑦ 步的重點很明確。 依 忠實度分維度，間距、顏色、圓角本來就會準，人工審查的時間應該花在互動、響應式與無障礙這三項本來就傳不過來的東西上——把時間花在檢查間距是浪費。
這條流程降低的是資訊損耗，不是取代交接。 設計→工程交接 那篇的核心框架——交接品質＝資訊損耗率——正好解釋了 MCP 的作用：它讓「檔案裡已經有的資訊」不再需要人工轉述一次。但檔案裡沒有的資訊，它一樣傳不過去，那仍然需要註解、對話與文件。
📖 流程二：從 frame 生 component 並入庫
比流程一多了一個目標：產出要進元件庫，而不是一次性的畫面程式碼。
① 先查有沒有現成的
└─ search_design_system：元件庫裡有沒有類似的？
└─ 有就不要造新的
② 確認這個東西值得成為元件
└─ 會重複出現嗎？介面穩定嗎？
③ 生成，並明確指定落點
└─「Add this component to src/components/ui/EmptyState.tsx」
④ 建立 Code Connect 對應
└─ add_code_connect_map（不計入限額）
└─ 元件須先在 Figma 手動發布
⑤ 驗證雙向
└─ 對另一個用到它的 frame 生成，確認會 import 這支元件
第 ① 步是整條流程的價值所在。 不查就生成，等於在元件庫裡不斷堆疊近似品——這是「AI 讓程式碼變多但系統變差」最典型的形態。search_design_system 把「先找再造」變成 agent 可執行的步驟。
第 ④ 步讓這條流程產生複利：每做一個對應，之後所有用到該元件的生成都會更準。這是少數真正會隨時間變好的環節。
📖 流程三：code → design 的反向同步
2026 年才成立的方向。相關工具（全部遠端限定）：
| 工具 | 做什麼 |
|---|---|
generate_figma_design | 把實際運行的網頁 UI 送進 Figma 成為設計圖層 |
html_to_figma | 把一份 HTML 文件轉成設計圖層 |
send_code_to_figma | 把本機專案匯入成 Make 檔案或程式碼圖層 |
use_figma | 在檔案中建立 frames、components、variants、variables、auto layout |
官方另外描述了一條路徑：提示 client 啟動本機伺服器，然後用擷取工具列擷取頁面、元素與狀態。
三個實際用途：
把線上實況拉回設計檔。 產品上線後持續被小幅修改，設計檔逐漸失真。從實際網頁反向生成，讓設計師看到的是真的在線上跑的東西。
把既有頁面變成設計起點。 要重新設計一個舊頁面時，先把現況拉進 Figma，比對著改，比憑記憶重畫準確。
把硬編碼值轉成變數。 官方明確提到 use_figma 可以用既有元件與變數來建構版面，包括把原始色值轉成變數——這是整理舊檔案的實用途徑。
這條流程目前只適合用在複本上
官方自述產出為 beta 品質，「may need manual review and cleanup」，並明確要求先在元件庫的複本或草稿檔測試，再動正式檔案，同時保留備份。 另有明確限制：每次工具呼叫最多回傳 20 KB；
use_figma無法自行加入圖片；含圖片或影片的元件匯入與建立 GIF 不支援；字型必須已上傳到 Figma 帳號，只裝在本機電腦的字型不可用。 費用：beta 期間免費，官方說明之後會變成按用量計費，價格未公布。
要求：Professional、Education、Organization 或 Enterprise 方案；對檔案有編輯權限；遠端伺服器；在草稿之外寫入需要 Full 席次。
📖 一張「誰做什麼」的對照
把三條流程裡的分工整理出來。這張表的用途是劃清人工審查的範圍：
| 環節 | agent 可以 | 人仍需要 |
|---|---|---|
| 取得設計脈絡 | ✅ 全自動 | — |
| 間距、顏色、圓角 | ✅ 可信（前提：auto layout ＋ 變數） | 抽查 |
| 元件重用 | ✅ 有 Code Connect 就可信 | 確認沒連到淘汰元件 |
| 版面結構 | ⚠️ 簡單可信，複雜巢狀易走樣 | 審查 |
| 互動與狀態 | ❌ | 全部 |
| 響應式斷點 | ⚠️ auto layout 傳達部分意圖 | 大部分 |
| 無障礙 | ❌ 除非寫進規則與 Code Connect 指示 | 全部 |
| 「這個設計對不對」 | ❌ | 全部 |
最後一列是根本的。 MCP 能讓實作忠於設計，但它完全不會告訴你那個設計是不是好的——這是一個經常在導入 AI 工具時被模糊掉的區別。
📖 把流程固化下來
上面三條流程若只存在於人的習慣裡，每個人、每一次的做法都會不同。官方提供的固化機制有兩個：
custom rules ——把工具的使用順序寫成規則。官方建議的規則檔內容明確包含「工作流規則」這一類：先取設計脈絡再實作、回應過大時改用 metadata、拉一張截圖當參考、最後對照 Figma 驗證。這正是流程一的 ③④⑥ 步。
skills ——Figma 官方提供的 agent 指示集，用 plugin 安裝時會一併帶進來。
兩者都見 與前端 agent 的整合。
🧠 重點整理
Figma MCP 在 2026 年是雙向的，「code → design」解決的是設計檔與線上實況分歧的問題。
用連結而非選取——連結能寫進 ticket 與規則檔，選取是隱含狀態。
人工審查的時間要花在互動、響應式、無障礙，不是間距。
MCP 降低資訊損耗，不取代交接——檔案裡沒有的資訊它一樣傳不過去。
生元件前先 search_design_system，不查就生等於在元件庫堆疊近似品。
add_code_connect_map 不計入限額，所以建立對應可以批次做，而且會產生複利。
反向同步目前只適合用在複本上——beta 品質、20 KB 上限、不支援圖片影片元件與 GIF、字型須已上傳。
寫回畫布 beta 期間免費，之後按用量計費，價格未公布。
MCP 不會告訴你設計是不是好的——這一項永遠是人的工作。
✍️ 動手做
建立一條可重複的流程，約一小時：
- 選一個真實的、小型的待辦 UI 任務（一個元件或一個區塊，不要整頁）。
- 完整跑一次流程一的七個步驟，每一步記下花了多久。
- 記錄第 ⑦ 步你實際改了什麼——分成「間距顏色類」與「互動響應式無障礙類」兩堆。
- 把這次用到的工具順序寫成規則檔的「工作流規則」。
- 用第二個任務再跑一次，這次讓 agent 照規則檔走，比較人工介入的量。
第 3 步的分堆是關鍵發現。如果你改的大多是第一堆，代表你的 Figma 檔案或 Code Connect 還有該修的地方；如果大多是第二堆，那就是正常的——那些本來就傳不過來，流程沒有問題。
🔗 資料來源
- Figma 開發者文件 — 寫回畫布——可建立的內容、工具、方案與席次要求、全部限制、beta 警告、免費期與未來計費（一手，2026-11-01 查證）。
- Figma 開發者文件 — 工具與提示——反向同步四個工具與 Remote only 標註。
- Figma 開發者文件 — 加入自訂規則——工作流規則的官方內容。
- Figma Help Center — Guide to the Figma MCP server——連結式指向、擷取實際 UI 的路徑。
- Figma 開發者文件 — 限額與存取——不計入限額的寫入工具。
- 三條流程的設計、分工對照表與審查重點是我的歸納，非官方建議。