設計 token 與元件版本：讓介面可以重建

你可能遇過這種情況：某天要把網站的主色換深一點，結果發現同一個藍色散落在兩百個地方。有些是按鈕，有些是連結，有些只是某位設計師當年覺得「這裡用藍色好看」。改完之後，總有幾個角落忘了改，或者改了不該改的。

問題不在顏色本身，而在於這兩百個地方從來沒有說清楚：「我為什麼是這個顏色？」設計 token 就是用來回答這個問題的工具。

token 是一個有名字的決定

最簡單的說法是：token 是一個變數，例如「主色」等於某個藍色。但如果只把它理解成「把色碼存進變數」，就會錯過它最有用的部分。

一個好的 token 名稱描述的是用途，不是長相。「畫布」「正文」「弱化文字」「主色」「焦點框」「錯誤底色」「錯誤文字」「儲存中」「衝突提醒」，這些名字讀起來就知道它們負責什麼。相反地，「藍色一號」「淺灰三號」只告訴你顏色，沒有告訴你決定。

當名字描述用途，同一個色碼就可以合法地出現在好幾個 token 裡。例如白色同時是畫布的顏色，也是放在主色按鈕上的文字顏色。它們今天剛好一樣，但明天如果要讓按鈕上的字稍微帶一點暖色，只需要改其中一個，另一個不會被牽連。

換句話說，token 讓設計決定從設計師的腦中搬到檔案裡。檔案可以被讀、被比較、被追溯，也可以被 AI 遵守；腦中的決定則只能靠口頭轉述，轉述一次就走樣一點。

三層：原始值、語意、元件

我們把 token 分成三層來想。

• 原始值：純粹的色碼、間距、圓角數字，例如某個白、某個藍、四像素、八像素。
• 語意 token：用途的名字，例如畫布、正文、主色、錯誤底色。它們從原始值裡挑一個來用。
• 元件：按鈕、欄位、狀態提示、導覽與浮層。元件只引用語意 token，從不直接寫色碼。

這樣分層最直接的好處，是「換皮」變成一件範圍清楚的事。要做深色模式，就替每個語意 token 準備一個深色的值；要讓同一套介面換成另一個品牌的樣子，也只是換掉語意層與外框。區段和元件的程式完全不用動，所以換皮之後只需要檢查畫面，不需要重新檢查邏輯。

另一個比較不明顯的好處是狀態。介面裡不只有「正常」，還有錯誤、成功、儲存中、衝突、停用。每一種狀態都有自己的文字色、底色與邊框色，各自是一組 token。當這些狀態被當成正式的設計決定，而不是臨時加上去的紅字，使用者在每個畫面裡看到的「出錯了」就會長得一樣，理解的速度也會一樣。

值一樣，不代表是同一個決定

接下來是一個我們刻意做的、看起來有點違反直覺的選擇。

我們有一種以資料閱讀與管理為主的介面，它的需求和一般網站頁面很不一樣：資訊密度更高、層次更細、狀態更多。這種介面使用一組獨立的 token，命名也自成一套，不混用網站的基礎樣式，也不建立「這個等於那個」的別名。

盤點之後會發現，這組獨立 token 裡有一部分的值，跟網站 token 完全相同。例如兩邊的畫布都是白色，主色也是同一個藍。直覺上會想把它們合併，讓資料介面直接引用網站的 token，少維護一份。

我們沒有這樣做，原因是：值一樣，只代表今天剛好一樣。網站的白色是為了閱讀與留白而選，資料介面的白色是為了在密集的表格裡維持清楚的層次而選。哪天網站決定換成帶一點暖意的米白，資料介面不應該被動地跟著變。

所以我們用一張對照表把兩邊的關係記下來：哪些值相同、哪些是資料介面專用。對照表只記錄，不連結。真的想合併，就另外做一個明確的決定，並且重新跑一次視覺比對，確認合併前後畫面沒有變化。

元件與 token 都有版本

token 解決了「為什麼是這個樣子」，版本則解決「什麼時候變成這個樣子」。

我們的元件與 token 都以版本發佈。當一個介面需要大幅改變，例如換一套全新的視覺語彙，我們不會在原來的版本上直接改，而是另外發一個新的候選版本。舊版本保留，原本依賴它的頁面照常運作；新版本經過比對與驗收之後，才逐步接手。

這樣做的關鍵在於「回退」。如果新版本上線後發現問題，必須能夠退回舊版，而且退回的時候，使用者存在介面裡的東西不能不見。為了做到這點，新舊版本共用同一份儲存約定：同樣的資料位置、同樣的識別方式。切換版本只是換掉畫面，不換掉資料的家。

這個原則聽起來保守，但它讓我們敢於嘗試。版本號也讓溝通變簡單：說「這頁用的是第二版的按鈕」，所有人都知道指的是哪一組樣子與行為。因為知道隨時可以回去，新的設計就可以被放到真實的情境裡測試，而不是永遠停在設計稿上。

可以重建，才叫做有系統

把前面幾件事放在一起，會得到一個很實際的能力：介面可以從檔案重建。

token 寫在檔案裡，有版本；元件引用 token，也有版本；頁面由登錄過的區段組成，頁面內容是資料而不是寫死在程式裡。任何一台乾淨的電腦，拿到這些檔案，就能把整套介面重新組出來，而且長得一模一樣。

這也讓檢查變得可行。每次改動之後，可以在不同寬度、淺色與深色模式下截圖，和上一版逐一比對。差異要嘛是刻意的，要嘛就是需要修的。沒有「應該沒影響吧」的灰色地帶。

對一個小團隊來說，這種能力的價值常常在意想不到的時候出現。例如新同事第一次接手介面，他不需要先聽完一段口述歷史，只要讀 token 檔案，就知道每個顏色負責什麼；又例如 AI 助理被請來新增一個區段，它也只能使用已經存在的語意 token，而不是自己挑一個看起來差不多的色碼。規則寫在檔案裡，人和 AI 遵守的就是同一套。

當有人真的需要一個新的顏色，正確的做法也很清楚：先替它取一個描述用途的名字，說明為什麼現有的 token 不夠用，再把它加進語意層。這一步多花的幾分鐘，會在之後每一次改版時省回來。

重點回顧

• token 是有名字的決定：名字描述用途而不是顏色；元件只認語意 token，換主題只改中間那層。
• 值相同不等於同一個決定：獨立介面使用自己的 token，用對照表記錄而不互相引用，合併需另做決定並重新比對。
• 元件與 token 都有版本：新版另立、舊版保留，共用同一份儲存約定，回退時資料不會消失。