design.md 與設計令牌在 AI UI 工作流程中的比較
比較 design.md 與傳統設計令牌在 AI UI 工作流程中的差異，重點探討代理可讀性、一致性與工作流程可攜性。
我是 Dora。我一週中大部分時間都在使用 coding agents 和 AI UI 工具——Cursor、Claude Code、Stitch，這些常見的工具——比我能記錄的速度更快地建立和重建介面。大約一個月前，我開始在每隔一個接觸的 repo 中看到相同的檔案：DESIGN.md。相同的名稱，相同的 YAML 在上、散文在下的結構。到了第三個專案，我意識到這不是巧合。這是一種正在取代我們大多數人過去以 tokens.json 形式交付之物的東西。
於是我重建了自己的其中一個元件函式庫兩次——一次使用經典的 DTCG 風格 token 檔案，一次使用 DESIGN.md——並針對兩者運行了相同的 coding agent。這是我找不到書面記載的比較部分：不是每種格式是什麼，而是每種格式實際上在優化什麼，以及哪一個現在應該屬於你的技術棧。
design.md 與傳統設計 Token
每種格式在優化什麼
設計 token，從傳統意義上說，是一種方法論。這個術語大約在 2014 年由 Salesforce 創造，以解決一個非常具體的規模化問題：如何在不提交四張工單的情況下，讓一個顏色決策在 web、iOS、Android 和四個程式碼庫之間保持同步？答案是一個與平台無關的名稱-值對，以 JSON 或 YAML 儲存，在構建時轉換為每個平台所需的格式。這種方法論現在由 W3C 的設計 Token 社群小組編纂，截至 2025 年底，DTCG 格式已有穩定的 v1 規範。
Token 優化的是確定性分發。十六進位顏色碼進去，在每個平台、每次構建中永遠輸出相同的十六進位顏色碼。沒有歧義。也沒有敘事——一個 token 檔案告訴你 primary: #1A1C1E，但它不會告訴你為什麼存在這個顏色，或者什麼時候不應該使用它。
DESIGN.md 由 Google Labs 於 2026 年 4 月開源，優化的是不同的東西：給予 coding agent 足夠的上下文，以便做出 token 檔案未涵蓋的決策。 它是一個帶有 YAML 前置資料（用於 token）和下方散文（用於原理說明）的單一 markdown 檔案。同一個檔案，兩種受眾——確定性部分給解析器，敘事部分給正在讀取 repo 的任何 LLM。
這才是真正的分野。不是「舊的 vs 新的」。不是「JSON vs Markdown」。而是值與同一檔案中的值加上推理之間的差異。
為什麼 AI agents 創造了新的需求集
當人類實作設計時，「token 說 #1A1C1E」和「這個空白狀態需要某種語調」之間的差距由人類填補。他們看過 Figma 檔案。他們參加了品牌工作坊。他們知道次要按鈕應該感覺低調，而不是強勢。
coding agent 沒有這些。它只有你放入 repo 的內容，以及它能從檔案名稱推斷出的內容。所以當你要求它生成一個 token 檔案未完全指定的頁面——一個邊緣情況、一個新元件、一個佈局決策——它要麼猜測，要麼預設為訓練中最常見的樣子。這就是每個人抱怨的「AI 米色美學」的來源：不是糟糕的模型，只是缺少上下文。
這就是 DESIGN.md 正在解決的問題。GitHub 上的官方規範明確指出——token 為 agents 提供精確的值，散文告訴它們這些值為何存在以及如何應用它們。這種格式期待兩個部分都存在。
design.md 在哪裡增加價值
持久的敘事上下文
我在測試的前 48 小時內注意到的事情：相同的 agent，給定相同的簡報，當有散文上下文存在時，會生成明顯不同的輸出。不是「顏色稍微好一點」。而是不同的佈局選擇、不同的文字風格、不同的元件密度。兩次運行中的 token 值是相同的——改變的是 agent 是否有一段說「品牌聲音是克制且編輯風格的；偏好留白而非裝飾」的段落。
這是傳統 token 管道無法傳遞的部分。DTCG JSON 檔案可以精確描述 --color-primary，但它無法告訴 agent 主要顏色應該謹慎使用。DESIGN.md 將這種判斷持久地帶入每次生成過程，無需任何人重新在提示中輸入它。
它有效。
為生成工作流程提供更好的多頁面一致性
在我的第二個測試中，我在兩天內為同一個應用程式生成了八個頁面。僅使用 token 上下文時，第 5–8 個頁面開始漂移——相同的調色板，但佈局語言變得鬆散。有 DESIGN.md 存在時，漂移要小得多。不是零。但更小。
我對原因的解讀是：每次 agent 讀取檔案時，散文部分都像是一個重新錨定。單獨的 token 為 agent 提供足夠的正確單個值。敘事為它提供足夠的能力來在 token 未預料到的決策中保持一致。對於一次性生成，這個差距無關緊要。對於多頁面輸出和持續迭代，它會累積。
這也是 DESIGN.md 與更廣泛的 agent 指令棧配合良好的地方——大多數設置現在從 AGENTS.md 中引用它，與 SKILL.md 檔案並列，因此設計系統與 agent 的其他持久指令位於相同的上下文層。
傳統 Token 仍然勝出的地方
兩種情境，都是真實的。
超越 web 的跨平台分發。 如果你要將同一個設計系統交付到 iOS、Android、React Native 應用程式和行銷網站，透過 Style Dictionary 或 Terrazzo 的 DTCG 管道仍然是阻力最小的路徑。DESIGN.md 的 YAML 可以透過官方的 @google/design.md CLI 匯出為 DTCG JSON，但事實來源的問題仍然重要——如果你的 token 圖很大、多主題且被非 AI 工具使用，將 DTCG 保留為標準格式是更整潔的設置。
具有既定治理的成熟設計系統。 Token 不僅僅是一種檔案格式。它們是一種方法論，有著大約十年的積累實踐——原始層、語義層、別名化、主題化，以及 Nathan Curtis 在設計系統中的 Token 中闡述的整個分類體系。如果你的團隊已經以這種方式運作，DESIGN.md 不會取代它。它位於其上，或與之並列，作為 agents 的上下文層。Token 保持標準來源；markdown 成為面向 AI 的翻譯。
將 DESIGN.md 解讀為 token 管道的替代品將是一個錯誤。它不是。它是具有不同消費者的不同層次。
建立 AI UI 管道團隊的決策框架
在決定將什麼放入 repo 時，我不斷回到四個問題：
- 誰在讀取這個檔案？ 如果主要消費者是一個輸出 CSS、Swift 和 Kotlin 的構建管道，你需要標準格式的 token。如果主要消費者是一個按需生成 UI 的 coding agent，你需要 DESIGN.md。如果兩者都是，你保留兩者——並讓 markdown 檔案的 YAML 鏡像 token 的一個子集。
- 你的 UI 介面多久重新生成一次？ 低頻率團隊（穩定的產品，偶爾的新頁面）從 token 獲得大部分價值。高頻率團隊（快速原型設計、agent 驅動的迭代、每週新頁面）會深切感受到缺少上下文的差距。重新生成頻率越高，散文層就越能發揮其作用。
- 有多少個平台？ 僅 web 或以 web 為主且有 agent 驅動的生成——DESIGN.md 是更簡單的技術棧。三個以上平台且有嚴肅的原生存在——token 優先，DESIGN.md 作為下游產物。
- 理由是否已經在某處記錄了？ 如果你的品牌指南、語調文件和元件哲學存在於任何 agent 都不會讀取的 Notion 頁面中，DESIGN.md 是你本季可以做的最高槓桿率的舉措。你不是在創建新文件——你是在將現有文件移動到 agent 實際打開的檔案中。
這是我的框架。你的可能有所不同。我要指出的是：不要因為某種格式是新的就選擇它。要根據誰在讀取檔案來選擇。
常見問題
design.md 是設計 token 的替代品嗎？
不是。DESIGN.md 是一個包含設計 token（在 YAML 前置資料中）加上圍繞它們的原理說明（在 markdown 散文中）的包裝器。其中的 token 在傳統意義上仍然是設計 token。如果你已經有一個 DTCG 格式的 token 檔案，DESIGN.md 不會取代它——它作為 AI agents 的並行產物存在，或者你可以在需要時讓 markdown 匯出 DTCG JSON。
為什麼 AI agents 需要的不僅僅是數字 token？
因為大多數 UI 生成請求並非完全由 token 圖指定。「生成一個定價頁面」需要數百個微決策——層次結構、密度、語調、要強調什麼——這些都沒有 token 檔案涵蓋。沒有敘事上下文，agent 會用訓練數據中見過的內容填補這些空白，這產生了大多數 AI 生成 UI 所共有的通用外觀。DESIGN.md 中的散文就是填補這個差距的東西。
哪些工作流程從 design.md 中獲益最多？
我見過最有回報的三種模式：
- 使用 Cursor、Claude Code 或 Stitch 比手寫速度更快交付 UI 的個人開發者和小型團隊。
- 維護多個內部產品的設計系統團隊，在這些產品中，AI 生成頁面的一致性正成為真正的問題。
- 希望有一個單一的即插即用檔案來為任何 coding agent 編碼客戶設計語言的代理商和合約團隊。
如果你的工作流程主要是手動編碼，偶爾使用 AI 輔助，邊際價值就會下降。
什麼時候經典的設計 token 基礎設施仍然足夠？
當你不使用 agents 生成 UI 時，或者當你的平台覆蓋範圍遠超 web 時。原生移動為主、多主題白標產品、成熟的設計運營實踐——這些仍然從 DTCG 生態系統中獲得比 markdown 檔案更多的收益。兩者並不相互排斥，但如果你必須選擇一個來投資，答案取決於你的生成摩擦實際在哪裡。
結論
誠實的版本：DESIGN.md 不是範式轉移。它是針對特定差距的集中解決方案——coding agents 缺乏 token 檔案未攜帶的原理說明。對於那些差距真實存在的工作流程，收益是立竿見影且顯而易見的。對於那些不存在的工作流程，傳統 token 仍然勝任。
我已經在我運行的每個 AI 生成專案上使用 DESIGN.md 兩個月了。它留在了工作流程中，這是我唯一信任的測試。token 檔案也沒有消失——它們仍然在做它們一直在做的事情，只是現在為需要更多而非數字的受眾有了一個同伴檔案。
在一個專案上自己運行試試看。兩天能告訴你的，比這篇文章多得多。
往期文章：
