Claude Code /design 是什麼？從 UI 設計草稿到程式實作完整教學

Claude Code 現在不只會照著需求寫介面，還能在動手改程式前，先做出幾個 UI 設計方向讓你挑。

Anthropic 設計師 Nate Parrott 在 2026 年 8 月 18 日公布 Claude Code /design early preview。Early preview 是功能正式普及前的早期測試版本。使用者可在 Claude Code Desktop 或命令列介面（CLI）輸入 /design，讓 Claude 讀取現有專案，建立多個可編輯的設計畫板；選好方向並微調後，再叫它把設計寫進程式碼。Nate Parrott 的 /design release 貼文

先說結論：/design 最值得用在「需求大致確定，但版面方向還沒決定」的階段。 它把原本直接生成程式、看結果、再整頁重改的流程，改成先用多個視覺方案做決策。這能減少在錯誤方向上反覆改 code 的成本，尤其適合 PM、前端工程師、獨立開發者與會碰程式碼的設計師。

但它不是按一下就完成正式產品的工具。/design 仍是 early preview，官方也尚未公布完整開放範圍。產生的畫板要經過資訊層級、響應式版面、互動狀態、無障礙與工程可行性檢查，才能進入正式開發。

Claude Code /design 是什麼？

/design 是 Claude Code 裡的設計指令。它會建立一張可編輯的 design canvas，也就是讓多個介面方案並排呈現的設計畫布。

畫布裡的每個 artboard 可以翻成「設計畫板」，代表一個頁面或元件的視覺方案。你可以讓 Claude 一次產生三到四個方向，比較資訊密度、操作方式與視覺層級，再選擇其中一個繼續修改。

在官方 40 秒 demo 中，Claude 並沒有憑空畫一張漂亮頁面。它先查詢 Composer 的功能使用數據，再讀取現有的 ComposerActions.tsx，確認最常用的操作後，才建立四個重新設計方案。使用者接著挑選其中一個 artboard、複製並調整，最後要求 Claude 把選定版本實作到 Composer.tsx。Claude Code /design 官方示範影片

這個流程真正重要的地方，不是多了一個 AI 畫圖工具，而是設計探索與程式實作共用同一份專案脈絡。Claude 能先讀現有元件、文案與資料，再把選定方向直接帶回 codebase，不必只靠一張截圖重新猜一次結構。

/design 和直接叫 Claude Code 寫 UI 有什麼差別？

一般做法是直接輸入「幫我重做登入頁」，Claude Code 隨即修改程式。若第一版方向不對，使用者往往要在已經寫好的 code 上繼續堆修改，或整段推翻重做。

/design 則把「選方向」放在「寫 code」前面：

我的判斷是，/design 不該取代所有前端 Prompt。小型按鈕調整、已經有完整 Figma 稿，或只是修正一個 padding 時，直接改 code 比較快。它最有價值的情境，是一個功能有兩到四種合理排法，而團隊需要先看見差異再決定。

/design 和 Claude Design、Figma 一樣嗎？

名稱很接近，但三者不是同一個產品。

Claude Design 是 Anthropic 獨立的設計工作區，可在 web 或 Claude Desktop 建立互動原型、簡報、one-pager 等視覺內容。它提供對話、畫布直接編輯、元件留言、組織分享與檔案匯出，也能把完成的設計交給 Claude Code。Anthropic：Introducing Claude Design

Claude Code /design 的重點則是留在 coding session 裡，根據目前的專案產生設計方向，再接著修改程式。它比較像「寫 code 前的可視化探索步驟」，而不是另一套完整設計協作平台。

Figma 仍適合需要成熟元件庫、多人協作、設計審查與正式交付規範的團隊。/design 可以縮短 PM、設計與工程之間的來回，但不會自動補齊設計系統治理、使用者研究與跨頁流程。若公司已有 Figma 工作流，較實際的做法是把 /design 用在早期方案探索或工程端的小型變體，不必立刻更換唯一設計來源。

Claude Code /design 使用前準備

1. 確認 Claude Code 帳號與環境

Claude Code Desktop 需要 Claude Pro、Max、Team 或 Enterprise 訂閱。CLI 除了這些方案，也能使用 Claude Console 帳號按 API 用量計費；Claude Free 不包含 Claude Code。Claude Code 安裝與帳號說明

Desktop 適合不想處理終端機、需要同時查看檔案、程式差異與預覽畫面的人。CLI 是在終端機中操作 Claude Code 的文字介面，適合已經習慣開發指令的使用者。兩者使用相同的 Claude Code 核心，Desktop 另外提供圖形化檔案編輯器、diff 與 App preview。Claude Code Desktop 官方文件

2. 更新 Claude Code，再查看指令選單

在 Claude Code 輸入 /，系統會列出目前帳號可用的內建指令、Skill 與外掛指令。官方文件也提醒，部分指令會依平台或方案而不同。Claude Code Interactive mode

如果清單中找不到 /design，先重新啟動並確認軟體已更新。Native installer 會在背景更新；透過 Homebrew 安裝的 macOS 使用者可執行：

brew upgrade claude-code

若安裝的是 latest channel，則使用：

brew upgrade claude-code@latest

更新後仍沒有指令，代表帳號可能尚未取得 early preview。官方在 2026 年 8 月 19 日以前沒有公布所有帳號的開放時程，因此不需要反覆重裝，也不要另外安裝來路不明的同名 Plugin。

3. 選一個可以安全測試的前端專案

第一次不要拿結帳、會員權限或公司首頁全面改版測試。建議選一個範圍小、能預覽、也容易回復的頁面，例如空狀態、設定面板或內部工具表單。

開始前先建立 Git branch 或 commit。Git 是記錄程式碼版本的工具，這一步能讓你清楚比較 /design 實作前後的差異，也能在結果不合適時回到原本版本。

Claude Code /design 完整教學

步驟一：先把設計問題說清楚

不要只輸入：

/design redesign this page

這句話沒有說明使用者、主要任務、不能改的範圍與成功標準。Claude 可能做出視覺上不同，卻沒有解決產品問題的方案。

比較實用的 Prompt 是：

/design 為目前的批改結果頁提出 3 個桌機版方向。

使用者是需要在 30 秒內確認分數與主要問題的老師。
請先讀取現有頁面、共用元件與 design token，不要改變評分資料結構。

三個方向分別強調：
1. 分數與等級最優先。
2. 原文、批改與建議並排比較。
3. 適合逐題檢查的工作流程。

請保留目前品牌色與字體，避免新增現有元件庫沒有的控制項。
先只建立 artboards，不要修改 production code。

Design token 是記錄品牌顏色、字級、間距與圓角等介面規則的共用設定。第一次出現時就指定 Claude 讀取現有元件與 token，能降低每個方案各畫一套風格的機率。

步驟二：讓 Claude 先讀專案，再建立多個方向

官方 demo 顯示，/design 可以先查詢使用數據、讀取相關元件，再建立設計畫板。對實際專案來說，你可以明確指定 Claude 先看哪些資料：

建立 artboards 前，先閱讀：
- 目前頁面的元件與路由。
- 共用 Button、Tabs、Card 和 Modal。
- 最近 30 天最常使用的 3 個操作；沒有數據就直接說沒有，不要自行猜測。
- loading、empty、error 與 permission denied 狀態。

這一步會直接影響設計品質。如果沒有產品數據，也不需要為了模仿 demo 而虛構比例。改用客服問題、使用者訪談結論或已確認的 PM 優先順序即可。

步驟三：用同一套標準比較 artboards

不要只選第一眼最漂亮的版本。至少用以下五個問題檢查每個方向：

1. 使用者進入頁面後，第一眼看見的是不是最重要的資訊？
2. 主要操作是否清楚，還是所有按鈕都在搶注意力？
3. 是否沿用現有元件與品牌規則？
4. 資料變長、沒有資料或載入失敗時，版面是否仍成立？
5. 窄螢幕、鍵盤操作與對比需求要怎麼處理？

可以直接請 Claude 對自己的方案做一次結構化比較：

請比較這 3 個 artboards，不要再畫新版本。
用資訊層級、完成主要任務的步驟數、現有元件重用率、長內容風險與 mobile 適應性評分。
指出每個方向最可能失敗的情境，最後推薦一個，但保留由我決定。

這比問「哪一個最好」更可驗收。Claude 必須說明取捨，PM 與設計師也能檢查它的判斷是否符合實際需求。

步驟四：複製喜歡的版本，再做小範圍微調

官方影片顯示，使用者可以選取 artboard 裡的元素，調整背景、圓角、透明度與邊框等屬性，也能複製一個方向後建立自己的變體。

建議保留 Claude 的原始版本，再複製一份修改。這樣可以回答「改了之後是否真的更好」，也避免直接覆蓋後失去比較基準。

若要用文字修改，請一次處理一個明確問題：

以 B 方案建立 B2，不要影響其他 artboards。
把次要操作收進 More menu，保留最常用的兩個操作在第一層。
縮短標題區高度，但不要降低分數與狀態的辨識度。

步驟五：指定唯一版本，再要求實作

選定方向後，不要只說「implement it」。畫布上可能有多個版本，Claude 需要知道唯一目標與工程邊界。

實作 B2 artboard，只修改批改結果頁與必要的共用樣式。

要求：
- 優先重用現有元件，不新增重複 Button 或 Modal。
- 保留現有 API 與資料結構。
- 補齊 loading、empty、error 與 permission denied 狀態。
- 支援 390 px mobile 與 1440 px desktop。
- 保留鍵盤操作與可見 focus state。
- 完成後執行相關測試並開啟 preview。
- 回報修改檔案、沒有實作的設計細節與原因。

這一步把設計稿轉成可驗收的工程任務。若 Claude 因為現有架構限制而無法完全照做，應該回報差異，而不是默默換成另一種版面。

步驟六：檢查 diff、畫面與互動，不只看完成訊息

Diff 是程式修改前後的差異。Claude Code Desktop 可直接檢查 visual diff，也能啟動 App preview，讓 Claude 與使用者查看實際頁面。Claude Code Desktop preview 文件

最低限度要檢查：

• 修改範圍是否超出指定頁面。
• 是否重用原本元件，而不是建立外觀相同的副本。
• 主要操作、表單、導覽與返回路徑能否使用。
• loading、空資料、錯誤、超長文字與權限不足狀態。
• 390 px 與 1440 px 版面是否出現溢出或遮擋。
• 鍵盤 focus、文字對比與按鈕名稱是否清楚。
• 測試是否真的執行且通過。

/design 能把方向探索移到寫 code 之前，但最後仍要用實際 App 驗收。畫板看起來成立，不代表資料串接、互動與例外狀態都正確。

一個適合 PM 的 /design 工作流程

PM 不一定要自己調 CSS，仍可把 /design 當成需求澄清工具。最實際的流程是：

1. 先寫一段問題定義，說明使用者、任務、限制與成功條件。
2. 要求 Claude 讀取現有產品與元件，不先改 code。
3. 產生三個有明確差異的 artboards，不接受只換顏色的假選項。
4. 用同一份 UX 檢查表比較，記錄淘汰原因。
5. 把選定版本交給設計師或工程師 Review。
6. 只實作一個方向，完成 mobile、狀態與測試驗收。

這套方法比「請 AI 幫我畫三版」多了一個重要環節：每一版都要回答產品問題，而不是用視覺差異製造選擇感。對小團隊來說，它能快速做 MVP；對已有設計流程的團隊，它則適合作為進入正式設計前的探索工具。

Claude Code /design 目前有哪些限制？

1. Early preview 不等於所有人都能使用

官方 release 明確標示 early preview，完整 rollout 範圍與時程尚未公開。即使已付費並更新 Claude Code，指令也可能還沒出現在帳號裡。最可靠的判斷方式是打開 / 指令選單，而不是只看別人的版本號。

2. 官方完整 reference 還沒補齊

2026 年 8 月 19 日的 Claude Code 一般指令文件尚未列出 /design 的完整參數、配額與支援範圍。文章能確認的是官方貼文與 demo 展示的工作流，不應延伸宣稱它能匯出 Figma 原生檔、同步所有設計系統或支援所有程式框架。

3. 畫板不會自動處理所有產品狀態

AI 最容易畫出「資料剛好、文字剛好、網路正常」的理想畫面。正式產品還有空資料、長文字、權限不足、讀取失敗、mobile、鍵盤操作與不同語言。若 Prompt 沒有要求，這些情境很可能不會出現在首輪 artboard。

4. 它降低溝通成本，不會消除設計責任

Claude 可以提供方案，但誰是使用者、什麼資訊最重要、哪些錯誤不能發生，仍要由產品團隊決定。沒有清楚需求時，多產生四個版本只是把模糊問題放大四次。

我的立場是中性偏多。/design 對 UI 探索確實有實際價值，但判斷是否值得長期使用，不能只看首張畫板有多漂亮。真正該追蹤的是：同一個需求從開始到通過驗收花多少時間、需要幾輪修改，以及最後有多少 code 必須由工程師重寫。

Claude Code /design 常見問題

Claude Code /design 已經正式開放了嗎？

它已在 2026 年 8 月 18 日以 early preview 形式公布，但官方沒有宣布所有 Claude Code 使用者都已取得。請在 Desktop 或 CLI 輸入 / 查看自己的指令清單；找不到時，先更新並重新啟動，仍沒有就等待帳號開通。

/design 可以免費使用嗎？

Claude Code 本身不包含在 Claude Free。Desktop 需要 Pro、Max、Team 或 Enterprise；CLI 也可用 Claude Console 帳號依 API 用量付費。/design early preview 是否對所有付費方案採相同開放方式，官方尚未公布完整說明。

/design 會直接修改 production code 嗎？

官方示範先建立可編輯 artboards，直到使用者選定並要求 implement，Claude 才開始修改程式。Prompt 中仍建議明確寫「先只建立 artboards，不要修改 production code」，避免任務邊界不清楚。

/design 可以取代 Figma 嗎？

目前不適合這樣判斷。它擅長在 Claude Code 裡探索方案並接到程式實作；Figma 的成熟設計系統、多人協作、交付與治理能力仍更完整。小團隊可用 /design 快速做 MVP，大型團隊則比較適合把它當成前期探索或工程端變體工具。

已經有 Figma 設計稿，還需要 /design 嗎？

若設計稿已完整定義桌機、mobile、元件狀態與互動，直接讓 Claude Code 按稿實作通常更快。若只有主要頁面，還需要探索空狀態、工具列或資訊密度，才值得用 /design 補做方案。

一次應該產生幾個 artboards？

建議先做三個真正不同的方向。兩個選擇容易變成二選一，四個以上則會提高比較成本。每個方向應有不同的資訊架構或任務流程，不要只換顏色、圓角與陰影。

結論：先決定要蓋什麼，再讓 Claude Code 動工

Claude Code /design 解決的是 AI coding 很常見的順序問題：過去使用者常在還沒決定介面方向時，就讓 AI 開始寫 code；等看到結果不合適，才用更多 Prompt 修補。

現在可以先讓 Claude 讀現有專案，建立幾個 artboards，用 UX 與工程標準選出方向，再把唯一版本交回同一個 session 實作。這對 PM、設計師與前端工程師都更容易討論，也比較符合「先快速做 MVP，再依證據迭代」的工作方式。

如果帳號已經看到 /design，建議從一個非核心頁面開始，完整跑過「三個方向 → 選擇 → 微調 → 實作 → mobile 與狀態驗收」。它若能減少修改輪數與人工重寫量，就值得納入工作流；如果只是更快產生漂亮首稿，卻沒有改善最後交付，就仍然只是另一個 demo 工具。

資料來源

• Nate Parrott：Claude Code /design early preview release
• Anthropic：Introducing Claude Design by Anthropic Labs
• Claude Help Center：Get started with Claude Design
• Claude Code Docs：Advanced setup and update
• Claude Code Docs：Interactive mode
• Claude Code Docs：Use Claude Code Desktop
• Claude Code Docs：Desktop quickstart
• Claude Code Docs：Commands
• Claude Code Docs：Data usage