告别「审美随机」：DESIGN.md 如何重构 AI 时代的设计系统
告别「审美随机」：DESIGN.md 如何重构 AI 时代的设计系统
你一定遭遇过这种尴尬：让 AI 写一个设置页面，功能逻辑无懈可击，界面却像是三个设计师各自为战的结果——按钮圆角大得像儿童 App，蓝色主色像是随机抽的，字体用着毫无立场的系统默认。
于是你开始往 Prompt 里塞规则：「主色 \#1A73E8」「圆角 8px」「不要渐变」。下一次对话，重来一遍。AI 不是不守规矩，只是没人把规矩白纸黑字地交给它。
2026 年 3 月，Google 在更新设计工具 Stitch 时推出了 DESIGN.md。逻辑朴素：在项目根目录放一个 Markdown 文件，让 AI 生成代码前先读它。
一、设计哲学：给 AI 一份「设计合同」
约束，而不是引导
DESIGN.md 的核心主张是：别试图通过 Prompt 启发 AI 的审美判断，直接给它一套绕不过去的规则。
「生成一个干净、现代、专业的页面」——AI 听到的是「发挥训练数据里的平均审美」。Primary color: #1A73E8, Button border-radius: 8px——AI 听到的是执行指令，没有发挥空间。描述留给人，约束留给机器。
Token，而不是描述
从「说感受」到「定决策」，是最关键的思维跳跃。「充满活力的蓝色」对人有意义，对 AI 是噪音。真正有用的是语义化命名：
- Primary: #1A73E8
- Success: #34A853
- Error: #EA4335
- Text Muted: #5F6368有了这套命名，AI 知道错误状态用 Error token，不需要每次猜是用红还是橙，也不会「感觉差不多」就用了粉红。
「设计禁忌」的核威慑
大多数文档只讲「要做什么」，DESIGN.md 显式鼓励你写「不准做什么」。AI 的默认审美训练自海量互联网内容，渐变按钮、彩色左边框、emoji 装饰这些平庸模式就藏在那里。不主动排除，它们会悄无声息地混进你的界面。
设计即代码
DESIGN.md 是纯文本，天然进 Git。改了主色调，开一个 PR，通过后合并。设计变更从此有了和代码同等的记录、审查与回溯机制，设计稿和代码脱节的问题也就自然消失了。
可读性是精确性的前提
为什么不用 JSON 或 YAML？因为设计文件需要 PM、设计师、开发者共同维护。Markdown 的结构足够 AI 解析，又简单到任何人都能直接编辑，不需要学习任何额外工具。
二、落地实践：一份标准模板
在项目根目录创建 DESIGN.md，参考以下结构：
## Colors
- Primary: #1A73E8 (Brand identity)
- Surface: #FFFFFF (Cards and layers)
- Text Muted: #5F6368 (Secondary information)
- Error: #EA4335
- Success: #34A853
## Typography
- Font: Inter, sans-serif
- Base size: 16px
- Headings: font-weight 600, line-height 1.3
- Body: font-weight 400, line-height 1.6
## Components
- Button border-radius: 8px
- Input border: 1px solid #DADCE0
- Card shadow: 0 1px 3px rgba(0,0,0,0.12)
## Design rules (Anti-patterns)
- No gradient buttons
- No colored left-border on cards
- No emoji as decorative elements
- No box-shadow on flat surfaces如何让 AI 读懂它：
- Cursor：在
.cursorrules中加入Always follow the DESIGN.md in the root directory - Claude Code：在
CLAUDE.md中注明Refer to DESIGN.md for all UI work - Google Stitch：原生自动读取，无需任何配置
三、Awesome DESIGN.md：现成的参考文件库
如果你不想从零开始写，开源仓库 Awesome DESIGN.md 是目前最好用的参考资源。它由 VoltAgent 于 2026 年 3 月底发布，三天内在 GitHub 拿到 4,385 颗 Star。
仓库里有什么
核心思路只有一句话：收录主流产品的设计系统，转成 plain-text，让 AI 直接读懂。 目前已收录 55+ 份来自真实公司的 DESIGN.md 文件，涵盖多个产品方向：
- 支付 / SaaS：Stripe、Vercel、Supabase、Figma
- 生产力工具：Notion、Linear、GitHub
- 消费品牌：Apple、Spotify、Airbnb、NVIDIA
- AI 产品：Claude（Anthropic）
仓库还附带了可直接运行的代码示例，比如「用 Vercel 的 DESIGN.md 生成一个按钮」「Stripe 风格的卡片组件」「Supabase 风格的暗色 Dashboard」，选模板前可以先验证生成效果是否符合预期。
几个代表性案例
不同产品的 DESIGN.md 侧重点差异很大，选模板前值得先了解各家的「设计性格」：
- Stripe：极度克制，大量留白，精确的排版层级；Anti-patterns 里明确禁止装饰性阴影，字体依赖系统原生字体栈
- Notion：中性色系语义 Token 分得极细，对 hover / active / disabled 等交互状态有独立颜色定义，整体配色几乎没有纯黑
- Linear：暗色模式优先，所有背景色都有对应的 dark variant，圆角普遍偏小（4–6px），透出工程师审美的冷峻感
- Supabase：偏向开发者工具风格，代码块和终端样式有详细定义，配色以深绿为品牌锚点
怎么用才对
把 Stripe 的配置原封不动搬进你的项目，大概率不合适。正确的姿势是把这些文件当作「设计决策的参考清单」——它们替你回答了「一个成熟产品通常需要定义哪些 Token」，具体的值仍然需要你来填。
起点流程：
- 按风格找最接近的参考文件：极简风找 Stripe / Vercel，暗色系找 Linear / Supabase，内容密集找 Notion
- 把它的结构骨架复制过来：Colors / Typography / Components / Anti-patterns 这四块是标配
- 用自己品牌的色值逐行替换颜色部分
- 重点检查并保留 Anti-patterns——这里的禁忌往往最有价值，很多条可以跨产品直接沿用
四、两个必须知道的局限
它不是全能的设计系统。 DESIGN.md 只解决 Token 层面的问题——颜色、数值、禁忌。什么时候用主按钮而不是次按钮，信息层级该如何排布，这些仍然是人的工作。
手动同步是隐患。 DESIGN.md 与实际代码（比如 Tailwind 配置文件）的同步目前是手动的。改了代码里的颜色，别忘了同步更新这个文件，否则 AI 会用旧值生成代码，产生静默的「幻觉记忆」。
花一个小时把品牌规范梳理进 DESIGN.md，换来的是此后每次生成都不需要重复解释。Prompt 可以不断改，但规范文件只需要写一次。