title: "AI 写代码能过 review，但过不了审美——一个 md 文件正在补上最后一块短板" description: "Google 开源的 DESIGN.md 让 AI 终于能听懂'高级一些'到底是什么意思。但设计规范文件化这条路，远没有看上去那么平坦。" tags: ["AI设计", "DESIGN.md", "Google", "开源", "AI编程"]
所有 AI 生成的页面，长得像同一个人穿了不同颜色的衣服。
按钮是圆的，间距是对称的，配色永远是那几个——Tailwind 默认靛蓝、Inter 字体、白色背景。你让它"高级一些"，它把靛蓝换成深紫；你让它"炫酷一些"，深紫变成荧光绿。换汤不换药。
这不是 AI 的审美有问题，是你没给它审美标准。
代码层面，我们早就解决了这个问题——CLAUDE.md 告诉 AI 用什么框架，AGENTS.md 告诉它怎么协作，Skills 告诉它怎么调用工具。AI 写的代码能过 code review，但生成的界面连你自己都不想看第二眼。
设计层面，一直缺一份"宪法"。
Google Labs 四月份开源的 DESIGN.md，正在填这个坑。GitHub 上两周 6700 Star，现在已经 2.5 万。但比数字更值得关注的是：它试图定义的，是 AI 时代设计系统的标准格式。
从"猜你想要"到"知道你想要"
DESIGN.md 的核心思路极其简单：把设计系统写成一份 AI 能读懂的 Markdown 文件。
文件分两层。YAML front matter 放机器可读的精确值——颜色十六进制、字号像素、间距、圆角。Markdown 正文放人可读的设计理念——为什么主色是这个、为什么按钮要做成圆角。
AI 读到 primary: "#1A1C1E"，知道标题用深墨色；读到"温暖米色背景营造阅读舒适感"，知道为什么不用纯白。精确数值让它能执行，设计意图让它能判断。
这两层缺一不可。只有数值没有意图，AI 遇到没见过的场景就懵了——规范里没写卡片阴影该多大，它就随便来。只有意图没有数值，AI 知道要"温暖"但不知道该用 #F7F5F2 还是 #FFF8E7。
Google 官方给了一个 Heritage 示例：Public Sans 字体、深墨标题、Boston Clay 红色 CTA 按钮、温暖米色背景。每个值都有出处，每段意图都有解释。AI 拿到这份文件，生成的页面就像同一个设计师做的。
不只是"另一个设计规范"
有人会问：Figma 里不是有 Design Token 吗？Tailwind 主题配置不是也能定义颜色和间距吗？为什么还要搞一个新的 Markdown 格式？
区别在于谁在读。
Figma 的 Token 是给设计师看的，Tailwind 的配置是给编译器看的。DESIGN.md 是给 AI Agent 看的。它不需要打开 Figma，不需要跑构建工具，只需要在生成代码前读一份纯文本文件。
这背后是一个更深的范式转变：设计系统的消费者，正在从人类变成 AI。
过去十年，设计系统的主要用户是前端工程师——他们从 Figma 量尺寸、抄颜色、对间距。现在，AI Agent 直接生成 UI 代码，设计系统必须变成 AI 原生的格式。DESIGN.md 就是这个转变的产物。
配套的 CLI 工具也印证了这一点。四条命令——lint 校验、diff 对比、export 导出、spec 输出——每一条都是 AI Agent 能自动调用的。npx @google/design.md lint DESIGN.md 跑完，8 条规则自动检查，输出结构化 JSON，Agent 直接根据结果修正。AI 不只是读 DESIGN.md，还能自己维护它。
生态拼图：三件套齐了
DESIGN.md 不是孤立存在的。把它和 CLAUDE.md、AGENTS.md 放在一起看，一个完整的 AI 编程"三件套"就浮现了：
- CLAUDE.md：教 AI 怎么写代码——框架、命名、测试规范
- AGENTS.md：教 AI 怎么协作——角色分工、流程编排
- DESIGN.md：教 AI 怎么写好看的代码——颜色、字体、间距、设计理念
代码规范 + 协作规范 + 设计规范，三份 Markdown 文件，覆盖了 AI Agent 生成代码的完整维度。
另一个开源项目 Awesome Design.md 则在往这个框架里填内容——它把 Claude、Notion、Apple 等 70 多个知名品牌的视觉风格，逆向翻译成了 DESIGN.md 格式。Google 立规矩，社区出样板，生态开始自转。
代价清醒：一份 Markdown 管不了所有事
但 DESIGN.md 远没有看上去那么万能。
首先，规范还在 draft 阶段。 Google 自己在 LinkedIn 上明确说了"spec could change under you"。现在基于这个格式构建工作流，下个月可能就要改。早期采用者的代价，就是帮 Google 踩坑。
其次，静态文件管不了动态场景。 响应式布局的断点怎么定义？暗色模式切换的 token 映射怎么做？复杂交互的动画时序怎么描述？这些 DESIGN.md 目前都覆盖不了。一份 Markdown 文件能定义"按钮是圆角 8px"，但定义不了"按钮在 hover 时 200ms 缓动放大 1.05 倍"。
第三，社区已经暴露了实际问题。 有人给 Claude Code 加了 DESIGN.md 插件做实时预览，结果发现——当页面设计极度内敛（比如 Claude 官网那种暖灰调）时，预览渲染跑偏严重。静态 Token 和实际渲染之间的鸿沟，比想象中大。
最后，还有一个更根本的质疑： 设计真的能被文件化吗？优秀的设计师做决策时，大量依赖直觉和上下文——品牌调性、用户心理、文化暗示。这些"隐性知识"能不能被 YAML 键值对捕获，本身就是个问号。
竞争格局：谁在定义 AI 的审美标准
DESIGN.md 背后还有一层博弈。
Google 推这个格式，表面上是开源贡献，实际上是在争夺 AI 设计工具的标准制定权。Stitch 是 Google 的 AI 设计工具，DESIGN.md 最初就是 Stitch 的内部格式。开源它，意味着所有 AI 工具——包括竞争对手的——都会读到 Google 定义的格式。谁定格式，谁定规则。
Figma 不会坐视不管。它的 Design Token 标准已经提交 W3C，背后是整个设计工具生态的既得利益。DESIGN.md 的 Token 格式虽然"inspired by W3C Design Token Format"，但终究是另一套体系。两套标准并存，开发者迟早要选边。
而 AI 编程工具这边，Cursor、Claude Code、v0、Lovable 都在往"AI 生成 UI"的方向走。谁能最好地对接设计系统，谁就能在 AI 前端开发这个赛道上拿到更多份额。DESIGN.md 是 Google 在这个竞争中的筹码。
趋势判断
DESIGN.md 能不能成为行业标准，现在下结论太早。但有一个趋势已经很明显了：
AI 编程的竞争维度正在从"能不能写代码"转向"能不能写好看的代码"。
当所有 AI 都能生成功能正确的代码时，设计质量就成了新的差异化。而设计质量的前提，是设计系统能被 AI 稳定地理解和执行。DESIGN.md 不管最终是不是那个答案，它提出的问题是对的。
三件套的最后一块正在补上。代码能过 review，审美也能过 review——这才是 AI 编程真正可用的状态。
至于那份 Markdown 文件够不够用，让社区再踩半年坑就知道了。
暂无评论。