AI 生成 UI 总缺高级感？聊聊 DESIGN.md

DESIGN.md，一个让 AI 生成界面不再“差点意思”的纯文本设计规范。它能否成为设计系统与 AI 之间的桥梁？本文梳理了其核心概念、与设计令牌的关系，并结合 Atlassian 实测，探讨其适用场景与边界。

前几天刷到一段关于 DESIGN.md 的介绍，说它能解决一个我一直有感的问题：让 AI 生成一个页面，功能全对，可一眼看上去——就是差点什么。差什么呢？颜色？对比度？字体？间距？你想要那种「高级感」，可你说不清，AI 也猜不准，来回改十遍还是不对。

这个描述我觉得挺准的。于是我花了半天，把这个概念相关的资料读了一圈——Google 的官方博客和文档、GitHub 上的社区合集、几位中英文作者的解读，还有一份企业环境下的对照测试，一共 10 个来源。

一、它想解决的问题

先给概念一个不绕的定义。

DESIGN.md 就是 README.md 的设计版。 一个放在项目根目录的纯文本文件，把这个产品长什么样——主色是什么、字号阶梯怎么排、圆角多大、按钮什么时候用主色——写清楚。AI 编码工具每次动手前先读它，然后照着生成。

它由 Google Stitch 提出。2026 年 4 月 21 日，Google Labs 在官方博客宣布把这套格式开源成草案规范，明确说是为了让它能跨平台使用，而不绑在自己一个工具上。官方文档里的定义是：AI agent 读取以生成一致 UI 的纯文本设计系统文档，可以从任意网址抽取，也可以自己定义后跨项目携带。

那它到底解决了什么？中文圈有一位作者 5key 写过一段挺具体的记录。他用 Claude Code 做一套数据分析系统时发现：

「菜单、Tab、输入框的样式，在两次 Coding 中出现了明显的不一致。」

他分析出三个原因：跨会话记忆丢失、AI 会自行跳过约束、以及我觉得最关键的一条——

「组件库文档是写给开发者的 API 参考，不是写给 AI 的设计决策指南。」

这句话我认为是整个概念的支点。

团队并不缺设计规范：Figma 有设计令牌、Storybook 有组件文档、Notion 有品牌指引。但这些都不在代码仓库，AI 编码工具只能读取仓库内文本，DESIGN.md 正是填补这一缺口。

二、它和设计令牌是什么关系

这是我一开始最没搞清楚的地方：既然已经有设计令牌了，为什么还要再来一个文件？designmd.app 上有一篇对比文章把这层说得很清楚：

「一个在跟编译代码的机器说话，另一个在跟写代码的机器说话。

设计令牌是给构建系统用的，只有值没有语义。Agent 看到 47 个颜色变量，它不知道哪个该用在卡片背景、哪个该用在页面背景。DESIGN.md 补的正是这层「意图」——它会写上「卡片不用投影，只用 1 像素描边」「主色按钮只留给页面上最重要的那一个动作」这类规则。

所以它的文件结构是刻意分成两半的：上半段是确定性的数值，给解析器读；下半段是自然语言写的设计意图，给大模型读。同一个文件，服务两类读者。

这个思路我觉得是成立的。那篇对比文给的建议也很务实：

还有一个视角我觉得对 PM 有用。有作者把当下这些新出现的 markdown 约定放在一起看，提出了一个分层框架：AGENTS.md 管整体行为和边界，SKILL.md 管单个可执行任务，DESIGN.md 管可验证的视觉规则。 底层逻辑是——能被形式化验证的东西（对比度、色值），就下沉到结构化规范里；需要人来判断的东西（语气、分寸），就留在自然语言里。

顺着这个框架看，DESIGN.md 就不只是设计圈的新玩具，而是「AI 协作文档正在分层」这件事的第三块拼图。这个视角比「又一个好用的工具」耐用一些。

三、目前公开的一份实测记录

读资料的时候我特意找了找有没有带数字的实测，因为讲怎么用的文章比较多，讲用下来实际表现如何的相对少。找到一份：Atlassian 在自家工程博客上，记录了他们把 DESIGN.md 和自己已有的设计系统方案（ADS MCP）放在一起做对照测试的过程。任务是生成一个登录页。

先说明这份材料在测什么。 它测的是「DESIGN.md 这种格式喂给 Agent 之后，生成表现如何」，和用什么工具生成这个文件无关。所以下面的内容应该理解成这个规范在当前阶段的特性，而不是某个具体工具的问题。

它记录到的正向部分： 在一次大会 keynote 的演示里，他们靠 DESIGN.md 把一版通用感很强的界面，变成了一眼能认出是 Atlassian 的界面；生成结果在颜色、间距、形状、字体上都对上了预期值。可携带性也确实好——单个文件，换任何环境、任何 AI 工具都能用，不需要装任何内部工具链。

它记录到的三点使用条件：

第一，文件是一次性全量加载的。 每次都把整个文件放进上下文，目前还没有按需检索的机制。在他们的测试里，这带来了明显高于 MCP 方案的 token 消耗。

第二，因为全量加载，文件体积需要控制。 他们的文件到 80KB（约合 1 万多个 token）就得做取舍，取舍掉的部分包含组件指引和一部分设计令牌，最终能覆盖到的设计系统上下文约 30%。

第三，Agent 有时会重新生成一个组件，而不是复用已有的设计系统。 生成出来的东西看着对，但没有接到团队真实的组件库上。

第三点不是他们一家的观察。Better Stack 的技术解析里也提到同一条边界：DESIGN.md 处理的主要是视觉令牌，而组件的行为，Agent 目前还是在推测。

有一点我想特别说一下，这也是我觉得这份材料值得读的原因：Atlassian 的作者自己写了一句「这些结果不应被视为结论性的」，并明确说换个模型、换个设计系统，结果都可能不一样。这是一份很克制的工程记录，而不是一份评测结论——我引用它，也是按这个分量来引用的。

四、那它目前更适合谁

把上面的东西合起来，我的理解是：这不太像一个「好不好」的问题，更像一个「你在哪个阶段」的问题。

在原型和 demo 阶段，它的性价比很高。

因为它的优点在这个阶段全部生效，而那几条使用条件在这个阶段基本不构成困扰：一个文件就能携带、跨工具通用、生成结果在颜色、间距、圆角、字体上确实能对上。至于 token 消耗和上下文覆盖率，做原型的时候通常不太在意。

在已经有成熟设计系统的生产环境里，值得多想一层。

你已经有组件库、有设计令牌、有一整套工程约束了。这时候要考虑的是上面那第三点——Agent 可能绕过组件库另建一个。这未必一定会发生，但适合先在小范围验证再往外铺。

有一位中文作者 silenceper 给过一个我觉得很准的边界判断：

「只是做一两个简单页面，这套规范未必立刻体现价值。」

他同时也认为，它「很可能会变成设计系统和 Agent 之间一个很自然的中间层」。这两句话放在一起看挺完整的：它的价值需要一定的项目规模才显现，但规模再往上走，又需要跟既有的工程体系配合。它目前最舒服的位置，大概在这两者中间。

本文由 @肥源 原创发布于人人都是产品经理。未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议