Figma MCP 讓 Claude Code 做到什麼，跟我自己貼截圖有什麼不同？
貼截圖時，Claude 只看到像素；透過 Figma MCP，它讀到的是結構化資料：版面、顏色與間距變數、元件。這讓它能用你的 token 而不是猜一個接近的色碼。
反方向也可以：在 Claude Code 裡說「Send this to Figma」，把瀏覽器上跑著的畫面擷取成可編輯的 Figma 畫面框。
我是免費的 Starter 方案，能試試看嗎？
可以接上，但很快會撞到限制：依 DEV Community 的說明，Starter 方案與 View、Collab 席位每月最多 6 次工具呼叫，設定與測試就可能用完。
要把它用在真實工作，文章建議使用付費方案的 Dev 或 Full 席位。先在小範圍確認值得，再決定要不要為此買席位。
為什麼要一次只連結一個畫面框？
因為貼整頁或很大的畫面框，回應會變慢或被截斷。get_metadata 這個工具就是為此設計：給一份輕量的結構地圖，讓 Claude 只抓需要的節點。
實務做法是把頁面拆成元件或區塊，一個一個連結與實作，而不是一次丟整頁。
產出的程式碼可以直接用嗎？
不建議。文章提醒，React 加 Tailwind 的輸出若原樣使用，可能長出一套和你現有元件重複的平行 UI 元件庫；圖層名稱不乾淨（例如「Group 5」）時，程式碼也沒有意義。
所以規則檔裡有一條：把輸出當成描述，不是最終程式碼，並在完成前和截圖比對。兩篇文章都沒有提供量化的品質數據，品質要靠你自己驗證。
Figma 的 MCP 伺服器讓 Claude Code 能直接讀取你的設計稿，而不是靠你截圖、貼文字描述。對沒寫過程式的設計師或 PM 來說，它省下的是「把畫面翻譯成需求」那一步。這篇整理 DEV Community 與 Builder.io 兩篇實作文章的內容：怎麼接上、Claude 讀得到什麼、哪些地方容易卡住。兩篇都沒有提供量化的效果數據，Builder.io 同時賣自己的競品，下面會標明。
第一個方向是讀：你貼一個 Figma 連結，Claude Code 讀出版面、變數與元件，據此產生程式碼。第二個方向是寫：在 Claude Code 裡打「Send this to Figma」，它會把瀏覽器上正在跑的畫面（正式站、測試站或 localhost）擷取成可編輯的 Figma 畫面框，文字可編輯、按鈕變成獨立元件、版面使用 auto-layout。後者用的是只限 Claude Code 與遠端 MCP 的 generate_figma_design 工具。
兩篇文章的步驟一致。先在終端機加入 Figma 的遠端伺服器（加上 --scope user 可以讓所有專案都能用）：
claude mcp add --transport http --scope user figma https://mcp.figma.com/mcp
接著啟動 Claude Code，輸入 /mcp，選 figma 再選 Authenticate，在瀏覽器完成 OAuth 登入，不需要手動貼 token。再輸入一次 /mcp，看到綠色狀態就代表成功；如果清單裡沒有 figma，重啟 Claude Code，因為 MCP 伺服器是在啟動時載入的。也可以用 claude mcp list 檢查，正常會顯示 Connected；顯示 Needs authentication 就再跑一次 /mcp；顯示 Failed to connect 則檢查網址是否以 /mcp 結尾、傳輸方式是否為 http。
還有另一種裝法是外掛：claude Plugin install figma@claude-plugins-official。外掛與伺服器擇一即可，兩個都裝會讓 Claude 看到重複的 Figma 工具。
DEV Community 那篇列出四個讀取工具：get_design_context 回傳你連結的畫面框、已整理成 React 加 Tailwind 的結構，當成寫程式的起點；get_variable_defs 取得顏色、間距、字型的變數與樣式，讓 Claude 使用你的 token 而不是寫死的值；get_metadata 給一份輕量的結構地圖，大範圍選取時只抓需要的節點；get_screenshot 提供畫面截圖，用來對照。另外有寫入畫布的功能（beta），只限遠端伺服器，beta 期間免費。
文章建議在專案的 CLAUDE.md 加一段規則，把每次的做事順序寫死：
## Figma MCP rules 1. Run get_design_context first. 2. If the response is too large, use get_metadata to find the nodes you need. 3. Run get_screenshot before coding. 4. Treat the output as a description, not final code. 5. Before finishing, compare the result against the screenshot.
實際的提示可以這樣寫：「把這個畫面框實作成 src/components/marketing/PricingCard.tsx 裡的 React 元件，重用我們現有的 Button，並使用我們的設計 Token：（貼上 Figma 連結）」。判斷是否成功的簡單方法，是看 Claude 在寫程式之前，有沒有先呼叫 get_design_context 和 get_screenshot。
第一，方案限制：建議使用付費方案的 Dev 或 Full 席位；Starter 方案與 View、Collab 席位每月最多 6 次工具呼叫，光是設定就可能用掉。付費席位則有每分鐘的呼叫上限。第二，連結範圍：貼整頁或很大的畫面框，回應會變慢或被截斷，一次只連結一個畫面框或元件。第三，產出會長出一套平行的 UI 元件庫：React 加 Tailwind 的輸出如果原樣使用，可能和你現有元件重複，所以要在提示裡指明框架與要重用的元件。第四，圖層命名：像「Group 5」這種名稱會產生沒有意義的程式碼。
Builder.io 那篇另外列了「程式碼送進 Figma」方向的限制：圖層不帶商業邏輯、事件處理或狀態管理；匯出是單向的，之後設計稿的更新必須重做；有註解標記的元素可能讓 MCP 失敗；Windows 上的 WSL 使用者有缺口，get_code 需要 Code Connect，而它只開放給組織與企業方案。該文最後推薦的是它自己的產品，因此讀這部分時請當作廠商觀點。
先確認席位。如果你還在 Starter 或只有檢視席位，每月 6 次呼叫幾乎不夠用，這會讓你誤以為工具不好用；真正要用在工作上，要有 Dev 或 Full 席位，這是額外的席位成本。
其次是用量。兩篇文章都沒有提到 token 消耗或測得的省時數字，所以我無法告訴你這個流程值多少錢。建議挑一個真實的小元件，完整跑一次，記下花了多少時間、修了幾次，再決定要不要為這個流程買席位。命名乾淨的圖層與完整的變數，是最便宜的投資：它們讓同一份設計稿被讀得更準，也減少重跑。