Design Token

設計 Token 是什麼，跟一般的顏色色票或 CSS 變數有什麼不同？

設計 Token 是把「一個設計決策」封裝成一筆有名字、有結構的資料，例如不是直接寫 #3B82F6，而是寫成 color.action.primary，這個名字背後才對應到實際的色碼。表面上看起來只是換個寫法，但關鍵差異在於：Token 有明確的分層與語意，同一個色碼可能在不同情境下被賦予不同名字（例如同一個藍色，在按鈕上叫 action-primary，在連結文字上叫 text-link），修改時只需要改動 Token 定義，所有引用它的地方會自動跟著變。

這跟單純的 CSS 變數不同的地方在於，CSS 變數只是瀏覽器能讀的技術格式，而設計 Token 是平台無關的抽象層，同一份 Token 定義理論上可以同時輸出成 CSS、iOS 資源檔、Android XML，不綁定任何單一工具或程式語言。

設計 Token 為什麼會出現，解決了什麼具體問題？

在沒有 Token 的年代，同一個品牌藍色，可能同時以 Figma 樣式、CSS 裡三個略有差異的十六進位色碼、Tailwind 的 class、iOS 的資源檔各自存在，彼此之間沒有連動，改一次色就要在四個地方分別手動修正，稍有遺漏就會出現「設計稿是對的、上線頁面卻不對」的落差。這種落差在團隊規模變大、平台變多之後會急遽惡化。

Token 的存在就是為了讓「這是一個決策」變成事實上唯一的說法：定義一次，所有下游（設計工具、CSS、行動裝置）都從同一份來源產生，理論上不可能出現「設計跟實作對不上」的狀況。這也是為什麼在 AI 生成介面的脈絡下 Token 特別關鍵——如果 AI 生成畫面時沒有一份結構化的 Token 可以參照，它只能憑統計上最常見的樣式去猜配色與間距，猜出來的結果自然跟品牌規範對不上。

設計 Token 實際上是怎麼運作、怎麼被使用的？

運作上通常分成三層：最底層是「原始值」（primitive），例如 blue-500 就是單純的一個色碼；中間層是「語意值」（semantic），例如 action-color 會指向某個原始值，代表「這是用在互動元件上的顏色」；最上層是「元件值」（component），例如 button-bg-primary 又指向語意值，代表「這是主要按鈕的背景色」。這種三層結構的好處是，如果整個品牌要換一次主色，只需要改動最底層的原始值，中間跟上層會自動跟著變，不用逐一去改每個元件。

實際使用上，設計師在 Figma 之類的工具裡透過「變數」功能定義 Token，工程端則透過 Style Dictionary 這類建置工具，把同一份 Token 來源轉換成 CSS 變數、iOS 資源檔或 Android XML。過去最大的問題是每個工具的匯出格式互不相容，Figma 匯出一種格式、Style Dictionary 又期待另一種，團隊得自己寫轉換膠水程式碼。2025 年 10 月底，W3C Design Tokens Community Group（DTCG）發布了第一個穩定版格式規格 2025.10，等於是統一了「Token 這份資料該長什麼樣子」，多個主要設計工具與建置工具陸續跟進支援，才真正解決了工具之間各說各話的問題。

如果我不是工程師，只是用 AI 設計工具生成畫面，設計 Token 對我有什麼實際影響？

就算你從來不寫程式，設計 Token 也直接影響你用 AI 設計工具的體驗品質。如果你用的工具支援匯入既有的設計系統（也就是匯入一套 Token），AI 生成畫面時會對照這套規則來配色與抓間距，結果自然比較貼近你原本熟悉的品牌風格；如果沒有匯入，AI 只能憑統計上最常見的樣式去猜，這也是為什麼很多 AI 生成的畫面看起來「差不多」——大家都在用同一套沒有 Token 約束的預設猜測。

對想認真評估 AI 設計工具的人來說，實務上值得問的問題是：這個工具能不能匯入我現有的設計系統？匯入後是每次生成都真的會對照這套規則檢查，還是只是參考一下就算了？這個差別，往往就是「生成出來能不能直接用」跟「還要花時間手動調回品牌樣式」之間的差距。