谷歌悄悄开源的DESIGN.md，正在重新定义AI编程的设计规则！
DESIGN.md本质上是给AI看的设计系统说明书，不是给人看的设计规范文档。它把Figma里的视觉语言、Tailwind里的样式参数、设计师脑子里的审美判断，全部翻译成AI能直接理解和执行的结构化文本。
谷歌Stitch团队把这个格式开源后，任何AI编程工具都可以读取同一个DESIGN.md文件，生成风格一致的界面。这解决了AI生成UI最大的痛点：每一页都像随机生成的，完全没有品牌一致性。简单说，DESIGN.md就是“公司审美的源代码”，让设计规范变得可编程、可继承、可自动化执行。
理解DESIGN.md为什么会出现
AI编程工具发展到现在，写代码的能力已经很成熟了，但有个根本问题一直没人解决。你让AI生成一个登录页，它给你一套蓝色主题。你再让它生成一个仪表盘，它给你一套紫色主题。两个页面放在一起，完全不像同一个产品。这不是AI能力不行，而是因为你没有告诉AI“你们应该长得像一家人”。
传统设计流程里，设计师用Figma做设计稿，然后前端工程师照着稿子写代码。这个流程里，设计规范是给人看的文档，存在Notion里或者贴在墙上。但AI不看Figma，也不读Notion文档，它只看你给它的提示词。每次生成新页面，你都要重新描述一遍设计风格，而且每次描述都会有细微差别。
DESIGN.md就是来解决这个问题的。它把设计系统写成一个标准化的Markdown文件，AI读了这个文件之后，就知道所有页面应该用什么颜色、什么字体、什么圆角、什么间距。这样一来，你不需要每次重新描述，AI也不需要每次都猜你的意图。
DESIGN.md在谷歌Stitch体系里的定位
这个文件来自谷歌Labs的Stitch项目，具体来说是Stitch Skills体系里的一个技能，名字就叫design-md。Stitch本身是一个AI编程工具，但它和Cursor、Copilot不一样的地方在于，Stitch更注重“设计的一致性输出”。
design-md这个技能的职责非常明确：把已有的用户界面转换成AI能理解的设计语言。输入可以是HTML代码、Tailwind类名、或者屏幕截图里的元素信息，输出就是一个完整的DESIGN.md文件。这个过程相当于反向工程设计系统，从已经做好的页面里提取设计规范，整理成结构化的文档。
在Stitch的2026年更新之后，DESIGN.md已经从辅助文件变成了核心组件。AI画布功能、语音编辑界面、点击修改设计、一次生成五个页面，所有这些能力的背后都依赖同一个DESIGN.md作为控制层。没有这个文件，AI不知道该怎么统一处理多个页面之间的样式关系。
传统设计流程的三个致命缺陷
第一个缺陷是设计不可编程。Figma是非常优秀的视觉设计工具，但它生成的文件格式是专有的，AI无法直接读取和理解。AI最擅长处理的是文本，特别是结构化的Markdown格式。DESIGN.md相当于在Figma和AI之间架了一座桥，把视觉语言翻译成文本语言。
第二个缺陷是设计无法继承。每次你用AI生成一个新页面，它都是独立处理的，不会自动沿用之前页面的设计决策。这就好比每次做新页面都换一个设计师，而且新设计师完全没见过之前的设计稿。DESIGN.md保存了所有设计决策，新页面生成时可以直接读取，实现设计知识的传递和复用。
第三个缺陷是人和机器的语言不一致。设计师会说“这个按钮稍微圆一点”，前端工程师知道改成rounded-lg，但AI听到“稍微圆一点”就懵了。它不知道你是要4像素还是8像素还是12像素。DESIGN.md把这种模糊的人类语言转换成精确的技术参数，同时又用语义化的描述让AI理解每个参数的意图。
design-md技能的核心能力拆解
design-md这个技能本质上是一个设计编译器，它做了三件关键的事情。第一件事是把用户界面解析成结构化的设计信息。它会从Stitch项目里抓取HTML结构、CSS样式、Tailwind类名、设计主题变量、甚至屏幕截图，把这些碎片化的信息整合在一起。
第二件事是转换成语义化的设计语言。原始的技术参数像#294056这种十六进制色值，AI只知道它是一个颜色，但不知道这个颜色是干什么用的。design-md会把它标注成“深沉的哑光蓝绿”，还会说明这个颜色用于主要标题和重要边框。rounded-lg会被描述成“轻微圆角”，shadow类会被描述成“轻柔扩散阴影”。这种语义化描述让AI不只是知道参数值，还理解每个设计元素的使用场景和意图。
第三件事是按照固定结构生成DESIGN.md文件。结构包括视觉主题氛围、颜色调色板及角色定义、字体排版规则、组件样式规范、布局原则这几个核心章节。重点不是列出参数，而是解释为什么这样设计。比如深色背景配浅色文字不是为了好看，而是为了确保对比度达到无障碍标准。
DESIGN.md作为AI提示词的升级版本
你可以把AI控制方式分成三个层级。初级就是直接写提示词，说“给我做一个深色主题的管理后台”。中级是提示词加示例图片或者参考链接，让AI有个参照。高级就是用DESIGN.md提供结构化的上下文信息。
普通提示词和DESIGN.md的关键区别在于几个维度。普通提示词是临时的，每次对话都要重新写，而且每次写的表述都不一样，AI输出的结果就不稳定。DESIGN.md是持久化存储的，放在项目根目录下，每次生成都读取同一个文件。普通提示词完全由人编写，描述是否准确全看人的表达能力。DESIGN.md是AI和人协作生成的，先由AI分析现有界面提取规范，再由人工审核调整。
普通提示词一次性使用，换个项目就失效了。DESIGN.md可以跨项目复用，只要设计风格相同，复制过去就能用。把DESIGN.md理解成把提示词变成系统配置文件，这个配置文件可以被所有AI工具读取和执行。
谷歌为什么要推动这个标准
这件事看起来只是一个小工具的开源，但背后传递的方向信号很重要。AI编程的核心竞争力正在从能不能生成代码，转向能不能提供高质量的上下文。谷歌的思路很清晰：问题不在于AI能不能生成界面，而在于你有没有定义好标准让AI遵循。
DESIGN.md做的事情是把设计规范变成AI的标准输入接口。这和业界正在形成的几个模式是同一类东西。AGENTS.md用来控制AI的行为规范，告诉AI应该怎么思考和处理任务。Schema用来控制数据结构和验证规则。DESIGN.md用来控制视觉输出的一致性。这三个文件放在一起，就构成了AI编程的完整上下文体系。
谷歌选择把这个格式开源，目的不是卖工具，而是推动这个格式成为行业标准。一旦大量项目都采用DESIGN.md，谷歌的AI工具在处理这些项目时就有天然优势。这是典型的开放标准策略，和安卓开源的路数一样。
实际开发工作流详解
实际开发中使用DESIGN.md的流程可以分为四步。
第一步是安装design-md技能。命令是npx skills add google-labs-code/stitch-skills --skill design-md。这个命令会把技能添加到你的开发环境中。
第二步是把DESIGN.md文件放在项目根目录。文件结构大概是这样的：项目文件夹下面有README.md说明文档、DESIGN.md设计规范、src源代码目录。DESIGN.md放在根目录是为了让AI工具能够自动发现和读取它。
第三步是在给AI的指令中明确引用这个文件。你可以直接说“根据DESIGN.md的规范，帮我生成一个仪表盘页面”。AI读取文件后就知道用什么颜色体系、什么字体规则、什么间距标准。
第四步是反复迭代和优化。每次生成新页面后，如果发现风格有不一致的地方，不是去修改生成的代码，而是去更新DESIGN.md文件。因为DESIGN.md是源头，修改源头之后所有后续生成都会自动遵循新规则。
验证和比较设计系统的命令行工具
谷歌还提供了一套命令行工具来验证和比较DESIGN.md文件。lint命令用来检查文件格式是否正确，有没有引用不存在的颜色标记，对比度是否符合无障碍标准。运行npx @google/design.md lint DESIGN.md，工具会输出JSON格式的检查报告，告诉你哪里有问题，严重程度是错误还是警告。
diff命令用来比较两个版本的设计系统。当你修改了DESIGN.md之后，可以用npx @google/design.md diff DESIGN.md DESIGN-v2.md看看改了哪些地方。输出会告诉你增加了哪些颜色标记，删除了哪些，修改了哪些。还会判断这次修改有没有导致设计倒退，比如删除了某个重要的组件样式定义。
export命令可以把DESIGN.md转换成其他格式。比如转成Tailwind的主题配置，就可以直接在Tailwind项目里使用。或者转成W3C设计令牌格式的JSON文件，实现跨工具的设计令牌互操作。
设计系统的具体内容结构
一个完整的DESIGN.md文件包含两个层次。顶层是YAML格式的前置数据区，用三个短横线分隔，里面存放机器可读的设计令牌。包括版本号、项目名称、颜色定义、字体定义、圆角尺寸、间距尺寸、组件样式映射。这些令牌是规范性的数值，AI优先读取这部分来生成具体的样式代码。
下面是Markdown格式的正文区，用两个井号开头的大标题组织内容。这部分写给人看也给AI理解，解释每个设计决策背后的原因。正文区的章节顺序是固定的，先是概述和品牌风格，然后是颜色、字体排版、布局间距、层级深度、形状圆角、组件样式、设计禁忌。这个顺序不能乱，因为AI会按照这个顺序解析文件内容。
颜色定义部分每个颜色都有语义化的名称，比如primary主色调、secondary辅助色、tertiary强调色。每个颜色用十六进制色值表示，同时会在正文里说明这个颜色用在什么地方。字体的定义包括字体家族、字号、字重、行高、字间距，每个字体样式也有语义化名称。
组件令牌的映射机制
组件令牌是DESIGN.md里最实用的部分。你可以定义一个叫做button-primary的组件，给它指定背景色从主色调取、文字颜色从主色调的文字色取、圆角从小圆角取、内边距固定为12像素。再定义一个button-primary-hover作为悬停状态，背景色换成深一点的版本。
这样定义之后，AI生成按钮时就知道用哪个颜色、哪个圆角、哪个内边距。而且所有这些值都是从统一的设计令牌派生出来的，不会出现不同页面的按钮样式不一致的情况。修改设计系统时只需要改令牌的定义，所有引用这个令牌的组件都会自动更新。
有效的组件属性包括背景色、文字颜色、字体样式、圆角、内边距、尺寸、高度、宽度。悬停、点击、聚焦等交互状态通过独立的组件条目来表示，用相关的名称来区分，比如button-primary和button-primary-hover。
实际项目中的使用建议
如果你在做AI编程相关的产品开发，DESIGN.md是必须要用的。因为单纯靠提示词控制AI输出实在是太不稳定了，稍微换个说法AI给的结果就差很远。有了DESIGN.md之后，设计风格就有了稳定锚点。
如果你在做一个SaaS产品或者前端项目，强烈建议把设计系统写成DESIGN.md格式，而不是只放在Figma里或者写在Notion文档里。因为DESIGN.md是AI可以直接读的，而Figma文件AI读不了。将来你会发现，能直接喂给AI的规范比给人看的规范有用得多。
如果你是个人开发者独立做项目，最简单的玩法是找一个现成的DESIGN.md示例，复制下来改成你自己的颜色和字体，丢进项目根目录，然后让AI按照这个规范生成所有页面。你不需要懂设计，只需要找一个你觉得好看的参考设计系统，让AI帮你翻译成DESIGN.md。
设计规范变成可执行代码的认知转变
这件事背后有一个很深的认知转变。以前设计规范是给人读的文档，写在PPT里或者贴在墙上，具体执行靠设计师和工程师的经验和自觉。现在设计规范变成了机器可读可执行的代码，AI可以直接按照规范生成界面。
这意味着未来的竞争不再是会不会写代码，而是谁能把自己的审美标准和品牌风格表达成机器能精确执行的语言。你的DESIGN.md文件就是公司审美的源代码，它比任何设计文档都更有价值，因为它是可以被AI直接执行的标准。
设计系统的可移植性和互操作性
DESIGN.md开源之后最大的价值是可移植性。以前你在Stitch里定义好的设计规则，换到别的工具就废了，要重新定义一遍。现在DESIGN.md是开放格式，任何支持这个格式的工具都可以读取同一个文件。
这就和Git一样，不管你用GitHub、GitLab还是Bitbucket，底层的Git格式是一样的。DESIGN.md要做的就是设计系统领域的Git，成为不同AI编程工具之间交换设计信息的通用格式。
谷歌提供了从DESIGN.md转换到Tailwind配置和W3C设计令牌格式的导出功能。这意味着你可以在Stitch里用AI生成DESIGN.md，然后导出成Tailwind配置用在传统前端项目里。反过来，你也可以从现有的Tailwind项目里提取设计令牌，生成DESIGN.md让AI使用。
格式规范的处理规则
对于未知内容的处理，规范有明确的规定。遇到不认识的大标题，工具应该保留这个标题而不是报错，因为可能是用户自定义的扩展章节。遇到不认识的颜色令牌名称，只要色值本身是有效的就接受，因为用户可能用了自定义颜色命名。遇到不认识的字体系列，只要格式正确就接受。遇到不认识的组件属性，给出警告但不拒绝整个文件。
这样的设计是为了保持兼容性，让DESIGN.md可以不断扩展而不破坏现有功能。同时重复的大标题会被视为错误拒绝处理，因为同一个章节不应该出现两次。
总结
点击标题：DESIGN.md是谷歌开源的AI设计系统协议，把设计规范变成机器可读的Markdown文件，让AI生成风格一致的界面，实现设计知识的可编程和可继承。
彩蛋
https://getdesign.md/ 是在 Stitch 的初始版本基础上也开发了自己的规范，并取得了不错的成果。本周，我们将根据新的规范修订这些规范，并更新预览。