design.md 火了，苹果的 HIG 其实早就是这个思路

design.md 是什么

design.md 是一份用 markdown 写的设计系统说明文件，专门给 AI 编程助手看，不是给人看的。文件里把一个产品的颜色、字体、间距、组件规则这些原本只存在设计师脑子里或者 Figma 文件里的东西，翻译成一份结构化的纯文本，通常包含品牌调性概述、色板和色值、字体层级、组件样式、布局间距规则，以及一份"不要做什么"的清单。

这套约定最早由 Google 的 AI 设计工具 Stitch 推广开来，思路很简单：把 design.md 放进项目根目录，Claude Code、Cursor、v0、Lovable 这些 AI 编程助手打开项目时会自动读取这份文件，之后生成界面就会直接套用里面定义的颜色和字体，而不是随手给一套通用的默认样式。

2026 年 4 月，Google Labs 把这套 DESIGN.md 格式开源，行业里开始把它和 README.md 相提并论——一个告诉 Agent 代码怎么跑，一个告诉 Agent 界面该长什么样。

为什么突然被讨论

原因很直接：现在几乎所有主流 AI 编程工具都在抢着读用户的设计系统，但过去这件事没有统一格式，每个工具各自维护一套私有的 tokens，或者靠用户在对话里反复描述"要现代简洁一点"。

design.md 把这件事标准化了。写一次，所有支持这个约定的工具都能读，省掉了反复解释品牌规范的沟通成本。现在已经有工具直接在产品文档里写明自己遵循的是"开放的 Google design.md 约定"，说明这套格式正在从一家公司的私货变成事实标准。

怎么用

写一份 design.md 并不需要遵循严格的 schema，本质上是用自然语言加结构化列表描述规则，Agent 会把它当作指令来读。

常见的做法是包含以下几个部分：品牌调性和目标受众的整体描述、主色和辅助色的色值及使用场景、字体家族和不同层级的字号字重、按钮卡片输入框等组件在不同状态下的样式、间距和圆角这些具体数值，以及一份明确的禁止清单，比如不用全大写文本或者不要卡片套卡片。

写好之后放进项目根目录，或者上传给支持这套约定的 AI 助手，后续每一次生成界面的请求都会自动带上这份品牌简报。

顺带看看苹果的 HIG

design.md 服务的是 AI Agent，苹果的人机界面指南（HIG）服务的对象一直是人类开发者，两者出发点不一样，但做法上有一个共同点越来越明显。

最近苹果给新设备 iPhone Duo 更新的设计规范文章，开头就藏着一段不会显示在页面上的元数据，标注了这篇内容的类型、所属分类、对应网址路径和文档角色，说明 HIG 本身也是用结构化的源文件在维护，再由内部工具编译成开发者看到的网页，文末的更新日志表格也在记录每一次改动的日期和内容。

也就是说，无论是给 AI 看的 design.md，还是给人看的 HIG，规范类文档正在往同一个方向走：用结构化、可版本管理的纯文本，取代散落在各处的口头约定或者截图说明。

评价和看法

design.md 能火起来不意外：AI 编程工具越来越依赖项目里已有的上下文来减少幻觉和风格跑偏，一份结构清晰的设计系统文件几乎是最省事的输入方式。

倒是苹果这次更新 HIG 的方式提了个醒。苹果一直被认为是设计规范做得最细的公司之一，现在连他们自己的文档系统都在往结构化数据的方向靠拢，说明不管是给人看还是给机器看，把规范写成可被程序解析的格式，正在变成整个行业默认的做法。