規則檔是把「每次都要重複講的話」固化下來的機制。官方對它的定義很精準：custom rules 捕捉的是那些資深開發者會口頭教新人的不成文慣例——該用哪些版面元件、元件檔案放哪裡、怎麼命名、什麼東西絕對不能硬編碼。把這些寫下來能減少重複提示，並讓人類與 agent 的貢獻維持一致。
接上 MCP 只是第一步。真正決定日常產出品質的是規則檔、skills，以及 agent 手上還有哪些其他工具。
📖 用 create_design_system_rules 起手
官方提供一個 MCP prompt：create_design_system_rules，無參數。它會依你的 codebase 產生一份規則檔草稿，省去從零寫起。
這是起點而非終點。 它產出的是對 codebase 的描述，你還要補上它推不出來的團隊約定——哪些元件已淘汰、哪些寫法被禁止、無障礙的底線在哪。
檔案放哪裡視 client 而定，官方給了兩個例子：
| Client | 位置 |
|---|---|
| Cursor | 專案的 .cursor/rules 資料夾 |
| Claude Code | CLAUDE.md |
📖 規則檔該寫什麼
官方把內容分成三類。這個分類本身就是有用的檢查表：
一、通用規則
- 使用既有的設計系統元件
- 緊密貼合 Figma
- 使用 design token 而非硬編碼值
- 符合無障礙要求
- 為元件撰寫文件
- UI 元件放在指定資料夾
二、工作流規則（讓產出一致）
固定的 MCP 工具使用順序：
- 實作前先取得設計脈絡
- 回應過大時改用 metadata
- 拉一張截圖當參考
- 最後對照 Figma 驗證
第二類是最容易被省略、但效果最直接的一類。 它把 流程一 的步驟變成 agent 每次都會執行的事，而不是依賴使用者記得在提示裡講。「先 metadata 再 context」這一條尤其值得寫死——它同時解決選取過大與呼叫次數兩個問題。
三、資產規則
官方的範例規則檔（Cursor 風格）大意如下：
description: Figma MCP server rules
globs:
alwaysApply: true
- Figma MCP server 會從 assets endpoint 提供圖片與 SVG。
- 若回傳 localhost 來源，直接照用。
- 不要加入 icon 套件；所有 icon 都應來自 Figma payload。
- 已有 localhost 來源時，不要建立 placeholder。
這三條之所以必須明寫，是因為 agent 的預設傾向與它們相反——它習慣裝一個 icon 套件、或在不確定時放 placeholder。這類「反直覺的否定規則」是規則檔最有價值的內容，遠比正面描述有效。
標準規則檔的建議內容
官方另外建議：可以請 agent 分析 codebase，記錄其 token 定義、元件庫、框架、資產處理方式、icon 系統、樣式方案與專案結構，並附上檔案路徑與程式碼片段。
「附上檔案路徑與程式碼片段」這一條是關鍵。 抽象描述（「我們用 Tailwind」）遠不如具體指向（「token 定義在 src/styles/tokens.css，用法見 src/components/ui/Button.tsx」）有效。
📖 Skills
Figma 提供的 skills：figma-use（Design）、figma-use-figjam、figma-use-slides、figma-spec（open beta）、figma-generative-plugins、figma-shaders、figma-code-connect。
官方講得很直白：「Skills don’t replace the MCP connection or add new capabilities.」 它們是把正確用法包裝成 agent 可讀的指示——作用是提升可靠度，特別是寫入工具。
這也是官方建議用 plugin 安裝的理由：plugin 會一併帶進 skills，手動加 server 不會。見 啟用與連接。
📖 規則檔、Code Connect 自訂指示、skills 的分工
三者都是「給 agent 的指示」，但作用範圍不同，放錯地方會失效：
| 機制 | 範圍 | 適合放什麼 |
|---|---|---|
| Skills | 工具的正確用法 | Figma 官方維護，你不必自己寫 |
| 規則檔 | 整個專案 | 框架、檔案結構、命名、工作流順序、資產處理 |
| Code Connect 自訂指示 | 單一元件 | 該元件的 prop 慣例、無障礙要求、不要用的寫法 |
最常見的錯置是把元件層級的規則寫進規則檔。 「Button 的 icon-only 版本必須給
aria-label」寫在CLAUDE.md裡會被淹沒在一堆通用規則中；寫在該元件的 Code Connect 自訂指示裡，它會在每次用到這個元件時被送進脈絡——貼近使用現場，命中率高得多。一條判斷準則：規則適用於所有元件就寫規則檔，只適用於某一個元件就寫 Code Connect。
📖 其他值得一起接的 MCP
Figma MCP 只提供設計脈絡。一條完整的前端工作流通常還需要另外三類資訊，而它們各自有對應的 MCP server：
程式碼庫脈絡。 agent 需要看得到既有元件、token 定義與專案結構。多數編碼 agent 內建檔案存取，但大型 repo 需要搜尋或索引類的工具才找得到東西。
瀏覽器與執行時驗證。 生成之後要確認它在真實瀏覽器裡長什麼樣、有沒有 console 錯誤、響應式斷點對不對。這補上了 Figma MCP 完全看不到的一塊——get_screenshot 給的是 Figma 裡的樣子，不是你程式碼跑出來的樣子。
這兩張截圖的比對，是忠實度驗證最直接的做法：Figma 的設計截圖 vs 瀏覽器的實作截圖。Figma MCP 只能提供前者，後者需要瀏覽器類工具。
issue 與規格。 設計之外的需求脈絡——驗收條件、邊界情況、為什麼要這樣做。Figma 的註解與 dev resources 補了一部分（官方建議把文件、程式碼、ticket 掛到圖層上），但完整的規格通常在別處。見 Problem Framing ＋ Spec-Driven Development。
接 MCP 有成本。 每一個 server 都會佔用 agent 的工具清單與脈絡空間，工具太多反而會讓 agent 挑錯——官方自己就承認 agent 會挑錯工具。從 Figma MCP 加一個瀏覽器工具開始，不要一次全接。
🧠 重點整理
規則檔捕捉的是「資深開發者會口頭教新人」的不成文慣例。
用 create_design_system_rules 起手，但要補上它推不出來的團隊約定。
官方把規則分三類：通用、工作流、資產。工作流那類最常被省略卻最直接有效。
「先 metadata 再 context」值得寫死——同時解決選取過大與呼叫次數。
反直覺的否定規則最有價值（不要加 icon 套件、不要放 placeholder），因為 agent 的預設傾向相反。
規則要附檔案路徑與程式碼片段，抽象描述效果差得多。
skills 不新增能力，只提升可靠度，用 plugin 安裝才會帶進來。
規則適用所有元件就寫規則檔，只適用某一個就寫 Code Connect 自訂指示。
瀏覽器工具補上 Figma MCP 看不到的一塊——實作跑出來的樣子。
不要一次接太多 MCP，工具太多會讓 agent 挑錯。
✍️ 動手做
建立第一版規則檔並驗證它真的有效，約 40 分鐘：
- 執行
create_design_system_rules，把產出存成規則檔。 - 讀一遍，補上三條它不可能知道的團隊約定——例如某個元件已淘汰、某種寫法被禁止。
- 加入官方的四條工作流規則（先脈絡、過大用 metadata、拉截圖、對照驗證）。
- 加入三條資產規則。
- 測試否定規則是否生效：故意選一個含 icon 的設計，看 agent 會不會去裝 icon 套件。
第 5 步是真正的驗證。否定規則最容易寫了卻沒被遵守——而且因為它是「沒有發生的事」，不主動測就不會發現。測過一次，你就知道這個規則檔的指示力道有多強。
🔗 資料來源
- Figma 開發者文件 — 加入自訂規則——custom rules 定義、
create_design_system_rules、檔案位置、三類內容、範例規則檔、標準規則檔建議（一手，2026-11-01 查證）。 - Figma 開發者文件 — 工具與提示——skills 清單與 prompt。
- Figma Help Center — Guide to the Figma MCP server——「Skills don’t replace the MCP connection or add new capabilities」。
- Figma 開發者文件 — Code Connect 整合——自訂指示會進入脈絡。
- Figma 開發者文件 — 組織 Figma 檔案——dev resources。
- 三種指示機制的分工表、其他 MCP 的搭配建議是我的歸納，非官方建議。