给 AI 写一份设计的「源代码」：评 Google Labs 的 DESIGN.md
2026 年 4 月,Google Labs 悄悄开源了一个看上去毫不起眼的东西——一份文件格式规范,名字就叫 DESIGN.md。它不是一个炫目的应用,没有界面,甚至连一行可运行的产品代码都不算。它只是约定
Markdown 文件,把一整套设计系统讲给 AI 编程代理听。可就是这样一个朴素的东西,在 GitHub 上三天涨了五千多颗星,把「设计师是不是第一个被 AI 取代的职业」这个老问题重新点燃,还逼着 Atlassian 这样的大公司专门写了篇工程复盘来回应它。要理解这股热度,得先弄明白它到底在解决什么。
它解决的是 AI 做设计时最尴尬的那个问题
任何用过 Claude Code、Cursor 或 v0 的人都遇到过同一种挫败
写代码很在行,但让它连续生成五个页面,你会得到五种漂移的设计语言。第一屏是克制的深灰,第三屏冒出来一道紫色渐变,第五屏的圆角又莫名其妙地从 8px 变成了 16px。这不是模型「笨」,而是它在缺乏上下文时,只能退回到训练数据里的「平均审美」——默认的 Tailwind 蓝、Inter 字体、到处都是的柔和阴影。业内给这种东西起了个不客气的名字 slop,直译过来就是「AI 泔水」。过去对付这个问题的办法都很笨拙。要么每写一个 prompt 就重新粘一遍「主色用 #4F46E5,标题用 Inter,圆角 8px」,要么丢一张截图过去让模型自己揣摩。前者繁琐且容易遗漏,后者更糟——一张截图能告诉 AI「这个按钮长这样」,却永远没法告诉它「这个次要按钮应该显得安静,而不是抢戏」。
DESIGN.md 的思路,是把设计意图变成一份代理可以反复读取的持久上下文。你在项目根目录放一份 DESIGN.md,AI 在会话开始时读一次,之后每一次生成都引用同一套色彩、字阶和组件规则。用一句在社区里流传很广的话说,它要让「第十屏看起来和第一屏属于同一个产品」。
一份 DESIGN.md 长什么样
它的结构简单到几乎可以一眼看懂,只有两层。
文件顶部是一段用 --- 围起来的 YAML 前置元数据,这是给机器读的部分,定义了设计 token：颜色、字体、圆角、间距、组件。颜色用十六进制,尺寸用 px 或 rem,token 之间还能用 {colors.primary} 这样的语法互相引用。这套 token 体系明确借鉴了 W3C 的设计 token 规范(DTCG),所以它能和 tokens.json、Figma 变量、Tailwind 配置之间来回转换,并不打算另起炉灶。
文件下半部分是 Markdown 正文,这才是给人读、也是给 AI 真正「理解」用的部分。规范要求它按固定顺序写八个区块
、颜色、排版、布局、层次与深度、形状、组件、以及「该做与不该做」。规范里反复用来举例的是一套叫「Heritage」的设计系统。它的主色是一种近乎墨色的深灰 #1A1C1E,点缀色是一抹暖土红 #B8422E,被起名叫「Boston Clay」。关键在散文里那句话
#B8422E 本身可以是任何东西,但「Boston Clay,唯一的交互驱动色」这句话,让 AI 知道它只该出现在可点击的元素上。
Google Labs 在配套的设计哲学文档里把这一点提到了纲领的高度,措辞相当坚决:「设计活在散文里」。它主张「散文,而非 token,才是这份规范的重点」,强调「一个具体的参照,胜过一串形容词」,还专门点出「负向约束」的价值——你刻意省略掉的东西,定义了一套设计的性格。在它看来,生成设计的质量取决于意图被描述得多清晰,而不是数值有多精确;token 值「只是上下文,不是渲染指令」。这是个挺反直觉、但相当深刻的判断
AI 真正需要的不是更精密的参数表,而是人类设计师脑子里那套「为什么」。配套还有一个 npm 命令行工具 @google/design.md,能做四件事:lint 校验文件结构、检查对比度是否达到无障碍标准、揪出没解析的 token 引用;diff 比较两份文件,在你改了个颜色导致对比度不达标时报警;export 把 token 导出成 Tailwind 或标准 tokens.json;spec 则直接吐出规范本身,方便塞进 AI 的提示词里。值得一提的是,无障碍检查是这个格式的核心功能而非可选项——它默认对每个组件的前景背景色校验 WCAG AA 标准。
它不是 Figma 杀手,而是补上了缺失的一环
要给 DESIGN.md 定位,最容易犯的错就是把它当成某个现有工具的替代品。它谁都没打算取代。
跟 Figma 比,它根本不在一个赛道。Figma 的实时协作、权限管理、评论批注、像素级精修,DESIGN.md 一样都做不了,也不想做。真实的工作流是混搭的
Stitch 和 DESIGN.md 去构思、快速出原型、把设计转成代码,再回到 Figma 做精修和团队协作。(顺带一提,今年 3 月 Google 发布「vibe design」概念后,Figma 股价两天内跌了约 11%——这是媒体记录到的市场情绪,不能简单当成因果。)跟设计 token 那套成熟方法论(DTCG、Style Dictionary、Tokens Studio）比,它也不是来抢饭碗的,毕竟它的 token 直接就借用了 DTCG 标准。两者真正的分野不是「新与旧」,而是「纯数值」与「数值加理由放在同一份文件里」。如果你要把设计分发到 iOS、安卓、React Native 多个平台,有一套成熟治理流程,那么传统的 token 流水线依然是首选,DESIGN.md 顶多做它的上游或导出目标。
它最贴切的类比,其实是 AGENTS.md 和 CLAUDE.md——那些已经被开发者用熟了的「给代理看的说明书」。可以说 DESIGN.md 就是「设计版的 CLAUDE.md」。眼下整个行业正把给 AI 的指令拆成三层
.md 管代理的整体行为和边界,SKILL.md 管具体能执行的任务,DESIGN.md 管设计系统。这里有个微妙但重要的差别.md 已经在 2025 年底捐给了 Linux 基金会,由 Anthropic、Google、Microsoft、OpenAI 等共同治理;而 DESIGN.md 目前主要还攥在 Google Labs 自己手里。它能不能真正变成行业标准,这一点的走向至关重要。真正有用,但别高估它
把好处说清楚
.md 是纯文本,能进 Git,改个主色就是一次能被 review 的 PR diff,设计系统第一次像工程产物那样运作起来。它跨工具通用,意图跟着项目走,不被某个平台锁死。它能承载截图和 JSON 都装不下的「为什么」。有测评者做过对照实验,只往散文里加一句「品牌语气克制、偏好留白」,AI 生成出来的布局密度、文案语气都明显不同——而 token 值一个没改。这恰恰印证了那句「设计活在散文里」。但它远没有宣传得那么万能,有几条限制值得认真对待。
它还是 alpha 阶段,规范自己都说字段名随时可能变。更要紧的是,它没有任何强制力——DESIGN.md 说到底只是根目录里一个文本文件,没有任何机制能阻止 AI 生成一个不在规范里的颜色。lint 是事后检查,拦不住生成过程本身。
最硬的一记反证来自 Atlassian 的工程团队。他们在今年 6 月做了个实测
token 和组件库的生产代码库里,只用 DESIGN.md 当设计上下文去做一个登录页,结果消耗了 721 万 token、耗时近 7 分钟;而换用他们自己基于 MCP 协议的设计系统服务器,只花了 375 万 token、5 分钟出头。前者整整多烧了九成的 token,而且 DESIGN.md 能覆盖的设计系统上下文只有三成左右,MCP 那套能到八成。根子上的原因有三个：DESIGN.md 是一次性把所有内容全量塞进上下文,而 MCP 是按需加载;为了把文件压到能用的体积,他们不得不砍掉五十多个组件的用法说明,等于自废武功；最要命的是,它教 AI 的是「怎么从头重做一个组件」,而不是「怎么复用现成的组件」,这反而会制造技术债。Atlassian 的结论很中肯
.md 是一份出色的「可移植快照」,适合从零开始的原型、跨平台移植、给客户做主题定制,但它替代不了一套功能完整的设计系统工具。还有个隐忧没法靠工具消除。DESIGN.md 确实抬高了 AI 设计的下限,让界面「不再是默认的那种蓝」。但如果大量团队图省事,直接从社区里套用现成的品牌 DESIGN.md,结果可能反而是加剧了那种千篇一律的「AI 味」——而这正是 2026 年「反 vibe coding」声浪批评得最狠的地方。品牌的独特性,终究还是落在那些得由人来写的负向约束和具体参照上。
社区的态度,大体是高热度伴着清醒。星标暴涨、衍生的收藏库迅速破万星、开发者纷纷把它写进自己的工具链;但独立测评给出的典型评价也很实在:「出原型的提速很明显,但还是难彻底摆脱 AI 味,当草稿很强,真要做实用界面还得人来改。」
它搅动的几个行业
放到更大的格局里看,DESIGN.md 的意义其实大于它本身这个工具。
对 AI 编程工具行业，它把「上下文工程」从代码规范延伸到了视觉规范,补齐了 vibe coding 流程里一直缺的那块设计上下文。但 Atlassian 的数据也给整个行业提了个醒
,未必比按需检索更高明,在大型代码库里，MCP 这类方案往往更省也更准。对设计师这个职业，争议最大。前 Google 和 Meta 的产品负责人、投资人 Gokul Rajaram 在 X 上直接抛出断言:「设计,AI 的第一个牺牲品」,认为产品设计作为一项独立职能正在终结。这话立刻招来一片反驳。有人说，会被取代的是「只画像素的纯设计师」,你得同时成为一个会发货的 builder;有人说，第一个被干掉的不是「设计」，而是「交付物」——懂系统思维、懂怎么把东西真正做出来的设计师，反而正要起飞；还有人精准地指出,真正被淘汰的其实是高保真的 mockup 这道工序。更被普遍接受的看法是
「向上移动」——不再纠结按钮是 14px 还是 16px,而是去定义品牌主张、定义什么叫克制、定义 DESIGN.md 里到底该「禁止」什么。换句话说,DESIGN.md 没有消灭设计判断,它只是把设计判断从画布上挪到了文字里。对前端和设计到代码的工作流，它让设计系统终于有了 PR、有了 code review、有了变更历史。配合 Stitch 的 MCP 服务和 Claude Code,已经能跑通「在 Stitch 里设计 → 导出 DESIGN.md → AI 生成 React 代码」的完整闭环。
对设计系统工具行业，它既是挑战也是补位。它把设计系统的重心从 Figma 文件，往可移植的 Markdown 规范上轻轻挪了一点。但要真取代 Figma 当协作中枢,它还差着实时多人编辑、权限、分支合并、企业治理一大截。Atlassian 的选择很有代表性——「与其被动反应,不如主动塑造」,他们干脆公开了自己的 DESIGN.md,主动给规范提反馈,而且已经看到一些建议被采纳进了正式 spec。
该不该现在就用
如果你是 AI 优先、做单一产品的独立开发者或小团队,已经在用 Claude Code 或 Cursor,那花一两个小时写一份 DESIGN.md 放进仓库、把 lint 接进 CI,是笔很划算的投入。判断它值不值的标准很简单
AI 交付、不用你手动改色就「对味」的功能,什么时候出现。如果你要做的是蓝天原型、在陌生工具里试水、或者给客户做主题定制——这些正是它的甜区,放手用。
但如果你已经有一套成熟的设计系统,重度依赖 Tokens Studio 或 Figma 变量,那就别急着迁移。把 DESIGN.md 当成一个导出目标或者上游的意图层,而不是唯一真理来源;在生产代码库里,优先还是用 MCP 加 lint 规则这套零 token 成本的组合。等它脱离 alpha、有了独立治理、主流工具开始原生支持,再重新评估也不迟。
至于受监管的场景——医疗、金融、支付合规——现在就别碰一个还标着 alpha 的规范。
说到底,DESIGN.md 真正有意思的地方,不在于它是不是一个好工具,而在于它代表的那个判断
AI 越来越多地替我们生成界面,人类最该留在手里的,不是像素本身,而是关于这些像素「为什么是这样」的那段散文。它把这件事写成了一份可以被读、被校验、被版本管理的文件。哪怕这个具体的格式将来被别的东西取代,这个方向——把设计意图结构化地交给机器——大概是回不去了。