上周在重构我们内部运营后台的时候，我盯着屏幕愣了一分钟。
同一个页面里，两个按钮的圆角不一样，一个是 6px，一个是 8px；表格的标题字号一会儿是 16px 一会儿是 18px；甚至连主色调，AI 在生成“数据导出”弹窗时，鬼使神差地给我调深了两个色号。
这不是 AI 的能力问题，它写得很快，CSS 也没报错。这是上下文缺失的问题。
我们团队最近在用 Claude Code 和各类 AI Agent 批量生成前端页面。效率确实上去了，但随之而来的副作用是：UI 一致性在崩塌。
以前我们有设计师、有 Figma、有严格的 Code Review，这种事很少发生。但现在，AI 是一个“没有长期记忆的临时工”，你让它加个弹窗，它觉得“这样好看”就给你写死了样式。下次换个人或者换个 Session 让它改个列表，风格又变了。
就在我为这事头疼的时候，看到了 Google 最近开源的 DESIGN.md。说实话，看完之后我有种“这就对了”的感觉。
一、 它不是 UI 库，它是给 AI 看的“宪法”
DESIGN.md 本质上解决了一个工程问题：如何在 AI 主导的开发模式下，维护设计的单一事实来源（Single Source of Truth）。
传统的设计系统是给人看的，或者是给组件库用的。但 AI 不吃这一套，它看不懂你 Figma 里的 Auto Layout，也不一定能精准映射到你们复杂的 Tailwind Config。
Google 这个方案很取巧，它就是一个 Markdown 文件。但里面包含了两层信息：
机器可读的 Token（YAML Front Matter）： 定义了颜色、字体、间距、圆角的具体数值。这是给 AI 写代码时直接引用的。
人类可读的设计意图（Markdown Body）： 解释了“为什么”。比如，“Tertiary 色只用于关键行动点（CTA），不要用于普通标签”。
举个我们在项目里用的例子（脱敏简化版）
—
version: 1.0
name: Internal-Ops-Theme
colors:
brand: "#1A73E8"
danger: "#D93026"
background: "#F8F9FA"
surface: "#FFFFFF"
typography:
h1:
fontFamily: "Roboto"
fontSize: 1.75rem
fontWeight: 500
body:
fontFamily: "Roboto"
fontSize: 0.875rem
components:
button-primary:
backgroundColor: "{colors.brand}"
rounded: "6px"
—
## 设计意图
这是一个面向内部运营的后台系统，强调效率和清晰度，而非视觉冲击。
– **色彩**：严禁使用高饱和度的渐变色。Brand 色仅用于导航和主按钮。
– **排版**：所有表单标题必须使用 h1 规范，不得使用加粗的 body 文本冒充标题。
– **交互**：所有列表页面的操作按钮，必须固定在底部，不得随内容滚动。
有了这个文件，我再让 AI 去生成页面时，就不是靠它的“审美直觉”去猜，而是强制它去读这个文件。
二、 解决了 AI 协作的三个痛点
在真实的研发流程里，DESIGN.md 解决了我三个具体的焦虑：
1. 对抗“风格漂移”
以前我得在 Prompt 里反复唠叨：“用我们的品牌色，圆角 6px”。现在不用了，直接在上下文里挂载 DESIGN.md。AI 生成的代码，哪怕是不同的 Agent（比如今天用 Claude，明天用 Gemini），风格也能对齐。这比在 .cursorrules里堆砌零散的 CSS 规则要优雅得多。
2. 多 Agent 并行时的混乱
我们现在有时候会让一个 Agent 写列表页，另一个写详情页。如果没有约束，合出来的代码简直是灾难。现在大家都读同一份 DESIGN.md，相当于签了同一个条约。
3. 从“看图说话”到“理解气质”
以前我们给 AI 一张截图，让它“照着写”。但截图是静态的，规则是动态的。DESIGN.md里的那段“设计意图”，能让 AI 明白什么是能做的，什么是禁忌。比如我们明确规定“不要为了美观而增加额外的阴影”，AI 就不会自作主张地加那些花哨的 box-shadow。
三、 工程化落地：它不只是个文档
让我觉得这个东西能成事的，是它配套的 CLI 工具 @google/design.md。
光有文档，没有检查，等于废纸。我们把它接入了 CI 流程：
# 在 Merge Request 前跑一下
npx @google/design.md lint DESIGN.md
这个 lint命令很实用，它能检查 Token 引用是否正确，甚至能校验 WCAG 对比度。这意味着，AI 如果偷偷把文字颜色改成了浅灰导致看不清，CI 会直接挂掉。
我们还用到了 diff功能。当设计师调整了规范（比如想把圆角从 6px 改成 4px），我们用 diff 对比新旧两个版本的 DESIGN.md，一眼就能看出哪些设计 Token 变了，从而评估这次改动对代码的影响面。
四、 作为架构师的一点反思
坦白说，DESIGN.md 目前还是 Alpha 版本，直接把它当成企业级设计系统的核心底座还为时过早。它的生态还不够完善，和现有 Figma Variables 的同步还需要手动维护。
但我非常看好这个方向。
AI Coding 的瓶颈，从来不是“怎么写代码”，而是“怎么写好符合工程约束的代码”。
以前我们靠人的经验和 Code Review 来守门。现在，我们必须把这些隐形的规则显性化、文件化。无论是之前的 AGENTS.md规范行为，还是现在的 DESIGN.md规范界面，都是在为 AI 建立一套可执行的“社会契约”。
如果你也在重度使用 AI 写前端，特别是做内部工具、SaaS 后台或者快速原型，我建议你真的去试试这个东西。别让你的产品看起来像是东拼西凑的 Demo，给它一份看得见的“设计说明书”。
毕竟，我们不想成为那个对着屏幕发呆，纳闷为什么按钮圆角对不上的架构师。
