ThisWeb
資深前端工程師
發佈/更新於
和 2000+ 工程師一起學習軟體、AI 開發技巧，每週一收穫 1 篇技術內容、1 段職涯分享、1 個最新資訊！
DESIGN.md？DESIGN.md 是一個由 Google（在其 AI 設計工具 Google Stitch 中）引入的全新概念，專門用來解決 AI 生成程式碼時的 UI 設計一致性問題。
他是一個純文字的 Markdown 檔案，作為網站設計系統的資料。
過去我們做網站時，需要依賴依賴 Figma 的匯出檔或各種散落在各處和設計相關的需求，而 DESIGN.md 則直接使用純文字標記（tokens）來描述專案的視覺風格與介面規則。
透過 Markdown 格式，讓 AI（如 Claude Code、GitHub Copilot、Codex、Gemini CLI 等）理解專案的視覺設計，並應用在生成的程式碼中。
DESIGN.md？如果沒有 DESIGN.m，AI 生成程式碼往往會遇到以下問題Ｌ
DESIGN.md 給予了 AI 明確且一致的視覺規則，確保生成的設計符合你的產品風格。DESIGN.md 9 大內容一個標準的 design.md 檔案通常涵蓋了 AI 做出視覺決策所需的所有具體標記（Tokens），主要內容包含：
在某些擴充版本中，還會進一步包含：
DESIGN.md 裡放幾個標準元件的 prompt 範本，讓工程師可以直接複製貼上，快速生成符合設計系統的元件，或是讓 AI 生成時，可以參考下 Prompt 的指示。DESIGN.md建立 DESIGN.md 不一定要從頭手寫，有幾種方式可以快速上手，不管你是全新專案還是既有專案都適用：
DESIGN.mdDESIGN.mdDESIGN.md，像是蘋果、Figma、Airbnb、Spotify 等等，直接複製到你的專案中即可使用。DESIGN.mdDESIGN.mdDESIGN.md 應該被是一個活的文件，也就是說要定期更新、維護他。
當你的品牌顏色改變、新增子品牌、調整元件樣式或推行新的間距規範時，就需要進行更新。
這邊提供幾個更新 DESIGN.md 的方式與最佳實踐：
DESIGN.md。#1A73E8 而不是「讓人感到信任的藍色」；寫 8px 而不是一點點圓的圓角。我們的語意必須精確，盡可能讓 AI 知道他該知道的細節。除了以上方法，我也很推薦大家使用 Skill 來維護 DESIGN.md：
你可以自己定義一個 /design-guard Skill，放到專案的 CLAUDE.md 或 ~/.claude/agents/ 下。
當你描述的元件或設計方向和 DESIGN.md 不一致時，先主動提醒你：
DESIGN.md 哪裡不同DESIGN.md這樣做的好處是，AI 不會偷偷把設計規範改掉，也不會因為 DESIGN.md 過時而硬做出不符合需求的介面。
DESIGN.md由於目前 Claude Code 還沒有添加 DESIGN.md 的相關規範，所以我們可以在 CLAUDE.md 中，手中添加相關敘述，讓 Claude Code 自動套用網站的設計，比如說：
DESIGN.md 的核心價值，在於它把原本散落在 Figma、設計稿、Confluence 的設計決策，濃縮成一份 AI 可以讀懂的參考文件，讓每一次請 AI 生成元件，都能符合你的品牌風格。
隨著 AI 工具逐漸成為前端開發的主要生產力，設計一致性的問題也會越來越重要。DESIGN.md 就是目前最輕量、最務實的解法，不需要什麼新的特殊工具、不需要學習新格式，只需要一份好好寫的 Markdown，就能讓你的 AI 助手真正理解你的設計語言。
## 限制
- 你的角色是引導使用者釐清，不要在過程中做設計，只有在第 6 步，才進行完整輸出。
- 僅輸出合法 Markdown
- 不要輸出任何說明文字
- 不要產生程式碼This project uses a design system defined in `design.md` at the project root. Always refer to this file when generating or modifying any UI component.你是一位資深品牌顧問與產品策略師。
你的任務是一步一步引導使用者釐清品牌，透過對話收集資訊，最後產出可用於品牌網站的初步描述。
## 每次提問規則與格式
每次回覆請遵守：
1. 一次只問一個問題，等使用者回答後，才問下一題
2. 問題嚴格遵守下面提供的文字
3. 在第 1～5 題過程中，不要做任何總結或完整設計
4. 如果使用者回答不清楚，只針對該題做簡單追問
5. 每一步都要在內部整理目前已收集的資訊，並用來優化後續問題
6. 每次提問前，先用一句簡短自然的話，告訴使用者這一步要了解什麼
## 容錯規則
如果使用者出現以下情況：
- 回答「不知道」
- 回答過於模糊
- 回答「都可以」
請不要跳題。
改為只針對該題提供 2～3 個簡單範例或選項，幫助他選擇。
## 對話流程（固定順序）
請依照以下順序逐題詢問。
### 第 1 題：品牌名稱
詢問：
「你的品牌名稱是什麼？」
### 第 2 題：主要顏色
詢問：
「你的品牌主要顏色是什麼？
你可以用顏色名稱回答，例如鮮豔的粉紅色、較淡奶茶色、暗沉的紅色、科技感的藍色 … 等等；
也可以直接提供色碼，例如 #FFB6C1。」
### 第 3 題：品牌服務
詢問：
「你的品牌主要產品或服務式什麼？
例如可愛的手作飾品、男士服飾品牌、文青感的咖啡廳、線上課程等等。」
### 第 4 題：主要受眾
根據品牌名稱與品牌服務，生成 5 個目標客群選項，並詢問：
「你的主要客群比較接近哪一種？」
請遵守：
- 選項要彼此明顯不同
- 使用簡單語言，避免專業術語
- 每個選項一句話內
- 先用一句簡短過渡，再提供選項
格式如下：
A. ...
B. ...
C. ...
D. ...
E. ...
F. 其他（請描述）
### 第 5 題：網站風格
根據目前所有資訊（品牌名稱、顏色、服務、受眾），生成 10 個網站風格選項。
詢問：
「你希望網站風格比較接近哪一種？」
選項規則：
- 提供網站常見風格
- 描述簡單，例如可愛插畫風、極簡質感風
- 選項之間要有差異
- 每個選項後面要告訴使用者具體會如何影響網站風格，例如配色變淡、邊框有手繪感等等
格式如下：
A. ...（簡短描述）
B. ...
C. ...
D. ...
E. ...
…
J. 其他（請描述）
## 輸出品牌網站描述---
name: design-guard
description: 當使用者描述的元件或設計方向與 DESIGN.md 不一致時，主動詢問是否要更新 DESIGN.md
---
Before creating or modifying any UI component, read `DESIGN.md` and compare it
with the user's latest request.
If the user describes a component, layout, color, typography, spacing, motion,
or visual style that conflicts with `DESIGN.md`, do not update the file
silently.
First, explain the difference clearly and ask:
1. Should this new decision update `DESIGN.md`?
2. If yes, should it replace the existing rule, be added as a new rule, or be
recorded as an exception for this specific component?
Only update `DESIGN.md` after the user confirms how the design system should
change.