Claude Code 串接 Figma MCP：設計稿轉 UI 完整教學

很多人應該都遇過這個畫面：設計師把一份精心調過的 Figma 檔交到你手上，間距、字級、顏色、元件全都標得好好的，你滿心歡喜打開編輯器，然後發現自己要把每一個 Frame 用肉眼對照、一行一行敲成程式碼。一個中型首頁，熟練的前端也要拆上一整天。更尷尬的是，設計師跟你說「這個按鈕按下要有點回饋」，你抬頭問「回饋長什麼樣子」，他比手畫腳講了三分鐘，你還是只能猜。

這篇要回答的核心問題只有一個：把 Figma MCP 接上 Claude Code，真的能讓設計稿變成可運行的 UI 嗎？答案是可以協助產出第一版程式碼，但不是一鍵完成。你仍要釐清設計意圖、補足互動規格，並驗收響應式、無障礙與效能。

三分鐘先講結論：MCP（Model Context Protocol）是 Anthropic 在 2024 年底提出的開放協定，作用是讓 AI 工具以統一方式連接外部資料與工具；Figma MCP 能把圖層、元件、變數與版面等設計脈絡交給 Claude Code，再由 Claude 生成或修改 UI 程式碼。版面、文字、色彩與間距通常較容易取得明確資料；互動、動態、響應式與產品規則仍需要規格和驗收。它適合協助製作品牌頁、活動頁、作品集與後台雛形，複雜互動或金流則應由工程流程主導。

設計稿變程式碼，中間到底卡在哪

我把這個問題想很久，結論是：卡住的不是工具，是「設計的語言」和「程式的語言」根本是兩套表達系統。

Figma 用視覺元素表達意圖：一個矩形在這裡、這個寬、這個顏色、跟旁邊那個距離 16px。程式碼用結構與邏輯表達意圖：這是一個 flex 容器、主軸對齊置中、子元素 gap 16、背景色寫在 design token 裡。兩者描述的是同一個畫面，但切換的過程會漏掉三樣東西：意圖（為什麼這裡要 16 而不是 12）、互動（按下去會怎樣）、狀態（手機上會變成什麼）。

傳統手工切版，這三樣東西靠的是設計師與工程師當面溝通、反覆來回。AI 加進來之後，問題沒有消失，只是換了形式：你得一個人在提示詞裡把這些「沒被畫在稿上的東西」講清楚。這就是為什麼很多人接好 MCP、按下生成，卻得到一個「看起來像、但哪裡怪怪的」的成品。怪的不是 AI，是漏掉的意圖。

想把這個觀念打底，可以先把 UI 與 UX 的根本差異想清楚：UI 是表面的呈現，UX 是背後的決策邏輯，而 MCP 目前搬運的主要是前者，後者大多要你自己補。如果你的稿子還停在很粗的階段，先走一趟 線框圖設計流程把結構定下來，再進 Figma 細修，後面餵給 Claude 的素材會乾淨很多。

先把 MCP 講清楚：它不是外掛，是翻譯官

MCP 不是 Figma 專用外掛，也不只屬於 Claude；它是一套共通協定。支援 MCP 的 AI Host 可以連接相容的 MCP Server，但實際可讀取的資料與可執行動作，仍取決於客戶端支援、Server 實作、授權與權限設定。

這個協定是 Anthropic 在 2024 年 11 月底公開的，定位上是開放標準，不是某一家的私房菜（公告全文見 Introducing the Model Context Protocol）。你可以把它想成 AI 工具與資料來源之間的共用介面：只要資料端提供 MCP server、AI 端支援 MCP client，兩邊就能透過一致的方法交換工具與脈絡。官方的快速上手文件說明了這個關係。

把這個定位放回我們的主題：Figma 提供遠端與桌面版 MCP server，Claude Code 則是支援 MCP 的 client。Figma 官方建議多數情境優先使用遠端 server；桌面版模式適合需要讀取目前選取範圍等本機情境。連線後，Claude 可以呼叫 Figma 提供的工具，取得圖層、元件、變數、版面與 Code Connect 等結構化脈絡，也能依可用工具把內容寫回 Figma 畫布（設定方式見 Figma 官方說明）。

這裡有個觀念我特別想點出來：MCP 搬的是資料，不是美感。它能提供設計師設定的數值與結構，但不會替你判斷這些決策好不好看、合不合理。設計師若把間距設成 13px 而非 16px，Claude 可能依取得的脈絡沿用 13px；規格本身不理想，生成結果也不會自動變好。MCP 是資料介面，不是審美顧問。

如果你還沒摸過 Claude Code 這個工具本身，建議先讀過 Claude Code 的完整中文教學，把 Agent Loop、CLAUDE.md、權限模式這些基礎觀念建立起來，後面談連線與提示詞才不會霧煞煞；若你連 Claude 整個產品線都還不熟，Claude 完整使用指南能幫你把地基先打好。MCP 只是 Claude Code 能吃的其中一類外部能力，把它放回整個工具的脈絡裡，你才不會過度期待它。

Claude Code 接 Figma MCP 的三層架構

要穩定用好這條鏈路，你得在腦海裡建立起三層架構。我把每一層的職責拆開，因為後面排查問題的時候，你得先判斷是哪一層壞掉。

層	是誰	職責	壞掉時的症狀
資料層	Figma 檔案＋REST API	把設計以節點、元件、變數的形式存在雲端，對外提供結構化讀取	抓不到資料、欄位空白
橋接層	Figma Dev Mode MCP server	把 Figma 的資料包成 MCP 協定的工具，讓外部 client 能呼叫	連線成功但工具叫不動
消費層	Claude Code（MCP client）	呼叫工具、解讀回傳的設計資料、生成並修改 UI 程式碼	資料進來了但生成的程式碼走樣

資料層的源頭是 Figma 檔案本身。Figma 另有 REST API，供開發者讀取檔案結構、匯出資產與查詢評論；MCP server 則提供一組為 AI 工作流整理過的工具。兩者用途有重疊，但不能把 MCP 簡化成 REST API 的單純包裝。

橋接層有兩種做法。遠端 server 透過帳號授權連接，不要求 Figma 桌面版持續開著；桌面版 server 才需要在 Figma 中啟用 Dev Mode MCP，並讓本機端點可連線。排錯時先確認自己接的是哪一種，不要把桌面版的限制套到遠端模式。

消費層是 Claude Code。它拿到設計資料之後，做的是理解、推理、生成三件事：理解這個 Frame 的階層與意圖，推理該用什麼版面技術（flex、grid、還是絕對定位），生成對應的程式碼。同一份設計資料，交給不同模型或不同提示詞，產出的程式碼品質可以差很多。這也是為什麼這條鏈路的上限，其實取決於你的提示詞能力，MCP 只是把這個上限撐開而已。

想看 MCP 在另一個實戰場景怎麼運作，Claude Code 接 WordPress 的 MCP 實戰走的是同一套協定、不同的資料來源，對照著看你會更理解「協定共用、資料端替換」這個設計的美感。如果你要的是更完整的 Claude Code 工作流拼圖，用 Claude Code 搭網站的 Skills 加 MCP 完整流程把這一塊放進更大的脈絡裡。

連線之前，先把 Figma 稿整備到位

這一步很容易被跳過，然後在生成結果裡付出代價。我講一句實話：Figma 稿的結構與命名，會直接影響 Claude 取得脈絡後的判讀。同樣的連線與模型，餵進去一份亂糟糟的稿跟一份整備過的稿，產出品質可能差很多。我把連線前該做的整備列成下面這份清單，每一項都附上它實際影響什麼。

整備動作	沒做的後果	對產出的影響
圖層命名語意化（header、product-card，不是矩形 12）	Claude 抓到無意義名稱，拆元件時亂猜	元件結構與命名正確度
間距全面改用 Auto Layout，不要靠絕對定位手拉	padding 與 gap 抓不準，版面鬆散	間距與排版忠誠度
顏色、字級、間距、圓角全部設成 Variable／Token	生成出全是一堆 magic number，之後改不動	可維護性與一致性
Component 拆出來、Variant 設清楚	狀態多時 Claude 會漏掉某一態	元件狀態完整度
清掉隱藏圖層、未命名副本、暫存框	雜訊被一起傳過去，影響推理	生成穩定度
至少畫桌面與手機兩個尺寸	行動版只能靠規則推導，誤差大	響應式還原度

這張表裡我最在乎的是第三項，design token。原因是它帶來的好處不只限於這一次生成，更會貫穿你整個產品的生命週期。顏色、間距、字級一旦變成 token，Claude 產出的程式碼就會引用這些 token，之後你要改品牌色，改一個地方全部連動，省回頭改幾百個 hex 色碼的工夫。這個觀念跟 CSS 的基礎觀念裡講的「不要把樣式寫死」是同一件事，只是搬到設計端來做。

Auto Layout 那一項也值得多講兩句。Figma 的 Auto Layout 本質上就是 flex 排版的視覺化版本：你設主軸方向、間距、對齊，它就幫你把元素排好。當你的稿是用 Auto Layout 搭起來的，MCP 傳過去的結構幾乎可以直接對應到 CSS 的 flex 屬性，Claude 還原的精準度會明顯比「靠肉眼手拉絕對位置」的稿高上一截。正因如此，我會建議設計師朋友，就算不為了 AI，也該把 Auto Layout 用好，它是設計與工程之間最直接的共同語言。想把這套排版觀念再打底，Figma 的 Layout Grid 與網格系統有完整的設定教學。

整備這件事看起來是設計師的工作，但如果你是工程師主導流程，請務必回頭跟設計師溝通這幾項。前期多花兩小時整備，後期少花兩天 debug，這筆帳怎麼算都划算。而且整備過的稿不只對 AI 友善，對任何接手的人類工程師也一樣友善，這是沒有副作用的投資。

第一次連線：把 Figma MCP 接上 Claude Code

觀念講完了，來動手。我把第一次連線拆成五個動作，順序不能亂，因為每一步都依賴前一步的狀態。

1. 先選遠端或桌面模式。多數人可優先安裝 Figma 官方 Claude plugin：claude plugin install figma@claude-plugins-official，再於 /plugin 完成授權。若組織或工作流需要桌面模式，再於 Figma Dev Mode 啟用本機 MCP server。
2. 確認本機端點真的活著。用瀏覽器或 curl 去戳那個本地端點，有回應才算啟用成功。這一步看起來多餘，卻能幫你省下後面兩小時的鬼打牆。
3. 桌面模式才需註冊本機端點。官方目前提供的範例是 claude mcp add --transport http figma-desktop http://127.0.0.1:3845/mcp；實際設定仍以當下官方文件為準。
4. 重啟或重新連線 Claude Code，確認它看得到 Figma 的工具。註冊完之後，用 claude mcp list 確認狀態是可連線，並確認 Figma 開出來的工具（抓結構、抓圖、抓變數這幾個）有列出來。
5. 挑一個小 Frame 做第一次試拉。不要一開始就丟整個首頁，挑一個卡片或一個表單區塊，給 Claude 一個明確任務（例如「把這個 Frame 轉成 React 加 Tailwind，間距用 design token」），看它能不能把資料拉回來、轉成合理程式碼。

五步走完，你手上的就是一條能跑的鏈路。接下來的問題，不再是「接不接得起來」，而是「怎麼讓產出的東西真的能用」。這中間的差距，就是你接下來要練的提示詞功夫。

設定過程裡如果你用到 Plugins 或 Skills 來管理 MCP 來源或團隊共用設定，Claude Code Plugins 指南跟 Claude Skills 完整教學能幫你把環境整理得更乾淨，不會每換一個專案就要重接一次。

從一個 Frame 到可運行的 UI：我的完整工作流

連線跑通之後，真正決定產出品質的是你的工作流。我把自己反覆用下來、最穩定的流程拆成四個階段，每個階段都附上我會用的提示詞思路。

階段一：選 Frame，先講脈絡再講轉換。我不會一開口就說「把這個轉成程式碼」。我會先給 Claude 一段脈絡：這個 Frame 是什麼頁面的哪一區、它要放在什麼框架裡、之後會接什麼資料。脈絡給足了，Claude 才會選對的版面技術與命名慣例，避免給你一個孤立、之後接不回去的片段。

階段二：指定技術棧與結構慣例。React 還是純 HTML？Tailwind 還是 CSS Modules？要不要拆成子元件？這些問題你不回答，Claude 就會用它的預設值，而它的預設值往往跟你的團隊慣例對不上。我習慣在 CLAUDE.md 或提示詞開頭把這些慣例寫死，例如「原子單位用 rem、顏色一律走 design token、間距用 4 的倍數」，這樣每一次生成都會遵守同一套規矩。

階段三：分批轉換，邊轉邊驗。把頁面切成幾個語意區塊（header、hero、feature list、footer），逐段轉換，每完成一段就在瀏覽器預覽並和原稿比對。這個節奏也符合提示詞設計的基本原則：小步生成、即時校準，比整頁生成後再一次除錯更容易定位問題。

階段四：補互動、補狀態、補響應式。這是 MVP 生成完之後，真正拉開品質差距的一步。我會針對每個區塊，把「滑鼠移過去會怎樣」「按下會怎樣」「手機上會變幾欄」用白話講給 Claude，讓它把這些沒被畫在稿上的行為補進程式碼。這一步的提示詞長相會像：「這張卡片在 hover 時陰影加深、整張微微上移 2px，行動版縮排改成單欄」；相對之下，「幫我加互動」這種空泛指令幾乎不會有效果。

提示詞類型	長相	適合的時機	風險
整合型	「把這段設計轉成元件，套用現有 design token」	稿子乾淨、慣例明確時	過度信賴會漏互動
重建型	「用 Tailwind 從零做出這個版面」	想換技術棧、或稿子很亂時	容易偏離原稿細節
描述型	「這個區塊在桌面是三欄、手機是單欄，間距 24」	補響應式與狀態	描述不準就會做錯
修補型	「把這個卡片的圓角改成 token 裡的 radius-lg」	生成後的微調	改太多會失去結構

這四種提示詞我會混著用，不會從頭到尾只靠一種。整合型打底、描述型補肉、修補型收尾，重建型只在必要的時候上場。這個判斷沒有公式，是你跑過幾個專案之後長出來的手感。單靠「幫我把這個轉成程式碼」這種空泛指令，通常很難穩定產出可直接上線的結果。

MCP 傳得了什麼、傳不了什麼：設計忠誠度的真實邊界

這是整篇文章我最想讓你帶走的一段。很多人對 MCP 的失望，來自於期待它「還原整個設計」，但它的能力是有邊界的，而且這個邊界非常清楚。我把各類設計元素的忠誠度整理成一張表，你在評估產出的時候，拿這張表對照，就知道哪裡的「怪」是正常的、哪裡的「怪」要回頭修。

設計元素	MCP 傳遞忠誠度	通常的狀況與補救
版面結構、圖層階層	高	命名有規矩時幾乎完整還原；命名混亂時會誤判語意
文字內容、字級、字重	高	內容與樣式忠實，但字體載入策略要自己處理
顏色（有設 Variable／Token）	高	有用 design token 會漂亮還原；硬編碼色票會變死值
間距、padding、圓角	中高	Auto Layout 處理得好；絕對定位混用時容易抓錯
元件、Component 實例	中	巢狀 Variant 偶爾漏層性，要回頭核對
互動、Prototype 連線	低	大多要靠提示詞補述，稿上畫的連線常被忽略
動態、微互動、轉場	視稿件而定	即使有 Prototype 脈絡，仍應文字補充行為與具體數值
響應式斷點、行動版狀態	低	設計稿通常只畫一兩個尺寸，其他要靠規則推導
無障礙設定、焦點狀態	低	稿上極少標註，要主動在提示詞裡要求

從這張表可以看出一個清楚的分野：靜態、數值型的資訊通常較明確；動態、行為型的資訊更依賴原型設定與文字規格。設計稿常聚焦於畫面狀態，即使附有 Prototype 連線，也未必涵蓋例外狀態、完整轉場與工程限制。

這個分野帶來一個很實用的判斷：當生成出來的 UI「長得對、但感覺死死的」，先檢查互動、狀態與轉場是否有明確規格，再判斷連線或生成環節是否出錯。把 UI 原型設計的觀念借過來用：原型是用來溝通互動的，你的提示詞某種程度上就是在扮演「文字版原型」的角色。

特殊效果也要額外核對，例如毛玻璃、漸層遮罩與複合陰影。若工具回傳的設計脈絡不足，Claude 可能用不同的 CSS 手法重建，視覺就會走樣。遇到這類效果，可在提示詞裡寫出期望的 CSS 手法，例如「這層用 backdrop-blur 加半透明疊加」，再以瀏覽器實際比對。想理解這類效果的設計端原理，Figma 毛玻璃效果跟 Figma 按鈕動態是很好的對照。

響應式那道坎：設計稿沒畫的，要靠提示詞補回來

前面提過響應式是低忠誠度的一環，這一段我單獨拉出來講，因為它是實務上最容易翻車、也最容易被略過的一塊。背後有一個你必須知道的硬數字：全球網站流量已經有超過六成來自行動裝置（Statista 的逐季統計，2026 年 4 月）。也就是說，你生成出來的 UI 如果只在桌面上看順眼，實際上線後有超過一半的訪客看到的是歪掉的版本。

問題的根源在於：大多數 Figma 稿只畫桌面版，最多再加一個手機直式。平板、橫向手機、大桌面這些中間狀態幾乎沒人畫。MCP 把桌面版的結構忠實傳過來，Claude 照著寫，你拿到的就是一個「只有桌面版」的成品。要把它變成真正的響應式，你得在提示詞裡做兩件事。

第一件，建立斷點策略。在你的慣例文件或提示詞裡，明確定義你要用哪幾個斷點（例如手機、平板、桌面三段），每個斷點下版面要怎麼變化。這等於是在補設計稿沒畫的那幾個尺寸。第二件，指定伸縮規則：哪些區塊要固定寬度、哪些要填滿、哪些要換欄、字級要不要隨寬度縮放。這些規則不講，Claude 就會用它的預設值，而它的預設值通常跟你品牌要的對不上。

把這兩件事做好，你的提示詞會長得像這樣：「桌面三欄、平板兩欄、手機單欄，欄間距桌面 32 手機 16，主標題桌面 48px 手機 32px，圖片填滿欄寬並維持比例」。這段文字沒有任何一個字來自設計稿，但它決定了行動版的成敗。把 響應式網頁設計的觀念跟 AWD 與 RWD 的差異先讀通，你寫出來的規則才會合理，也才不會亂定一通再回頭怪 AI 做不出來。

設計端如果你能影響流程，鼓勵設計師在 Figma 裡用 響應式外掛與 Layout Grid至少標註手機版，這會讓 MCP 傳過來的資料多了行動版的維度，你的補述壓力會小很多。設計與工程在這裡是同一條船，稿畫得越完整，後面 AI 能幫的越多。

無障礙與效能：MCP 不會替你把關的兩件事

走到這裡，你已經能產出第一版 UI，但還有兩件事不能只靠 MCP 資料判定：無障礙（accessibility）與效能（performance）。設計稿可以標示部分焦點、對比與互動狀態，卻通常不含完整 HTML 語意、實際資源大小、載入順序與執行成本；這些仍要在程式碼與瀏覽器裡驗收。

先講無障礙。Figma 稿記錄的是視覺，不是語意。一個看起來像按鈕的圓角矩形，在稿上跟一個裝飾用的色塊沒有區別，MCP 沒辦法知道前者該用 <button>、後者該用 <div>。Claude 會根據視覺線索去猜，但猜錯的代價很實際：用鍵盤導航的人按不到那個「按鈕」、螢幕讀報軟體唸不出它的意義、焦點移過去的時候沒有任何視覺回饋。這些都是無障礙的硬傷，而且它們影響的不只是特定族群，搜尋引擎跟某些 AI 助理讀你的頁面時，用的也是類似的語意解析邏輯，語意亂掉等於自己在 SEO 與 GEO 上扣分。

我把無障礙相關、你該主動寫進提示詞的要求列成清單：互動元素一律用語意標籤（button、nav、main、section）；所有圖片補 alt，純裝飾圖標記為 hidden；可聚焦元素都要有清楚可見的 focus 樣式；色彩對比要符合 WCAG AA；表單欄位要有對應的 label。這份清單不長，但每一項你不講，Claude 就不會主動加。把 設計思考裡「同理使用者」這一層想進去，你就會理解為什麼這些東西不能省：無障礙的本質，就是把使用者的範圍從「跟我一樣的人」擴大到「跟我很不一樣的人」。

再講效能。MCP 傳過來的設計資料裡，圖片常常是高解析的原檔，字體可能是設計師用的付費字，動態效果用的是 Figma 的智慧動畫。Claude 把這些直接對應成網頁資源時，如果沒有人提醒，它會用最直觀但最重的方式實作：原圖不壓縮、字體整套載入、動畫用 JS 函式庫驅動。結果就是一個長得很漂亮、但載入要五秒、手機滑起來卡卡的頁面。

效能的補救跟無障礙一樣，要寫進提示詞：圖片要壓縮並用現代格式（WebP、AVIF）、需要時加上 lazy load；字體只載實際用到的字重，並設定 font-display 策略；動畫優先用 CSS 或 Web Animations API，避免動不動就掛一個動畫函式庫；行動版要降低同時載入的資源量。這些要求跟前面講的響應式策略是同一套邏輯：設計稿畫的是結果，達成結果的工程手段要你來指定。

這兩件事我特別拉出來講，是因為它們是最容易被「看起來成功了」掩蓋掉的失敗。你在桌面上預覽，畫面跟設計稿一模一樣，很容易就覺得完工了。但無障礙的問題要開螢幕讀報軟體才看得到，效能的問題要開慢速網路或拿起手機才感覺得到，而它們恰恰是上線之後最容易反噬你的兩件事。把這兩項寫進你的慣例文件，讓每一次生成都預設帶上，才是真正把這條鏈路用在生產環境的前提。

接不上的時候：一份排查清單

鏈路跑不順的時候，最怕沒有系統地亂試。實務上最常見的故障點，我對照如下整理成一份排查表，你照著從上往下檢查，通常十分鐘內能定位問題。

症狀	最可能的原因	先檢查這個
claude mcp list 顯示連不上	授權或端點設定失敗	遠端模式重做帳號授權；桌面模式確認 Figma 已開啟並啟用 Dev Mode MCP
連得上但工具叫不動	權限、檔案或方案限制	確認帳號能存取檔案、連結或選取範圍有效，並核對官方方案限制
抓到資料但欄位空白	選到的節點不對	確認 Frame 的連結或節點 id 是否正確
程式碼生成但走樣嚴重	提示詞缺脈絡	補技術棧、命名慣例、design token 來源
回應變慢或斷斷續續	本機端點搶資源	關掉其他佔用同一 port 的程式、重啟 Figma
顏色或間距跟稿不同	硬編碼值沒走 token	在提示詞強制要求使用 design token
互動完全沒做進去	提示詞沒描述行為	補 hover、focus、行動版狀態的具體數值

這張表的核心觀念是：不同層的問題，症狀長得不一樣。連線層壞掉是「叫不到工具」，資料層壞掉是「叫到了但空的」，消費層壞掉是「資料齊全但成品走樣」。先判斷是哪一層，再動手修，才不會把提示詞改了半天，結果發現是 Figma 沒開。

這條路值得走嗎？跟手刻、跟其他 AI 轉碼工具的取捨

把成本、產出品質、可控性擺在一起，這條 MCP 鏈路值不值得引進你的工作流？我給你一個誠實的對照，不灌水。

方式	速度	設計忠誠度	可控性	最適合
純手工切版	慢	最高（人盯著）	最高	複雜互動、金流、長期維護的產品
Claude Code 加 Figma MCP	快	中高（靜態高、動態低）	中（靠提示詞）	品牌頁、活動頁、後台雛形、迭代快的專案
Figma 原生的 AI 轉碼功能	快	中（綁原生流程）	低（黑箱）	快速驗證、不想架環境的人
通用 AI 陪聊寫版面	中	低（憑描述猜）	低	只有想法、連稿都還沒畫時

從這個對照可以看出，Claude Code 加 Figma MCP 的甜蜜點很明確：有稿、要快、結構可控、但不需要做到金融級互動的場景。它的角色是把「把稿變成第一版可用程式碼」這段最耗時的體力活自動化，讓人把時間留給真正需要判斷的互動、狀態、效能優化。如果手上還沒有現成的設計稿，也可以先讓 Stitch 出畫面、再交給 Claude Code 重寫，把生成稿當作輸入走同一套流程。

這裡有一個判斷我想額外提醒你：一次性頁面跟可重複使用的元件庫，對待這條鏈路的態度要不同。如果目標是活動 landing page 這種用完即丟的頁面，你可以盡量讓 MCP 與 Claude 自由發揮，反正之後不太需要回來改，速度優先。但如果你的目標是建立一套團隊會長期沿用的元件庫，就必須把前面講的 design token、命名慣例、無障礙要求全部寫死在 CLAUDE.md，每一次生成都嚴格遵守，並且產出後立刻人工審過再收進元件庫。後者容錯率低，因為一個帶病的元件會被複製到整個產品裡，壞的影響是乘開的。把這個分界放在心裡，你才不會把「快」這個優點，變成「到處埋雷」的缺點。想建立更完整的元件化思維，網頁版面設計的模組化觀念是很好的延伸讀物。

HubSpot 的 2026 行銷報告顯示，AI 已廣泛用於內容與媒體產製流程；這支持了「團隊正在增加自動化環節」，但不能直接推論採用某一套工具就一定會更快上市。MCP 的實際價值，仍要看它是否減少交接、重工與人工轉錄。

我自己的判斷是：這條路值得走，值得走的原因在於：它把人的時間從機械勞動裡解放出來，去做 AI 做不到的事。這跟我一直講的觀念完全一致：能熟練駕馭這條鏈路的人，不但不會被取代，還能把產能放大好幾倍。想把心態調對，vibe coding 的完整入門跟 生成式 AI 的正確使用觀念是很好的配套讀物。

如果你想看 Figma 自己的 AI 路線走到哪、跟 MCP 這條外部鏈路怎麼分工，Figma AI 三大功能解析把 Make、MCP、Design Agent 的角色拆得很清楚，能幫你決定哪些事交給 Figma 原生、哪些事拉出來交給 Claude Code。手邊還沒有順手的設計地基，Figma 中文完整教學先補起來，這條鏈路吃的是你 Figma 稿的品質，稿爛，再強的 AI 也救不回來。

四步落地：下禮拜就能跑起來的行動方案

觀念讀完，接下來是手上的事。我給你一個四步行動方案，照著走，下禮拜你就能在自己的專案裡把這條鏈路跑起來。

1. 挑一個目標專案，但只挑一個小區塊。不要拿正在趕上線的主專案當實驗場。挑一個寬限比較大的頁面，例如作品集的某個區塊、活動 landing page 的 hero，把範圍縮到一個 Frame，風險才可控。
2. 把 Figma 稿收拾乾淨。命名要語意化、圖層要分群、顏色與間距盡量走 Variable 與 design token。這一步做多少，後面 AI 還原的忠誠度就差多少。這是整個流程裡投資報酬率最高的一步。
3. 連線跑通並完成第一次試拉。照前面那五個動作把 MCP 接上，挑那個小 Frame 做一次完整轉換，在瀏覽器比對原稿。第一版通常仍需調整，重點是讓整條鏈路在你手上跑過一遍。
4. 建立你的慣例文件。把這次試拉裡用有效的提示詞、技術棧設定、design token 來源、斷點策略寫進 CLAUDE.md 或一份共用的慣例文件。下一次接新頁面，直接套用，產出穩定度會跳一個級別。

這四步走完，你不會變成 AI 轉碼大師，但你會擁有一條屬於自己、能反覆使用的設計到程式碼產線。剩下的，就是一次一次把提示詞磨細、把稿收拾乾淨、把互動補完整，這是沒有終點的功夫，也是沒有人能替你走的路。

換句話說，MCP 解決的是「資料能不能傳過去」這個工程問題，而你仍要處理「設計意圖怎麼落到程式碼」的判斷。把稿整理乾淨、把慣例寫進專案文件、把互動與無障礙規格補齊，產出才有穩定的驗收基準。如果你正在重新思考整個網站從設計到上線的流程，網頁設計從零到一的完整指南能幫你把這條鏈路放回更大的地圖裡。