昨天把設計系統與元件庫拆開來看,結論是一致性要靠系統長出來,而不是逐一手調。但那套系統做得再漂亮,只要它停在 Figma 檔案裡、進不了 codebase,對使用者就等於不存在。今天要談的正是這段最容易掉東西的接縫:設計交付(design-to-code handoff)——設計師的意圖如何完整地變成能跑在瀏覽器裡的程式碼。這段路在 2026 年被 Dev Mode MCP、Code Connect 與 AI 編輯器重新洗過一遍,交付的定義已經和三年前不一樣了。
📖 學
交付不是「把檔案丟過牆」,而是把行為說清楚
傳統的 handoff 心智模型很單純:設計師畫完稿、標好尺寸、匯出切圖,丟給工程師照著刻。這個模型的致命傷是它把交付當成一次性的檔案傳輸,而畫面長什麼樣子其實只是冰山一角。真正會讓工程師卡住、來回問到天荒地老的,從來不是「這個間距是幾 px」,而是「這個按鈕在載入中要顯示什麼」「表單驗證失敗的錯誤狀態長怎樣」「清單為空時畫面該是什麼」「文字超長會不會爆版」。
2026 年業界的共識是:當工具已經能自動把螢幕與尺寸標註搬過去之後,一次交付的品質幾乎完全取決於行為規則與決策背後的理由。所以現代的交付文件重點不在「像素」,而在把邏輯層(logic layer)寫清楚——每一個互動狀態(含焦點與錯誤狀態)、內容極端值(最長、最短、為空)、響應式行為、動效規格、無障礙細節,以及最重要的:為什麼要這樣設計的約束理由。設計交付從「這看起來怎樣」升級成「這在各種情況下怎麼運作」。
Dev Mode MCP:讓 AI 直接讀設計,而不是猜截圖
2026 年最大的結構性改變,是 Figma 的 Dev Mode MCP Server。它是一個本地服務,透過 Model Context Protocol 這個開放標準,把 Figma 檔案裡結構化的內容——元件名稱、版面約束、間距 token、字體樣式、完整的圖層樹——直接串進 AI 工具的 context window。
關鍵字是「結構化」。過去 AI 產碼靠的是解讀截圖或匯出的圖檔,本質上是在猜:猜這塊藍色是哪個品牌色、猜這個間距想對齊什麼、猜這是不是一個可重用元件。MCP 讓 AI 拿到的是機器可讀的設計中繼資料,不再需要猜。Figma 在 2026 年 2 月正式推出與 Claude Code 的雙向整合(Design to Code 加上 Code to Canvas),到了 6 月 24 日的 Config 2026,執行長 Dylan Field 直接把年度主軸定調為:設計與實作之間的交付層,正在變成 agent-native(以 AI 代理為原生的)。官方 MCP 目前支援 Claude Code、Cursor、Windsurf 等 AI 編輯器。
Code Connect:把「產生器 CSS」換成「你們自己的元件」
MCP 解決了「AI 讀得懂設計」,但還有一個更關鍵的問題:AI 產出的程式碼是不是你們專案真正在用的元件?這就是 Code Connect 要補的洞。
Code Connect 做的事是把 Figma 元件對應到 repo 裡真實的程式碼元件。設定好之後,工程師在 Dev Mode 檢視一個按鈕,Inspect 面板右側顯示的不再是自動產生、一次性的 CSS,而是production codebase 裡那一段真正的 <Button variant="primary">。這裡有個乾淨的對應關係值得記住:設計工具裡 Category/Component/Variant 的命名結構,可以整齊地對應到 code 裡 components/category/Component.tsx 的檔案結構——設計系統裡的每一個元件,理想上在程式碼裡都有且只有一個對應。
搭配 design token 就更完整了:一個叫 color/action/primary 的背景 token,在 Inspect 面板會直接顯示成 --color-action-primary,可以原封不動貼進 stylesheet。工程師看到的是有意義的 token 名稱而不是一串裸值(raw value),往回問的次數自然大幅下降。這正好接上昨天說的:token 是設計與工程之間的單一真實來源,而 Code Connect 是讓這個真實來源在交付當下被強制引用的機制。
現代交付的預設架構,與「垃圾進、垃圾出」
把上面幾塊拼起來,2026 年一個有真正元件庫的產品團隊,交付的預設流水線長這樣:Figma → Code Connect → MCP → AI 編輯器 → 人工收尾。注意最後一棒還是人。這條線上有句話值得刻在牆上:handoff 在 2026 年已經不太像一次交付了,它是 Figma、AI 編輯器與「仍然得清理輸出的工程師」之間一段持續的介面。
也因此,設計端的檔案衛生從「美觀問題」升級成「production 問題」。如果你的 Figma 檔案是像素亂堆、沒有 auto-layout、沒有 variables、沒有 Code Connect 對應,AI 回給你的就是一坨對應的亂碼——garbage in, garbage out 現在是實實在在的生產風險。過去圖層命名亂、沒用 auto-layout,頂多是隊友接手時罵一句;現在它會直接汙染 AI 產出的程式碼。AI 能加速執行、能快速生出原型變體、甚至能給可用性回饋,但它取代不了設計師與工程師之間關於邏輯與行為的那場對話。用 AI 來加速執行,不是用它來跳過協作。
🧠 記
- 交付的品質不在像素,在邏輯層:互動狀態、內容極端值、響應式、動效、無障礙、以及「為什麼」。工具已能自動搬畫面,行為規則才是你唯一能加的價值。
- Dev Mode MCP 讓 AI 拿到結構化設計中繼資料而非截圖,從「猜」變成「讀」;2026 年 2 月 Figma × Claude Code 雙向整合、6 月 Config 定調 agent-native handoff。
- Code Connect 把 Figma 元件對應到 repo 真實元件,Inspect 面板顯示的是你們的
<Button>而非產生器 CSS;命名結構Category/Component/Variant↔components/category/Component.tsx。 - 現代預設流水線:Figma → Code Connect → MCP → AI 編輯器 → 人工收尾,最後一棒永遠是人。
- Garbage in, garbage out:沒有 auto-layout、variables、token、Code Connect 的髒檔案,現在會直接汙染 AI 產碼,檔案衛生已是 production 問題。
✍️ 實踐
挑一個你手上正在交付、或最近交付過的元件(例如一個帶載入與錯誤狀態的送出按鈕),做三件事:
- 列一張行為清單而非尺寸清單。 寫下它的所有狀態:預設 / hover / 焦點 / 按下 / 載入中 / 停用 / 錯誤,以及各狀態間的轉場動效與時長。再補三種內容極端值(標籤最長會怎樣、多語系換行、圖示缺失時)。你會發現原本的稿只畫了其中一兩個狀態——那些沒畫的,正是工程師會來問你的。
- 檢查一次檔案衛生。 這個元件有沒有 auto-layout?顏色與間距是用 variable/token 還是手打的裸值?圖層命名看得懂嗎?想像把它丟給 AI 編輯器產碼,它會不會因為你的亂而回你一坨亂。把最髒的一處修掉。
- 把「為什麼」寫進交付。 針對其中一個非顯而易見的決策(例如「錯誤訊息為什麼放欄位下方而不是 toast」),寫一兩句理由。這句理由的價值,往往高過你標註的所有間距數字。
🔗 延伸學習
- Introducing our Dev Mode MCP server: Bringing Figma into your workflow(Figma 官方部落格) — MCP server 的第一手介紹與運作原理。
- Getting started with Code Connect CLI(Figma 開發者文件) — 官方快速上手,教你把 Figma 元件對應到 repo 真實程式碼。
- Design Handoff in 2026: Figma MCP, Code Connect & AI — 把 2026 年交付工具鏈與流水線講得很完整的整理。
- Design Tokens: How to Sync Design and Code in Figma(Figma 資源庫) — token 如何在設計與程式碼之間保持同步。
💬 問 AI
我是 UIUX 設計師,想把設計交付(design-to-code handoff)做得更接近 2026 年的做法。請幫我:
1. 針對「一個帶載入/錯誤/停用狀態的表單送出按鈕」,列出一份完整的交付清單,重點放在「行為/邏輯層」而非像素尺寸(所有互動狀態、內容極端值、響應式、動效、無障礙、決策理由)。
2. 解釋 Figma Dev Mode MCP Server 與 Code Connect 各自解決什麼問題、兩者如何搭配,以及「Figma → Code Connect → MCP → AI 編輯器 → 人工收尾」這條流水線裡,設計師該負責哪幾段。
3. 給我一份「檔案衛生自檢表」,列出哪些 Figma 檔案的壞習慣(缺 auto-layout、裸值、亂命名等)會導致 AI 產碼變成 garbage in, garbage out。
請用繁體中文(台灣用語)、能實際照做的方式回答。