我的知識庫

UIUX · 2026-07-19

閱讀時間約 15 分鐘

2025 年 10 月底,W3C 設計代幣社群小組(Design Tokens Community Group,簡稱 DTCG)發布了第一份穩定版格式規格(2025.10),背後有 Adobe、Google、Meta、Figma 等 24 個以上組織背書。這件事聽起來很技術、很無聊,但正是這種「無聊」讓 2026 年的設計系統圈出現一個明確轉向:設計 token(design tokens)不再是設計師自己在 Figma 裡玩的變數表,而是正式升級成「設計、工程、品牌、甚至 AI 產碼工具」共用的平台級契約。多份 2026 產業調查顯示,token 採用率已達 84%,而 74% 的成熟設計系統把 token 列為主要交付物之一。這篇整理的重點不是「什麼是 design token」這種入門常識,而是往上一層——當格式之爭結束之後,真正決定 token 系統能不能活下去的治理(governance)機制長什麼樣子。

📖 學(核心)

格式終於統一,戰場移到治理層

過去十年,「你們的 design token 是什麼格式」是一個能吵一整個下午的問題:SCSS 變數、CSS 自訂屬性、某團隊自己發明的 YAML、Style Dictionary 的巢狀 JSON,每套工具都有自己的方言,團隊之間交換 token 永遠要寫轉換腳本。DTCG 規格把這場爭論收掉了——統一用 $value 與 $type 描述每一個 token,陰影、漸層、文字排版組合、轉場動畫都是「複合型別」(composite types),不再是字串硬湊;{color.brand.500} 這種參照語法能在轉換到不同平台後依然正確解析;$description、$extensions、$deprecated 這些中繼資料也被規格化,可以被 lint 工具檢查。Style Dictionary、Tokens Studio、Figma Variables、Penpot、Supernova、Zeplin 等主流工具全部支援同一份格式,換工具不必重寫下游 pipeline。格式統一之後,真正困難、也真正有價值的工作,變成了架構設計、審核流程,以及「決定一顆 token 到底能不能安全上線到正式環境」的那套規矩。

三層架構:Primitive、Semantic、Component

實務上能撐過團隊成長的 token 系統,幾乎都收斂成同一個三層形狀。Primitive(原始層) 是最底層的原始數值,例如 color.neutral.900、space.4、font.size.6,只有品牌或設計負責人能改,而且只給 semantic 層讀取,不對外開放。Semantic(語意層) 描述的是「用途」而非「數值」,例如 color.surface.primary、color.text.secondary、space.layout.gutter,是設計師實際思考、溝通時用的詞彙,內容全部參照 primitive 層。Component(元件層) 則是每個元件專屬的 token,例如 button.primary.background、card.padding.inline,幾乎永遠參照 semantic 層,由元件負責人維護。這裡最重要的一條鐵律是:元件永遠不可以直接讀 primitive 層。如果 Button 元件直接寫死 color.blue.500,那深色模式或多品牌主題就會變成一場要花半年重構的災難——因為沒有語意層當緩衝,每個直接引用 primitive 的地方都得逐一手動修改。把既有系統重構成這種三層形狀,一個中型專案大概要花一季,但只要做完,下一次換主題或換品牌的成本會直接砍到幾乎為零。

主題與多品牌:用 $value 切換,不是複製檔案

在 DTCG 的世界裡,切換深色模式或多品牌不是複製一份新的 token 檔案出來改,而是同一顆 token 底下掛不同模式的數值($extensions.modes),例如 color.surface.background 在亮色模式參照 {color.neutral.0},在暗色模式參照 {color.neutral.1000},在高對比模式直接給 #ffffff。建置工具(如 Style Dictionary)會針對每個模式各自輸出一份 CSS,前端只需要在 <html> 上切換 data-theme="dark" 或 data-brand="brand-green" 屬性,所有引用該 token 的元件就會整批重繪,不需要 JavaScript 主題提供者,也不必維護重複的覆寫規則集。多品牌支援用同一套機制處理——過去被認為「不太可行」的多品牌需求,現在只是一個 data-brand 屬性加上一組 token 模式。

治理是 token 系統存活的關鍵,而不是格式本身

Token 系統失敗,通常不是敗在技術,而是敗在「人」的流程沒設計好。幾條實務上證明有效的治理規則值得抄:第一,每個修改 token 的 PR 都要同時經過設計與工程兩邊審核,兩個 approval 缺一不可,用 CODEOWNERS 強制執行——只有設計審會有視覺跑掉的風險,只有工程審會有建置壞掉的風險。第二,token 的「名稱」視為不可變的 API,「數值」才是可以調整的部分:新增 token 算 patch、改數值算 minor(視覺變了但介面契約沒變)、改名或刪除都算 major,而且改名時要保留舊名稱、標記 $deprecated: true 至少維持一個大版本,再搭配 lint 規則警告任何還在用已棄用 token 的元件程式碼。第三,所有觸碰樣式的元件 PR 都必須引用 token,不能寫死顏色或間距的數值——這條規則靠 stylelint 或 ESLint 的自訂規則在 CI 擋下來,效果往往比任何架構文件都實在。第四,同一個用途只能有一顆語意 token:如果 color.text.muted 和 color.text.subtle 沒人說得出差在哪裡,就該合併,系統的價值在於它的限制,不是它的豐富度。

CI 管線:讓設計師與工程師在同一條生產線上

2026 年多數團隊收斂出的工作流程大致是:設計師在 Figma 用 Tokens Studio 或 Figma Variables 編輯 token,透過外掛推送到 Git 儲存庫的 tokens/ 資料夾,走分支對應一個 PR 的模式;CI 第一步對 JSON 做 DTCG 格式驗證與自訂 lint(檢查孤兒 token、缺漏的 $type、未追蹤的棄用),並在 PR 上留言差異報告;第二步用 Style Dictionary 建置成 CSS、Tailwind 設定、TypeScript 型別、Swift 常數、Kotlin 常數等各平台輸出,並做視覺快照比對;第三步部署帶著新 token 的 Storybook 預覽,跑視覺回歸測試,把預覽連結貼回 PR;合併到主分支後才正式發版、推播給下游消費端的儲存庫。整個管線第一次架設大概要花一週,但架好之後,設計師提出的 token 修改會像一般程式碼一樣走 PR 審核,不再是「Figma 裡改一改就算數」的黑箱動作。

AI 產碼時代,token 是介面風格的字典

一個容易被忽略的效益是:結構完整、命名清楚、有 $description 的 token 系統,正是讓 AI 產碼工具(如 Claude Code、Cursor)生成「看起來像自家產品」介面的關鍵字典。如果把每個語意 token 的人類可讀說明彙整成一份 tokens.md 隨套件一起發布,AI 工具在產生「幫我做一個設定頁,風格要跟我們產品一致」這種需求時,才有機會真正對齊品牌調性,而不是產出一種「哪裡都不像」的樣板感介面。反過來說,如果 token 系統本身就雜亂無章,AI 產出的介面也只會放大這種雜亂。

常見反模式:治理實務中的地雷

幾個在系統健檢中反覆出現的錯誤值得提前避開:不要疊超過三到四層 token(primitive、semantic、少數情況加 pattern、component 已是上限,更多層只是徒增複雜度);不要把所有東西都主題化,顏色、圓角、陰影和少數語意層表面通常足夠,連字體、間距、動效都各自做一套主題,通常代表這其實是不同的產品而非同一套主題;不要自己刻一套建置管線,Style Dictionary 4 已經是業界公認答案;不要把 primitive 層直接暴露在對外 API 或文件裡,只對外說明 semantic 與 component 層;不要在 semantic token 裡直接寫死像素值,color.surface.primary 若直接寫 #ffffff 而不是參照 {color.neutral.0},整條可編輯的參照鏈就斷了;也不要為了個人偏好隨意改名,那等於是拿別人的舊程式碼開刀,遇到命名不理想寧可加別名慢慢淘汰。

🧠 記

  • 2025 年 10 月,W3C DTCG 發布首份穩定版 token 格式規格(2025.10),24+ 組織背書,主流設計工具已全面支援。
  • Token 系統的重心從「格式」轉向「治理」:誰能改、怎麼審、怎麼版本化,決定系統能不能活下去。
  • 三層架構是業界收斂的標準形狀:Primitive(原始值)→ Semantic(語意)→ Component(元件),元件永遠不直接讀 primitive。
  • 主題與多品牌靠同一顆 token 掛不同模式($extensions.modes)實現,不是複製檔案,靠 data-theme / data-brand 屬性切換。
  • 治理鐵律:token PR 需設計 + 工程雙審核;名稱視為不可變 API,改名要走 deprecate 流程,不能直接砍掉重練。
  • CI 應該擋下「元件寫死顏色或間距值」的 PR,這條 lint 規則的實際效益常常超過任何架構文件。
  • 74% 的成熟設計系統已把 token 列為主要交付物,token 採用率達 84%,是目前 ROI 最高的設計系統投資項目之一。
  • 良好結構、有說明文字的 token,是讓 AI 產碼工具生成「風格一致」介面的關鍵字典;混亂的 token 只會放大 AI 產出的不一致。
  • 常見反模式包括:疊太多層、什麼都主題化、自建建置管線、暴露 primitive 層、語意層寫死像素值、隨意改名。

✍️ 實踐

  1. 先做一次審計:對現有元件程式碼跑 stylelint(暫時關掉嚴格值檢查),列出所有實際用到的顏色、間距、圓角數值,通常會發現同一個藍色有十幾種變體。
  2. 依審計結果,由設計主導把發散的原始值收斂成一組 primitive 色階(例如 30 個顏色取代 200 個),先只建立這一層,不急著碰元件。
  3. 針對每個元件實際的視覺用途(不是元件名稱)定義 semantic token,問自己「這個背景色代表的意義是什麼」,而不是「這個元件叫什麼」。
  4. 導入 Style Dictionary 4,設定至少一份 CSS 輸出與一份 TypeScript 型別輸出,先讓 token 以「附加」形式存在,不強迫任何元件立刻改用。
  5. 在 CI 加一條 lint 規則,禁止元件樣式檔案出現裸露的顏色或間距字面值,先設成警告,等到八成元件遷移完畢再切成強制錯誤。
  6. 建立 token 修改的雙審機制(CODEOWNERS 同時指定設計與工程負責人),並訂出版本規則:新增視為 patch、改值視為 minor、改名或刪除視為 major 且需保留 deprecated 別名。

🔗 延伸學習

💬 問 AI

我正在幫 {專案/產品名稱} 的設計系統導入 W3C DTCG 格式的 design tokens,目前狀況是 {現有 token 管理方式,例如:散落在 SCSS 變數或完全沒有系統化}。
請幫我:
1. 設計一套 primitive / semantic / component 三層 token 架構,並用 {主要平台,例如:Web + iOS + Android} 為輸出目標;
2. 針對 {既有元件數量或範圍} 規模的專案,給出一份分階段遷移時程建議;
3. 提供一套 CI 治理規則草案(含 PR 審核流程、版本規則、lint 規則),讓 token 修改能像一般程式碼一樣被審核與追蹤。

反向連結