get_design_context 回傳的內容並非目標框架的程式碼，而是一種看起來像 React 與 Tailwind 的中介描述——這是官方文件的說明。模型因為大量訓練於網頁程式碼，能順利把這個格式翻譯成你要的語言與慣例。理解這一點能一次解釋兩件事：為何你要 SwiftUI 卻拿到 React，以及為何提示裡指定框架是必要的而非可選的。
📖 基本流程
- 在 Figma 選好範圍，或右鍵「Copy link to selection」複製連結
- 在 client 裡下提示，講清楚框架、放哪裡、用哪些既有元件
- agent 呼叫
get_design_context（必要時先get_metadata） - agent 產出程式碼
- 用
get_screenshot比對驗證
第 5 步是多數人跳過、但成本最低的品管步驟。 結構化資料描述不了「看起來對不對」，截圖可以。
📖 指定框架
官方文件對「為何回傳網頁程式碼」給了三個解法：
一、在提示裡講清楚。 官方範例逐字如下：
「Generate iOS SwiftUI code from the selected Figma frame.」 「Implement the selected frame using Chakra UI components.」 「Generate this using components from src/components/ui.」 「Add this component to src/components/marketing/PricingCard.tsx.」 「Implement this using our Stack layout component.」
這五句的共同點值得注意：它們都在指定約束，而不是描述想要的視覺結果。設計的視覺部分由 MCP 提供，提示要補的是 MCP 不知道的事——你的框架、你的檔案位置、你的版面元件。
二、用 Code Connect 處理多框架。 若元件已對應多個框架，可以選擇 agent 要拿哪一個。遠端伺服器透過 clientFrameworks 參數指定（值如 React、SwiftUI）；本機伺服器則依 Dev Mode 裡所選的連接。
三、檢查方案。 官方明確指出：Professional 方案一次只能啟用一個框架。 若你預期拿到別的框架卻一直得到網頁程式碼，團隊管理員可到 Admin → Settings → Resources → Code Connect 更改啟用中的框架。
第三點是一個容易漏掉的制度性限制。 它不是提示寫得不好，也不是模型不行——是方案層級的設定擋住了。一個同時做 Web 與 iOS 的 Professional 方案團隊會持續踩到這件事。
📖 忠實度：能期待到什麼程度
官方沒有公開任何忠實度的量化指標，也沒有第三方的受控評測。因此本篇不給百分比，只講哪些維度本來就會準、哪些本來就不會。
| 維度 | 可期待的忠實度 | 為什麼 |
|---|---|---|
| 間距 | 高——前提是用了 auto layout | auto layout 的參數是明確數值；絕對定位則只能靠推測 |
| 顏色 | 高——前提是用了變數 | 變數有名稱可對應；硬刻顏色只會得到十六進位值 |
| 字級 | 中高 | 文字樣式可取得，但對應到你的字級系統仍需規則 |
| 圓角、邊框 | 高 | 同樣來自變數或明確數值 |
| 版面結構 | 中 | auto layout 可映射到 flex；複雜巢狀或絕對定位容易走樣 |
| 元件重用 | 取決於 Code Connect | 有做就用你的元件，沒做就每次重生 |
| 互動與狀態 | 低 | 設計檔通常只有靜態畫面；變體有助但不等於行為 |
| 響應式行為 | 低到中 | auto layout 表達了部分意圖，但斷點邏輯多半要人補 |
| 無障礙 | 低 | 設計檔很少帶這些資訊，須靠規則檔補 |
這張表的實際用途是調整期待與分工：前四項可以放心交給 agent；互動、響應式與無障礙三項本來就得人工補，把它們當成 agent 的失敗是誤判，見 何時仍需人工。
響應式那一項可以用設計端改善：官方建議用 auto layout 表達「設計在不同尺寸下應該如何反應」，並在生成程式碼前先縮放 frame 確認行為符合預期。這一步把原本只存在設計師腦中的意圖變成檔案裡的資料。完整的響應式實作考量見 全響應式。
📖 讓產出貼近設計的五件事
依投報率排序，前兩項的效果遠大於後三項。
一、把重複的東西做成元件，並做 Code Connect。 官方稱 Code Connect 是讓 agent 重用真實元件「the most effective way」。見 第五篇。
二、用變數管間距、顏色、圓角、字體。 官方建議的四類正是如此。沒有變數，agent 只能給你硬編碼值，而那是後續所有不一致的來源。
三、圖層與元件取語意化名稱。 官方要求把 Frame1268、Group5 這類預設名稱換成描述用途的名稱，如 CardContainer、ProductImage、CTA_Button。名稱是 agent 唯一能用來推測語意的線索。
四、用 auto layout，避免絕對定位。
五、加註解（annotations）與 dev resources。 官方建議用註解說明難以用視覺表達的行為、對齊或響應式規則，並在 Dev Mode 把相關文件、程式碼或 ticket 掛到圖層上。
第三與第五項常被當成「設計師的潔癖」，但在 MCP 的脈絡下它們是功能性的。 圖層名稱會直接變成變數名與元件名；註解是唯一能把「這一塊在手機上要收起來」這種意圖傳進 agent 的管道。這正是 設計→工程交接 所講的資訊損耗——MCP 只能傳遞檔案裡真的有的東西。
📖 處理大型選取
不要一次選整頁。 官方把這列為獨立的問題頁面，症狀是「slow down the tools, cause errors, or return incomplete results」。
官方建議：
- 針對較小的區段或單一元件生成——例如一張卡片、一個 header、一個 sidebar
- 覺得慢或卡住時，選少一點再試
- 大型設計先讓 agent 呼叫
get_metadata取輕量輪廓，再針對需要的部分取完整脈絡
官方沒有給出具體的 node 數量或尺寸門檻，只有定性描述。
📖 資產（圖片與 SVG）
本機伺服器會以 localhost 連結提供圖片與 SVG。官方的規則檔範例明確要求 agent：
- 若回傳 localhost 來源，直接照用
- 不要另外加 icon 套件，所有 icon 都應來自 Figma payload
- 不要在已有 localhost 來源時建立 placeholder
這三條之所以要寫進規則檔，是因為 agent 的預設傾向正好相反——它習慣裝一個 icon 套件或放 placeholder。見 規則檔。
遠端這一側則用 download_assets（至多 20 個 node）與 upload_assets。
🧠 重點整理
get_design_context 回傳的是 React／Tailwind 風格的中介描述，不是目標框架的程式碼——這解釋了為何總是拿到網頁程式碼。
提示要補的是 MCP 不知道的事：框架、檔案位置、要用哪些既有元件。視覺部分 MCP 已經提供了。
Professional 方案一次只能啟用一個框架，同時做 Web 與 iOS 會持續踩到。
忠實度分維度看：間距顏色圓角高（前提是 auto layout 與變數）、互動響應式無障礙低。
互動、響應式、無障礙本來就要人補，當成 agent 的失敗是誤判。
投報率最高的兩件事是 Code Connect 與變數，其餘是補強。
語意化圖層名稱與註解是功能性的，不是潔癖——它們是 agent 唯一的語意線索。
不要一次選整頁，官方建議先 get_metadata 取輪廓再針對性取用。
資產規則要寫進規則檔，因為 agent 的預設傾向與正確做法相反。
✍️ 動手做
量出「檔案品質」對產出的影響，約 40 分鐘。這個實驗的目的是說服自己（或說服團隊）去修 Figma 檔案：
- 挑一個沒有用變數、圖層名稱是預設值的既有設計區塊，生成一次程式碼。存檔。
- 把同一個區塊複製一份，然後在複本上做三件事：把顏色與間距換成變數、把圖層改成語意化名稱、把重複元素做成元件。
- 對複本生成一次程式碼。
- 並排比較兩份產出：顏色是變數名稱還是十六進位？間距是 token 還是魔術數字？重複元素有沒有被識別為同一個元件？
- 記下你在第 2 步花了多少時間。
第 5 步是重點。那個時間就是「修檔案」的成本，而兩份產出的差距就是收益——這組數字比任何人的建議都更能決定你的團隊該不該投入。
🔗 資料來源
- Figma 開發者文件 — 伺服器回傳網頁程式碼——React／Tailwind 中介格式的說明、三個解法、Professional 單框架限制與管理員路徑（一手，2026-11-01 查證）。
- Figma 開發者文件 — 撰寫有效的提示——五句官方範例提示（逐字引用）。
- Figma 開發者文件 — 組織 Figma 檔案——元件、變數、命名、auto layout、註解、dev resources 的官方建議。
- Figma 開發者文件 — 避免大型 frame——症狀描述與
get_metadata解法。 - Figma 開發者文件 — 加入自訂規則——資產處理的三條規則。
- 忠實度分維度表是我的歸納，官方未提供任何量化指標，見 主張 vs 可佐證。