<我做了一個開源的設計工作台：管理 & 編輯 & 生成 DESIGN.md>

原始來源與檔名：2026-09-04T094457+0800-我做了一个开源的设计工作台：管理 & 编辑 & 生成 DESIGN.md

SOURCE | 資訊源評估

• 準確性: 高 - 作者親自介紹其開源專案 (RICOUI DESIGN) 的設計理念、架構與使用方式。
• 易理解性: 高 - 透過清晰的表格、使用場景劃分（看 vs 做）與架構圖，清楚說明 DESIGN.md 的結構與價值。
• 閱讀策略建議: 適合設計師與前端工程師閱讀。重點關注 DESIGN.md 的骨架結構，以及如何將「不該怎麼做 (Don’ts)」納入給 AI 的提示詞中。

NAPKIN | 餐巾紙

餐巾紙公式

DESIGN.md = Design Tokens (顏色/排版/間距) + 組件約束 + Do’s and Don’ts 一份人類好讀、AI 易懂，並能自動派生 CSS 與 JSON 的唯一設計真相源 (Single Source of Truth)。

一句話

作者開源了一個名為 RICOUI DESIGN 的工作台，推廣使用 DESIGN.md 作為介於 Figma 與前端程式碼之間的橋樑，讓 AI 與開發者能準確理解並生成符合品牌規範的介面。

餐巾紙草圖

+-----------------------+
| 參考源 (Brands/網址)    | -> (AI 萃取)
+-----------------------+      |
                               v
                     +-------------------+
                     |    DESIGN.md      | (唯一維護的源文件)
                     | - 結構化 Markdown   |
                     | - 包含品質護欄       |
                     +-------------------+
                       /       |       \
                     /         |         \ (自動派生檢查)
                   v           v           v
          +---------+   +----------+   +----------+
          |  預覽視圖 |   | Token JSON |   | CSS 變數 |
          +---------+   +----------+   +----------+
          (設計師看)     (前端工程師用)   (AI 工具用)

ROUND 1: SKELETON | 骨架掃描

“這本書在說什麼”

• 核心問題: 設計規範散落在 Figma、協作文件和程式碼中，難以維護，且現有的 Design Token 無法有效告訴 AI「組件該怎麼用」以及「不該做什麼」。
• 核心答案: 建立一個基於 Markdown 的標準化文件 DESIGN.md 作為唯一事實來源，並透過工作台進行視覺化編輯、預覽，再自動派生出開發所需的 CSS 與 JSON。
• 論證結構: 痛點與解法介紹 -> 解釋 DESIGN.md 的結構與意義 -> 產品功能走查 (看與做) -> 不同角色的獲益 -> 雲端與開源部署說明 -> 核心設計哲學。

章節骨架

1. 背景與痛點: 品牌庫好用但難以直接轉化為專案規範，設計細節容易遺忘。
2. DESIGN.md 是什麼: 一套固定的 Markdown 骨架 (包含 Tokens, Components, Do’s and Don’ts)，人類與 AI 皆可讀。
3. 工作台功能 - 看與做: 從品牌庫找靈感 (看)，到修改、建立與交付自己的規範 (做)。
4. 角色收益: 設計師得視覺控制、前端得代碼、AI 得上下文。
5. AI 輔助生成: 可輸入公開網址，讓 AI 萃取並起草 DESIGN.md (作為分析起點而非精確複製)。
6. 派生與安全機制: 只有通過校驗的 MD 才能匯出 CSS/JSON，避免產生錯誤依賴。

ROUND 2: DISSECTION | 血肉解剖

“憑什麼這麼說”

論證鏈

Figma 專注於視覺，Design Token 僅包含原子數值，兩者都缺乏語意化的設計上下文 --> 透過建立 DESIGN.md，將數值與「設計決策 (約束與禁忌)」結合 --> AI 獲得了完整的上下文，能寫出更符合品牌規範的程式碼，同時前端也免去了手動維護 Token 的麻煩。

關鍵證據

1. 品質護欄 (Do’s and Don’ts) 的價值: 作者指出，告訴 AI「不隨意增加新的強調色」或「不同時出現多個主要按鈕」，往往比單純給 AI 一個色值更能防止設計崩壞。
2. 單一真實來源 (SSOT): 實務上，若允許修改產出的 JSON 或 CSS，會導致規範立刻與設計稿脫節。因此系統設計為「CSS 匯出會被鎖住，除非 DESIGN.md 通過語法與變數引用檢查」。

隱形假設與邊界

• 隱形假設:
  • AI (如 Claude, Cursor) 具備足夠的 Markdown 閱讀與理解能力，能嚴格遵循文件中的約束。
• 邊界條件:
  • 透過網址自動生成 DESIGN.md 僅能作為「分析起點」，無法 100% 準確還原複雜網站的佈局層級與隱藏狀態。

ROUND 3: SOUL | 靈魂提取

“還能怎麼用”

• 作者盲點: 對於大型企業中「多品牌 (Multi-brand)」或「多主題 (Multi-theme, 如高對比模式)」在單一 Markdown 中的組織與繼承方式，說明較少。
• 知識連接: 此概念與基礎設施即代碼 (Infrastructure as Code) 中的宣告式配置 (Declarative Configuration) 類似，將「設計」宣告為一份文本，再由系統編譯 (派生) 為各種最終產物。
• 行動觸發: 在團隊的 Frontend Repo 根目錄下建立一份 DESIGN.md，並把「不要做的事情 (Don’ts)」寫清楚，然後將其加入 Cursor 的 .cursorrules 參考文件中。

留白提問 (Guided Reflection)

• 提問：在你的專案中，當 AI 幫你寫前端 UI 時，它是否經常發明新的顏色或間距？
  • 架構師視角 (引導思路)：這通常是因為缺少了「設計上下文」。你給了 AI Tailwind 的工具，卻沒有給它設計手冊。導入 DESIGN.md 作為 Prompt 的一部分，是收斂 AI 輸出的最佳解法。

跨域映射

• 在 軟體架構，這叫 單一真相來源 (Single Source of Truth) 與文件即代碼 (Docs-as-Code)。

DEEP READ | 精讀指引 (Must-Read Segments)

[!IMPORTANT] 學習的本質需要「認知阻力」。請親自回到原文閱讀以下核心段落，感受原始論述的阻力，不要只依賴 AI 的總結。

1. DESIGN.md 是什麼 (結構與意義)

   • 「Figma 仍然更適合做視覺設計和組件協作，Design Token 更適合保存顏色、字號、間距、圓角這些原子值。DESIGN.md 在我的工作流裡更像一層『設計上下文』…」
   • 推薦理由: 精準定位了 DESIGN.md 在現代工具鏈中的生態位。它不是用來取代 Figma，而是補足了設計決策與 AI Prompt 之間的缺失環節。

2. 檢查、導出說明 (派生校驗機制)

   • 「一份文檔『能保存』和『能正確派生 Token、CSS』是兩回事…如果檢查沒有通過，CSS 導出會被鎖住…這樣做是為了避免導出一份彼此對不上的 CSS。」
   • 推薦理由: 這展現了嚴謹的工程思維。容錯的 Markdown 編輯與嚴格的程式碼編譯分離，確保了下游工程師不會拿到破壞性的依賴。

STRUCTURE MAP | 全書結構圖

RICOUI DESIGN (DESIGN.md 工作台)
+-- 為什麼需要 DESIGN.md
|   +-- 解決設計規範散落的問題
|   +-- 提供給 AI 完整的設計上下文 (超越純 Token)
+-- 核心骨架 (Markdown 結構)
|   +-- 品牌調性 & Theme
|   +-- Tokens (Colors, Typography, Spacing/Shapes)
|   +-- Components (組件約束)
|   +-- Do's and Don'ts (品質護欄，對 AI 極重要)
+-- 產品功能模塊
|   +-- 看：Brands 品牌參考庫 (拆解成熟產品)
|   +-- 做：編輯器 (源碼/結構化/預覽視圖切換)
|   +-- 魔法：輸入網址透過 AI 萃取起草
+-- 工程與交付
|   +-- 派生校驗：必須合法才能產出 CSS/JSON
|   +-- 產出物：tokens.json, variables.css, Tailwind v4 theme
+-- 部署與架構
|   +-- 本地優先 (IndexedDB)
|   +-- 支援 Supabase 雲端同步與開源自建

</我做了一個開源的設計工作台：管理 & 編輯 & 生成 DESIGN.md> <我做了一個開源的設計工作台：管理 & 編輯 & 生成 DESIGN.md (Architectural Deep Dive)>

前言/背景

作者發現，雖然手邊有許多品牌設計參考，但在實際專案中，設計規範往往散落在 Figma、協作文件和程式碼中，難以維護且無法有效交由 AI (如 Cursor, Claude) 使用。為此，作者開發並開源了「RICOUI DESIGN」工作台，推廣使用 DESIGN.md 作為跨越設計、開發與 AI 的核心溝通媒介。

章節詳細總結

什麼是 DESIGN.md？

這是一份結構化的 Markdown 文件，不僅人類可讀，AI 也能輕易解析。

• 骨架包含：品牌調性、主題 (Theme)、原子 Tokens (顏色、字體、間距、圓角)、組件約束 (Components)、以及品質護欄 (Do’s and Don’ts)。
• 與現有工具的關係：它不取代 Figma (專注視覺) 或 Design Token (專注數值)，而是提供一層「設計上下文 (Design Context)」。它告訴 AI 這個值該怎麼用、組件間的關係，以及哪些設計是絕對禁止的。

產品功能：看與做

• 看 (品牌參考)：系統內建了多個成熟品牌的 DESIGN.md 解析。使用者可以拆解這些品牌的顏色層級、字號組織等，而不只是看一張 UI 截圖。
• 做 (編輯與交付)：使用者可以從零建立、複製品牌庫來修改，或是輸入一個公開網址讓 AI 萃取並生成初稿。編輯器提供原始碼、結構化表單與視覺預覽三種視圖。

不同角色的價值

• 設計師：無需寫程式即可透過結構化面板精確調整視覺規範。
• 前端開發者：獲得由單一來源 (DESIGN.md) 自動派生出的 tokens.json、variables.css 與 Tailwind v4 的 theme.css。
• AI (Prompt 應用)：獲得具體的約束與禁忌，不再盲目發明新的顏色或做出違背品牌風格的排版。

嚴謹的派生檢查機制 (Validation)

作者在工程設計上做了一個關鍵區分：「能儲存的 Markdown」與「能派生的代碼」是兩回事。

• 如果 Token 名稱不合法或變數引用錯誤，系統會鎖住 CSS 與 JSON 的匯出功能。
• 這樣做是為了強制使用者在源頭 (DESIGN.md) 修正錯誤，避免下游工程師拿到互相矛盾的 CSS，確保「單一真相來源 (Single Source of Truth)」的純潔性。

部署與儲存策略

• 專案支援本地優先運行，草稿存於瀏覽器的 IndexedDB。
• 提供 Supabase 串接選項，實現跨裝置同步與私有交付，並開源供企業內部自行部署。

總結與結論

• 將設計規範「代碼化 (Docs-as-Code)」並加入語意化的約束，是迎接 AI 輔助開發時代的關鍵基礎建設。
• DESIGN.md 透過結合精確數值與自然語言的 Do’s/Don’ts，成功填補了設計交付與 Prompt Engineering 之間的斷層。

🔗 Source: https://x.com/ricouii/status/2095364380850631102