從空白畫布開始很慢，所以直接丟一份現成的風格檔進專案、讓 AI Agent 照著跑，是很誘人的做法。事情確實會動起來。但在我還沒想清楚自己的產品需要什麼之前，別人產品的假設也跟著溜進了程式碼。
awesome-design-md 對付空白頁很有用。它收集了一批以知名產品和品牌為範本的 DESIGN.md，每份都寫了視覺主題、色彩角色、字體、元件、版面、層次、響應式行為和各種限制。
這個 repo 建議你把檔案複製進專案，再請 Agent 照著做。我會早一步停下來。複製來的檔案，我只當成研究資料，先用它替專案寫一套新的設計系統，然後才讓 Agent 動手實作。
直接套用的問題
參考用的 DESIGN.md，是替別人的公司、受眾、產品和內容寫的。字體可能要授權。適合開發者工具的深色介面，放到閱讀類產品裡可能就不對味。從專業儀表板搬來的密集控制項，對一個簡單的新手引導流程毫無幫助。
原封不動交給 Agent，這些假設也就一起交出去了。做出來的東西可以非常一致，卻還是不適合你的產品。多半看起來就是某個熟悉的品牌，只是換了一批文字。
這份合集能幫上什麼
它讓我有比「做簡約一點」更精確的詞彙。我可以看 Linear、Vercel、Notion 或 Stripe 怎麼建立層級，然後追問：它的個性到底從哪裡來？字體、間距、顏色、邊框、圖像，還是互動？
我幾乎不會整份照搬某一個參考。這一份也許能幫我抓文章的節奏，那一份能回答密集控制項怎麼排，動效可能還要去別處找。每個參考都得有它在這裡的理由。沒有理由地混搭幾套外觀，只會混出一套更糊的外觀。
這個階段我要的，是一小份值得試試看的決策清單，不是一個拿來模仿的品牌。
從產品開始
動 DESIGN.md 之前，我會先寫下設計要服務的事：
- 誰在用這個產品？
- 他們想完成什麼？
- 這是行銷頁、應用程式、文件，還是視覺體驗？
- 手上已經有哪些真實內容？
- 哪些裝置、無障礙需求和技術限制要考慮？
- 這個介面絕對不能變成什麼樣子？
這一步能防止參考資料不知不覺變成產品策略。一個漂亮的儀表板，沒辦法告訴我產品到底需不需要儀表板。
借鑑決策，而非照搬外觀
合集裡的 DESIGN.md 結構都差不多，而且好用。我讀的時候，找的是能搬到別的專案去的決策：
- 視覺主題，以及它想營造的氛圍。
- 有語意的色彩角色，而不是一堆色碼。
- 字體層級和行寬。
- 間距、格線、密度和留白。
- 元件在預設、懸停、聚焦、停用、載入和錯誤狀態下怎麼表現。
- 版面在不同螢幕尺寸下怎麼真正改變，而不是把桌面版縮小。
- 明確的「要做」與「不要做」。
有些數值可以直接沿用，大部分則需要轉譯。「用紫色」不算一套系統；「只留一個強調色給主要操作，絕不拿來裝飾」才算。
為專案重寫 DESIGN.md
我會把借來的檔案換掉，改成專為這個專案寫的版本。這是我用的大綱：
# Design System: [Project]
## Product context
- Primary users
- Main task
- Platform and usage environment
- Content and technical constraints
## Creative north star
A short description of the visual idea and why it fits the product.
## Foundations
### Color
- Semantic roles and accessible values
### Typography
- Families, weights, hierarchy, line height, and reading measure
### Layout and spacing
- Grid, containers, spacing scale, density, and breakpoints
## Components
- Structure, variants, states, and interaction rules
## Motion
- Purpose, duration, easing, interruption, and reduced-motion behavior
## Responsive behavior
- What reflows, collapses, scrolls, or disappears
## Accessibility
- Focus, contrast, keyboard order, touch targets, and semantics
## Code mapping
- CSS variables, framework tokens, and shared component locations
## Do and don't
- Decisions the agent must preserve
- Common patterns that do not belong in this project
文件裡要寫出專案實際使用的字體、token、斷點、元件和程式碼慣例。如果程式碼已經有 token 層，DESIGN.md 就指向它，不要再造一份標準。
以 V2SPACE 來說，我沒有寫「複製一個極簡作品集」。這套系統寫明了：白底、以文字為主、16px 的 IBM Plex Sans、一條結構側欄、窄的閱讀欄、兩種字重、克制的懸停狀態。它也禁止卡片、漸層、陰影和裝飾性數字。這些都來自網站的用途和內容，不是從哪一個參考抄來的。
先測試一個頁面
我會先在一個有代表性的頁面上試新的 DESIGN.md。頁面上要有足夠的真實內容，才能把弱的規則逼出來：長標題、一些次要文案、一個操作、幾個重複項目、一個互動狀態，再加上窄螢幕。
然後看實際渲染出來的樣子。我會瞇起眼睛把細節糊掉，看層級還撐不撐得住。再檢查相關的元素有沒有自然成組、長標籤會不會換行、鍵盤焦點看不看得到、觸控目標夠不夠大。在手機上，我要看到版面真的重新排過，而不只是縮小。
如果這個頁面撐不住，我會先修系統，再做其他頁面。不然同一條爛規則會散到十個頁面上，之後得修十次。
給 Agent 明確的實作範圍
到這一步，我才請 Agent 開始做。請求裡會寫清楚：目標頁面、真實內容、既有元件、要處理的狀態，以及我會怎麼驗收。
DESIGN.md 是視覺上的約定。AGENTS.md 說明在這個 repo 裡怎麼工作。產品需求寫的是必須有哪些東西。三者各管各的事。
邊界畫好以後，Agent 可以自己做一些小決定，不用每個畫面都重新發明一套視覺語言。它也有足夠的脈絡，拒絕那些流行但不適合的做法。
讓文件保持最新
專案的設計決策變了，DESIGN.md 就該跟著變。我不會每截一張圖就重新產生一次，也不會把它當成一張凍結的情緒板。
它要寫得夠細，才真的能約束實作，但也要短到有人願意從頭讀完。如果專案裡沒有人說得出某條規則為什麼存在，我也不指望 Agent 懂。
我還是會用 awesome-design-md，因為它能幫我跨過空白頁。只是我不會把挑中的那份檔案當成施工說明，而是拿它來寫出這個專案一開始就該有的設計系統。