AI Productivity
Google 开源 design.md：AI 前端真正缺的不是审美，而是可校验的设计上下文
AI 写前端最常见的问题，不是完全不会写，而是太容易写成平均值：Inter 字体、蓝紫渐变、巨大圆角卡片、三段式 SaaS 首屏。问题不在某个模型“审美差”，而在于我们给它的设计上下文太弱。
“高级一点”“更有品牌感”“像 Apple 一点”这些话对人类设计师有用，是因为人类有长期视觉经验和追问能力；对 coding agent 来说，它们只是模糊偏好。Google Labs 开源的 design.md 想补的就是这层缺口：把设计语言写成一份 agent 能读取、能执行、能校验的文件。
它不是又一个设计灵感库
站内之前写过 awesome-design-md，那类项目的价值是把真实品牌风格整理成可复用样本。Google 官方 design.md 的位置不同：它更像文件格式和执行规范，告诉大家一份 DESIGN.md 应该怎么写、怎么校验、怎么被工具消费。
这一区别很关键。样本库解决“我想参考哪种风格”，规范解决“Agent 怎么稳定理解并复用这种风格”。前者像素材市场，后者像协议。
DESIGN.md 的两层结构
官方 README 给出的核心结构很清楚：文件顶部是 YAML front matter，放颜色、字号、圆角、间距、组件 token；正文是 Markdown，解释品牌气质、配色理由、字体选择、布局原则、组件使用边界。
机器可读的 token 让 Agent 有精确值可用，人类可读的设计理由让 Agent 在遇到新组件、新页面和边界情况时不只是机械套色。这比单独塞一份 Tailwind config 更有用，也比只写“简洁现代”可靠。
真正有用的是 CLI 校验
官方包 @google/design.md 提供了几类命令：lint 检查文件结构、断裂引用、缺失主色、WCAG 对比度和孤立 token；diff 对比两个版本，发现 token 级别回归；export 导出 Tailwind theme 或 W3C DTCG token；spec 输出规范文档，方便塞进 agent 上下文。
这一步让 DESIGN.md 从“写给模型看的提示词”变成“能进工程流程的资产”。如果一次改版导致主色、按钮对比度、组件 token 被悄悄改坏，团队至少可以在 lint/diff 里看到信号，而不是等到页面生成出来才肉眼发现。
怎么落地更稳
- 先为产品写一份最小 DESIGN.md，只覆盖颜色、字体、间距、圆角和核心组件。
- 把它放在项目根目录，并在 AGENTS.md 或 CLAUDE.md 中明确要求读取。
- 每次 UI 大改后跑
npx @google/design.md lint DESIGN.md。 - 如果使用 Tailwind，把 DESIGN.md 导出成主题配置，避免 token 和代码分叉。
- 把“不要做什么”写进正文，例如不要大渐变、不要低信息密度 hero、不要过度阴影。
边界也要说清楚
DESIGN.md 不能替代设计判断。它能减少 AI 模板味，不能保证产品信息架构正确，也不能替你决定品牌定位。它更适合被当成“设计上下文的版本化载体”：让团队把已经认可的视觉规则沉淀下来，让 Agent 在这个边界里工作。
AI 前端下一步拼的不是谁会生成更多组件，而是谁能把设计标准、工程规范和验收动作放进同一条链路。Google design.md 的价值就在这里：它把审美从口头偏好，往可复用、可校验、可交接的工程资产推了一步。