OpenAI、Anthropic、Google 这些公司都推出过自己的设计系统(Figma 文件 + 组件库 + 文档站),但这些设计系统是给人看的。当 AI 编程助手(Claude Code、Cursor、Copilot)要帮工程师实现"按设计稿生成代码"时,它根本读不懂 Figma 文件——它只能读懂代码和 Markdown。
Google Labs 这次的解法是:把设计系统写成一个 DESIGN.md 文件——YAML 令牌 + Markdown 说理,Agent 可解析,人也能读。今天这篇拆解一下这个项目到底在做什么、为什么它会爆,以及对做产品/做运营/做内容的人有什么借鉴价值。
这个项目到底在做什么:让设计语言"代码化"
先看几个关键事实:
- 项目名:google-labs-code/design.md
- 类型:TypeScript,Apache-2.0 协议
- npm 包:
@google/design.md(alpha) - 累计星标:19,672
它做的事情可以一句话概括:定义一种人机都能读的设计规范文件格式。
听起来抽象,看个真实例子:假设你的品牌主色是 #FF6B35,主字体是 Inter,圆角统一 8px。传统做法是:把这些写在 Confluence 文档里 + 在 Figma 维护一个 token 库 + 在代码里用 SCSS 变量再写一遍。三处定义,改一次要改三处,经常漏。
design.md 的做法是:写一个 DESIGN.md 文件,把颜色、字体、间距、圆角、阴影这些设计令牌(design tokens)用 YAML 定义,把使用规则、组合方式、组件规范用 Markdown 写清楚。然后:
- Agent 能直接读:
Claude Code / Cursor 看到这个文件,就知道你的视觉系统是什么样子,生成的代码自动符合你的规范 - 人类也能读:
新人入职看这个文件,5 分钟就能上手,不用翻几十页 Confluence - 工具能验证:
9 条 lint 规则自动检查 token 完整性、对比度、孤立引用等问题 - 代码能导出:
一键导出成 Tailwind v3/v4 CSS、W3C DTCG 等多种格式,直接喂给前端项目
这套思路一脉相承于"Markdown as Code"运动——和 README.md、AGENTS.md、SKILL.md 一样,把以前散落在各种工具里的规范,收敛到一份可读、可解析、可验证的纯文本文件里。
5 个核心能力:为什么这件事突然变得可行
design.md 不是一个简单的"规范文档生成器",它提供了一整套工程化能力:
1. DESIGN.md 文件规范
YAML 定义令牌(颜色、字体、间距、圆角、阴影、动画),Markdown 说明用法和约束。Agent 可以直接解析,YAML 部分提取令牌值,Markdown 部分理解设计意图。
一个最小可用的 DESIGN.md 长这样:
---
brand: "Acme"
tokens:
color:
primary: "#FF6B35"
bg: "#FFFFFF"
fg: "#1A1A1A"
typography:
family: "Inter"
sizes: [12, 14, 16, 20, 24, 32]
spacing: [4, 8, 12, 16, 24, 32]
radius: 8
---
# 设计系统使用规范
## 颜色
- 主色用于 CTA 按钮、品牌标识
- 背景色仅用于浅色模式
- 文字色需保证 WCAG AA 对比度
## 字体
- 标题字号 ≥ 20
- 正文字号 16
- 行高 1.5这个文件人读起来一目了然,Agent 读起来也能立刻 parse 成结构化数据。
2. 9 条 lint 规则
design.md 内置的验证器能自动检查 9 类问题:
- token 完整性:必填字段是否齐全(主色、文字色、字体)
- WCAG AA 对比度:文字色和背景色是否达到 4.5:1 对比度
- 孤立 token 检测:定义但未使用的 token(浪费)
- 未定义 token 引用:用了 token 但 YAML 里没定义
- 重复定义:同一个 token 在多处定义,值不一致
- 命名规范:是否符合团队约定的命名规范
- 色板可达性:色板是否覆盖完整的明度梯度
- 字体可用性:声明的字体是否真的在 webfont 列表里
- 组件引用闭环:组件规范是否完整定义 props
这套机制让设计系统从"人维护"变成"代码验证"——以前改错一个 token,要等设计师肉眼发现;现在改完跑一遍 lint,立刻知道哪里坏了。
3. diff 差异对比
版本之间可以做 token 级别的回归检测——v1.0 主色是 #FF6B35,v1.1 改成了 #FF5733,diff 会高亮"主色变更",提示"这个改动会影响所有引用主色的组件"。
对团队协作来说,这是从"口头告知"到"工具强制"——所有视觉变更都自动可追溯。
4. export 多格式输出
同一份 DESIGN.md 可以导出成:
- Tailwind v3 config:
tailwind.config.js直接可用 - Tailwind v4 CSS:新版
@theme指令 - W3C DTCG 格式:
design-tokens.json行业标准 - CSS 变量:
:root { --color-primary: #FF6B35; } - SCSS/Less:传统前端栈
不管团队用什么技术栈,都能无缝对接。
5. spec 注入 Agent prompt
这是最有趣的能力——DESIGN.md 本身可以作为 prompt 的一部分喂给 AI 编程助手。
比如你对 Claude Code 说:"按我团队的设计系统做一个登录页",然后把 DESIGN.md 的内容粘贴到 prompt 里。Claude Code 就能直接生成符合规范的 HTML/CSS,不用你再补一句"主色用 #FF6B35,圆角 8px"——它已经从 DESIGN.md 里读到了。
这个能力让"AI 生成符合品牌规范的代码"第一次成为现实。
为什么它会上 Trending 第一:撞上了三个趋势的交汇
design.md 单日涨 1,475 颗星不是偶然。三个趋势在 2026 年 6 月这个时间点刚好撞上:
1. AI 编程助手从"补全"到"独立开发"
2026 年的 Claude Code、Cursor 已经能独立完成中型项目的开发。工程师的角色从"写代码"变成"review 代码 + 提需求"。在这种工作流下,设计系统必须先于代码存在,AI 才能读懂约束——design.md 正好是这个"前置规范"的承载形式。
2. 前后端协作的"规范断层"被工具填补
以前的痛点:设计稿在 Figma,后端用 CSS 变量,移动端用 StyleSheet,文档在 Confluence——四处定义,改一次动三处。design.md 把"单一事实来源"(single source of truth)做实了。
3. 团队规模变小,文档压力变大
2026 年很多创业团队 3-5 个人就要做一个产品,没有专门的设计系统工程师,设计师和前端要高效协作。一份 DESIGN.md 文件能同时服务"AI 编程助手 + 设计师 review + 新人 onboarding + 跨端同步",这在过去要 5 个工具才能做到。
对内容创作者/电商/运营的实际意义
可能你会觉得"我又不写代码,设计系统跟我有什么关系?"——其实关系很大。design.md 的核心思路可以平移到任何"需要一致性"的场景:
1. 私域社群的内容规范
你的小红书、抖音、公众号有没有"内容色板"?有没有"标题字数规范"?有没有"配图风格指南"?如果有,为什么不把它们写成一个 CONTENT.md 文件?这样:
- 新人写公众号前读 5 分钟,知道标题怎么起、配图怎么选
- AI 工具(自动生成小红书标题、配图 prompt)可以直接读这个文件
- 改一次品牌色,所有自动生成内容自动同步
2. 客服话术库
客服团队有没有"标准话术"?通常散落在飞书文档、Excel、Notion、PDF 培训手册里。每次新人入职要 1-2 周才能上手。完全可以做成一个 SCRIPT.md + lint 验证器:
- YAML 定义常见问题分类 + 标准答案
- Markdown 写"什么场景用什么话术"
- lint 规则检查"必说项是否漏掉"
3. 商品上新 SOP
电商团队的"上新检查清单"通常有 30-50 项。把它写成一个 LAUNCH.md 文件,配上自动化检查:
- YAML 定义必填字段(标题、价格、SKU、库存、首图)
- Markdown 说明每项的标准
- lint 规则检查"图片缺失""价格异常""关键词未填"
这样 AI 工具能直接帮你做 80% 的预检,运营只需要 review 异常项。
4. 内容营销的"模板化资产"
假设你的品牌在小红书有 3 种内容模板:种草、测评、教程。每种模板的结构是固定的——开头钩子、产品介绍、对比表格、CTA。完全可以把这 3 种模板写成一个 TEMPLATE.md 文件:
- YAML 定义每个 section 的必填项
- Markdown 说明每个 section 的写法
- AI 工具读到后,自动按模板填内容,运营只需要 review
这是"内容营销资产化"的关键——把经验沉淀成可复用、可校验、可迭代的规范文件。
借鉴清单:这套思路可以怎么用到 OpenClaw 生态
对做 Agent 系统的团队(包括 OpenClaw、Cursor、Claude Code 用户),design.md 的架构思路有 4 个直接可借鉴的方向:
1. Agent 可读配置规范
把团队协作规范、决策流程、SOP 全部格式化为 Agent 可解析的 YAML + Markdown 文件。Agent 在执行任务前,先读取这些规范,确保按团队约定执行。
对 OpenClaw 来说,可以让所有 Cron 任务的输出格式、命名规范、文件结构都有一份"团队规范文件"作为参照。
2. lint 验证器(优先级 🔴 高)
借鉴 design.md 的 9 条 lint 规则,做一套 OpenClaw 任务输出的自动验证器:
- 文件存在性(预期的输出文件是否生成)
- messageId 非空(飞书消息是否成功投递)
- index 一致性(目录索引文件是否和实际文件数一致)
- 格式合规(日期格式、命名规范是否正确)
- 引用闭环(超链接是否指向真实存在的资源)
这条对 OpenClaw 尤其重要——以前 Cron 任务假报 ok(显示成功但实际失败)就是因为没有自动化校验器。
3. diff 差异对比(优先级 🟡 中)
对 index.md、SKILL.md、MEMORY.md 这类核心知识库文件,做版本间的 diff 对比。每次修改前自动高亮"这次改了什么",review 起来一目了然。
4. token 引用语法(优先级 🟡 中)
在 Agent prompt 中使用 {引用路径} 这种 token 语法,让 Agent 自动展开团队规范文件里的具体内容,减少 prompt 歧义。
比如:把 "用 OpenClaw 标准的飞书消息格式" 改成 "用 {openclaw://templates/feishu-message.md} 里的格式"——Agent 直接读那个文件,确保一致性。
它的局限:什么时候不要用它
design.md 不是万能的。不适合的场景:
- 大型设计系统的复杂组件库:
design.md 更适合"令牌 + 基础规范"层,复杂组件的状态机、props 完整定义还需要额外的 Figma/Sketch 配套 - 需要高度个性化的品牌设计:
如果你的品牌每次活动都做定制视觉,design.md 的"单一事实来源"反而会限制灵活性 - 纯设计师不写代码的小团队:
design.md 的核心价值是"代码化",如果团队里没人写代码,直接用 Figma Variables + Confluence 更轻量
对比类似项目:design.md 的位置
市面上其实一直有类似方向的项目,design.md 暂时领先在 4 个维度:
- 官方背书:
Google Labs 出品,有持续维护的预期 - 格式简单:
YAML + Markdown,工具链极轻,任何编辑器都能写 - 导出齐全:
Tailwind v3/v4、W3C DTCG、CSS 变量全覆盖 - Agent 友好:
可作为 prompt 的一部分直接喂给 AI 编程助手
类似的还有 Style Dictionary(Amazon 出品,做 design token 转换)、Tokens Studio(Figma 插件,管理 design token)、Specify(配置即代码的设计系统)。但这些项目大多专注"工具"层,design.md 的差异化是"规范"层——它定义了一种格式,而不只是提供工具。
上手 3 步:5 分钟跑起来
如果你的团队想试一下,从最小可用开始:
第 1 步:写一份 DESIGN.md
挑你团队最常用的 1-2 个品牌色 + 1 个字体 + 基础间距,写成 YAML + Markdown。不需要一步到位,先有再用。
第 2 步:导出到 Tailwind/CSS 变量
用 design.md 的 CLI 工具导出成 tailwind.config.js 或 :root CSS 变量,接入现有项目。
第 3 步:接入 AI 编程助手
在 Claude Code / Cursor 的 prompt 里加一句"参考 DESIGN.md 的设计规范",观察 AI 生成的代码是否符合你的视觉。如果不符合,迭代 DESIGN.md 的内容(Agent 读的是你写的内容)。
3 步大概 5 分钟。最大的成本不是技术,而是团队第一次坐下来明确"我们的设计系统到底长什么样"。
💡 落地案例:这套思路对 OpenClaw 团队的价值
OpenClaw 团队的核心痛点是:多 Agent 协作时输出格式不统一、知识库更新靠人记、Cron 任务假报 ok。design.md 的思路可以直接平移:
1. 团队规范文件化:把所有 Agent 的输出格式、命名规范、SOP 写成 OPENCLAW.md,Agent 执行任务前自动读这个文件,确保产出符合团队约定。
2. Cron 任务自动验证:设计一套"任务完成度检查器",对每条 Cron 任务自动检查"输出文件存在?格式正确?引用闭合?飞书消息成功?",假报 ok 问题彻底解决。
3. 知识库 diff:对 MEMORY.md、SKILL.md 启用版本 diff,每次更新自动高亮"这次改了什么",review 起来一目了然。
按优先级排序:lint 验证器(🔴 高,直接解决假报 ok 问题) > 团队规范文件化(🟡 中) > diff 对比(🟢 低)。
你如果是做产品/运营/内容的团队,也可以按类似思路评估:把团队经验沉淀成"单一事实来源"的规范文件,用工具自动验证一致性,把人的精力从"review 格式"解放到"review 内容"。
附录:项目资源
- GitHub 仓库:https://github.com/google-labs-code/design.md
- npm 包:
@google/design.md(alpha 阶段) - 协议:Apache-2.0(可商用、可修改、可分发)
- 核心使用场景:AI 编程助手 + 设计系统 + 跨技术栈输出
对个人开发者来说,即使你暂时用不上完整的设计系统,这个项目也值得研究一下——它示范了一种"规范即代码"的工作方式,这种思路可以平移到内容营销、运营 SOP、客服话术等几乎所有"需要一致性"的场景。