今天中午：Google Labs 正式開源 DESIGN.md 設計規範

今天中午，Google Labs 正式開源了 DESIGN.md 設計規範，推進其成為標準，以便它可以在任何工具或平台上使用，並且官方還在繼續添加新功能。

倉庫地址為：github.com/google-labs-code/design.md

倉庫核心：一份文件，搞定設計系統的“雙向溝通”

DESIGN.md的核心創新，在於它採用了“機器可讀token + 人類可讀rationale”的雙層結構，簡單說，就是既給AI明確的“執行標準”，也給人清晰的“設計邏輯”，徹底解決了“AI懂數值，不懂意圖”的痛點。

1. 機器層：YAML Front Matter

文件頂部用---包裹的YAML部分，是給AI看的“精確指令”，定義了所有設計token，涵蓋5大核心模塊，每一項都有明確規範，倉庫給出的標準示例如下：

---
name: Heritage
colors:
  primary: "#1A1C1E"
  secondary: "#6C7278"
  tertiary: "#B8422E"
  neutral: "#F7F5F2"
typography:
  h1:
    fontFamily: Public Sans
    fontSize: 3rem
  body-md:
    fontFamily: Public Sans
    fontSize: 1rem
  label-caps:
    fontFamily: Space Grotesk
    fontSize: 0.75rem
rounded:
  sm: 4px
  md: 8px
spacing:
  sm: 8px
  md: 16px
---

• colors：語義化命名+十六進制色值（sRGB格式），比如primary: "#1A1C1E"（主色）、tertiary: "#B8422E"（強調色，倉庫稱其為“Boston Clay”），避免AI亂猜品牌色；
• typography：明確字體家族、字號、字重等，比如h1用Public Sans字體、3rem字號，body-md用1rem字號，確保排版統一；
• rounded/spacing：圓角和間距的階梯尺度，比如sm（小）為4px、md（中）為8px/16px，規範界面細節；
• components：組件級token，支持{path.to.token}格式的跨token引用，比如按鈕背景色直接引用{colors.tertiary}，減少重複定義，也避免偏差，變體（懸停、激活等）以獨立組件條目形式關聯命名。
  
  
  
  

2. 人類層：Markdown Body（傳遞設計意圖）

YAML下方的Markdown正文，是給設計師、開發者看的“設計說明書”，用自然語言解釋“為什麼這麼設計”以及“如何應用”。

更貼心的是，它規定了8個固定順序的章節（可省略，但存在即需按順序），確保規範的完整性和可讀性，倉庫明確的章節順序及別名如下：

1. Overview（品牌與風格總覽）：定調設計氣質，比如倉庫示例中的“建築極簡與新聞莊重感結合”，營造高端報紙或現代畫廊的質感；
2. Colors（色彩角色與情感）：說明每種顏色的用途，比如主色用於標題和核心文本，強調色用於交互元素，中性色作為頁面基礎；
3. Typography（排版氣質）：解讀字體選擇邏輯，比如無襯線字體傳遞簡潔專業感，不同字號適配不同層級內容；
4. Layout（佈局與留白策略）：明確頁面佈局原則和留白規範，確保頁面整潔有序；
5. Elevation & Depth（層級與陰影）：定義界面層次的表現方式，比如通過色調分層替代厚重陰影；
6. Shapes（形狀語言）：規範圓角、邊框等形狀設計，統一界面視覺風格；
7. Components（組件規範）：詳細說明按鈕、輸入框等核心組件的樣式及變體，明確組件屬性（如backgroundColor、textColor等）；
8. Do's and Don'ts（設計禁區）：明確禁止的設計行為，避免踩坑，比如禁止混合圓角和尖角元素。
   
   

對設計師意味着什麼？

DESIGN.md 格式足夠簡單——它本質上就是一個 Markdown 文件，設計師用任何文本編輯器都能寫，版本控制用 Git 就能管。

更長遠來看，如果 DESIGN.md 成為行業標準，意味着：

• 設計系統可以隨代碼倉庫一起版本化；
• AI 能準確精細的理解設計規範和需求
• 設計規範的維護成本大幅降低

在DESIGN.md出現之前，設計系統多以Figma文件、文檔等形式存在，AI無法直接讀取，跨工具、跨團隊協作時規範傳遞極易偏差。而Google Labs的開源，給行業提供了一個統一的、可機器讀取的設計規範標準。

它的意義遠不止“方便AI生成設計”：對設計師而言，無需反覆向AI和開發者解釋設計意圖，減少溝通成本；對開發者而言，有了明確的token標準，還原設計更精準，避免反覆修改；對行業而言，統一的規範格式，讓設計系統可複用、可迭代，也已經有開發者整理了大量知名品牌的DESIGN.md文件，推動其成為行業通用標準。

CLI 工具鏈：驗證、對比與導出

倉庫最貼心的地方，是自帶了@google/design.md CLI命令行工具，無需複雜配置，新手也能快速上手，可通過npm install @google/design.md安裝，或直接用npx運行，核心4個命令覆蓋設計規範的全流程需求，每個命令都有明確的使用場景和輸出格式：

1. lint：規範校驗，規避錯誤

執行npx @google/design.md lint DESIGN.md，就能自動校驗文件結構、檢查token引用是否完整，驗證 DESIGN.md 文件的結構正確性。示例輸出如下：

{
  "findings": [
    {
      "severity": "warning",
      "path": "components.button-primary",
      "message": "textColor (#ffffff) on backgroundColor (#1A1C1E) has contrast ratio 15.42:1 — passes WCAG AA."
    }
  ],
  "summary": { "errors": 0, "warnings": 1, "info": 1 }
}

若發現錯誤，命令退出碼為1，否則為0，方便集成到自動化流程中。

2. diff：版本對比，追溯變化

當設計系統迭代時，用npx @google/design.md diff DESIGN.md DESIGN-v2.md，就能快速對比兩個版本的差異。示例輸出如下：

{  "tokens": {    "colors": { "added": ["accent"], "removed": [], "modified": ["tertiary"] },    "typography": { "added": [], "removed": [], "modified": [] }  },  "regression": false}

若檢測到“after”文件中錯誤或警告更多（迴歸問題），命令退出碼為1。

3. export：多格式適配，無縫銜接開發

導出 DESIGN.md 標記到其他格式（tailwind, dtcg），核心命令如下：

npx @google/design.md export --format tailwind DESIGN.md > tailwind.theme.json

npx @google/design.md export --format dtcg DESIGN.md > tokens.json

其中dtcg格式對接W3C設計令牌格式模塊，進一步提升設計令牌的跨工具互操作性。

4. spec：輸出規範，輔助AI提示

執行 npx @google/design.md spec，可直接輸出完整的DESIGN.md規範：

npx @google/design.md spec

npx @google/design.md spec --rules

npx @google/design.md spec --rules-only --format json

最後

目前，DESIGN.md處於alpha版本，Google Labs仍在持續迭代優化，但它已經展現出強大的潛力——它不是要替代設計師，而是要成為設計師、開發者和AI的“溝通橋樑”，讓設計規範真正落地，讓創意更專注於核心價值。倉庫也明確說明，規範、token模式以及CLI正在積極開發中，隨着格式的成熟，可能會有進一步的更新。

倉庫地址為：github.com/google-labs-code/design.md

關於 DESIGN.md 其他系列文章：

從 DESIGN.md 得到啓發，我重構和開源了公眾號排版工具

輸入任何網站生成一個 DESIGN.md 設計規範

昨天才開源的瀏覽器擴展：一鍵獲取任意網站 DESIGN.md