設計系統生成工作流：從 brief 到元件

本工作流適合新頁面或新產品開始前使用。最後產物不是一個抽象的元件大集合，而是一組已經在代表頁面中驗證過的規則。

流程總覽

產品情境 → Visual Brief → 視覺方向 → Semantic Tokens
    → 元件狀態 → 代表頁面 → review 與交付

Step 1：整理輸入

寫下使用者、主要任務、內容密度、裝置、品牌限制、技術堆疊和無障礙要求。把不確定的部分標成「假設」，不要讓 AI 默默替你決定。

Step 2：提出並比較方向

請 AI 提供兩個方向，每個方向都要列出：字體、色彩角色、間距尺度、圓角、陰影、動效、適合的頁面類型和不適合的情境。用主要任務評選，而不是只看截圖。

Step 3：建立 Token

:root {
  --surface-page: 248 250 252;
  --surface-card: 255 255 255;
  --text-primary: 15 23 42;
  --action-primary: 37 99 235;
  --space-unit: 0.25rem;
}

接著定義亮色、深色和品牌主題的 semantic mapping。先做最小集合，只有在實際元件需要時才增加角色。

Step 4：寫元件契約

每個元件文件至少包含 anatomy、props、尺寸、狀態、鍵盤行為、響應式行為和錯誤處理。例如 Button 不只要有 primary 和 secondary，還要描述 loading、disabled、focus 和 icon-only 的規則。

Step 5：做一頁代表實作

選登入、列表、表單或儀表板其中一頁。頁面必須包含真實內容、長文字、空資料、錯誤和窄螢幕，而不是只有 happy path 的展示卡片。

Step 6：審查與交付

用鍵盤走主要任務，測試兩個 viewport、兩個主題和減少動態偏好。交付時附上 brief、Token、元件契約、代表頁面截圖和已知限制。

AI 提示詞範例

請先閱讀 design-brief.md 和現有 tokens.css。
不要新增套件或重建既有 Button。
先列出受影響元件與缺少的狀態，再實作列表頁的 empty/error/loading。
完成後說明 keyboard、mobile、contrast 和 build 的驗證結果。

常見失敗

先生成 30 個元件，卻沒有一個完整頁面。
只定義成功畫面，導致 loading 和 error 各自發明樣式。
將 raw 色票暴露給元件，換主題時只能逐檔修正。