设计系统常被误解为「组件库的另一种叫法」。但真正让它发挥作用的,不是那一份组件清单,而是背后关于颜色、字号、间距、状态的决策逻辑。本文以 Aham 设计系统为例,说明长文排版规则如何在真实文档中落地。
为什么需要设计系统
设计系统不是一个组件库,也不是一份设计稿集合。它是团队对「界面应该长什么样、为什么这样」的共识,沉淀成可复用的 token、组件和规则。当团队规模扩大、产品线变多时,没有设计系统意味着每个新功能都要从零开始决策颜色、字号、间距,大量时间被消耗在重复的微观判断上。好的设计系统把决策前置:一次定义,处处复用,让设计师和工程师把精力留给真正重要的产品问题。它同时也降低出错概率——一致的 token 保证对比度达标,统一的组件状态让用户在不同模块获得相同的心智模型。最终,设计系统让产品在扩张中保持克制与统一。
克制不是匮乏,而是把每一次表达都用在刀刃上。好的系统不是让设计师无事可做,而是让他们不再为同样的小事反复争论。
— Aham 设计原则
设计系统的核心组成
Token:决策的最小单元
Token 是设计决策的最小单元。Aham 把颜色拆成三层表面、四级墨色与单一强调蓝,把字号收敛为 11 个语义样式,把间距统一到 4 基网格。组件只引用语义层 token,不直接消费原始值。例如正文阅读宽度用 --content-read(65ch),CJK 行高用 --leading-cjk(1.75),段间距用 1em。这样改一处全端更新,暗色模式也能零改动适配。
组件与规则
组件是 token 的组合,规则是组件之间的约束。Aham 的核心组成可以归纳为以下几层:
- Token:颜色、字号、间距、圆角的单一事实源
- 组件:按钮、输入、表格等可复用件,全状态覆盖
- 组合规则:同心圆角、对齐网格、动作主次
- 模式:表单、列表、详情等页型蓝图
- 介质落地:网页、桌面、Office、邮件分轨
落地的步骤
设计系统不是一次交付,而是一个持续演进的过程。建议按以下顺序推进:
- 先定义 token,建立 primitive → semantic → component 三层
- 沉淀核心组件,约定全状态与变体
- 写下组合规则与禁区,用预览页验证
- 接入暗色与无障碍校验,持续迭代
代码示例
长文排版的 CSS 落地并不复杂,关键是用对 token。下面是本页正文区使用的核心规则:
.prose:lang(zh) {
line-height: var(--leading-cjk);
max-width: var(--content-read);
}
.prose p {
margin-block-end: 1em;
}
.prose p:last-child {
margin-block-end: 0;
}
图文混排与基线对齐
图文同行时优先 baseline 对齐,而非垂直居中。居中在字号或字高变化时容易错位,baseline 对齐则让文字基线与图形底边成线,更稳。下图为 Aham 三层表面示意,与说明文字 baseline 对齐:
中西文混排的行高
在 Aham 设计系统中,正文行高遵循 CJK 1.75、西文 1.5 的双轨策略。这是因为在同样字号下,汉字字面占比约 95%,而拉丁字母(Latin)仅约 70%,套用西文行高会让中文段落显得局促。W3C clreq 规范明确建议 CJK 行高需 1.7–1.8,我们取 1.75 作为折中。你可以在这段文字里观察到中英文混排时的呼吸感——行高足够容纳汉字的完整字面,同时 Latin 字母与标点也不显得松散。更多细节可参考 clreq 中文排版需求。
文本样式对照
下表节选 Aham 11 个语义样式中与长文排版相关的几档,数字列右对齐并使用等宽字体:
| 样式 | 字号(px) | 行高 | 字重 | 用途 |
|---|---|---|---|---|
| Body | 14 | 1.55 | 400 | 默认正文 |
| Body-L | 17 | 1.50 | 400 | 长文正文 |
| Heading | 24 | 1.25 | 600 | 章节标题 |
| Mono | 14 | — | 400 | 代码 / 数字 |
这只是一个起点。真正的设计系统会在真实产品中反复打磨,把每一次微观决策都沉淀回 token 与规则,让下一个功能不必从零开始。