多數團隊以為，AI 生成的畫面一次比一次走樣、顏色又跟品牌對不上，問題出在 prompt 寫得不夠細。其實再細的描述都救不了，真正的原因是 AI 對你的品牌根本沒有一份「讀得懂的規則」。它認得「藍色」，卻不認得「你的藍色只能出現在主要按鈕、不能拿去當背景」；於是每次生成，它都在憑最接近的通用值猜，猜久了自然愈飄愈遠。
補上這份規則的關鍵，就是 design token（設計權杖）。它不是設計師關起門來自己整理的內部術語，而是一套把品牌決策寫成結構化資料、讓機器讀得懂的規範。當 AI 設計系統要「認得你的品牌」，靠的不是更長的 prompt，而是這一層能被穩定引用的 token。這也是為什麼這一兩年，design token 從設計流程裡的加分項，變成 AI 生成介面能不能守住品牌的基礎設施。
先從 design token 到底是什麼、為什麼 AI 生成內容時特別需要它講起，再一路拆到怎麼分層、怎麼餵給工具、生成完怎麼驗。
Design Token 是什麼？為什麼 AI 生成介面需要它？
先給一個精準的定義。design token 不是色碼，也不是某個數值本身，而是一筆「被命名、可重用、承載了設計決策」的資料。舉個具體的例子，你不會在介面裡直接寫 #2563EB，而是寫 color.action.primary（主要動作的顏色）。前者只是一串顏色代碼，後者則說清楚了這個顏色「代表什麼、該用在哪」。W3C 底下的 Design Tokens Community Group 把 design token 定義成一種「vendor-neutral」、可跨工具共享的設計決策格式，講的就是把設計背後的規則抽出來，變成一份機器與人都能引用的資料。
這裡要先分清 token 跟一般「變數」的差別，兩者長得像，用途卻不同。變數存的是純數值，你給它一個名字、塞一個數字進去，它就只記得那個數字。token 存的則是有語意的設計決策，像 color.action.primary 這個名字本身就在告訴讀它的人「這是主要動作用的顏色」，數值只是它的內容之一。換句話說，變數回答「這是多少」，token 回答「這是什麼、拿來做什麼」。對 AI 來說，後面這個資訊才是它守住品牌的依據。
為什麼 AI 生成內容時特別需要這一層？因為 AI 模型對任何品牌都沒有天生的知識。它從海量資料裡學到了「什麼是藍色、什麼是圓角、什麼叫留白」，卻完全不知道你的品牌規則，像是你的主色只能用在哪、標題字級跟內文差幾階、卡片內距固定是多少。這些是你團隊內部才有的約定，模型不可能猜到。
沒有結構化的 design token 時，會發生什麼？你只能靠 prompt 每次重新把品牌規則描述一遍。問題是文字描述本身很不穩。這次寫「深藍色，偏正式」，下次可能寫成「品牌藍，穩重一點」，換個人寫又是另一套形容詞。這種「prompt 漂移」，也就是不同人、不同時間對同一個品牌規則寫出不一致的描述，會讓 AI 抓到的目標一直晃動。結果就是顏色出現微妙偏移、間距抓錯了幾個像素、整體樣式跟品牌對得起來卻又哪裡怪怪的。你以為是 prompt 不夠精準，實際上是這套規則從一開始就沒有一個穩定、可引用的形式讓模型讀。
Design Token 要涵蓋哪些視覺規則
一提到 design token，很多團隊第一個做的是顏色，做完就以為系統建好了。其實顏色只是其中一類，一套真正能讓 AI 守住品牌的 token 系統，要管到的視覺規則比想像中多。把它攤開來看，大致有這幾類：
- 顏色：這是最常被做、也最容易只做一半的類別。除了主色、輔色，還包含文字色、背景色、狀態色（成功、警示、錯誤）等各種用途。DTCG 的穩定版規範甚至把色彩空間擴展到 Display P3 與 Oklch，對齊 CSS Color Module 4。意思是連「同一個藍在不同螢幕、不同平台怎麼呈現」都納進了標準管理範圍，而不只是丟一個十六進位色碼了事。
- 字體：不是一個 token，而是一整組：字體家族（font family）、字重（font weight）、字級（font size）、行高（line height）都要各自命名。例如
font.heading.size對應標題字級、font.body.lineHeight對應內文行高。少了行高與字重的 token，AI 很容易把標題和內文的層次感弄歪。 - 間距：元件之間、內容與邊界之間的距離，像
spacing.card.padding（卡片內距）這種。間距是介面節奏感的來源，卻最常被漏掉，因為它「看不太出來」，可是一旦亂掉，整個版面就會顯得鬆散或擁擠。 - 圓角：按鈕、卡片、輸入框的圓角半徑，例如
radius.button。同一個品牌通常有一套統一的圓角語言，做成 token 才不會這裡圓一點、那裡方一點。 - 陰影：這是台灣團隊特別容易漏做的一類。陰影決定了介面的層次與立體感，
shadow.card、shadow.modal這種 token 沒定好，AI 生成的元件很容易「浮」得不一致，有的重、有的輕，看起來就不像同一套系統。 - 圖示風格：線條粗細、填色或線框、圓角或方角，這些一致性規則同樣可以用 token 或規範描述來管。這也是常被忽略的一類，結果 AI 東拼一個實心圖示、西湊一個線框圖示，風格立刻散掉。
把這六類擺在一起，你會發現，所謂「品牌規範」，具體拆解下來就是這些可以被命名、被引用的規則。只做顏色 token，等於只給了 AI 品牌的四分之一。陰影跟圖示風格這兩塊常常被跳過，偏偏它們又最影響「整體看起來像不像同一個品牌」，補齊它們，AI 才有機會把畫面做得像出自同一雙手。
為什麼同一句 prompt，AI 每次生成的畫面不一樣？
理解了 token 的價值，還有一個更根本的問題要弄清楚。同一句 prompt，AI 每次吐出來的畫面卻不一樣，根源在設計系統跟生成模型是兩種性質完全不同的系統。
設計系統（design system）本質上是確定性（deterministic）的規則，主色就是這個色碼、標題字級就是這一階、卡片內距就是這個數字，一是一、二是二，不會今天這樣明天那樣。但 LLM 這類生成模型本質上是機率性（probabilistic）的，它在每個環節挑的是「最可能」的下一步，而不是「品牌唯一正確」的那一步。當你只丟一段品牌形容詞、沒有給它一個可以強制對齊的錨點時，模型就會往它學過的、最普遍的通用值靠攏。於是你會發現，同一句 prompt 生成的結果一次比一次飄。不是模型壞了，是它從頭到尾都在機率分布裡取樣，而你的品牌規則從來不在它必須遵守的那一格裡。
這個落差不是靠「把話講清楚」就能補起來的，因為問題不在措辭，在於確定性的規則遇上了機率性的生成。這也解釋了一個業界普遍觀察到的現象。AI 寫程式碼、畫介面已經很普及，但大家對它的信任度卻遠遠跟不上。Figma 一份 AI 報告的數字很能說明這件事。已經有 68% 的開發者用 AI 來寫程式碼，可是只有 32% 的設計師與開發者信任這些輸出。用得多、卻信不過，這中間的落差，很大一部分就是輸出不穩定造成的。
還有一個反直覺的陷阱，叫做 context rot（脈絡腐化）。直覺上你會想，那我把整包 token 庫、加上一長串歷史對話，全部塞進 prompt，資訊愈多模型不就愈準嗎？實際上剛好相反。當你一次丟進去的內容太多、太雜，真正關鍵的那幾條規則反而會被淹沒、被稀釋，模型從一大堆資訊裡抓到的，往往是離它最近、最省力的通用值，而不是你埋在中間那條「主色只能用在主要按鈕」的關鍵限制。塞得愈多，訊號愈弱，這就是 context rot，不是餵得不夠，而是餵得太雜，把重點餵糊了。所以問題從來不是「給 AI 的資訊夠不夠」，而是「有沒有用它讀得進去、抓得住的方式給」。
Design Token 怎麼分層，AI 才不會抓錯值
AI 老是往通用值靠攏，關鍵就在 token 的結構安排。分層分得好，AI 每次都能穩穩抓到「該用的那個值」，而不是最底層的原始色碼。一套經得起 AI 使用的 token 系統，通常會拆成三層：原始值、語意層、元件層。這樣分不是為了複雜，而是為了讓 AI 讀的永遠是「有用途說明的那一層」，不是一堆沒有語意的裸數字。DTCG 的穩定版規範也明訂了 token 之間可以有繼承（inheritance）、別名（alias）與元件層級引用（component-level references）的關係，這套分層做法有官方標準背書，不是哪一家工具自己發明的。
底下用三個子步驟，把這三層一層一層拆開講。
第一層：先建原始值（Global／Primitive Token）
最底層叫 global token 或 primitive token，它的功能很單純，只回答「這是什麼值」。這一層放的是純粹的原始數值：一整組色階（color.blue.500、color.blue.600）、一整組字級階、一整組間距階，裡面不含任何用途資訊。它就像顏料盤上排好的顏料，只是把可用的原料備齊，還沒說哪個顏料要畫在哪。
關鍵在於，AI 不該被直接餵這一層。如果你把 color.blue.500 這種原始色階直接丟給生成工具，它就會把這個原始色碼硬編（hardcode）進輸出。表面上顏色沒錯，但你的品牌一旦改色，這些寫死的值全部對不上，而且 AI 也無從判斷這個藍該用在按鈕還是背景。原始值是必要的地基，但地基不該直接曝在外面給人踩。
第二層：疊上語意層（Alias／Semantic Token），這是 AI 該讀的那一層
語意層是整套系統裡最關鍵的一層，也是回答「design token 怎麼讓 AI 讀懂品牌規範」的核心。這一層的 token 不用顏色命名，而用用途命名：color.action.primary（主要動作色）、color.text.primary（主要文字色）、color.background.subtle（次要背景色）。它們自己不存原始數值，而是「別名」，指向底層某個 primitive token，例如 color.action.primary 引用 color.blue.500。
用途命名為什麼比顏色命名更能讓 AI 判斷？因為名字本身就是使用說明。color.action.primary 這個名字直接告訴模型「這是主要動作要用的顏色」，AI 讀到它就知道該把這個值放在主要按鈕、主要連結上，而不會拿去當背景。相對地，如果只給 color.blue.500，模型只知道這是某個藍，卻不知道它的職責，判斷就得靠猜。
語意層還有一個實務上很甜的好處，就是品牌改色時，名稱不必跟著變。假設哪天品牌主色從藍換成綠，你只要把 color.action.primary 的指向從 color.blue.500 改成 color.green.500，所有引用了 color.action.primary 的地方，不管是介面還是 AI 生成流程，全部自動跟著換，名稱一個都不用動。用途是穩定的，顏色是會變的，讓 AI 讀穩定的那一層，它自然不會抓錯。
第三層：對應到實際元件（Component Token）
最上面一層是 component token，它把語意層再收斂到具體的介面元件上，例如 button.background（按鈕背景色）引用 color.action.primary、card.radius（卡片圓角）引用 radius.md。這一層讓每個元件都有自己一組明確的 token，AI 要做一顆按鈕、一張卡片時，能直接對到這個元件該用哪些值。
不過這一層有個常見的過度設計要提醒你，就是不要太早就把每一個元件都做成獨立 token。設計初期元件還在變，這時就給每顆按鈕、每張卡片各自抽一套 token，系統會迅速膨脹到沒人維護得動，而且很多 token 建了之後根本沒被重複用到。比較務實的節奏，是等某個元件真的穩定下來、在多個地方重複出現了，再把它抽成 component token。先讓語意層扛大部分工作，元件層留給那些反覆用、值得單獨管的元件。
Design Token 怎麼餵給 AI 工具，實際落地五步驟
分層架構懂了，最後一哩路是把它接進 AI 工作流程。這一步最容易被跳過，也是最多人「做完 token 卻沒真的用上」的地方。下面這套五步驟，從盤點既有樣式一路走到把 token 餵進 AI、再驗證輸出，你可以照著做。整條路上有三個關鍵反覆出現：先讓 AI 讀語意層、小範圍生成、事後一定驗證。抓住這三點，才不會做了一堆 token，AI 做出來的東西卻還是我行我素。
步驟一：盤點現有色碼、字級與間距，別急著全部 token 化
第一步是回到你既有的設計稿或網站，把重複出現的樣式值抓出來。你多半會發現同一種東西有好幾個相近的值，像間距一下 23px、一下 24px、一下 25px，其實是不同時間、不同人各自量出來的，彼此沒有真正的意義差異。這時要做的是收斂，把這些相近但無意義差異的數字合併成一個標準值，例如統一收成 24px 的間距階，而不是把每個看到的數字都做成一個 token。
為什麼強調「別急著全部 token 化」？因為盤點的目的是理出秩序，不是把混亂原封不動地搬進 token 系統。如果你把 23、24、25 全部各建一個 token，等於把原本的混亂固定下來，AI 讀到三個幾乎一樣的間距 token，反而更不知道該挑哪個。先合併、再命名，token 系統才會乾淨。
步驟二：把 token 整理成 AI 讀得懂的結構化檔案（JSON）
盤點收斂完，下一步是把這些 token 寫成結構化檔案，目前最通用的格式是 JSON。原因很單純，幾乎所有 AI 工具、所有主流程式語言都能解析 JSON，它是設計端與工程端、人與機器之間最沒有摩擦的交換格式。
這裡有個容易漏掉、卻很關鍵的細節。JSON 檔案裡除了數值，還應該寫上每個 token 的描述文字，也就是這個 token 能用在哪、不能用在哪。AI 會把這段描述當成使用限制來讀。舉例來說，你在 color.action.primary 底下附一句「僅用於主要動作按鈕與主要連結，不可作為大面積背景」，模型生成時就多了一條明確的護欄，而不是只拿到一個色碼自己揣摩。數值告訴 AI「是什麼」，描述告訴 AI「怎麼用」，兩者都給，AI 才守得住規矩。
這件事在 2025 年底有了公認標準可以依循。W3C 底下的 Design Tokens Community Group（DTCG）在 2025 年 10 月發布了 design token 規範的第一個正式穩定版，這是一份 vendor-neutral（不綁單一廠商）的格式，由 Adobe、Google、Microsoft、Meta 等 20 多位編輯共同制定，支援多品牌主題化、還能把同一份 token 輸出成 iOS、Android、Web 各平台的程式碼。目前已有 Figma、Style Dictionary、Tokens Studio、Penpot、Sketch、Framer 等 10 多個工具支援或正在導入。這代表現在談 design token，你不必各家各寫一套格式土法煉鋼，而是有一個大家都認的共同標準，不同工具之間交換 token 檔案，終於能對得起來。
步驟三：讓 AI 設計／程式碼工具直接讀取這份規則檔
有了結構化的 token 檔，就能讓 AI 工具在生成前先讀它，而不是憑空產出。這是目前最前沿的落地做法，而且已經不是理論，各大平台都做出了實際的規格。
一個代表性的例子是 Google 旗下 Stitch 推出、並開源出來的 DESIGN.md 格式。它把「先讀規則再生成」這套邏輯做成一份可以匯出、匯入、跨專案共享的規格檔。AI 代理在動手畫介面之前，先讀這份檔案，就能知道每個顏色是做什麼用的，而不必用猜的。更進一步，Google 說明 AI 代理還能拿自己選的值去對照 WCAG 無障礙規則做驗證，確認顏色對比等條件符合標準。Google 特別強調把它開源成草案規格，是為了讓這套做法能跨任何工具、任何平台使用，不綁在單一產品上。
同樣的邏輯也出現在 Figma 的 MCP server 上。它讓 Claude、Cursor 這類 AI 工具能直接讀取 Figma 檔案裡的元件、樣式與變數，把 design token 自動套用進生成的程式碼，對齊品牌與無障礙標準，而不是各自憑空生成。Figma 在說明裡打了個很到位的比方，說叫 AI 代理在沒有設計系統脈絡的情況下寫程式碼，就像叫一個新工程師還沒 onboarding 就開始出貨。這兩個例子指向同一件事。AI 設計系統的前沿，已經從「怎麼把 prompt 寫得更好」轉向「怎麼讓 AI 直接讀到那份規則檔」。
步驟四：分批餵、別一次把整套系統塞給 AI
規則檔就位後，怎麼餵也有講究，這裡最常見的失敗方式，就是把一整套多品牌 token 庫、加上一長串對話紀錄，一次全丟給 AI。前面談過的 context rot 就是這樣發生的，資訊塞太多、太雜，關鍵規則反而被稀釋，模型抓到的是最省力的通用值。
正確做法是依任務只餵相關的 token 子集。如果這次只是要做一張社群貼文圖，那就只給色彩與字體 token，陰影、動效、表單這些用不到的規則沒必要一起塞進去。而且生成時盡量小範圍、分段來，一次生成一個區塊、一顆元件，而不是一口氣叫 AI 生成整個頁面。範圍愈聚焦，模型能守住的規則就愈多；範圍一大，它又會回頭去抓通用值。少即是準，這一步跟直覺相反，卻是實務上差別最大的地方。
步驟五：生成完一定要驗證，AI 有沒有真的照著 token 用
最後這一步最常被跳過，卻也最重要。生成完，一定要回頭驗證 AI 有沒有照著 token 用。這裡有個要認清的現實。就算 AI 讀了 token，它在生成時還是可能「偷懶」，硬編一個相近但不對的色碼，或是抓了一個沒被定義的間距值。讀了規則不等於守了規則。
驗證分兩種輸出來看。程式碼輸出相對好查，直接比對它用的是正確的 token 名稱（color.action.primary），還是寫死了一個裸數值（#2563EB）。如果看到寫死的值，就代表這裡沒守住 token，要抓回來改。視覺輸出（例如生成的圖或畫面）就沒辦法純靠比對名稱了，得靠人工、或是另一個檢視步驟，去對照畫面是否符合品牌規則。前面提到 Stitch 讓 AI 對照 WCAG 驗證顏色對比，就是把「事後驗證」這件事往流程裡再往前收的一種做法。把驗證變成固定習慣，而不是有空才做，這套 token 系統才真的兜得起來，不然前面四步做得再漂亮，最後沒人檢查，AI 一偷懶就前功盡棄。
導入 Design Token 前，團隊該避開的常見錯誤
走完五步驟，最後把幾個最容易讓「做了 token 系統，AI 卻還是亂生成」的地雷整理出來，當作導入前的自我檢核。這些錯誤有個共通點，它們不是技術做不到，而是治理上的疏忽，偏偏 AI 對這類疏忽特別敏感。
第一個地雷是命名只寫顏色、不寫用途。如果你的 token 全叫 blue、darkBlue、lightGray，那 AI 讀到的只是一堆顏色，卻完全沒有判斷依據，它不知道 blue 該用在按鈕還是背景。命名要落在語意層，用途寫進名字裡（color.action.primary），AI 才有規則可循。這是本篇一路強調的核心，也是最多人做錯的一步。
第二個地雷是設計端與程式碼端的 token 各自維護、兩邊對不起來。設計工具裡有一套 token，工程程式碼裡又手動維護另一套，時間一久兩邊必然漂移，設計改了顏色，程式碼那邊沒同步，AI 讀到的到底是哪一套就成了謎。這也正是 DTCG 想解決的問題，用一份 vendor-neutral 的共同格式當單一真相來源，讓設計與工程讀的是同一份 token，而不是各自維護、各自漂移。
第三個地雷是一次把所有樣式都做成獨立 token，系統膨脹到沒人維護得動。前面談元件層時提過這點，太早、太細地把每個元件、每個數值都抽成 token，最後會養出一個龐大、重複、沒版本控制的怪物，維護成本高到大家乾脆繞過它。DTCG 穩定版規範很強調版本化與多品牌主題管理，正是因為一套沒有版本控制、無限膨脹的 token 系統，反而違背了規範一開始想解決的問題。少而準，永遠勝過多而亂。
design token 已經從「設計師關起門來的內部整理習慣」，變成現階段 AI 能不能認得你品牌的基礎設施。DTCG 在 2025 年底把它推上第一個正式穩定版、Google 把 DESIGN.md 開源成人人可用的規格，這兩件事指向同一個訊號。讓 AI 讀懂品牌這件事，已經有了公認的做法，不再是各家自己摸索。所以接下來該做的，其實不是等工具更成熟、等 AI 更聰明，而是先動手把品牌的顏色、字體、間距，整理成一份語意清楚、用途寫明的規則。工具再前沿，也得先有一份讀得懂的規範可讀。把那份規範備好，AI 才有機會真的替你守住品牌。