一張 settings page 的 wireframe，從零到互動 prototype，花了多少時間？

如果你用 Figma，大概半天。如果你先開 Figma 再開 Slack 跟 PM 對齊需求，加上來回三輪修改，一天。如果你是後端工程師被臨時抓去做 internal tool 的 UI，那個時間乘以三，因為你要先搞懂 Figma 怎麼用。

Claude Design 的答案：一段對話。

4 月 17 日，Anthropic Labs 推出 Claude Design，目前是 research preview 狀態。底層用的是 Claude Opus 4.7。功能一句話：你用文字描述你要什麼，它生成可互動的視覺稿，你透過對話修改，改到滿意後可以匯出成 PDF、PPTX、HTML，或者直接交接給 Claude Code 實作。

這不是「AI 生成圖片」那個路線。不是 Midjourney 不是 DALL·E。這更像是一個聽得懂人話的 Figma，但你永遠不用碰它的工具列。

第一步：理解 Claude Design 在做什麼

在打開 Claude Design 之前，先理解它的定位。

想像你找了一個很厲害的實習生。你跟他說：「幫我做一個 SaaS 產品的設定頁面，左邊 sidebar 放導覽，右邊放帳號、帳單、通知、整合四個區塊，每個區塊可以展開收合。」實習生聽完就開始畫，畫完拿給你看。你說「通知那個區塊要再加一個 toggle」，他馬上改。

Claude Design 就是這個實習生，但速度快大概一百倍，而且不用吃飯。

它能做的事：prototype（互動式原型）、slide deck（簡報）、one-pager（單頁文件）、信件模板、landing page。它不能做的事：高保真視覺設計（像素級的精修）、品牌識別設計（logo 那些）、複雜動畫。

誰可以用

Claude Design 目前開放給 Pro、Max、Team、Enterprise 四種訂閱方案。用量從你現有的訂閱額度扣，不需要額外付費。

進入方式：在 Claude 的對話介面裡選擇「Claude Design」模式，或者直接在對話中描述你要設計的東西——Claude 會自動判斷是否切換到 Design 模式。

核心操作流程

用 prompt 啟動設計

最直覺的用法：用文字描述你要什麼。

做 prototype 的 prompt 範例：

「設計一個新用戶 onboarding 流程，五個畫面：第一步連結資料來源、第二步設定第一個 dashboard、第三步邀請隊友、第四步選擇通知偏好、第五步完成畫面。每個步驟之間要有進度條。」

做簡報的 prompt 範例：

「做一份 10 頁的季度業務回顧簡報，包含：封面、目錄、Q1 營收概覽、用戶成長數據、產品更新時間軸、競品比較、Q2 計劃、團隊擴張、風險清單、結語。風格要乾淨專業，用深藍配白底。」

做 internal tool 的 prompt 範例：

「設計一個 admin panel，功能包括：可搜尋的用戶帳號表格，支援按方案類型和帳號狀態篩選。點擊用戶後右側彈出詳情面板，顯示帳號歷史紀錄和權限設定。」

Claude 會根據你的描述生成第一版。不用期待第一版就完美——重點是「快速拿到一個可以開始討論的東西」。

用對話迭代

第一版出來之後，你可以直接在對話裡修改。

「sidebar 的寬度再窄一點，大概 240px。」
「把通知設定那個區塊移到最上面，因為新用戶最常改的就是這個。」
「再做一個深色模式的版本讓我比較。」

Claude Design 的迭代速度幾乎是即時的。你說完，它就改。這跟傳統設計工具最大的差異不是「功能多不多」，是「feedback loop 有多短」。從「我想到一個修改」到「看到修改後的結果」，整個循環壓縮到幾秒鐘。

你也可以一次要求多個版本比較：

「給我三種不同的 user profile 頁面 layout：一個用卡片式、一個用左側 sidebar、一個用頂部 tab 導覽。」

這在設計評審的時候特別好用——不用事先花半天做三個版本，直接讓 Claude 生成，當場決定方向。

串接 Codebase：這才是真正強的地方

如果你只是用 Claude Design 做 generic prototype，它就是一個好用的原型工具。但一旦你把 codebase 串進去，它就變成另一個東西了。

為什麼這件事很重要

沒有串 codebase 的情況：Claude 會用它自己的 component 風格生成 prototype。看起來不錯，但拿給工程師看，第一句話通常是「我們沒有這個 component」。Prototype 和實際產品之間有一道鴻溝，每次交接都要重新翻譯。

串了 codebase 之後：Claude 看得到你的 component library。它會用你現有的 button、card、modal、layout 來設計。顏色用你的色彩系統，間距用你的 spacing scale，字體用你的 typography 設定。生成出來的 prototype 跟你的產品長得幾乎一樣，因為它用的就是同一組積木。

怎麼串

Claude Design 支援兩種方式連接 codebase：GitHub import 和本地目錄 attach。都從介面上的 Import 按鈕進去。

連接之後，你的 codebase 就變成 project context 的一部分。你可以在 prompt 裡直接引用 component 名稱——「用 ProductCard component」或「照 settings page 的 layout pattern」。

Claude 從你的 code 裡讀取什麼？四個層面：component 結構（你的 UI building blocks 和它們怎麼組合）、styling 和 theming（色彩系統、spacing scale、typography、CSS 方法論）、framework patterns（state management、hooks、data flow）、檔案組織方式（component 命名和目錄結構）。

注意事項

大型 monorepo 可能會讓瀏覽器卡頓。如果你的 repo 超過 100 人在貢獻，建議只 attach 相關的 package 或 component 目錄，不要整包丟進去。特別要避免把 .git 目錄和 node_modules/ 一起 attach——檔案數量太大，Chrome 會吃不消。

交接給 Claude Code：從 Prototype 到 Production

這是整個流程裡最有價值的一步。

設計做完了，通常接下來的劇本是：設計師把 Figma 連結丟給工程師，工程師打開看，然後問十個問題——「這個間距是多少」「這個顏色色碼是什麼」「loading state 長什麼樣」「空的時候要顯示什麼」。一來一往又是半天。

Claude Design 的做法：點 Export，選 Hand off to Claude Code。它會把設計檔案、整段對話紀錄（包含你做了哪些設計決策和為什麼）、一份 README 打包成一個 bundle。你會拿到一段 prompt，貼到 Claude Code 裡就能開始實作。

如果你的 codebase 已經串接了，交接效果更好——因為 Claude Code 本來就知道 prototype 用了哪些 component 和 pattern，不需要重新猜。

讓交接更乾淨的技巧

第一，在 prototype 裡把東西命名清楚。如果你在設計對話中叫一個 component「UserCard」，那個名字會一路帶到交接文件裡。工程師打開就知道對應哪個 component。

第二，在對話裡記錄設計決策。當你做了一個選擇（「用 tab 不用 sidebar，因為用戶需要一次看到所有 section」），這段推理會變成實作的 context。工程師不只知道「做什麼」，還知道「為什麼這樣做」。

第三，交接前讓 Claude 把 edge case 都跑一遍。問它：「這個設計在空狀態、錯誤狀態、loading 狀態、資料量很大的時候各長什麼樣？」這會讓工程師拿到一張更完整的 spec。

跟其他工具的差異

Claude Design 最容易被拿來跟 Figma 和 Canva 比。但這三個工具解決的問題其實不太一樣。

Figma 是給專業設計師用的——precision 工具、pixel-level 控制、完整的 design system 管理。Claude Design 不會取代 Figma。如果你需要做最終的高保真視覺稿，Figma 還是答案。

Canva 是給非設計師用的——模板導向、拖拉操作、快速產出行銷素材。Claude Design 跟 Canva 的目標群體有重疊（都服務非設計師），但方法不同——Canva 給你模板讓你填，Claude Design 讓你用文字描述、它來生成。

Claude Design 真正的定位是「設計過程中的前 80%」——從 idea 到「可以討論的 prototype」。剩下的 20%（高保真精修、品牌一致性的最後 polish）還是需要專業設計工具或設計師。

如果你是 PM 需要在會議前兩小時做出 prototype、或是工程師被要求「先做個 mockup 出來看看」，Claude Design 的價值最明確。它不是讓設計師失業的工具，是讓非設計師也能快速產出「足夠好」的視覺溝通素材。

學完這個接著學什麼

如果你已經上手 Claude Design，下一步可以往兩個方向走。

第一個方向是 Claude Code 的深度整合。Claude Design 的交接功能配合 Claude Code 的 codebase 感知能力，可以把「設計 → 實作」的循環壓到極短。值得去看 Claude Code 的 Sub-agents 和 Hooks 機制——它們讓你可以自動化更多交接後的步驟。

第二個方向是 Design System 的建立。如果你的團隊還沒有正式的 design system，Claude Design 串接 codebase 的過程其實會逼你整理 component library。這是一個很好的契機去建立統一的設計語言——不只是為了 Claude Design，是為了整個團隊的效率。

兩條線：一條是工具能力的延伸（Claude Design → Claude Code → 自動化流程），另一條是組織能力的延伸（prototype → design system → 團隊設計規範）。選哪條取決於你現在的角色——如果你是工程師，走第一條；如果你是 PM 或設計 lead，兩條都走。

原文來源：Using Claude Design for prototypes and UX - Claude Tutorials
原文來源：Introducing Claude Design by Anthropic Labs
參考來源：Anthropic launches Claude Design - TechCrunch