20
26
2026
產品設計師的 AI 協作工作流程指南
當 AI 進入設計流程，設計師的判斷從未這麼重要。 從工具選型到三平台交付，建立系統性的 AI 設計工作方法。
產品設計師面對 AI 工具的第一個問題往往是：「這些工具是要取代我嗎？」這個問題問錯了方向。 更準確的問題是：「當 AI 接管了執行工作，我的不可取代性在哪裡？」
AI 工具擅長「量的擴大」——更多探索方向、更快彙整資料、更快生成骨架程式碼。 但設計師最核心的價值——為什麼用戶行為如此、洞察背後的文化脈絡、判斷哪個方向是對的—— 始終是人的工作。
「AI 工具讓執行的成本趨近於零，但也因此讓判斷力成為唯一稀缺的資源。」
Claude Design 可以在 30 分鐘內生成 5 個方向的互動原型，Figma Make 讓你不離開 Figma 就完成 UX 流程驗證， Google Stitch 免費生成多螢幕高保真 UI——但這三個工具都不知道你的用戶是誰、 你的品牌試圖傳遞什麼情緒、這個功能在整個產品旅程中的位置。那些判斷，是你的。
設計師在 AI 工具選型上最常犯的錯誤，是把功能相似的工具當成可以互換的選項。 事實上，每個工具解決的是完全不同的問題——混用它們不會讓你更快，只會讓你在錯的節點用錯的工具。
在這個工具鏈裡，有一個最根本的分類方式：視覺探索工具和流程文件工具 是兩類完全不同的東西。把流程文件工具當成視覺探索工具的替代品，就像問「可以用 Excel 取代 Photoshop 嗎」—— 它們根本不在同一個工作節點上競爭。視覺探索工具之間，則是依照「誰主導」和「在哪裡工作」來選擇，而不是互相取代。
Claude Design
設計探索加速器 · Opus 4.7 · 設計師主導
2026 年 4 月 17 日正式推出。對話式生成互動 HTML 原型，讀取你的 DESIGN.md 和 codebase 確保品牌一致性。30 分鐘內可以生成 3–5 個可點擊的方向供三方評選。最重要的能力是 Handoff Bundle——一鍵把探索結果交付給 Claude Code。
Figma Make
Figma 生態系 · 留在 Figma 內探索
直接在 Figma 內用 prompt、圖片或現有設計稿生成 Web App Prototype，生成時可讀取現有 Figma 設計系統的 component 作為參考。三條移植路徑：Copy design（截圖重建）/ html.to.design / MCP Write to Canvas（圖層品質最高）。最大優勢是不需切換工具；限制是移植後圖層與 Make 檔案斷開，設計系統 Variables 需手動替換。
Claude Code
工程師主導的設計探索 · CLI
生活在終端機。探索即程式碼——原型就是真實元件，不需要翻譯步驟。根本差異：Claude Code 改變的是「誰主導探索」（工程師），而非「探索效率」。搭配 Figma MCP 可以雙向同步：Code → Figma 和 Figma → Code，但設計師技術門檻高，需工程師支援。
Google Stitch
免費 AI UI 生成 · Google Labs
文字/圖片/語音 → 高保真 UI，多螢幕同步生成，直接 Export to Figma（帶 Auto Layout）。支援 7 種框架輸出：HTML / CSS / Tailwind / Vue / Angular / Flutter / SwiftUI。完全免費（350 次/月）。穩定性風險：Google Labs 實驗性產品，建議作為 Claude Design 的備援而非完全替換。
Claude Cowork
流程文件工具 · 非視覺生成 · 貫穿全開發週期
本質是結構化文件工具，負責 Spec 補充文件、QA Checklist 自動生成、Change log 維護、DESIGN.md 管理——不是視覺探索工具，無法取代上方四個工具中的任何一個。用 Cowork 取代 Claude Design，等於移除了整個設計探索能力。Cowork 的工作在探索工具的「下游」，與探索工具是串聯關係而非替代關係。
工具選型原則
視覺探索工具之間依場景互補，而非互相取代：Claude Design 用於大量視覺發散（設計師主導）；Figma Make 用於在 Figma 內驗證 UX 流程（已有方向時）；Claude Code 用於技術可行性驗證（工程師主導）；Google Stitch 作為免費備援選項。Claude Cowork 在所有情境下負責文件流程，不受探索工具替換影響。
三種視覺探索工具的使用場景
| 工具 | 最適合的情境 | Figma 移植路徑 | 平台支援 |
|---|---|---|---|
| Claude Design | 大量視覺發散・30 分鐘 3–5 方向・設計師主導 | html.to.design / Anima → 需清理 hardcode | Web-first；移植後搭配 Visual Copilot 用於 iOS/Android |
| Figma Make | 已有方向、在 Figma 內驗證 UX 流程・不切換工具 | Copy design / html.to.design / MCP Write to Canvas（品質最高） | Web App（瀏覽器運行）；Native 需另外處理 |
| Google Stitch | 多螢幕同步生成・免費備援・快速高保真原型 | Export to Figma（帶 Auto Layout），品質不錯 | 可輸出 SwiftUI / Flutter；Google Labs 穩定性待觀察 |
各工具對 Web 和 App 的適用性差異
Claude Design、Figma Make、Google Stitch 這三個視覺探索工具，本質上都是 Web-first 的輸出。 html.to.design、Anima Agent、Figma-Console-MCP 這些「移植工具」輸出的都是 HTML/CSS/React 框架的程式碼。 你不能把這些工具的輸出直接用在 native iOS（SwiftUI）或 native Android（Jetpack Compose）的開發上。 唯一例外是 Google Stitch，它支援 SwiftUI 和 Flutter 框架輸出，但仍需要工程師整合進 native 專案。
最常見的錯誤路徑
設計師用 html.to.design 或 Anima 把 App 設計稿「轉成程式碼」，然後工程師試圖在 iOS/Android 上使用這些 HTML/React 程式碼。這條路行不通。App Store 也會因為「重新包裝的網站」拒絕這類提交。
| 平台 | 程式碼生成工具 | 設計系統連結 | 說明 |
|---|---|---|---|
| Web | Figma Dev Mode + Code Connect | React / Vue | 最完整，三工具天然支援 |
| iOS | Visual Copilot + Code Connect | SwiftUI | 需額外設定 SwiftUI label |
| Android | Visual Copilot + Code Connect | Jetpack Compose | 需額外設定 Compose label |
產品設計不是一個線性過程，但每個階段確實有不同的核心任務和最適合的工具組合。 理解「這個階段我在解決什麼問題」，比了解「這個工具有什麼功能」更重要。
FIG.01 · 三平台共用的前段工作流程
↓ Kickoff 後，Web / iOS / Android 進入各自的 Native 開發分支
Research — 研究與洞察
核心任務：把混亂的資料轉化為可驅動設計決策的結構化知識。 主要工具：Claude Cowork。建立 Research Project，把競品截圖、訪談逐字稿、數據報告一起餵進去。 補充：html.to.design 截取競品頁面直接帶入 Figma 做視覺對比。
設計探索 — Design Exploration
AI 工具影響最深遠的階段。傳統上一週 2–3 個設計方向；現在 30 分鐘可以生成 5 個可點擊互動原型供三方評選。 三種工具對應三種探索情境，依照當下的需求選擇最適合的路徑：
Claude Design——大量視覺發散的首選。讀取 DESIGN.md 和 codebase 確保品牌一致性，30 分鐘產出 3–5 個方向，Handoff Bundle 直接交付 Claude Code。適合「還不確定往哪個方向走」的早期探索。
Figma Make——已有設計方向、需要在 Figma 內驗證 UX 流程時使用。最大優勢是不需要切換工具，可以讀取現有設計系統的 component 作為生成參考。移植路徑：Copy design（快速）/ html.to.design（較乾淨）/ MCP Write to Canvas（圖層品質最高）。限制：移植後圖層與 Make 檔案斷開，Variables 需手動替換，每月 Standard 配額 350 次需監控。
Google Stitch——免費備援選項。文字/圖片/語音直接生成高保真 UI，多螢幕同步生成，Export to Figma 帶 Auto Layout。Google Labs 實驗性產品，穩定性不保證，建議作為 Claude Design 的備援而非主力。
無論使用哪個工具，工程師必須在這個階段參與，讓他們對「為什麼選這個方向」有第一手理解——這是後續降低設計工程溝通往返的最重要前期投資。
產品開發 — Development
核心問題：如何確保設計意圖在工程實作中不流失？ 工程師不應透過截圖或口頭說明理解設計規格——Dev Mode 提供精確數值、版本 diff、以及搭配 Code Connect 後的真實元件使用範例。 Dev Mode 的輸出品質，100% 取決於設計師的 Figma 建檔品質。
產品維護 — Maintenance
最容易出現「設計漂移（design drift）」——工程師緊急修復時調整了 UI 但沒有更新 Figma。 修改的黃金順序：先 Cowork change log → 再更新 Figma → 再通知 iOS / Android / Web 三個平台工程師分別確認影響範圍。 「靜默覆蓋」是設計工程信任關係最常見的破壞點。
三方評選的關鍵原則
方向評選必須讓 PM + 設計師 + 工程師三方都在場，不能只是設計師和 PM 決定。工程師在探索階段的參與，讓他們對「為什麼是這個設計」有第一手理解，是後續降低設計工程溝通往返的最重要前期投資。
這六條原則是從大量設計工程摩擦點中反推出來的。它們不是關於 AI 工具怎麼用， 而是關於「如何讓整個設計→開發流程不在某個節點崩潰」。每一條都有對應的真實痛點。
Figma 建檔品質是工程效率的天花板
所有 component 使用 Variables + Auto Layout。iOS 用 4pt 格線，Android 用 8dp 格線。Dev Mode 的輸出品質 100% 取決於設計師的建檔品質——AI 工具無法修補建檔問題，這個問題只存在於設計師的工作紀律中。
Spec 必須包含「是什麼」和「為什麼」
Dev Mode 呈現視覺規格（是什麼），Cowork 補充文件說明設計意圖、手勢行為、Edge case 清單（為什麼）。Out of scope 清單和 in scope 清單同等重要——工程師遇到設計稿沒有覆蓋的情境，如果沒有明確的 out of scope，往往自行實作或等待確認，兩者都是成本。
設計修改禁止靜默覆蓋，先記錄再改
順序：Cowork change log → 更新 Figma → 通知 iOS / Android / Web 工程師分別確認。靜默覆蓋是設計工程信任關係最常見的破壞點。iOS 格線是 4pt，Android 是 8dp，同一個間距的修改對兩個平台的影響可能完全不同。
所有設計溝通集中在 Figma comment
禁止用 Slack、Line 或口頭說明來溝通設計細節。Figma comment 讓決策與圖層連結，後來接手的人也能追溯。口頭說的不算，comment 才算。 Dev Mode 的 comment 回覆有時間戳記，是設計工程溝通歷史的可追溯記錄。
DESIGN.md 是三平台的品牌承諾書
Web CSS token、iOS pt 規格、Android dp 規格統一維護在 DESIGN.md，每次 Variables 更新後 24 小時內同步。Claude Design 每次啟動前讀取最新版本確保品牌合規；Figma Make 直接讀取 Figma 設計系統的 Variables 和 component；Google Stitch 透過 DESIGN.md 文字描述輸入品牌規範。三個工具的品牌感知程度不同，但都需要這份文件作為起點。這份文件是整個 AI 工具鏈的知識基底，不是設計師的私人筆記。
驗收標準在 Kickoff 定義，不在 Review 爭論
P0/P1/P2 問題分類，加上可接受偏差範圍（Web: ±2px，iOS: ±1pt，Android: ±2dp），在 Kickoff 前對齊並記錄在 Spec 文件中。這不是降低品質要求，而是讓設計師和工程師對「什麼是必須修的、什麼可以累積到下個 sprint」有共同語言。
Checklist 的目的不是行政程序——每一個項目都在防止某一種具體的返工。 標記「必要」的項目是根本性問題，一旦漏掉會造成大量工程修改； 未標記的是理想狀態，可以在時程壓力下累積到下個 sprint。
Web 設計師交付 Checklist
iOS 設計師交付 Checklist（Native 專屬規格）
iOS 與 Web 的根本差異
iOS 設計稿的單位是 pt（點），不是 px。Variables 需要以 iOS 語意色彩命名（label、systemBackground、secondaryLabel），不是直接用 hex。這些不是風格選擇，是 Code Connect 輸出正確 SwiftUI 程式碼的前提。
Android 設計師交付 Checklist（Native 專屬規格）
Android 與 iOS 的關鍵差異
Android 使用 dp（density-independent pixels），格線是 8dp。字型用 sp（支援使用者無障礙字型縮放）。Material 3 的色彩系統採用語意色彩，需要在 Figma Variables 完整對應 MaterialTheme。還需要考慮 Foldable 裝置（如 Galaxy Z Fold）的展開/折疊兩種佈局。
不要試圖一次導入所有工具和流程。從一個最小可行的改變開始， 完成一次完整的循環，比規劃一個完美的系統然後擱置更有價值。
更新 DESIGN.md：加入三平台規格區塊
把現有 Web CSS token 對照表擴充，加入 iOS pt 規格和 Android dp 規格。30 分鐘完成。這份文件是整個 AI 工具鏈的共識基礎——Claude Design 每次啟動時讀取它確保品牌合規；Google Stitch 透過它感知品牌規範；Figma Make 則直接讀取 Figma 設計系統，但 DESIGN.md 仍是跨工具的唯一規格來源。誰做：設計師
試跑一次 Figma Make：從現有設計稿生成 Prototype
打開一個已有設計方向的 Figma 檔案，用 Figma Make 輸入 prompt 或截圖直接在 Figma 內生成 Web App Prototype。觀察它是否正確讀取你的設計系統 component。這一步是在驗證你的設計系統「是否已達到 AI 可用的成熟度」。之後再試 Anima Agent 做比較——兩者移植品質不同，適合不同場景。誰做：設計師
選一個小功能，走完 Web Checklist 一輪
不要一次導入所有工具。選一個 1–2 個畫面的小功能，從 Phase A 走到 Phase E 的 Checklist，感受每個步驟的工作節奏。這次試跑的本身就是最好的培訓。誰做：設計師 + PM
與工程師確認 Code Connect 評估計畫
Web：React/Vue Code Connect 評估。iOS：SwiftUI Code Connect 評估（需 Org/Enterprise 方案）。Android：Jetpack Compose 評估。估算設定時間成本（約 1–2 週/平台），這是一次性投資但效益永久。誰做：工程師
設定 P0/P1/P2 驗收標準，下次 Kickoff 前對齊
Web: spacing ±2px 可接受，token 錯誤不可接受。iOS: ±1pt 可接受，touch target 不符不可接受。Android: ±2dp 可接受，Safe area 遮擋不可接受。誰做：設計師 + 工程師
「Claude Design、Figma Make、Google Stitch 讓設計探索從 30 小時壓縮到 30 分鐘，但讓這 30 分鐘有價值的，始終是設計師對問題的理解深度。工具改變的是執行速度，不可取代的是你的設計判斷力。」