Appearance
DESIGN.md：写给 AI 的设计规范
元信息
- 目标：能说出 DESIGN.md 治的病（AI 生成界面的风格漂移）与文件的两层结构（令牌层给值、散文层给规则）；能对照八个标准节说出各自管什么；能讲清它与 AGENTS.md、与前端UI术语手册的分工；知道去哪里拿现成的规范文件
- 关键概念：DESIGN.md、设计令牌 design token、风格漂移 drift、语义角色、AGENTS.md
- 关联阶段：cp1
- 常见误区：把设计要求写进提示词就完事（提示词只活一次，DESIGN.md 每次生成前都被读）；只给值不给规则（光写
#B8422E不够，还要写「这个颜色只用于主操作按钮」）；以为它要替代 Figma 或组件库（它是设计决策与 AI 之间的沟通层，不是设计工具）
AI 画不准风格的病根
让 AI 生成过界面的人都见过这组症状：周一按钮是一种蓝，周五换了一种蓝；字体这次 Inter、下次 Poppins；间距 16px、20px、12px 随缘；圆角今天圆明天方。你在提示词里写「现代、简洁、大气」，它每次都礼貌地重新猜一遍。
病根不在 AI 笨，在它对你的项目没有记忆——每次生成都是一次从零开始。这个现象叫风格漂移（drift，没有统一约束时输出逐渐偏离原样）。
药方思路你其实已经见过：本周作业把主题色、间距收进 :root 变量，就是让样式决策只定一次、处处引用。DESIGN.md 做的是同一件事，只是服务对象从 CSS 换成了 AI：把设计决策写成文件放在项目根，AI 每次动手之前先读它。
DESIGN.md 是什么
DESIGN.md 由 Google Stitch（谷歌实验室的 AI 界面设计工具）团队提出，后由 Google Labs 发布为开放规范（Apache 2.0 授权，仓库在此）。一句话定义：
一份纯文本的设计系统文档：AI 代理读了它，生成的界面风格前后一致。
它就是一个 markdown 文件。没有 Figma 导出、没有 JSON 模式、没有专门工具——因为 markdown 是大语言模型读得最好的格式，训练语料里到处都是，AI 不需要任何解析配置就能直接吃。
与我们已经很熟的 AGENTS.md 正好凑成一对：
| 文件 | 谁读 | 管什么 |
|---|---|---|
AGENTS.md | 编码代理 | 项目怎么建（命令、约定、结构） |
DESIGN.md | 任何生成界面的代理 | 项目长什么样（颜色、字、间距、组件样式） |
你正在读的教程仓库就维护着 AGENTS.md——同一种思路在设计一侧的镜像，就是本篇的主角。
两层结构：令牌与规则
一个 DESIGN.md 文件分两层，缺一不可：
- 令牌层：文件开头的 YAML 前言（front matter，markdown 顶部一段
---包裹的键值数据），放设计令牌（design token，给设计决策起的最小命名值：主色、基础字号、间距刻度）。机器可读，是值的事实源 - 规则层：markdown 正文，写值背后的用法与理由——「primary 只用于主操作按钮」「阴影只用在卡片，不用在按钮」
为什么值和规则要在同一个文件里？JSON 令牌给得了值，给不了「这个值什么时候不许用」；提示词给得了规则，活不过当次对话。DESIGN.md 两层合体，外加三个工程优点：上下文轻（约两三千 token）、无需构建管线、随 git 版本化。
令牌之间还能互相引用：{colors.primary} 写一处、改一处、处处生效——和本周 :root 变量是同一个思想，令牌就是它的上游（第 14 周的 design token 专题会接这条线）。
八个标准节
规范的正文分八节，节序固定——语言模型从头读到尾，顺序就是语境的累积，可省略某节但不能乱序：
| 节 | 管什么 | 一句话 |
|---|---|---|
| Overview | 品牌与气质 | 产品什么感觉：严肃还是活泼、紧凑还是留白——没写到的决策都回落到这里 |
| Colors | 色板与角色 | 每个颜色配语义名（primary、neutral、error）加用法规则，防止错误红被当强调色用 |
| Typography | 排印层级 | 9 到 15 级字号字重行高——机器要数字，「大字体」对它没有意义 |
| Layout | 布局与间距 | 间距刻度（xs 到 xl），网格与边距 |
| Elevation & Depth | 层级与深度 | 阴影体系；若是扁平风，写清楚用什么替代（描边、色块） |
| Shapes | 形状语言 | 圆角档位（sm/md/lg/full），小小圆角大大性格 |
| Components | 组件样式 | 按名字登记组件：背景、文字色、圆角、内边距，hover/active 各状态单列 |
| Do's and Don'ts | 禁止事项 | 负面指令对语言模型格外有效，专防「AI 味通用设计」 |
注意 Components 节：它登记的正是 前端UI术语手册 里那些组件词条——术语在这里落成带取值的条目。
与前端UI术语手册的关系
第 4 周的术语手册给了四层架构（控件、组件、模式、风格），DESIGN.md 与它的关系一句话：术语手册是词汇表，DESIGN.md 是词典——词汇表给你名词，词典把每个名词钉上取值和用法：
- 风格层的名词（主色、圆角、阴影）变成 Colors、Shapes、Elevation 节里的令牌
- 组件层的名词（button、modal、badge）变成 Components 节里的词条与状态
- 「玻璃态」「扁平化」这类风格名，变成 Overview 节里的人话描述
两个方向都成立：叫不出名字，就写不进规范——Components 节空着，AI 只好每次现编；反过来，规范一旦立好，AI 生成的一切组件都被摁在同一套取值上，术语从「能沟通」升级成「可执行」。上篇「用术语指挥 AI」是一单一点外卖，DESIGN.md 是常驻的协议。
用法与工具
拿到一份 DESIGN.md 有四条路，从快到慢：
- 抄现成的：从下面资源库挑一份放项目根，改值
- 让 AI 从代码里提炼：把技能或代理指向你的仓库，它扫 CSS 变量与组件，反向生成规范
- 从 Stitch 导出：在 Stitch 里做完设计，原生导出同款结构
- 手写：照八节结构写，再跑
npx @google/design.md lint校验——查令牌引用断裂、WCAG AA 对比度（无障碍的色彩对比底线，见可访问性）、孤儿令牌、节序错乱
落地那一步也与本周接上：export 命令能把令牌导出成 CSS 变量或 Tailwind 主题——写作业时那份 :root 变量表，上游正该是一份 DESIGN.md。
资源
以下偏教学与可视化，全部免费或开源：
- 官方规范（google-labs-code/design）——规范原文与
@google/design.md命令行工具（lint 校验、diff 对比、export 导出），Apache 2.0 开源 - Google Stitch——概念的提出方，谷歌实验室的 AI 界面设计工具，输入提示词生成界面，Google 账号即可使用，可原生导出 DESIGN.md
- Awesome Design MD——70 余份主流网站（Stripe、Linear、Apple、Notion 等）的 DESIGN.md，每份配 preview.html 可视化目录：色板、字阶、按钮、卡片一屏看全，适合当「活的设计系统标本」对照阅读
- designmd.app 入门讲解——第三方教学站，八节结构逐节展开，附数百份按行业与风格整理的现成文件库
- 回看前端UI术语手册的资源——Learn UI Name 的风格图鉴管「看得出」，本篇的规范库管「写得出」，两侧合起来才是完整的风格表达
小结
- AI 生成界面风格漂移的病根是无记忆；DESIGN.md 把设计决策落成常驻文件，每次生成前先读
- 两层结构：YAML 令牌给值，散文规则给用法；与
:root变量同源，令牌是变量的上游 - 八个标准节，节序即语境；Components 节就是组件术语的登记处
- 术语手册是词汇表，DESIGN.md 是词典；与 AGENTS.md 一对：一个管怎么建，一个管长什么样