DESIGN.md：给 AI 编码智能体一份看得懂的设计规范

当 AI 编码智能体开始写前端代码，最大的痛点不是不会写，而是写出来的东西没有灵魂——颜色不对、间距失调、字体混乱。Google Labs 今日开源的 DESIGN.md 试图用一份结构化的 Markdown 文件，让智能体像人类设计师一样理解视觉标识。上线不到一天即斩获 1,475 颗星，它正在成为 AI 原生设计系统的“通用语”。

这个项目在做什么

DESIGN.md 是一份格式规范，专门为编码智能体（如 Copilot、Cursor、Devin）描述视觉标识。它把设计系统拆成两层：机器可读的 YAML 前端数据（token）和人类可读的 Markdown 正文（设计理由）。token 告诉智能体精确值，prose 告诉它为什么这么用。

这解决了 AI 编码的一个核心矛盾：人类设计师用 Figma 图层和直觉工作，而智能体看到的是像素和 DOM 树。DESIGN.md 充当了翻译层——智能体读取一份文件，就能输出风格一致的 UI。

为何此刻被关注

2026 年 6 月 25 日，Google Labs 在 GitHub 上发布了 DESIGN.md 的完整规范与 CLI 工具，并同步在 X 上引发了讨论。此前一周，该项目已积累 1,641 星，而今日单日新增 1,475 星，直接冲上日榜。

爆发点在于：AI 编码工具正处于从“能写代码”到“能写好看代码”的转折期。Anthropic 的 Claude 3.5 Sonnet 刚支持了视觉理解，Cursor 也在推广设计到代码的工作流。DESIGN.md 恰好提供了一个标准化接口——不是又一个设计系统，而是设计系统的“元格式”。

技术上有何不同

与 Style Dictionary 或 Design Tokens 格式相比，DESIGN.md 的独特之处在于：

双重视角：YAML 前端 + Markdown 正文。Style Dictionary 只有 token 定义，没有设计理由；DESIGN.md 的 prose 部分让智能体理解“为什么这个颜色是主色”，而不仅仅是“主色是 #1A1C1E”。
组件变体支持：通过命名约定（如 button-hover）表达 hover、active、pressed 状态，避免了复杂的嵌套结构，智能体更容易解析。
内置验证与对比：CLI 工具可以验证 token 引用、WCAG 对比度，并输出结构化 JSON 供智能体消费。designmd diff 命令能检测两个版本间的 token 和 prose 回归——这在团队协作中非常实用。
容错设计：对于未知的 section 标题或 token 名称，规范要求“保留，不报错”；只有重复的 section 标题才拒绝。这种宽松策略降低了智能体解析失败的概率。

谁应该用它

AI 编码工具团队：如 Cursor、Copilot、Windsurf 的开发者，可以将 DESIGN.md 作为智能体上下文注入的标准格式，提升生成 UI 的一致性。
设计系统维护者：需要同时面向人类和机器输出设计规范时，DESIGN.md 可以自动生成 Style Dictionary 或 Figma 插件的数据源。
前端工程师：在 AI 辅助编写组件时，通过一份 DESIGN.md 文件约束生成结果，避免反复修改。

局限与开放问题

目前 DESIGN.md 仍处于早期阶段：没有官方 Figma 插件，token 类型仅覆盖颜色、尺寸、排版等基础属性，对于复杂的动画、响应式断点、暗色模式等场景尚未定义。此外，智能体对 prose 的理解质量取决于模型能力——如果模型无法正确解析“温暖石灰岩背景”这样的自然语言描述，token 的精确性就失去了意义。