你的 Figma 文件，AI 看不懂。
这是我最近研究 Stitch 时意识到的一个问题。
我们把所有的设计决策压缩进 Figma——配色、字体、圆角、间距、组件规范——然后交给开发者"对着设计稿还原"。这套流程跑了十几年，勉强可以。
但现在 AI agent 开始参与生成 UI 了。问题来了：它看不懂 Figma。它不知道你的品牌主色是 #2665fd，不知道你不喜欢阴影，不知道你的按钮永远是 8px 圆角。每次生成，它都在从零猜测你的审美。
结果就是：每个页面都像是不同设计师做的。
DESIGN.md 可以解决这个问题。
一份文件，定义整个项目的视觉语言
DESIGN.md 的逻辑很简单：把你的设计系统写成纯文本，让 agent 能读。
你可以把它理解成设计界的 AGENTS.md：
| 文件 | 读者 | 定义的内容 |
|---|---|---|
| README.md | 人类 | 项目是什么 |
| AGENTS.md | 编程 agent | 怎么构建 |
| DESIGN.md | 设计 agent | 怎么呈现 |
有了它，每次 Stitch（Google AI）生成新页面，都会先读这份文件，然后再干活儿。配色一致，字体一致，圆角一致。所有页面看起来像同一个产品，而不是同一个 AI 在不同心情下的随机输出。
它不是静态的配置文件。它是活的文档（就这个问题，还有老外在推特上问我）—— 你改它，agent 跟着变；设计演进了，它也跟着进化。
三种方式创建它
让 agent 生成。 最省力的方式。你只需要描述感觉：
"一款活泼的咖啡店点单 App，暖色调，圆角，亲切友好的氛围"
Stitch 把这句话翻译成完整的设计 token，连同 DESIGN.md 一起吐出来。
从品牌资产提取。 如果你已有品牌，丢一个 URL 或图片给它。它会从中提取配色、字体、风格模式，帮你构建出 DESIGN.md。适合那些"品牌已经有了，只是没有整理成 agent 能读的格式"的场景。
手写。 最精确的方式。每个章节都是普通 Markdown，没有特殊语法，不需要任何工具链。适合对设计系统有强烈主导欲的人。
它长什么样：六个章节
每份 DESIGN.md 遵循固定结构，章节顺序保持不变，不相关的可以省略。
Overview：定调
这里描述产品的性格，而不是具体数值。
## OverviewA calm, professional interface for a healthcare scheduling platform.Accessibility-first design with high contrast and generous touch targets.
当没有具体 token 可以参考时，agent 靠这段话做高层决策。写得越准确，生成结果越贴近你的直觉。
Colors：配色
每种颜色需要两样东西：十六进制值，和用途说明。
## Colors- **Primary** (#2665fd): CTAs, active states, key interactive elements- **Secondary** (#6074b9): Supporting actions, chips, toggle states- **Tertiary** (#bd3800): Accent highlights, badges, decorative elements- **Neutral** (#757681): Backgrounds, surfaces, non-chromatic UI
agent 会从这四个基础色派生出完整的命名色板：surface、on-primary、error、outline……遵循 Material color role 规范，存在结构化 token 里。你只需要定义根，它负责长出整棵树。
Typography：字体
定义字体家族和各层级的用法：
## Typography- **Headline Font**: Inter- **Body Font**: Inter- **Label Font**: InterHeadlines use semi-bold weight. Body text uses regular weight at 14–16px.Labels use medium weight at 12px with uppercase for section headers.
有一个细节值得注意：标题和正文是否同一字体家族，会直接影响整体气质。 统一用 Inter 传达的是克制和统一；衬线标题配无衬线正文，则制造视觉对比。agent 会有意识地延续这种对比关系。
Elevation：深度
有些设计靠阴影区分层次，有些完全扁平，靠边框和色彩差异说话：
## ElevationThis design uses no shadows. Depth is conveyed through border contrastand surface color variation (surface, surface-container, surface-bright).
如果你用了阴影，把扩散范围、模糊值、颜色、以及哪些组件需要层级感都写清楚。
Components：组件
对核心组件原子的样式描述：
## Components- **Buttons**: Rounded (8px), primary uses brand blue fill, secondary uses outline- **Inputs**: 1px border, surface-variant background, 12px padding- **Cards**: No elevation, 1px outline border, 12px corner radius
每种组件需要说清楚：形态变体（primary/secondary/tertiary）、尺寸和内边距、圆角、各状态（hover、focus、disabled、error）。
你也可以按项目场景补充：移动 App 写导航栏，Dashboard 写数据表格。
Do's and Don'ts：护栏
这部分是给 agent 的红线。当它在边界情况下做选择时，这些条目是它的依据：
## Do's and Don'ts- Do use the primary color only for the single most important action per screen- Don't mix rounded and sharp corners in the same view- Do maintain WCAG AA contrast ratios (4.5:1 for normal text)- Don't use more than two font weights on a single screen
在 Stitch 里查看、编辑、导出
写完 DESIGN.md，打开 Stitch 的 Design System 面板，就能看到所有已解析的 token：颜色、字体、圆角、间距、组件模式。如果项目里有多套设计系统，面板显示的是当前选中页面对应的那一套。
设为默认之后，项目里所有新生成的页面都会自动继承它的 token。已有页面不会被追溯更新——如果要对齐，需要逐一手动应用。
面板本身也支持直接编辑：配色的四个基础色、三种字体家族、圆角刻度，都可以在这里改。改动会同步更新结构化 token 和 DESIGN.md 摘要。
更细粒度的修改——组件规范、规范与禁忌、概览描述——直接编辑 Markdown 文件本身。
导出时，DESIGN.md 会随生成的页面一起打包进 zip。这份文件是独立的，不依赖 Stitch 就能被读取：开发者可以用它对齐实现细节，其他 agent 可以用它继续生成，设计师可以用它做评审的参照。
两份表示，一套系统
这里有一个设计得很聪明的地方：DESIGN.md 同时存在两种形态。
你看到的 Markdown，是给人读的：模糊的表达可以接受，"暖色调、圆润感"这种描述就够用。
底层的结构化 token，是给 agent 用的：精确的十六进制、字体枚举、间距刻度。
你写 Markdown，Stitch 负责维持两者同步。你可以写得模糊，它帮你翻译成精确值；你也可以写得精确，它原样遵守。
这个设计消除了"描述和执行之间的鸿沟"——设计师不需要懂 token 体系，也能给 agent 喂出有效的指令。
我觉得
DESIGN.md 最有意思的地方，不是它解决了什么技术问题，而是它重新定义了设计规范的栖居之所。
过去，设计系统活在 Figma 里，活在设计师的认知里，活在评审会议的口头约定里。它是人类之间协作的产物，只有人类能读。
现在，设计系统开始需要被机器读懂。
DESIGN.md 是这个转变最简单的答案：一个 Markdown 文件，放在项目根目录，和代码一起被版本控制，被所有人——包括 agent——共同维护。
如果你正在用 AI 生成 UI，从今天起给你的项目加一份 DESIGN.md。
经验心得
Stitch 当设计总监，ClaudeCode 当开发工程师
Stitch 导出的 ZIP 里除了 HTML 和截图，还有一个 DESIGN.md。Stitch 花几分钟想出来的这套东西，比 frontend-designskill 的设计指导具体得多。
可以直接把 DESIGN.md 给 ClaudeCode，让它严格按规范生成代码。
Stitch 和 ClaudeCode 各有一块很强的长板。
Stitch 强在设计直觉。给它一段描述，它能快速找到一个有品位的视觉方向，配色、字体、组件风格都想得很到位。这是目前 ClaudeCode 不管装什么 skill 都做不到的。
ClaudeCode 则强在工程实现。给它一份清晰的设计规范，生成的代码结构好、可读性高、浏览器打开就能跑。这是 Stitch 导出的 HTML 做不到的。
DESIGN.md 是连接两者的桥。
Stitch 把设计决策写成结构化的规范文件，ClaudeCode 拿着这份规范去写代码。设计归设计，代码归代码，各干各的强项。
具体操作也很简单。
打开 stitch.withgoogle.com，输入你的需求，选一版满意的导出 ZIP。把 ZIP 里的 DESIGN.md 丢给 ClaudeCode 即可，让 ClaudeCode 按规范写代码。
Stitch 当设计总监，ClaudeCode 当开发工程师。这套组合目前是我知道的，出活质量最高的工作流。
2026.03.22 17:33 沪 · 赵巷 KFC
