AI 設計協作的雙模式工作流程
建立 tokens.css、components.css 和設計規格 MD 之後，你擁有了一套精準執行的基礎——但這只是工作流程的一半。這篇文章說明如何加入探索模式，讓 AI 從執行者變成設計思考夥伴，以及如何在兩種模式之間切換，打造可掌控品質、同時保留創意空間的完整設計工作流程。
如果你已閱讀完上一篇文章，你現在應該有： tokens.css（顏色語意）、components.css（元件骨架）、CLAUDE.md（AI 協作規則）、設計規格 MD（設計意圖）。 這四層讓 AI 能夠精準輸出符合你設計系統的 prototype——顏色正確、元件骨架正確、設計意圖正確。
但這套工作流程解決的，是設計過程的後半段：你已決定怎麼設計，AI 幫你精準輸出。 設計過程的前半段——探索可能性、發現更好的方向、讓 AI 帶入它的設計知識——還沒有被設計進工作流程裡。
「你建立的精準基礎，是為了讓 AI 執行你的決定。但你還沒有建立讓 AI 幫你做出更好決定的流程。」
這篇文章補完這一半。你將學到：
目標一
理解兩種工作模式
探索模式與精製模式的定義、差異、以及各自要給 AI 哪些資訊。
目標二
建立三區邊界框架
清楚定義哪些是 AI 必須遵守的、哪些是軟性建議、哪些是刻意留給 AI 的創意空間。
目標三
掌握模式切換流程
在一個設計專案中，何時使用哪個模式、如何從探索切換到精製、每個階段可以期待什麼成果。
「只用精製模式」的工作流程，有一個不易察覺的代價： 設計師漸漸從設計者變成規格撰寫者。 你花在寫設計規格 MD 的時間，多於花在思考設計本身的時間。 AI 輸出精準了，但設計的品質取決於你在寫規格之前就想清楚了多少。
代價一：AI 的設計知識被鎖在規格之外
被過度規格化的工作流程浪費了
AI 訓練了數百萬個設計案例，知道哪些設計模式對使用者有效、哪些已過時。但當你給 AI 完整的規格，AI 只能執行——它帶入設計知識的機會已被規格鎖死。
代價二：探索設計方向沒有工具支援
發散階段仍靠設計師獨力完成
要用 AI 生成第一個 prototype，你需要先寫完規格。但規格需要你先做設計決策。設計決策需要你先探索可能性……AI 沒有幫上設計前段的忙。
代價三：精準度達到 85% 後回報遞減
繼續精進規格的成本不成比例
components.css 可以讓 prototype 達到 85–90% 的視覺還原度。剩下的 10–15% 需要越來越細緻的規格，但設計決策本身的品質沒有因此提升。
代價四：vibe coding 的「vibe」消失了
工作流程失去了它本來的設計感
Vibe coding 的核心是「描述設計感覺，AI 輸出正確結果」。當工作流程變成「先把所有決定寫成規格，再讓 AI 執行」，你失去了 vibe coding 最有價值的部分：設計的直覺空間。
核心問題不是精準度不夠，而是工作流程缺少探索階段
精製模式是必要的，不是問題。問題是它是工作流程中唯一的模式。 一個完整的設計工作流程需要兩種模式在不同的設計階段交替使用—— 探索模式讓你更快找到好方向，精製模式讓你精準執行選定的方向。
完整的 AI 設計協作工作流程由兩種模式組成。 它們服務設計過程的不同階段，給 AI 不同程度的自由度，產出不同形式的設計結果。
模式 A · 探索模式
AI 主導 · 設計師策展
給 AI 最小的約束（設計問題 + 設計系統硬規則），
讓 AI 在 SHP token 框架內自由探索，生成多個設計方向，並主動解釋每個方向的設計邏輯。
設計師的角色：提問、觀察 AI 的設計思維、識別洞見、選擇或組合方向。
模式 B · 精製模式
設計師主導 · AI 精準執行
給 AI 完整的約束（四層知識架構全部就緒），
讓 AI 按照設計規格精確輸出高保真 prototype，不做任何超出規格的自主決定。
設計師的角色：確認規格完整、QA 輸出品質、調整規格後重新生成。
| 比較面向 | 模式 A · 探索模式 | 模式 B · 精製模式 |
|---|---|---|
| 給 AI 的資訊 | 設計問題 + 設計系統硬規則（token + CLAUDE.md） | 完整四層（token + components.css + CLAUDE.md + spec MD） |
| AI 自由度 | 高——AI 自行選擇視覺策略和構圖方向 | 低——AI 嚴格執行規格，不做自主判斷 |
| 產出形式 | 3–5 個設計方向 + 每個方向的設計邏輯說明 | 1 個高保真 HTML prototype（85–90% Figma 還原度） |
| 設計師工作 | 提問、觀察、識別洞見、選擇方向 | 確認規格、QA 輸出、更新規格、重新生成 |
| 適合的設計階段 | 設計早期：探索方向、驗證假設、發現洞見 | 設計後期：精製方案、互動原型、工程 handoff |
| 速度 | 快（5–10 分鐘生成多方向） | 中（規格準備 15–30 分鐘；生成後 QA） |
兩種模式不互相取代，而是接力
標準的工作節奏：模式 A 找到正確方向 → 模式 B 精確執行選定方向。 你也可以在設計迭代過程中再次切換回模式 A——當你遇到設計卡關、 需要重新評估方向時，模式 A 讓你快速重新發散，而不需要重寫所有規格。
兩種模式的設計，需要一個核心框架來支撐：設計師和 AI 的工作邊界不是一條線，而是三個區域。 每個區域定義了 AI 在其中有多少自由度。 清楚定義三個區域，才能在模式切換時不讓工作流程崩潰。
AI 必須遵守，不容商量
設計系統的 token 語意規則（basic vs. element 系列、功能色限制、dark mode 規則）、
無障礙標準、品牌禁止事項。這些放在 CLAUDE.md 中，
在探索模式和精製模式中都必須遵守。
AI 可以自由發揮視覺方向，但不能違反這些規則。
AI 應該遵守，但可以提出替代方案
components.css 的元件骨架定義、設計規格 MD 的視覺意圖。
這些在精製模式中 AI 嚴格執行；在探索模式中，
AI 可以使用預定義的元件，也可以提議不同的元件結構，但必須說明理由。
設計師決定要接受 AI 的替代方案，還是堅持原有定義。
AI 被授權自由發揮，設計師策展
設計師刻意留白的區域：版面構圖的可能性、視覺層次的不同詮釋、 互動流程的替代方案、設計問題的不同切入角度。 這個區域是模式 A 的核心——設計師用設計問題開啟這個空間， AI 用它的設計知識填滿，設計師再從中策展最有洞見的方向。
五個設計工作原則
不同設計階段，給 AI 不同程度的自由
設計早期（探索假設）：給 AI 最大自由度，讓它帶來你沒想到的可能性。 設計後期（精確執行）：鎖定所有決策，讓 AI 嚴格輸出。 自由度不是固定的，它跟著設計進度調整。
讓 AI 說明它的設計邏輯，不只是生成結果
在模式 A 中，要求 AI 解釋每個設計方向的設計假設和邏輯。 AI 說明設計決策的過程，本身就是對設計師的啟發—— 你可能不選 AI 的方向，但 AI 的分析邏輯可能改變你的設計思考。
探索的目的是找到可以鎖定的決策，不是生成更多選項
模式 A 的終點是「選定一個方向」，不是「生成越來越多方向」。 探索的價值在於讓你的設計決策有更好的依據，而不是讓 AI 替你做決定。 設計師做決策，AI 擴大決策的視野。
components.css 定義的元件是軟約束，不是牢籠
預定義的元件骨架給 AI 提供了「最常見的正確答案」。 但如果一個設計問題需要突破現有元件定義， 你應該更新 components.css，而不是在 prompt 裡繞過它—— 規格文件永遠是設計決策的唯一來源。
設計師的工作是「策展」，不是「控制」
最有效的 AI 設計協作，不是設計師把所有決定提前寫死，而是設計師設定問題、給定框架、觀察 AI 的回應、識別洞見、做出判斷。 你是策展人，AI 是有豐富設計知識的創作夥伴。
探索模式的核心是一個認知轉換：你問 AI 一個設計問題，而不是給 AI 一份設計規格。 AI 的任務不是執行，而是帶著它的設計知識，在你的設計系統約束內，提出多個值得考慮的方向。
探索模式的輸入結構
探索模式 Prompt 框架
模式 A · 探索模式 Prompt 範本
── 設計問題（以使用者任務為中心）──────────────────── 這個設計問題是： [用一句話說明使用者要完成的任務，例：] 「讓使用者在商品列表頁 3 秒內找到感興趣的商品並觸發點擊」 ── 設計洞見請求（在設計前先請 AI 分析）────────────── 在開始設計之前，請先告訴我： 1. 類似場景（電商列表頁）最有效的設計模式是哪些？哪些已過時？ 2. 使用者在這類頁面最常遇到的認知負擔是什麼？ 3. 針對這個設計目標，你認為最值得探索的設計假設是什麼？ ── 探索指示 ───────────────────────────────────────── 然後，在以下約束內生成 3 個不同方向的設計概念： · 必須使用 @tofuydesign/shp-react 的 token（--shp-*） · 必須遵守 CLAUDE.md 的 token 選用規則 · 三個方向使用不同的視覺策略（請自行選擇有意義的對比維度） ── 要求每個方向說明 ───────────────────────────────── 每個方向需要說明： · 視覺策略和設計假設是什麼 · 這個方向最適合哪種使用者情境 · 你選擇這個方向的設計邏輯 ── 輸出格式 ────────────────────────────────────────── 每個方向輸出： · 設計說明（150 字以內） · HTML prototype（單頁，支援 dark mode） · 你認為這個方向的最大優點和最大風險各一點
如何評估和使用 AI 的探索結果
先讀 AI 的設計洞見分析，再看設計方向
AI 在生成設計方向之前對設計問題的分析，通常比設計方向本身更有價值。 關注 AI 識別出的使用者問題和設計假設——這些可能改變你對設計問題的理解。
評估每個方向的設計邏輯，不只是視覺效果
AI 生成的視覺效果只是設計方向的載體，真正的價值是它背後的設計邏輯。 問自己：「這個方向的設計假設是否值得驗證？」而不是「這個視覺效果我喜不喜歡？」
可以組合不同方向的最佳元素
你不一定要選擇 AI 給出的某一個方向。 你可以告訴 AI：「我喜歡方向 1 的資訊架構，加上方向 3 的視覺調性，請生成組合版。」 設計師的判斷在於識別並組合最有價值的設計決策。
確認選定方向後，將設計決策轉化為規格
選定方向之後，把這次探索確定的設計決策整理進設計規格 MD——這是進入模式 B 的準備。 探索的結論（設計決策）是模式 B 的輸入，不需要重新從零開始寫規格。
模式 A 的最大價值：AI 帶來你沒想到的視角
最值得注意的不是 AI 給你了幾個設計方向，而是： AI 的分析有沒有讓你對這個設計問題有不同的理解？ 如果 AI 的回應讓你覺得「這個角度我沒想到，但它說的有道理」—— 那就是模式 A 發揮了最大的價值。
精製模式在前一篇文章已有完整說明（四層架構 + components.css 建置流程）。 這一節聚焦在兩個設計師需要清楚理解的現實： components.css 能把 prototype 精準到什麼程度，以及剩下的缺口如何處理。
視覺還原的真實上限：85–90%
85–90% 對大多數設計用途已經足夠：設計概念驗證、設計評審展示、互動原型測試。 剩下的 10–15% 主要是需要額外資產或特殊說明的部分—— 在設計師 QA 確認後，可以視需求補充或在工程 handoff 時說明。
視覺還原 QA 檢查流程
每次生成 prototype 後，按照以下四層檢查清單進行 QA。 發現問題時，修正的來源是設計規格，不是直接改 HTML。
| QA 層級 | 檢查項目 | 目標還原度 | 修正方式 |
|---|---|---|---|
| Layer 1 · 顏色語意 | 所有 CSS 使用 var(--shp-*)，無 hardcode hex · data-theme="dark" 切換正確 |
100% 可達 | 更新 CLAUDE.md token 規則 |
| Layer 2 · 元件骨架 | border-radius 與 Figma 一致 · padding 正確 · font-size / line-height 一致 · gap 正確 | 95% 可達 | 更新 components.css 對應 class |
| Layer 3 · 互動狀態 | hover / pressed · loading skeleton · empty state · error · disabled 全部已定義且正確 | 90% 可達 | 在 spec MD 補充狀態說明後重新生成 |
| Layer 4 · 進階細節 | 動畫時間曲線 · responsive breakpoint · 品牌圖示 SVG · 字型渲染 | 需額外處理 | 在 spec MD 補充說明 / 提供 SVG 資產 / 接受瀏覽器渲染差異 |
當 QA 發現問題時，修正的正確順序
判斷問題屬於哪一層
顏色選錯 → Layer 1（CLAUDE.md 問題）。 骨架尺寸不對 → Layer 2（components.css 問題）。 狀態缺少 → Layer 3（spec MD 問題）。 先診斷來源層，再決定修正在哪裡。
修正設計規格，不是直接改 HTML
直接改 HTML 是一次性的修補，之後重新生成問題又回來。 修正設計規格（更新 components.css 或 spec MD），再重新生成—— 規格是持久的，HTML 是可以重新生成的。
重新生成後確認修正是否有效
重新生成後，對照 Figma 設計稿確認問題已解決。 如果同樣問題出現在多個元件，通常是 CLAUDE.md 或 components.css 層面的系統性問題—— 在規格層修正一次，所有元件都受益。
模式 B 精製模式 · Prompt 範本
精製模式的 prompt 應該明確：引用哪份規格、使用哪些 class、要求不自行發明 CSS。
模式 B · 精製模式 Prompt 範本
根據 specs/[路徑]/[檔案名稱].md 的設計規格， 使用 CLAUDE.md 元件 class 對照表（.shp-card、.shp-btn 等）， 生成 [元件 / 頁面名稱] 的 HTML prototype。 要求： · 引入 @tofuydesign/shp-react 的 tokens.css 和 components.css · 使用 components.css 中的預定義 class，不要重新定義元件 CSS · 處理所有狀態：[列出 spec MD 中定義的狀態] · 支援 data-theme="dark" 的 dark mode 自動切換 · 所有顏色使用 var(--shp-*) 變數，不使用 hardcode 值 輸出到：prototypes/[YYYYMMDD]-[名稱]/index.html
一個完整的設計工作週期，是兩種模式按照設計進度交替使用的過程。 以下是一個典型設計專案從開始到交付的完整節奏，包含每個階段的觸發點和切換時機。
FIG.03 · 雙模式設計工作流程 · 完整週期
模式切換不是單向的——設計迭代過程中遇到卡關或需要重新評估方向時，可以再次啟動模式 A
完整流程：七個步驟手把手引導
定義設計問題（模式 A 的起點）
用一句以使用者為中心的句子，說明這個設計任務要幫助使用者完成什麼。 「這個頁面要讓使用者快速找到感興趣的商品」比「這個頁面是商品列表頁」更有效—— 前者是設計問題，後者只是頁面類型。
啟動模式 A：讓 AI 先分析，再生成
使用模式 A 的 Prompt 框架，要求 AI 在生成設計方向之前先分享設計洞見。 重點：把 CLAUDE.md 的硬規則提供給 AI，但不提供 components.css 或 spec MD—— 讓 AI 有足夠的自由度真正探索。
策展 AI 的探索結果
先閱讀 AI 的設計分析（比設計方向本身更重要）。 評估每個方向的設計邏輯和假設——不只是視覺效果。 選定一個方向，或組合多個方向的最佳元素。 如果 AI 的所有方向都不對，重新問一次，換一個對比維度。
將選定方向轉化為設計規格 MD（模式 B 的前置工作）
從模式 A 的探索結果中，提取已確認的設計決策： 視覺層次、CTA 位置、元件選擇、狀態清單。 把這些決策填入設計規格 MD（範本 A 或 B）—— 不需要從零開始，直接整理探索階段確認的決策就夠了。
啟動模式 B：使用完整四層生成精製 prototype
確認四層都就緒（tokens.css + components.css + CLAUDE.md + spec MD）。 使用模式 B 的 Prompt 範本生成 prototype。 明確告訴 AI 使用 components.css 的預定義 class，不要重新定義元件 CSS。
QA 四層檢查，更新規格後重新生成
按照 Block 05 的 QA 清單逐層確認。 發現問題 → 判斷屬於哪一層 → 修正設計規格 → 重新生成。 反覆迭代，直到 prototype 達到 85% 以上的視覺還原度。
交付或繼續迭代
設計評審通過 → 設計規格 MD 直接作為工程師的 design spec（token 名稱和 Figma 一致）。 設計方向需要調整 → 切回模式 A，重新探索，不需要從頭寫規格。 設計規格 MD 在整個過程中持續更新，是設計決策的唯一記錄。
模式切換的觸發條件
| 情境 | 切換至 | 理由 |
|---|---|---|
| 設計專案剛開始，還沒有方向 | 模式 A | 需要探索設計空間，不應該過早鎖定方向 |
| 有初步方向但設計卡關，迭代沒有進展 | 模式 A | 可能需要重新評估設計假設，AI 的洞見可以打開新視角 |
| 設計方向已確認，需要精製細節 | 模式 B | 方向已定，AI 的任務是精確執行，不是再度發散 |
| 準備設計評審或工程 handoff | 模式 B | 需要高保真輸出，設計決策必須完全確定且有文件記錄 |
| 設計評審後需要重大調整 | 模式 A | 重大調整可能意味著設計假設需要重新驗證 |
| 設計評審後只需要微調細節 | 模式 B | 方向不變，只更新設計規格 MD 後重新生成 |
雙模式工作流程在不同階段產出不同形式的設計成果。 以下是每個階段你可以合理期待的具體結果—— 以及一些需要管理期望的現實。
模式 A 探索階段的成果
設計洞見報告
AI 對設計問題的知識貢獻
AI 對類似場景的有效設計模式分析、使用者常見問題識別、值得驗證的設計假設。這通常是模式 A 最有價值的輸出，即使設計方向最後沒有採用。
3 個設計方向 prototype
有設計邏輯說明的探索稿
使用 SHP token 的 HTML prototype，附帶每個方向的設計假設說明。視覺還原度約 60–70%（無 components.css 約束），但足以傳達設計方向。
設計決策基礎
進入模式 B 的輸入
從探索中確認的設計決策——視覺策略、元件選擇、CTA 定位——直接轉化為模式 B 的設計規格 MD。不需要重頭寫規格。
模式 B 精製階段的成果
高保真 HTML Prototype
視覺還原度 85–90%
使用 --shp-* token + components.css 預定義元件生成的 prototype。
顏色精準、元件骨架正確、dark mode 自動處理、所有定義的狀態都有呈現。
適合用於：設計評審展示、使用者測試、設計提案、工程師起點參考。
設計規格 MD（工程 handoff）
設計師和工程師的共同語言
記錄所有設計決策的 MD 文件——token 名稱（而不是 hex 值）、元件選用、狀態清單、禁止事項。
工程師的 npm install @tofuydesign/shp-react token 和 Figma 完全一致，不需要對色。
設計規格 MD 是整個專案週期最穩定的設計語言。
需要管理的期望
這套工作流程仍有的限制
模式 A 不能替代設計師的設計判斷。
AI 的探索結果提供視角和可能性，但設計決策仍然需要設計師做。
AI 不知道你的產品策略、使用者研究、商業目標——這些是設計師帶入的，AI 沒有。
模式 B 的 85–90% 還原度不等於 100% Figma 精確度。
動畫、響應式行為、品牌圖示仍需要額外工作。
工程師 handoff 仍需要 QA 確認，不能直接從 prototype 上線。
設計規格 MD 需要設計師維護。
Figma 有更新時，設計規格 MD 需要同步更新；components.css 也需要對應調整。
這是工作流程的維護成本，但遠低於每次手動對色的成本。
這兩篇文章（008 + 009）描述的工作流程，核心是一個設計哲學上的轉變： AI 在設計工作中的最大價值，不是更快地執行你的設計，而是幫你做出更好的設計決策。
精製模式（模式 B）讓你的設計決策被精準執行。 探索模式（模式 A）讓你的設計決策有更好的依據。 兩種模式缺一不可——只有執行，沒有洞見；或者只有探索，沒有精準輸出，都是不完整的工作流程。
「給 AI 清楚的問題，它帶來設計洞見。給 AI 完整的規格，它輸出精準結果。設計師的工作，是知道什麼時候問問題、什麼時候給規格。」
三區邊界框架（硬約束 / 軟約束 / 創意空間）是這套工作流程的骨幹。 清楚定義邊界，才能在給 AI 足夠空間的同時，保持對設計品質的掌控。 邊界不是為了限制 AI，而是為了讓 AI 在對的地方發揮它的能力。
這套工作流程需要一次性的前置投資（建立 components.css、更新 CLAUDE.md、熟悉兩種模式的切換節奏）， 但之後的每個設計專案，都能從這個基礎上受益—— 更快的探索、更精準的輸出、更清楚的設計決策記錄、更順暢的工程 handoff。