規範與治理

設計體系最大的敵人不是「建不起來」，而是漂移：資源與程式碼各改各的，半年後規範說一套、線上跑另一套。swift-web 用三條紀律防止這件事。它們都不複雜，但需要設計與前端兩側共同遵守。

紀律一：調色只在語意 token 層

設計新網站 / 改版配色時，顏色調整必須落在語意 token上（--primary、--background……），不允許在稿子裡散點取色。

  • 在 Claude Design：讓 AI「把主色換成 X」而不是逐一元素改色（見上手教學第 4 步）。
  • 在 Figma：改 Variables 集合的值，元素顏色一律綁定變數而非寫死色值。

為什麼：散點色進不了合約——落地時前端無從判斷「這 7 種相近的金色哪個是主色」，只能猜或歸一，設計意圖在翻譯中損失；而 token 層的修改天然全稿一致、天然可交付。語意 token 覆蓋不了的品牌特有色（VIP 金、等級色、支付通路色），作為補充 token 在清單中顯式列出（程式碼側對應 --brand-* 命名空間），同樣是命名的、可交付的——紀律約束的是「散點」，不是「色彩豐富度」。

紀律二：設計資源是派生物，不手動修改

swift-web 的設計資源（Claude Design 的 20 張卡片、Open Design 的設計系統資源包、Figma 的 Variables 與元件庫）全部由框架源碼自動派生。這意味著：

  • 不要在 Claude Design 裡直接編輯設計系統卡片、不要手動改 Open Design 資源包裡的 DESIGN.md / tokens.css，也不要在 Figma 裡手動改動資源庫的 token 值——手動改動會在下次派生時被覆蓋，且改動期間稿與碼已經悄悄分岔。
  • 對元件形態 / token 預設值有訴求（覺得某元件預設樣式不合理、想加一個通用 token），提給框架維護者，走框架正常迭代：源碼更新 → 資源自動重新派生 → 兩條軌道同步拿到新版。設計師的意見會推動框架進化，只是路徑經過程式碼這個「唯一事實源」。
  • 用資源做設計不受任何限制——紀律約束的是「改資源本體」，不是「用資源出稿」。稿子裡怎麼組合、怎麼覆蓋 token 都是設計自由。

為什麼：一份資源兩處維護必然漂移，這是所有設計系統爛掉的頭號死因。把「可信來源」收斂到框架源碼一處，資源永遠反映真實線上形態——這也是設計師敢放心照著卡片出稿的底氣。

這條紀律還有一個自然推論：接入新設計工具 = 為流水線新增一個派生目標，核心資產不動。Open Design 就是這麼接入的——框架源碼不變，只是多了一種從源碼生成的資源形態。將來出現下一個值得用的工具，同理：先問「它吃什麼格式的設計系統」，再讓流水線多產出一份，而不是為那個工具單獨手動維護一套資源。

組織管理提示：Claude Design 的 Team / Enterprise 組織預設任何成員都能發布 / 修改設計系統；Enterprise 方案可透過 Claude Design Admin 權限把發布權收斂給指定成員，從機制上保證單一事實源。組織接入時建議一併設定。

紀律三：新品牌接入 = 一張 token 清單

為新品牌 / 新網站建立設計資源，輸入只有一樣東西：品牌 token 清單（設計師定稿的 token 值列表，產出方式見配色工作流程）。

流程：

  1. 設計師從底版設計系統起稿探索，在 token 層定出品牌配色；
  2. 整理品牌 token 清單（15～25 項 + 可選的 --brand-* 補充項），連同定稿一起交付；
  3. 框架維護者把清單餵給自動化管線，一次生成：該品牌的 Claude Design 設計系統變體（後續該品牌的設計都基於它出稿）+ 程式碼側品牌覆蓋樣式（專案 rebrand 落地）；
  4. 之後該品牌的設計與程式碼共享同一組 token 值，任何一側的調色需求都回到清單更新、重新派生。

為什麼：把「接入一個品牌」壓縮成單一輸入 + 自動化輸出，成本低到可以為每個專案都建專屬資源——這是「所有專案共用一套通用資源、越用越對不上」的反面。

快速自查表

場景✅ 正確姿勢❌ 反面姿勢
新站配色token 層調色，交付 token 清單稿內散點取色，交付「看圖取色」
覺得元件預設樣式不好提需求給框架維護者直接改設計系統卡片 / 資源庫
品牌特有色列為 --brand-* 補充 token混在稿子裡不命名
新品牌啟動底版起稿 → 清單接入複製別的品牌資源手動改
稿與線上不一致回報給維護者核對派生鏈手動改資源遷就線上

相關連結