前言

「ㄟ...怎麼感覺 AI 這次修改的畫面跟我原本的風格不同？」

這不是你的錯覺，是非常常見的狀況。

畢竟我們當初討論的所有設計風格（色票、間距、按鈕層級、文案語氣）都只存在那個對話的 context 裡，只要你關掉 or /clear 開新對話，這些東西就會全部消失，除非你有特別跟 AI 說要把這些設計決定寫成文件鎖起來，否則它會一直重新即興發揮跟猜測。

所以為了解決這件事情，這章節我們將會來介紹一個東西，就叫做 設計文件（DESIGN.md）。

站在巨人的肩膀上 DESIGN.md

那為什麼我們會需要這個章節與設計文件呢？最主要原因是 AI 每次做的畫面風格都不一樣，因為設計決定通常只存在於當前對話的 context 裡，只要對話結束就消失了。

接著你只要請 AI 開發新功能、新元件，儘管 AI 會去分析跟尋找上次的設計決定以及透過閱讀程式碼去推測，但它也很難做對，然後就會導致各種畫面不平衡問題（如按鈕顏色不一致、間距不一致、字型大小不一致...），所以我們需要一份設計文件來鎖住風格。

那問題來了，所以我們該怎麼解決這問題呢？這邊剛好有一個好消息要跟你講，Google 幫我們準備了一套設計文件的標準格式，叫做 DESIGN.md。

這個東西其實是源自 Stitch 這款 AI 設計工具，只要你用一句話描述就能夠產出 UI 畫面，而 DESIGN.md 就是從 Stitch 孵化出來的設計系統格式，後來在 2026 年由 Google Labs 開源到 GitHub 上，目標是讓所有的 AI 工具（Claude Code、Cursor、Copilot...）都能用同一套格式讀懂你的設計系統。

Note
你可能會注意到官方專案跟 npm 套件的名稱是小寫的 design.md（等等的指令裡就會看到），不過為了閱讀上的一致，這篇我一律用大寫的 DESIGN.md 來稱呼它。

那這套 DESIGN.md 怎麼解決呢？這邊讓我舉例一下情境，假設你請 AI 製作一顆藍色的按鈕，AI 可能會這樣.....

• 第一次： #3B82F6
• 第二次： #2563EB
• 第三次： bg-blue-500

雖然三者都是藍色，但...實際上還是有一點差異，那這個微妙的差異就會導致畫面不平衡甚至奇怪，更不用說套用到產品上會有問題。

「那我把這些規則寫到 CLAUDE.md 不就好了？CLAUDE.md 不是最高憲法嗎？」

我相信你馬上就想到這件事情，我認為這確實是一種解法，但實際上 DESIGN.md 的做法會更好，因為它把設計決定拆成兩層：

• YAML front matter：放精確的設計 token（色碼、字型、間距、圓角、元件），這是給機器精準讀取用的。
• Markdown 內文：放設計理由，為什麼選這個顏色、什麼時候用、什麼時候不准用，這是給人（跟 AI）讀的。

這樣 AI 不只是知道「主色是 #245C4A」，它還能夠知道「這個綠只能用於哪邊」，甚至整體的設計理念是什麼，那這樣就可以大幅降低用錯顏色的可能性。

讓它自己交設計文件

那我們到底該怎麼寫這個 DESIGN.md 呢？我相信這是滿多人的疑問，而答案就是：請 AI 自己整理並撰寫成 DESIGN.md 啦～

還記得昨天 Prompt 的最後一句「改完告訴我你做了哪些設計決定跟理由」嗎？其實那句就是為了今天鋪的路，畢竟整個改造過程中做最多設計決定的就是 AI 自己，這些決定它最清楚，由它來寫這份文件再適合不過。

做法很簡單，直接輸入以下 Prompt 就可以了（這邊只需要使用 manual mode on or accept edits on 模式就可以，不需要額外使用 Plan Mode）：

請執行 `npx @google/design.md spec` 了解 DESIGN.md 所需要的格式規範，然後把這個專案目前的設計決定整理成一份符合規範的 DESIGN.md 並放在根目錄下，內容必須以實際的程式碼為準（色碼請對照 src/style.css 的 token）。

Markdown 內文除了官方推薦的章節之外，請額外加一節「響應式與無障礙驗收」，把 375px / 768px、按鈕至少 44px 高這些驗收條件寫進去。

如果 CLAUDE.md 裡已經有樣式相關的規則，請一併搬進 DESIGN.md，不要兩邊各留一份。

之後任何畫面相關的改動，都必須遵守 DESIGN.md 的規範，不能再憑印象亂改，所以請在 CLAUDE.md 的開頭加上這一行：
規格見 @SPEC.md，設計規範見 @DESIGN.md，畫面相關的改動一律遵守設計規範。

那看到這邊我相信你應該充滿問號，別擔心，我這邊特別針對三個地方解釋一下：

• 第一段的 npx @google/design.md spec： 這一行指令會輸出「一份標準的 DESIGN.md 應該要長什麼樣子」的格式規範，所以其實就是請 AI 先讀完 DESIGN.md 規範再開始，這樣它寫出來的檔案才會符合標準，而不是自己想像一份出來。
• 第三段的「請一併搬進 DESIGN.md」： 這個是因為要避免一個規則放兩處的問題， 如果你沒這樣做，有很大機率會遇到「改了 A 忘了改 B」，最後就變成文件打架，所以就趁現在調整一下，讓設計規範只住在 DESIGN.md 一個地方。
• 最後一段的 @SPEC.md / @DESIGN.md： 這一行的最核心目的是讓 AI 之後每次開啟新的對話都會自動讀到設計規範（DESIGN.md），至於 @ 呢......等我後面再來解釋。

那底下這邊我也簡單摘錄一些 DESIGN.md 的內容給你參考，完整的檔案請直接看專案裡的 DESIGN.md：

---
version: alpha
name: Money Note 暖色紙本帳冊
description: 單人記帳工具的設計系統。紙底墨字、帳冊欄位線、合計雙底線，數字優先，不做藍白後台。
colors:
  # === 底色 ===
  paper: "#F3EFE7"
  card: "#FFFDF8"
  # === 墨色 ===
  ink: "#1F2925"
  ink-soft: "#56625C"

... 略過一堆

# Money Note 設計規範

實作規格見 [SPEC.md](./SPEC.md)。這份文件只管畫面長什麼樣子：色票、字級、間距、元件狀態與驗收條件。

**唯一真實來源是程式碼裡的 token。** YAML front matter 的值與 `src/style.css` 的 `@theme` 區塊、`src/constants/categories.js` 逐一對應，改一邊就要改另一邊。

## Overview

Money Note 是一個人用的記帳工具。核心情境是「花完錢的當下，站在超商門口拿手機記一筆」，所以整套視覺只服務一件事：**讓數字最快被讀到、最快被寫進去。**

視覺方向是**暖色紙本帳冊**，不是後台管理介面。畫面應該讀起來像一本翻開的手記帳冊：米黃紙底、深墨字、橫向欄位線一列一筆、金額欄有一條直線把錢跟文字分開、月總額下面壓一條會計慣例的合計雙底線。

帳冊的三種線本身就帶著資訊（一列一筆、錢與文字分欄、單線小計雙線總計），拿來當版面骨架就不需要另外加裝飾。**層級一律靠線條粗細與紙／卡兩層底色差建立，不靠陰影、不靠圓角、不靠顏色數量。**

情緒上要安靜、可信、耐看，接近「工具」而不是「App」。不做漸層、玻璃效果、emoji 功能圖示、浮誇陰影、彩色標籤牆。畫面上最亮眼的東西永遠是那個月總額的數字，其他全部退到它後面。

很方便吧？叫 AI 自己整理就好，這樣你就不用自己去想 YAML 格式、Markdown 章節要怎麼寫了。

設計文件也有 Lint

什麼叫做「設計文件也有 Lint」呢？簡單來講，Lint 就是「檢查」特定格式的工具，像是 ESLint、Stylelint、Markdownlint 都是這種東西，而 DESIGN.md 呢？它當然也有屬於自己的 Lint。

那為什麼會特別介紹這個呢？畢竟 AI 有沒有寫對格式，如果你沒有熟悉 DESIGN.md 的話，很難透過肉眼抓出來，但剛好官方就有提供一套 Lint 工具幫助我們，所以你可以輸入以下 Prompt 告知 AI 來幫你檢查 DESIGN.md 是否有問題：

請使用 `npx @google/design.md lint DESIGN.md` 指令檢查 DESIGN.md 是否符合 DESIGN.md 規範，請把檢查結果回報給我。

那這個 lint 做了哪些事情呢？主要是以下：

• YAML 結構對不對、colors 裡有沒有給必填的 primary、推薦章節有沒有缺
• token 引用有沒有壞掉（像是 {colors.primery} 少了一個 a，或是用了規範不認識的屬性）
• 有沒有「定義了卻沒人用」的 orphan token
• WCAG AA 對比度有沒有過

所以是不是超方便的呢？

Note
Windows 使用者如果發現 DESIGN.md 沒有反應，那可能是 .md 被檔案關聯吃了，你可以試著改用 npx -p @google/design.md designmd lint DESIGN.md 試試看。

加入到憲法

前面講了那麼多，你可不要以為這樣就結束了，儘管有 DESGIN.md 這份設計文件幫忙控制，但你必須要讓它每次開新對話都會自動讀到這份文件，否則它還是會忘記。

所以我們要在 CLAUDE.md 裡加上這一行：

規格請看 @SPEC.md，設計規範則是 @DESIGN.md，只要跟畫面相關的調整一律必須遵守 DESIGN.md 的規範。

當然，你也可以直接把這句話丟給 AI 讓它幫你加上去，這樣就不用自己手動改了。

請在 CLAUDE.md 的開頭加上這一行：
規格請看 @SPEC.md，設計規範則是 @DESIGN.md，只要跟畫面相關的調整一律必須遵守 DESIGN.md 的規範。

那麼接下來你應該會很好奇 @ 是什麼東西，儘管前面我們有寫過類似的「請你閱讀 @SPEC.md」這種語法，但在這邊可以提一下，不同的地方使用起來效果不太一樣：

• 對話中的 @： 只有「這一次對話」會讀那份檔案。
• CLAUDE.md 裡的 @： 這是 CLAUDE.md 的 import 語法（引入這個檔案），每次開新對話都會自動把那份檔案一起載入。

理解之後，我們回頭看一下目前的行為，其實整個核心的文件大致上都到齊了，你沒注意到？其實這些文件各自的角色是：

• SPEC.md： 管「做什麼」
• CLAUDE.md： 管「怎麼做」
• DESIGN.md： 管「長怎樣」

而且這些檔案都不會因為對話結束而消失，每次開一次開啟新的對話時，CLAUDE.md 都會自動把 SPEC.md 與 DESIGN.md 讀進來，這樣就不會忘記規格與設計決定了。

所以真的鎖的住嗎？

都把 DESIGN.md 寫好了，CLAUDE.md 也加上了 @DESIGN.md，那真的就鎖住風格了嗎？我覺得這是大家的疑問，所以這邊我們就試著來做一個實驗，看看 DESIGN.md 的規範是否真的有鎖住風格。

首先，請你打開一個全新的對話（輸入 /clear），然後輸入以下 Prompt（別忘了切 Plan Mode）：

請在「記一筆」跟「支出明細」這兩個標題上方，分別加上「新增紀錄」與「最近紀錄」的小型 section 標籤。

接著你應該會看到 AI 思考的過程，確實有去參考 DESIGN.md，那這就代表我們所期望的風格固定是有做到的。

結語

那今天時間也差不多了，一樣幫你把重點收一收：

• 畫面風格會跟著對話一起蒸發，解法是把設計決定寫成 DESIGN.md，而且格式不用自己發明，直接用 Google Labs 開源的 design.md 規範：YAML 放精確的設計 token、Markdown 放設計理由。
• 用 @DESIGN.md 掛進 CLAUDE.md 之後每次對話自動載入三份核心文件：
  • SPEC.md 管做什麼。
  • CLAUDE.md 管怎麼做。
  • DESIGN.md 管長怎樣。

那如果問題我們下一篇見囉～