01 AI 写前端，真正缺的不是代码
过去让 AI 写前端，最常见的翻车点不是“它不会写代码”，而是“不懂你的设计系统”。你说“高级一点”，它可能甩出渐变大卡片；你说“保持品牌感”，它不知道品牌感到底是颜色、字体、圆角，还是页面密度。
Google Labs Code 的 design.md 有点像给 AI 编码代理准备的“设计说明书”。它不是 UI 框架，也不是组件库，而是一种约定：把设计系统写进 DESIGN.md，让人能读懂，让机器也能稳定执行。
02 它的核心：token + 设计意图
它的结构很简单：顶部用 YAML 写 token，下面用 Markdown 写设计意图。YAML 负责精确值，比如颜色、字号、间距、圆角、组件样式；Markdown 负责解释“为什么这么用”和“哪些地方不能乱用”。前者解决“别猜”，后者解决“别机械套值”。
比如可以这样写：
colors:
primary:"#1A1C1E"
tertiary:"#B8422E"
rounded:
sm:4px
components:
button-primary:
backgroundColor:"{colors.tertiary}"
rounded: "{rounded.sm}"
再在正文补一句：tertiary 只用于关键操作，不做普通装饰。这样 AI 看到的就不是“做个好看的按钮”，而是“主按钮用指定 token，强调色只服务于交互焦点”。
03 一个最小实战样例
我做了一个最小样例，项目根目录里放一份 DESIGN.md，先把颜色、字体、圆角和按钮规则写清楚。
样例 1：DESIGN.md 关键片段
然后真实跑一次官方 CLI：
npx @google/design.md lint samples/DESIGN.md
输出会把结构检查结果转成 JSON。这个例子里没有 error，但提示 neutral 颜色还没有被组件引用，这类信息很适合放进 PR 检查。
样例 2：lint 输出
最后，把同一组 token 映射到页面，就能得到一个更稳定的 UI 起点。重点不是这张页面多惊艳，而是 AI 不再凭感觉猜颜色、圆角和按钮样式。
样例 3：根据 token 渲染出的 UI
04 我会把它用在哪些地方
实战里，我会把它用在三个地方。
第一，独立开发者做产品原型。
以前每次开新对话，都要重复“别用大圆角、别用紫色渐变、字体紧一点”。现在把这些偏好写进 DESIGN.md，AI 每次进项目先读它，输出会稳定很多。
第二，团队前端项目。
设计系统常常散落在 Figma、Tailwind config、组件库和口头约定里。DESIGN.md 不需要替代它们，它更像代码仓库里的“AI 可消费摘要”。新人、外包、AI agent 都能从同一份文件里拿到视觉边界。
第三，持续改版的运营页或品牌站。
局部改得好看不难，难的是整体不跑偏。design.md 提供了 lint、diff 这类工程化思路：检查 token 引用、结构、对比度，也能比较两个版本的设计变化。设计变更就不只是肉眼评审，而能进入 PR 流程。
05 怎么落地到你的项目
我的建议是：先写最小版本，只覆盖品牌气质、颜色、字体、间距、组件禁忌五件事。不要一开始追求完整设计系统。AI 最需要的是高频决策依据：按钮怎么做、卡片要不要阴影、列表密度多大、强调色能不能滥用。
然后把文件放到项目根目录，在任务里明确一句：“开始前先阅读 DESIGN.md，所有视觉实现必须遵守其中 token 和 Do's / Don'ts。”这句话会把文档变成约束，而不是摆设。
接着把 token 映射到真实代码。Tailwind 项目同步到 theme；组件库项目让 Button、Card、Input 引用这些 token。这样 AI 写新页面时，也会沿着已有轨道走。
06 最后说一句
我对 design.md 的判断是：它真正解决的不是“AI 会不会设计”，而是“AI 有没有稳定上下文”。设计偏好如果停留在聊天窗口里，就是一次性的；写成结构化文件，才会变成项目资产。
推荐标签：
#AI编程# #前端开发# #设计系统# #DesignTokens# #ClaudeCode# #Codex# #产品实战#