Design Token Tier System

Design Token 三層架構是什麼，跟單層的 Token 命名方式有什麼不同？

單層命名法是最早期、最直覺的做法：直接用描述性的名字命名一個顏色或數值，例如 blue-500 代表一個特定的藍色色號。這種命名法在 Token 數量少的時候很好用，但隨著設計系統擴大，問題會浮現——如果某個按鈕的背景色用了 blue-500，之後想把「所有主要按鈕的背景色」統一換成另一個顏色，卻發現 blue-500 同時被用在十幾個跟按鈕完全無關的地方（連結文字、圖示顏色、邊框），改一個值會牽動一大片不該被影響的地方。

三層架構把命名拆成三個獨立層級來解決這個問題：第一層「全域原始值」（Global/Primitive）只負責定義原始數值本身，例如 blue-500 = #2D5BD6，不涉及任何用途；第二層「語義別名」（Semantic/Alias）賦予這個原始值一個用途導向的名字，例如 color-action-primary 指向 blue-500，這一層回答「這個顏色用在哪種情境」；第三層「元件專屬」（Component-specific）則是特定元件引用語義層的 Token，例如 button-primary-background 指向 color-action-primary。改色時只需要調整第二層的對應關係，不用动到底層原始值，也不用一個個去改元件層。

為什麼需要發展出三層架構，它解決了什麼背景問題？

這個架構的出現，直接對應設計系統規模化之後必然出現的「Token 混亂」問題。當一個設計系統只有幾十個 Token 時，單層命名完全夠用，因為人力還能記住每個 Token 被用在哪裡；但當 Token 數量成長到幾百甚至上千個，涵蓋多個平台（網頁、iOS、Android）與多個主題（淺色、深色、品牌變體），單層命名法會讓「這個 Token 到底能不能安全修改」變成一個需要全文搜尋程式碼庫才能回答的問題，大幅拖慢設計與開發的迭代速度。

三層架構的核心思路，是把「原始值是什麼」跟「這個值代表什麼用途」拆成兩個可以獨立變動的關注點——原始值可以保持穩定（藍色的色號不會常常變），但語義層的對應關係可以隨著品牌調整或深色模式切換而改變，而元件層幾乎不需要變動，因為它只是穩定地指向語義層。這種分層讓「換色」、「切換深色模式」、「調整品牌識別」這類常見的大規模變更，變成只需要調整中間那一層,而不必逐一排查整個程式碼庫。

三層架構具體怎麼運作，各層之間的引用關係是什麼？

具體的引用鏈是單向的：元件層 Token 引用語義層 Token，語義層 Token 引用全域層 Token，全域層 Token 本身是終點，不再引用其他 Token。以一個實際例子說明：全域層定義 gray-900 = #1A1A1A（純粹的顏色數值）；語義層定義 color-text-primary = {gray-900}（賦予這個顏色「主要文字顏色」的用途）；元件層定義 heading-text-color = {color-text-primary}（標題元件引用這個語義用途）。如果之後要調整深色模式，只需要讓語義層在深色模式下指向不同的全域值（例如 color-text-primary 在深色模式下改指向 gray-100 而不是 gray-900），元件層完全不用更動，因為它引用的是語義層這個穩定的中介名稱,而不是具體的顏色數值。

實際導入時常見的做法是用工具（例如 Style Dictionary 之類的 Token 轉換工具）把這三層定義寫成結構化的檔案（通常是 JSON 或 YAML），再自動產出各平台能讀取的格式（CSS 變數、iOS 的 .swift 常數、Android 的 XML 資源）。這樣設計師在 Figma 裡調整語義層的對應關係，可以直接同步產出所有平台的程式碼變更，不需要工程師手動逐一修改。

對讀者或正在建立設計系統的團隊有什麼實際影響？

如果你的團隊正在從零開始建立 Design Token，三層架構值得從第一天就採用，而不是等 Token 數量膨脹到難以維護後才回頭重構——重構一個已經被大量元件直接引用的扁平命名系統，成本遠高於一開始就分層設計。具體的起手判斷方式：先列出團隊真正需要的「語義用途」（主要行動色、次要文字色、危險警示色等），再回頭定義支撐這些用途的全域原始值，而不是先把一堆顏色數值定義好,再事後想該怎麼分類。

如果你的團隊已經有一套扁平命名的 Token 系統、正在考慮要不要重構成三層架構，實際的成本效益判斷點在於：團隊未來半年到一年內，是否預期會有「大規模換色」「新增深色模式」「支援多品牌」這類橫跨大量元件的改動需求。如果這類需求不會發生，維持現狀可能比重構的工程成本更划算；如果這類需求確定會發生，越早重構，後續每一次大改的成本就越低。