前言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. ## Dos and Donts - Do make learning progress visible. - Do keep learning content readable. - Do use light gamification to increase motivation. - Dont overuse coins, badges and animations. - Dont make report pages look like admin dashboards.这段内容不需要很长但它能帮助 AI 明确产品气质和设计边界。重点不是告诉 AI “页面要好看”而是告诉它这个产品像什么 不该像什么 哪些设计可以用 哪些设计不能用六、Do’s and Don’ts 非常重要很多人写设计系统时只关注颜色、字体、间距。但在 AI 生成 UI 时“不要做什么”往往比“要做什么”更重要。例如## Dos and Donts - Do use tokens instead of arbitrary values. - Do keep primary actions clear. - Do maintain consistent card style. - Dont introduce new primary colors. - Dont overuse gradients and shadows. - Dont 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
AI 编程时代，UI 设计系统也需要工程化：从 Google DESIGN.md 说起
前言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. ## Dos and Donts - Do make learning progress visible. - Do keep learning content readable. - Do use light gamification to increase motivation. - Dont overuse coins, badges and animations. - Dont make report pages look like admin dashboards.这段内容不需要很长但它能帮助 AI 明确产品气质和设计边界。重点不是告诉 AI “页面要好看”而是告诉它这个产品像什么 不该像什么 哪些设计可以用 哪些设计不能用六、Do’s and Don’ts 非常重要很多人写设计系统时只关注颜色、字体、间距。但在 AI 生成 UI 时“不要做什么”往往比“要做什么”更重要。例如## Dos and Donts - Do use tokens instead of arbitrary values. - Do keep primary actions clear. - Do maintain consistent card style. - Dont introduce new primary colors. - Dont overuse gradients and shadows. - Dont 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
