最近看 AI Coding Agent，我越来越觉得一个问题会变得很重要：不是它会不会写代码，而是它写出来的界面能不能保持一致。

很多人应该都有类似体验。你让 AI 帮你做一个页面，第一次看还行；再让它加一个弹窗、补一个设置页、改一套卡片样式，味道就开始变了。按钮圆角变了，颜色深浅变了，标题字号也变了。它不是不会写 CSS，而是它没有一个稳定的设计上下文。

Google 最近开源的 DESIGN.md，解决的就是这个问题。它不是一个 UI 框架，也不是一套组件库，更像是一份「给 AI 看的设计说明书」。你把品牌颜色、字体、间距、圆角、组件规则和设计意图写进一个 Markdown 文件，代码 Agent 以后做界面时，就有了一个可以反复读取的设计依据。

我查了一下，这个项目是 2026 年 4 月创建的，目前 GitHub 已经有 15k+ stars、1.4k+ forks，最近一次 release 是 0.2.0，仓库在 6 月 11 日还有提交，说明不是一个发完就不管的概念仓库。对正在用 AI 写前端、搭产品原型、维护多页面工具的人来说，这个方向值得看。

它是什么？

DESIGN.md 的核心很简单：用一个普通的 Markdown 文件，同时保存两类信息。

第一类是机器可读的设计 Token，放在文件开头的 YAML front matter 里，比如颜色、字体、间距、圆角、组件属性。第二类是人能读懂的设计说明，放在 Markdown 正文里，解释这些颜色和样式为什么这样用，以及哪些场景该用、哪些场景不该用。

一个很简化的例子大概是这样：

---
version: alpha
name: Heritage
colors:
  primary: "#1A1C1E"
  secondary: "#6C7278"
  tertiary: "#B8422E"
  neutral: "#F7F5F2"
typography:
  h1:
    fontFamily: Public Sans
    fontSize: 3rem
    fontWeight: 700
components:
  button-primary:
    backgroundColor: "{colors.tertiary}"
    textColor: "#FFFFFF"
    rounded: "{rounded.sm}"
---

## Overview

Architectural Minimalism meets Journalistic Gravitas.

## Colors

Primary 是深墨色，用于标题和核心正文；Tertiary 是唯一强调色，主要用于关键操作。

这个设计有意思的地方在于，它没有把「设计」完全压缩成一堆变量。Token 负责精确值，正文负责解释意图。对人来说，这是设计规范；对 AI Agent 来说，这是上下文。

为什么它适合给 AI 用？

传统的设计系统更多是给人和工程项目用的。比如你有 Figma，有组件库，有 Tailwind 配置，有一堆设计规范文档。问题是，AI Coding Agent 未必知道这些东西之间的关系，也未必每次都能正确读取。

DESIGN.md 的切入点更轻。它就是一个文件，放在项目里，Agent 可以直接读。相比在 Prompt 里反复写「请使用深色科技风、按钮圆角 8px、主色 #4285F4」，一个稳定的 DESIGN.md 更像项目级记忆。

我觉得它最适合解决三个场景：

  • AI 生成页面时风格漂移，今天像 Notion，明天像 Linear，后天又像 Bootstrap 默认主题。

  • 多个 Agent 或多次对话参与同一个项目，大家对 UI 风格的理解不一致。

  • 你想让 AI 不只是「照着截图做」，而是理解一个产品应该有什么气质。

这里有个细节很关键：DESIGN.md 不只是写「高级」「简洁」「科技感」。这种词对 AI 太宽了。它鼓励你写具体的参考、颜色意图、使用边界，比如「这个强调色只用于主按钮，不用于普通标签」，这比单纯堆形容词更有用。

和直接写 Prompt 有什么区别？

直接写 Prompt 当然也能用。比如你可以告诉 AI：「做一个深色后台页面，蓝色强调色，圆角卡片，字体大一点。」短期看没问题，但 Prompt 很容易丢上下文，也很难形成项目资产。

DESIGN.md 的区别在于，它把设计上下文文件化了。

这件事的价值不在于格式多复杂，而在于它可以被重复消费。你今天用 Claude Code，明天用 Gemini CLI，后天换另一个 Agent，只要它能读项目文件，就可以读同一份设计说明。设计风格不再被锁在某一次对话里。

从工程角度看，这也更接近我们熟悉的工作方式：README.md 解释项目怎么跑，AGENTS.md 解释 Agent 怎么协作，DESIGN.md 则解释界面应该长什么样。

比较值得看的设计

我觉得 DESIGN.md 里有几个点比较实用。

第一个是 Token 和 prose 结合。很多设计系统文件只剩变量，变量当然准确，但 AI 不一定知道为什么要这么用。DESIGN.md 保留 Markdown 正文，就是为了把设计意图写清楚。比如一个颜色是不是只用于 CTA，一个字体是不是只用于标题，一个阴影是不是要少用，这些都适合写在正文里。

第二个是有 CLI。它提供 @google/design.md 这个 npm 包，可以做 lint、diff 和 export。lint 可以检查结构、Token 引用、WCAG 对比度；diff 可以比较两个版本有没有设计回退；export 可以导出到 Tailwind 或 Design Tokens 格式。

常用命令大概是：

# 校验 DESIGN.md
npx @google/design.md lint DESIGN.md

# 比较两个版本
npx @google/design.md diff DESIGN.md DESIGN-v2.md

# 导出 Tailwind 配置
npx @google/design.md export --format tailwind DESIGN.md > tailwind.theme.json

0.2.0 版本还加了 Tailwind CSS v4 的 @theme 导出，并支持更多 CSS Color Module 颜色格式。最近的提交还在补嵌套 Token 声明和 Windows/PowerShell 调用文档，说明这个工具还在快速补工程细节。

第三个是它足够轻。你不需要先引入一个庞大的设计平台，也不需要把现有项目重构掉。对很多个人项目、内部工具、AI 生成原型来说，先放一份 DESIGN.md，成本比搭完整设计系统低很多。

适合谁用？

如果你已经在用 AI 写前端，尤其是让 Agent 一次次改页面、补组件、生成管理后台或产品原型，DESIGN.md 很值得试。它不能保证 AI 一次就写出好设计，但至少可以减少「每次都重新发明风格」的问题。

如果你是独立开发者，它可以当作轻量设计系统。很多个人项目没有完整 Figma，也没有专门设计师，但仍然需要颜色、字号、间距、按钮样式保持一致。这时一份 DESIGN.md 可能比零散 Prompt 更靠谱。

如果你是团队里的前端或产品工程师，它也可以用来给 Agent 设边界。尤其是公司内部工具，大家不一定追求特别惊艳的视觉，但需要一致、可维护、不要乱来。

不适合/需要注意什么？

首先，DESIGN.md 目前还是 alpha。它的规范和 CLI 还在变化，不能把它当成已经稳定多年的行业标准。现在更适合试用、观察、放到个人项目或非关键链路里验证。

其次，它不会自动让 AI 拥有审美。DESIGN.md 能提供约束和上下文，但如果说明本身写得很空，最后生成出来的东西还是会空。比如你只写「现代、简洁、高级」，它帮助有限；你写清楚颜色使用规则、参考气质、组件边界，效果才会明显。

还有一点，团队项目要考虑和现有设计资产的关系。如果你已经有 Figma Variables、Tailwind Theme、组件库，那么 DESIGN.md 最好是一个 Agent 可读的说明层，而不是又多造一个事实来源。否则很容易出现 Figma 里一套、代码里一套、DESIGN.md 里又一套。

小结

我对 DESIGN.md 的判断是：它不是一个会立刻改变前端开发方式的大工具，但它抓住了 AI Coding Agent 时代一个很实际的问题。

以前我们担心 AI 不会写代码，现在代码越来越能写了，新的问题会变成：它是否理解项目的长期约束。设计就是其中很典型的一类约束。颜色、字号、间距、组件状态，看起来都是小事，但小事不稳定，产品就会显得很散。

所以 DESIGN.md 真正有价值的地方，不是「又多了一个 Markdown 规范」，而是它把设计上下文变成了项目文件。这个思路我觉得会越来越常见：未来项目里可能不只有 README，还有给 Agent 看的架构说明、测试说明、设计说明、协作说明。

如果你经常让 AI 帮你写 UI，可以拿一个小项目试一下。先不要追求完整设计系统，只写清楚主色、背景、字体、间距、按钮、卡片，以及几条明确的 do / don't。然后让 Agent 按这份文件继续改页面，看它还会不会跑偏。

项目地址