設計交到工程手上才是問題開始：Figma Variables、Dev Mode MCP 與 AI 轉程式碼的真實工時帳（2026）

2026 年 2 月，Figma 正式推出 Dev Mode MCP 的雙向整合，讓 AI 編碼代理可以直接讀取設計檔的結構化資料，而不是對著截圖猜。半年過去，這件事在接案現場造成的最大改變不是「設計自動變成程式碼」，而是設計檔的品質第一次直接決定了程式碼的品質。畫得亂的檔案，AI 產出的就是一堆魔術數字；畫得有結構的檔案，產出的程式碼會直接引用你的變數名。這篇談的就是這條分界線，以及它在報價單上值多少錢。

四個公開案例：他們的設計檔長什麼樣

• Shopify Polaris：把設計決策拆成語意層與原始層兩級變數。設計師選的是 color-bg-surface-critical 這種語意名稱，不是某個色碼。結果是整個商家後台換一次品牌色只需改原始層，不需重畫任何畫板。
• GitHub Primer：以「功能性色彩」為核心，把深淺色主題視為同一組語意變數的兩種值，而不是兩套設計。這讓 Primer 的暗色模式不是額外的設計工作，而是變數表多一欄。
• IBM Carbon：把 2x 網格與字級階梯做成可計算的規則，間距只能取自固定序列。這種限制看似綁手，實際效果是任何人畫出來的東西都能被工程直接對應到既有 CSS class。
• Atlassian Design System：強制元件命名與程式碼端的元件名一致，並公開對照文件。設計師在 Figma 裡放的 Button/Primary，工程師在程式碼裡拿到的就是同名元件。

四家做法不同，但共通點只有一個：設計檔被當成工程的相依項來維護，而不是一份等著被「參考」的圖。這正是 Dev Mode MCP 之所以有用的前提——它能給出 get_variable_defs 這種變數定義，前提是你的檔案裡真的有變數。

設計背後的邏輯：為什麼「命名」比「好看」更省錢

認知心理學上，人類處理視覺資訊靠的是分組（chunking）：我們記不住 12 個不同的間距數值，但記得住「小、中、大」三檔。設計系統把連續的視覺選擇壓縮成離散的階梯，正是利用這個機制——選項變少，決策速度變快，一致性自然出現。

對機器則是另一套邏輯。AI 編碼代理能不能產出可維護的程式碼，取決於它拿到的是「24px」還是「space-300」。前者是一個孤立事實，後者是一個帶著意圖的參照。Figma 官方文件說明 MCP 伺服器提供四個核心工具：get_code（預設輸出 React 與 Tailwind 表示）、get_variable_defs（變數與樣式定義）、get_image（節點渲染）、get_code_connect_map（節點對元件的映射）。第二與第四個工具的價值，完全建立在你的檔案有沒有做好命名這件事上。

技術成本與限制

把設計檔整理成機器可讀，不是免費的。實際工時帳如下（以一個 30 頁規模的中型專案為基準）：

• 建立變數體系：色彩、間距、字級、圓角、陰影五組，約 12 到 20 小時。
• 既有畫板改用變數：每 10 個畫板約 4 到 8 小時，30 頁專案約 12 到 24 小時。
• 元件命名與程式碼對應：約 8 到 16 小時，含與工程端對表。
• Auto Layout 全面套用：這是 MCP 能正確推斷結構的前提，改造既有檔案約 10 到 20 小時。

合計約 42 到 80 小時，以設計端 NT$1,500/小時計，是 NT$63,000 到 NT$120,000 的前置投入。回收在哪？業界回報的數據是，相較於截圖式的上下文，使用 MCP 提供結構化參照可將實作往返次數大幅降低（有團隊回報約四倍差異），且產出的程式碼會引用既有 token 而非猜測數值。以我們自己的專案經驗，前端實作工時大約落在減少 20% 到 35%，且改版時的回歸風險明顯下降。

但限制要說清楚：

• AI 產出的是初稿，不是成品。版面結構、無障礙屬性、狀態邏輯仍需人工補完。把它當成「省去打字」，不是「省去思考」。
• 對 SEO 沒有直接幫助，但有間接風險。AI 傾向產出巢狀很深的 div 結構與 JavaScript 導向的互動。若不人工整理語意標籤與真連結，頁面可能對搜尋與 AI 檢索變得難以解析。
• 效能不會自動變好。自動產出的樣式常帶冗餘，未整理前 CSS 體積容易膨脹 20% 到 40%，直接影響首屏最大內容繪製。

適合的行業 vs 不適合的行業

怎麼套用到你的網站（5 個步驟）

• 步驟一：先定五組變數，不要多。色彩（含語意名如 danger／success）、間距（4、8、12、16、24、32、48）、字級（5 到 7 級）、圓角（3 級）、陰影（3 級）。一個下午就能定完，這是所有後續工作的地基。
• 步驟二：把既有畫板改成引用變數。從最常用的 5 個頁面開始，不要一次全改。改完後在 Figma 裡把硬編碼的色值搜出來，數量歸零才算完成。
• 步驟三：全面套用 Auto Layout 並統一命名。元件用 PascalCase、圖層用 kebab-case。命名對照表要跟工程端一起訂，不要單方面決定。
• 步驟四：接上 Dev Mode MCP 或等價工具，先跑一個頁面試水溫。比較 AI 產出的程式碼有沒有引用你的變數名。如果還是出現魔術數字，回到步驟二——問題在檔案不在工具。
• 步驟五：建立同步節奏。約定設計端變數異動後，工程端在一週內同步；並在程式碼端用 Style Dictionary 或 Tokens Studio 之類的工具把 token 匯出成 CSS 變數或 Tailwind 設定。沒有這個節奏，兩邊三個月後必然分岔。

常見錯誤 × 怎麼避開

• 錯誤一：一開始就定 80 個變數。用不到的變數比沒有變數更糟，因為沒人知道該選哪個。避開：從 25 到 35 個變數起步，缺了再加。
• 錯誤二：只用原始層命名（如 blue-500）沒有語意層。換品牌色時要逐頁改。避開：語意層（color-action-primary）指向原始層，畫板只准用語意層。
• 錯誤三：期待 AI 直接產出可上線的程式碼。避開：把 AI 產出定位成「結構初稿」，並在流程中固定加一道人工整理，處理語意標籤、無障礙屬性與樣式去冗。
• 錯誤四：設計端改了變數卻沒通知工程端。避開：變數表視為介面契約，任何異動走與 API 變更相同的通知流程。
• 錯誤五：對小型專案硬套設計系統。四週的活動網站導入 token 體系，前置成本吃掉一半預算。避開：用專案生命週期判斷——低於三個月且不迭代的，直接手刻更划算。

延伸資源

• Figma 官方 — Dev Mode MCP Server 介紹：四個核心工具與設定方式的第一手說明。
• Style Dictionary：開源 token 轉換工具，可把同一份 token 輸出成 CSS 變數、Tailwind 設定、iOS 與 Android 資源。
• Tokens Studio：Figma 外掛，適合需要複雜 token 階層與多主題的團隊。
• Shopify Polaris 與 GitHub Primer：兩套公開文件完整的設計系統，可直接參考語意變數的命名邏輯。
• web.dev — Largest Contentful Paint：驗收前端產出時的效能基準。

常見問題 FAQ

小團隊值得花 40 到 80 小時整理設計檔嗎？

看專案壽命與元件複用率。如果這個產品會維護超過一年、且畫面超過 20 個，前置投入通常在第二次改版就回收。如果是四到十二週的活動網站，不值得——直接手刻更快。判斷標準是「同一個元件會不會出現在五個以上的畫面」。

AI 產出的程式碼可以直接上線嗎？

不行，但可以省下大量結構搭建時間。實務上它產出的是版面骨架與樣式引用，仍需人工補上語意標籤、無障礙屬性、狀態邏輯與樣式去冗。把它當成把工程師從「排版」解放到「邏輯」的工具，而不是取代前端。

這套流程對 SEO 有幫助嗎？

沒有直接幫助，但有間接風險要管。AI 傾向產出深層巢狀 div 與 JavaScript 導向的互動，若不整理，頁面的語意結構會變差、真連結可能消失，這對搜尋與 AI 檢索都不利。務必在驗收清單裡加上「主要導覽必須是真 <a href>」與「標題階層正確」兩條。

Figma Variables 和 Design Token 是同一件事嗎？

不完全相同。Figma Variables 是 Figma 內部的機制，Design Token 是跨工具的抽象概念與檔案格式。實務上的做法是在 Figma 用 Variables 維護，再透過 Tokens Studio 或 Style Dictionary 匯出成標準 token 檔，供網頁與行動端各自消化。兩者要對齊，但不要混為一談。

我的設計是外包的，檔案結構很亂，還救得回來嗎？

救得回來，但要算清楚成本。實務作法是不重畫全部，只把「會重複出現的元件」抽出來變數化，其餘畫板維持原狀。以 30 頁專案為例，這種局部改造約 20 到 30 小時，能拿到七成的效益。全面重整通常不划算，除非這份檔案還要用兩年以上。

想把設計與程式碼對齊？

ScriptWalker 提供「設計系統對齊」服務：從變數體系盤點、元件命名對照、到程式碼端的 token 匯出設定，一次把設計與工程接起來。適合已經有 Figma 檔案、但每次改版都要重談細節的團隊。我們會先做一次免費的檔案結構評估，告訴你值不值得做。

• Email：[email protected]
• 電話：0916-224-047
• LINE：@ufv9089p