前言
AI 编程工具正在改变前端开发方式。
以前我们做 UI，通常是：
产品需求 → Figma 设计稿 → 前端还原 → 组件沉淀现在很多时候变成了：
一句需求 → AI 生成页面 → 人工调整 → 继续迭代效率确实提高了，但问题也很明显：AI 生成的 UI 很容易不稳定。
第一个页面看起来不错，第二个页面风格开始变化，第三个页面颜色不统一，后面多个页面组合起来，就像不同模板拼在一起。
这不是 AI 完全不会做 UI，而是它缺少一份长期、稳定、可复用的设计上下文。
Google Labs 开源的DESIGN.md，本质上就是在解决这个问题。
它不是 UI 组件库，也不是前端框架，而是一种把产品视觉身份、设计规则、组件约束写成 AI 能理解的工程化文档。
一、为什么 AI 生成 UI 容易跑偏？
很多人让 AI 生成页面时，会这样描述：
帮我生成一个现代化、高级、简洁、好看的首页。 主题色用蓝紫色。 页面要有科技感。问题是，这些词太抽象。
“高级”“现代”“科技感”对人类来说有感觉，但对 AI 来说只是一个很宽泛的风格范围。它可能生成渐变背景、玻璃拟态、大圆角卡片、SaaS 官网布局，看起来完整，但缺少产品自己的气质。
真正好的 UI，不只是颜色、字体、圆角，而是要回答：
这个产品应该给用户什么感觉？ 主色什么时候使用？ 哪些地方不能使用？ 页面信息密度应该高还是低？ 组件应该克制还是活泼？ 哪些视觉风格明确不能出现？这些信息如果只存在于设计师脑子里、Figma 页面里、聊天记录里，AI 是无法稳定复用的。
所以，AI 需要一份项目级的设计系统上下文。
二、DESIGN.md 是什么？
简单理解：
DESIGN.md 是一份写给 AI Coding Agent 看的设计系统说明书。
它通常放在项目根目录：
project/ ├── DESIGN.md ├── package.json ├── src/ └── README.md它一般由两部分组成：
YAML Front Matter：机器可读的设计 token Markdown Body：人和 AI 都能理解的设计说明例如：
--- name: Product Design System colors: primary: "#4F46E5" background: "#F8FAFC" surface: "#FFFFFF" text-primary: "#111827" text-secondary: "#6B7280" typography: headline-lg: fontFamily: Inter fontSize: 36px fontWeight: 700 body-md: fontFamily: Inter fontSize: 16px fontWeight: 400 rounded: md: 14px lg: 24px spacing: md: 16px lg: 24px --- ## Overview This product should feel clear, trustworthy and focused. ## Colors Primary color is used only for key actions. Neutral colors should dominate the interface. ## Components Cards should be clean and lightweight. Buttons should be clear and action-oriented.YAML 部分负责精确值，Markdown 部分负责设计判断。
这就是 DESIGN.md 最核心的价值。
三、Token 只能告诉 AI “是什么”，不能告诉 AI “为什么”
传统前端项目中，我们经常会写 CSS 变量：
:root{--primary:#4f46e5;--radius-lg:24px;}这对代码有用，但对 AI 不够。
AI 知道主色是蓝紫色，但不知道：
这个颜色代表什么？ 它能不能做大面积背景？ 它是不是所有按钮都能用？ 它应该表达科技感、学习感，还是金融感？所以 DESIGN.md 不只写 token，还要写设计说明。
例如：
## Colors Primary color is used for the most important action on each screen. It should not be used everywhere. It should not be used as a full-page background. Success color is used only for completed states. Warning color is used only for temporary attention.这类说明比单纯的颜色值更重要。
因为 UI 设计真正难的不是“用什么”，而是“什么时候用、为什么用、什么时候不用”。
四、DESIGN.md 改变的是 AI 编程工作流
没有 DESIGN.md 时，AI 生成 UI 的方式是：
用户临时描述风格 ↓ AI 临时理解 ↓ 生成一个页面 ↓ 下次继续重新描述这种方式依赖当前对话，上下文很容易丢失。
有了 DESIGN.md 后，流程变成：
项目中沉淀 DESIGN.md ↓ AI 每次生成页面前读取 DESIGN.md ↓ 页面遵守同一套视觉规则 ↓ 发现问题后回到 DESIGN.md 修正规则 ↓ 设计系统越来越稳定这就从“单次 prompt 生成 UI”，变成了“项目级设计系统驱动 UI”。
以后我们不应该只对 AI 说：
帮我生成一个好看的页面。更合理的方式是：
请先读取项目根目录的 DESIGN.md。 生成页面时必须遵守其中的颜色、字体、间距、组件和禁用规则。 不要重新发明视觉风格。 如果需求和 DESIGN.md 冲突，先指出冲突。这才是更适合长期项目的 AI 编程方式。
五、举个简单例子
假设我们做一个 AI 英语学习产品。
如果没有统一设计系统，首页可能像 SaaS 官网，单词页可能像儿童游戏，学习报告页可能像后台图表，积分页又像电商活动页。
这时就需要在 DESIGN.md 中提前定义：
## Overview This is an AI-powered English learning product. The interface should feel motivating, focused and friendly. It should not look like a children-only cartoon app. It should not look like a cold enterprise dashboard. ## Do's and Don'ts - Do make learning progress visible. - Do keep learning content readable. - Do use light gamification to increase motivation. - Don't overuse coins, badges and animations. - Don't make report pages look like admin dashboards.这段内容不需要很长，但它能帮助 AI 明确产品气质和设计边界。
重点不是告诉 AI “页面要好看”，而是告诉它：
这个产品像什么 不该像什么 哪些设计可以用 哪些设计不能用六、Do’s and Don’ts 非常重要
很多人写设计系统时，只关注颜色、字体、间距。
但在 AI 生成 UI 时，“不要做什么”往往比“要做什么”更重要。
例如：
## Do's and Don'ts - Do use tokens instead of arbitrary values. - Do keep primary actions clear. - Do maintain consistent card style. - Don't introduce new primary colors. - Don't overuse gradients and shadows. - Don't make consumer-facing pages look like admin dashboards.这些规则可以有效减少 AI 跑偏。
因为 AI 最容易犯的问题不是不会生成页面，而是生成得太“平均”、太“模板”、太“泛化”。
明确边界，才能让它更接近你的产品定位。
七、从工程角度看，DESIGN.md 解决了什么？
我认为它主要解决四个问题。
1. 解决 UI 风格漂移
多个页面由 AI 分别生成时，很容易出现风格不一致。DESIGN.md 可以让所有页面遵守同一套视觉规则。
2. 解决设计决策无法沉淀
很多 UI 修改其实是经验规则，比如“按钮不要太亮”“页面不要像后台”“卡片信息不要太挤”。这些规则写进 DESIGN.md 后，后续页面都能复用。
3. 解决设计和代码割裂
传统设计系统可能存在于 Figma，代码里又维护一套变量。DESIGN.md 提供了一种中间层，让设计规则既能被人读，也能被 AI 和工程工具消费。
4. 解决 AI 缺少长期记忆
AI 编程最怕上下文丢失。DESIGN.md 相当于给项目增加了一份长期设计记忆。
八、它不是万能的
DESIGN.md 很有价值，但它不是万能方案。
它不能替代设计师，也不能保证页面一定高级。
如果 DESIGN.md 写得很泛，比如只写“高级、现代、简洁”，那 AI 依然会生成模板化 UI。
它也不能完整表达复杂交互，例如动效、手势、多状态组件、复杂图表、响应式细节，这些仍然需要单独的组件规范和交互文档。
所以，DESIGN.md 更适合作为前端工程中的设计上下文入口，而不是替代全部设计流程。
九、我建议怎么落地？
如果你正在用 AI 做前端开发，可以这样实践。
第一步：先写 DESIGN.md，再生成页面
不要一开始就让 AI 写首页。
先让 AI 帮你根据项目定位生成 DESIGN.md，明确产品气质、颜色规则、组件风格和禁用项。
第二步：每次生成页面前强制读取 DESIGN.md
让 AI 生成页面时，明确要求它遵守 DESIGN.md，不要自行引入新的主色、圆角、阴影和组件风格。
第三步：UI 跑偏时，先修 DESIGN.md
如果页面太像后台、太花哨、太模板，不要只让 AI 重写页面，而是把规则补充回 DESIGN.md。
例如：
## Page Style Consumer-facing pages should use card-based layouts. Avoid dense table-first layouts unless the page is truly>第四步：稳定后再沉淀组件当 DESIGN.md 稳定后，再提炼组件，例如：
BaseButton BaseCard PageHeader EmptyState FilterBar StatusBadge ProgressCard
这样组件不是凭空设计出来的，而是从统一设计系统中提炼出来的。
十、推荐的项目结构
我建议 AI 编程项目可以这样组织：
project/ ├── README.md ├── AGENTS.md ├── DESIGN.md ├── docs/ │ ├── pages.md │ ├── components.md │ └── api.md └── src/
每个文件负责不同上下文：
README.md 给人看项目是什么 AGENTS.md 给 AI 看如何开发 DESIGN.md 给 AI 看 UI 应该长什么样 pages.md 描述页面结构 components.md 描述组件规则 api.md 描述接口规则
AI 不怕信息多，怕的是信息散、规则不明确。
把项目知识沉淀成结构化文档，AI 的输出质量会稳定很多。
总结
DESIGN.md 的意义，不在于它发明了复杂技术，而在于它提出了一种新的思路：
把设计意图变成工程资产。
在 AI 编程时代，我们不能再只靠一次性的 prompt 让 AI 猜 UI 风格，也不能只把设计系统放在 Figma 里。
未来的前端项目，很可能会越来越多地出现这些文件：
README.md 描述项目 AGENTS.md 约束 AI 开发方式 DESIGN.md 约束 AI UI 生成方式 API.md 约束接口调用方式
这代表一种新的工程化趋势：
不是让 AI 每次重新猜你的项目，而是把项目知识沉淀成 AI 可以消费的上下文资产。
AI 生成 UI 的质量，不只取决于模型能力，也取决于我们有没有把设计系统表达清楚。
未来优秀的前端工程师，不仅要会写组件、调样式、做响应式，还要会把产品视觉语言抽象成结构化规则，让人、代码和 AI 都能复用。
这可能就是 AI 编程时代前端工程化的新方向。
- 参考链接：https://github.com/google-labs-code/design.md
