DESIGN.md 是把品味變成 UI 骨架的缺失橋樑
我認為 DESIGN.md 是 AI 設計工作最實用的中介層，因為它把視覺品味變成可執行、可重用、可審查的設計來源。
DESIGN.md 是把視覺品味變成可執行 UI 骨架的來源檔。
我支持 DESIGN.md，因為它把原本只能靠感覺傳達的設計偏好，變成 AI 可以反覆遵守的規格。像 VoltAgent 的 awesome-claude-design 這類專案，已經證明一份 markdown 不只是說明文件，而是能把參考風格轉成可交付的 UI 骨架、色彩與元件規則。
第一個論點
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
純 prompt 式設計最大的問題，是第二個畫面開始就容易走樣。第一個 landing page 也許還像樣，但一旦再生成一個設定頁或列表頁，間距、字級、色彩就會漂移，因為模型沒有持續存在的視覺契約。DESIGN.md 的價值就在於把規則留在檔案裡，讓每次生成都能回到同一套準則。
這不是抽象理論，而是工作流差異。該專案主張一份 markdown 可以展開成 README.md、colors_and_type.css、preview cards 與可運作的 UI kit，等於把設計輸入從「一句話」升級成「可追蹤的系統」。對團隊來說，這代表一致性不再靠記憶，而是靠版本化的規格維持。
第二個論點
DESIGN.md 最重要的地方，是它把品味變成可重用資產。多數團隊其實知道自己要什麼風格，缺的不是靈感，而是能被代理模型理解的表達格式。把 tokens、規則與設計理由放進同一份檔案，等於讓「為什麼這樣設計」跟著「設計本身」一起流動。
這件事在實際案例裡很清楚。像 Claude 的溫暖編輯感、Linear 的極簡精準、Stripe 的紫色漸層、Spotify 的深色張力，都不是隨機 mood board，而是能直接對應產品意圖的起點。對創辦人或 PM 來說，這種格式可以先鎖定品牌方向，再開始做元件，避免團隊在尚未對齊時就大規模產出。
反方可能怎麼說
最強的反對意見是：設計本來就有脈絡，不可能被一份 markdown 完整描述。法務限制、無障礙要求、受眾信任、地區文化，這些都不是 token 表能完全捕捉的。若把 DESIGN.md 當成萬能答案，確實會低估真正的設計判斷。
另一個合理疑慮是審美同質化。當大家都拿現成參考集去生成 UI，最後可能得到一堆看起來很乾淨、但彼此相似的產品。這不是工具壞掉，而是工具太好用，容易鼓勵複製而不是思考。
但這些問題不構成否定理由，反而說明 DESIGN.md 的角色應該更精確：它不是要取代設計主管，而是把設計主管的判斷寫成可執行規格。真正該做的不是丟掉這個檔案，而是把它放進審查流程，讓人類在例外、無障礙與品牌邊界上做最後決策。
你能做什麼
如果你是工程師，把 DESIGN.md 當成契約，不要當裝飾品：把它納入版本控制，讓 AI 生成的 tokens、元件與預覽都受它約束，並像審 code 一樣審設計輸出。如果你是 PM 或創辦人，先用它對齊品牌與產品方向，再開始做 UI 骨架，先選一個參考風格，生成初版，接著用真實需求修正檔案，而不是用 prompt 反覆賭運氣。
第一個論點
純 prompt 式設計最大的問題，是第二個畫面開始就容易走樣。第一個 landing page 也許還像樣，但一旦再生成一個設定頁或列表頁，間距、字級、色彩就會漂移，因為模型沒有持續存在的視覺契約。DESIGN.md 的價值就在於把規則留在檔案裡，讓每次生成都能回到同一套準則。
這不是抽象理論，而是工作流差異。該專案主張一份 markdown 可以展開成 README.md、colors_and_type.css、preview cards 與可運作的 UI kit，等於把設計輸入從「一句話」升級成「可追蹤的系統」。對團隊來說，這代表一致性不再靠記憶，而是靠版本化的規格維持。
第二個論點
DESIGN.md 最重要的地方，是它把品味變成可重用資產。多數團隊其實知道自己要什麼風格，缺的不是靈感，而是能被代理模型理解的表達格式。把 tokens、規則與設計理由放進同一份檔案，等於讓「為什麼這樣設計」跟著「設計本身」一起流動。
這件事在實際案例裡很清楚。像 Claude 的溫暖編輯感、Linear 的極簡精準、Stripe 的紫色漸層、Spotify 的深色張力，都不是隨機 mood board，而是能直接對應產品意圖的起點。對創辦人或 PM 來說，這種格式可以先鎖定品牌方向，再開始做元件，避免團隊在尚未對齊時就大規模產出。