Google Stitch Skills 如何安裝：Stitch MCP、Codex、Claude Code 與設計工作流程配置

Sun, 12 Jul 2026 12:16:00 +0800

Google Stitch Skills 是一組針對 Stitch 的 Agent Skills 和插件，遵循 Agent Skills 開放標準，可與 Codex、Gemini CLI、Claude Code、Cursor 等 coding agent 一起使用。它不是單獨的「提示詞包」：官方明確要求先配置並執行 Stitch MCP，再讓這些技能存取相應的設計工作流程。官方倉庫

如果你已有 Codex Skills 工作流程，可以把它理解為一個更聚焦的設計插件集合：stitch-design 負責設計任務，stitch-build 面向建構與元件，stitch-utilities 提供輔助能力。

安裝前先做三項確認

已有可用的 Stitch MCP 設定、憑證和網路存取；
明確技能運行在使用者級、專案級或工作區級，避免把專案專用設計上下文裝到全域；
知道哪些設計、程式碼或截圖可以交給外部服務，哪些必須留在本地。

不要只安裝 Skills 後再檢查「為什麼沒有工具」。 Skills 負責指導 Agent 如何運作，真正提供 Stitch 能力的是 MCP server。

先在空白項目上驗證 Stitch MCP

先不要在主項目裡排查第一輪問題。建立一個臨時目錄或使用無敏感設計資料的測試項目，按 Stitch 文件完成 MCP 的認證和連接，再從客戶端檢查 MCP server 是否顯示為已連接。隨後讓 Agent 執行一個唯讀或只產生草案的任務，例如列出可用設計資源、基於範例元件產生一個不發布的頁面變體。

這一步的目標不是做出正式設計，而是把問題分層：看不到 MCP 工具時，檢查 server 指令、認證和網路；看得到工具但 Skill 沒生效時，檢查插件安裝範圍；能呼叫但結果不對時，才回到專案規則、輸入和權限。不要把三類問題混在一起用「重新安裝」解決。

確認測試環境可用後，再決定安裝位置。個人常用的通用技能可以放使用者等級；依賴特定元件庫、token 或設計規格的技能放專案等級；團隊分享工作區才考慮 workspace 等級。範圍越大，越需要審查是否包含內部連結、截圖或專有設計上下文。

Codex 安裝外掛程式市場

官方給出的 Codex CLI 安裝方式如下：

codex plugin marketplace add google-labs-code/stitch-skills --ref main \
  --sparse .agents/plugins \
  --sparse plugins/stitch-design \
  --sparse plugins/stitch-build \
  --sparse plugins/stitch-utilities

--sparse 用於只拉取所需路徑，減少首次 clone 的內容。註冊 marketplace 後，再按需安裝設計、建置或工具插件；不要預設把所有插件裝進每個專案。

Claude Code 與 Cursor 的官方範例是專案或工作區範圍安裝：

1
2

npx plugins add google-labs-code/stitch-skills --scope project --target claude-code
npx plugins add google-labs-code/stitch-skills --scope workspace --target cursor

安裝完成後關閉並重新開啟客戶端，確認插件清單中能看到對應條目。若指令執行成功但用戶端沒有載入，先檢查目前目錄是否正是專案根目錄、--scope 是否符合預期，以及團隊設定是否覆蓋了個人設定；不要透過手動複製隱藏目錄來繞過外掛程式管理員。這樣後續更新、卸載和依賴檢查仍有可追溯的入口。

選擇性安裝時別漏依賴

只需要少數技能時，可以使用：

`1`	`npx skills add google-labs-code/stitch-skills`

但官方提示 Stitch Design Skills 之間可能存在依賴。選擇性安裝後出現「技能能看見但執行失敗」時，先檢查它引用的依賴是否同時安裝，而不是重複安裝或手動複製目錄。

用最小插件集跑通一次設計任務

例如只要把現有 Dashboard 做成篩選頁時，先安裝 stitch-design 與它聲明的依賴，保留 stitch-build 只在確實要產生元件程式碼時再加。讓 Agent 先輸出設計草案和變更說明，不授予寫入倉庫或發布共享項目的權限。檢查草案能否重複使用現有導覽、顏色 token、表格欄位和元件命名；這些約束正確後，再讓它進入建置階段。

升級插件或 MCP 前也應在同一套測試任務上復跑。記錄客戶端版本、外掛程式版本、MCP 配置和測試輸入；一旦新版本改變了工具名稱或產生結果，就能快速回退，而不是在真實設計專案中臨時排障。

設計任務怎麼寫才可審查

不要向 Agent 只說「做一個更現代的首頁」。更穩的任務應給出輸入、允許的副作用和驗收標準：

基于现有 Dashboard 组件创建一个新的筛选页草案。
只生成设计变体，不修改仓库代码，不发布到共享项目。
保留现有颜色 token、导航和表格字段。
输出两个变体，并说明每个变体改变了哪些组件和交互状态。

這能避免設計工具越過「生成草案」直接進入「改生產代碼」或「覆蓋共享設計」的範圍。

交付前的實際檢查清單

在一次設計任務結束時，要求 Agent 給予而不是只在對話中暗示：使用了哪些 Skill 和 MCP 工具、讀取了哪些設計資源、產生或修改了哪些頁面、哪些動作尚未執行。人工再核對共享項目是否沒有意外發布，關鍵組件是否仍沿用已有 token，截圖中是否包含不該外傳的業務資料。

若任務需要落到代碼倉庫，將「設計草案完成」和「代碼改變完成」拆成兩個提交或兩個審核點。前者允許探索，後者必須走現有測試、程式碼審查和發布流程。這樣 Stitch Skills 既能幫助 Agent 理解設計工作流程，也不會模糊設計工具與生產變更之間的責任邊界。

常見問題

現象	優先檢查
Skill 已安裝但沒有 Stitch 工具	Stitch MCP 是否已設定、運作並完成認證
安裝後只在某項目可見	檢查 `--scope project` 或 workspace 作用域是否符合預期
選擇性安裝後缺少能力	查看相關 Skill 的依賴，不要只複製單一目錄
設計結果不符合品牌	將 token、元件庫、停用操作和截圖驗收寫入專案規則

小結

Stitch Skills 的正確順序是：先有可用的 Stitch MCP，再按項目需要選擇插件或技能，最後用清晰的設計輸入和驗收標準約束 Agent。安裝成功只是開始；作用域、依賴和設計資料邊界決定它是否能在團隊流程中穩定使用。

Google Stitch on KnightLi的博客