外观
规范文档与开发对接
把 Token、组件、状态写成可执行的规范文档，让开发照着做，并做版本管理——这是设计系统"落地"的最后一环，也是整门课通往工程化的收官。记住这句：规范是给开发施工的说明书，可执行才有效；写完不版本管理，等于没写完。
规范写完了，开发为什么"不照做"
效果图式规范 vs 可执行规范：
| 说法 | 问题 |
|---|---|
| "按钮圆角要好看一点" | "好看"没有数值，开发没法照着做 |
| "间距要合适" | 模糊词，十个人有十种理解 |
| "界面应该长这样" | 只讲外观，不讲代码里怎么实现 |
前面你造好了设计系统的"零件"——Token（23）、组件与状态（24）。照理给开发一个"使用手册"就行，但现实里规范写完开发照样不照做。为什么？因为大多数"规范"是只给设计师看的"效果图"：写得模糊（"按钮圆角要好看一点"——开发怎么执行？）；只讲"应该是什么样"，不讲"代码里怎么写"；散落在一堆 PPT、邮件、聊天记录里，开发根本找不到"唯一真相"。根子在于：规范只有"说明"，没有"执行"。 它说了界面该长这样，却没告诉代码里怎么实现、去哪找那个值，于是开发只能自己发挥，一发挥就跑偏。
规范文档里装什么：五件套
五件套分别装什么：
| 内容 | 装什么 | 用微信举例 |
|---|---|---|
| Token 表 | 所有设计值的命名清单 | color-brand-primary = #07C160、spacing-base = 8px |
| 组件规格 | 每个组件的尺寸、间距、圆角 | 消息行的头像、标题、时间怎么摆 |
| 状态说明 | 每个组件的各种状态 | 按钮的默认 / 按下 / 禁用 / 加载 |
| 使用规则 | 什么时候用哪个、别怎么用 | 危险操作用 color-danger，别用普通绿 |
| 示例代码 | 开发照着抄就能跑 | 一段映射到 CSS 的 Token 片段 |
一份能落到地的规范文档，至少装这五样：Token 表（所有设计值的命名清单）、组件规格（每个组件的尺寸、间距、圆角）、状态说明（每个组件的各种状态）、使用规则（什么时候用哪个、别怎么用）、示例代码（开发照着抄就能跑）。有了这五件套，规范才从"给设计师看"变成"设计和开发一起看"——尤其要让开发看得懂、用得上。规范没有示例、不映射代码，等于发给施工队一张效果图。
规范五件套 = Token 表 · 组件规格 · 状态说明 · 使用规则 · 示例代码。
开发"照着做"是什么意思
Token 怎么映射到代码（不需要记语法，看关系）：
css
--color-brand-primary: #07C160; /* 微信绿 Token */
--spacing-base: 8px; /* 间距 Token */
.btn-primary{background:var(--color-brand-primary);padding:var(--spacing-base);} /* 按钮引用 Token */一份可执行的规范要有三个特征：有示例——每个 Token、组件都配可运行的代码片段，开发复制即用；无歧义——尺寸、间距、颜色都是具体数值（或指向 Token），不是"好看一点"这种话；映射到代码——Token 能对上 CSS 变量 / 代码里的变量名，开发一找就中。开发"照做"需要的不是"描述的愿望"，而是"可直接引用的值 + 可复制的示例"。
规范里写 padding: 8px 不如写 padding: var(--spacing-base)——后者开发能直接对到 Token 表，改一处全动。
版本管理：规范不是写完就完事
版本怎么动：
| 变更类型 | 版本怎么动 | 微信例子 |
|---|---|---|
| 修 bug、补说明、小改 | 小版本 +0.1 | v1.0 → v1.1（补了加载状态说明） |
| 加新组件、改关键 Token | 小版本 +0.1 | v1.1 → v1.2（新增视频消息组件） |
| 推翻性改动（换品牌色、改间距体系） | 大版本 +1 | v1.x → v2.0（品牌重塑） |
设计系统是活的：今天加一个组件、明天改一个间距。如果规范"写完就扔那不管"，设计师照新规范做、开发照旧文档写，两边对不上，设计系统名存实亡；出了 bug 也说不清是哪一版规范导致的，没法回退、没法追责。所以规范要版本化。
铁律：大版本 = 不兼容的改动。凡是"旧页面会崩、旧的照做会错"的变更，都该升大版本，并写清"旧版怎么迁移"。
对接流程：把"设计"递到"开发"手里
把整本微信设计系统沉淀成一份规范文档：
| 规范章节 | 内容 | 微信落地 |
|---|---|---|
| Token 表 | 颜色、间距、字号、圆角、阴影 | color-brand-primary、spacing-base、font-size-body |
| 组件规格 | 消息行、按钮、角标、弹层 | 消息行：头像 40px + 标题 + 时间 + 摘要 |
| 状态说明 | 每个组件的状态 | 按钮：默认 / 按下 / 禁用 / 加载 |
| 使用规则 | 用哪个、别怎么用 | 危险操作用 color-danger，删除用确认弹层 |
| 示例代码 | Token 映射到 CSS | .btn-primary { background: var(--color-brand-primary) } |
| 版本记录 | 版本号 + 变更 | v1.0 首版；v1.1 新增"加载状态" |
规范不是躺在文档库里的摆设，它要贯穿"设计 → 开发"。典型流程：① 设计与开发对齐——当面过一遍 Token、组件，确认开发能对上；② Token 映射到代码——把 Token 表导出成代码变量；③ 组件库交付——把组件 + 规范打包交付，开发对号入座，不自己重新发明。落地后的体验：老板要换品牌绿，你改 color-brand-primary 这一个 Token，同时给规范升一版、记一句 changelog，开发照着新版改一处，全端联动。设计系统这才真正工程化——从"画得好看"走到"管得住、改得动、能交付"。
一条"消息行"从规范到代码：开发拿到规范不需要问设计师任何一个值，照着文档就能实现得像设计稿一样——这就是"设计系统落地"的终极形态。
深度
规范文档怎么组织：一份"可导航"的文档
规范文档不是把话堆在一起，而是分层、可导航——从"原理"到"零件"到"用法"逐渐下沉，让一个新人照着文档能自己搭出一页微信。
| 层级 | 装什么 | 给谁看 | 微信例子 |
|---|---|---|---|
| 总览 / 设计原则 | 这套系统的主张 | 所有新人 | "微信：克制、清晰、高效" |
| 基础（Token） | 颜色、间距、字号、圆角 | 设计与开发 | Token 表 |
| 组件 | 每个零件的规格 + 状态 | 设计与开发 | 消息行、按钮、角标 |
| 模式 / 使用规则 | 什么时候用哪套 | 设计与开发 | 危险操作规范 |
| 版本记录 | 变更历史 | 所有人 | changelog |
边界：规范文档不是万能的
- 规范管"照着做"，不管"怎么想"：它告诉开发"用哪个 Token、怎么对代码"，但"为什么这么设计"靠总览和培训，不是每条都写进规格。
- 规范要"维护"，不是"存档"：没人维护的规范 = 博物馆展品，开发看一眼就走。要有人负责、定期更新、和代码同步。
- 规范是流程⑦的终点，也是循环的起点：文档落定后，设计系统进入"持续治理"——新组件加进来、旧组件退役，规范跟着版本走，永不"写完就完"。
反模式：规范文档的四种坑
- 写给设计师看的"效果图"：只讲"要好看"，不讲"怎么写"。开发拿到没法执行，自己发挥，跑偏。
- 没有示例代码：讲了一堆 Token，不给能跑的片段。开发还得自己猜映射。
- 写完不更新、不版本化：设计改了，文档还是旧的。设计与开发各拿一份"真相"，越走越偏。
- 有歧义、用模糊词："间距要合适""颜色再深一点"。十个人有十种理解，规范等于没写。
反模式共同点：规范失去了"可执行性"。规范的价值不在"写得全"，而在"开发照着就能做"。
误区
| # | 误解 | 正解 |
|---|---|---|
| 1 | "规范是给设计师看的" | 规范给设计师和开发一起看，尤其要让开发看得懂、用得上 |
| 2 | "规范写完就完事" | 设计系统持续演进，规范要版本化、有变更记录、持续维护 |
| 3 | "规范写得全就行" | 规范的价值在可执行——有示例、无歧义、映射到代码 |
| 4 | "开发看了规范自然会做" | 规范要主动与开发对齐、做 Token 映射、交付组件库，否则开发还是自己发挥 |
| 5 | "版本号无所谓" | 版本让设计与开发永远对得上"现在该照哪版"，大版本用于不兼容改动 |
练习
即时题 Q1：一份能落地的规范文档，至少装哪五样？
答案
Token 表、组件规格、状态说明、使用规则、示例代码。五件套。即时题 Q2：规范里写 padding: 8px 和 padding: var(--spacing-base) 有什么区别？
答案
`8px` 是死值，开发复制后改 Token 不跟着变；`var(--spacing-base)` 直接对到 Token 表，改一处全产品联动。后者才是"可执行、与开发对齐"的写法。即时题 Q3：什么样的改动该升大版本？
答案
推翻性改动（换品牌色、改间距体系）会破坏旧页面，属于不兼容改动，该升大版本并写清"旧版怎么迁移"。模块题 微信要换品牌绿，从 #07C160 换成 #07D160。用"一份规范文档 + 版本管理"的做法，说出从改 Token 到交付开发的完整流程，并说明规范版本为什么必须跟着升。
参考思路
- 改 Token：更新 `color-brand-primary` 这一个 Token。 - 更新规范：把 Token 表里的新值同步进规范文档。 - 升版本 + 记变更：这是改品牌色的关键值，属不兼容改动，升 v2.0，changelog 记一句"品牌绿调整"。 - 交付开发：开发拿到 v2.0，知道旧版别用了，改 `--color-brand-primary` 一处，所有引用它的组件、页面、端一起变。 - 关键点：规范版本和 Token 是挂钩的。版本是为了让设计永远对得上"开发现在该照哪版"，否则两端各改各的，设计系统落地即腐化。迷你案例（微信实战） 把前面几节攒的微信设计资产，沉淀成一份"规范文档"：
- 打开你整理的 Token 表、组件库、状态清单。
- 按"五件套"搭一个文档骨架：Token 表 / 组件规格 / 状态说明 / 使用规则 / 示例代码。
- Token 表：把前面整理的 Token 抄进去，每行标好"值 + 用在微信哪"。
- 组件规格：挑一个组件（如消息行），写尺寸、间距、圆角（用 Token 名，不写死数值）。
- 状态说明：给"消息行"列状态：未读 / 已读 / 新消息，各用什么样式。
- 示例代码：写 2-3 行，把消息行的背景或间距对到 Token（仿上文 CSS 那两行）。
- 使用规则：写两句"别有"——如"危险操作别用普通绿，用
color-danger"。 - 版本记录：标上 v1.0，写一句"首版微信设计系统规范"。
做完你就懂了：设计系统不是一堆散件，而是一份"开发和设计都对得上号"的说明书——从 Token、组件到规范文档、版本管理，设计系统完成从"画得好看"到"能交付、能治理"的工程化收官。
素材
- Style Dictionary：把 Token 一键导出成 iOS/安卓/Web 代码，是"规范映射到代码"的经典工具。
- Design Tokens W3C 规范：Token 的通用格式标准，看它如何跨工具、跨端共享。
- Changelog 规范（Keep a Changelog）：规范地写版本变更记录，是"版本管理"的落地模板。
- 前序衔接：23 Design Tokens（决策源头）→ 24 组件与状态（零件）→ 25 规范文档（把零件写成可执行的说明书，流程⑦终点）。
- 后续衔接：规范落定后，设计系统进入持续治理——新组件、新模式的版本演进，是新的循环起点。