设计系统常被误解为「组件库的另一种叫法」。但真正让它发挥作用的,不是那一份组件清单,而是背后关于颜色、字号、间距、状态的决策逻辑。本文以 Aham 设计系统为例,说明长文排版规则如何在真实文档中落地。

为什么需要设计系统

设计系统不是一个组件库,也不是一份设计稿集合。它是团队对「界面应该长什么样、为什么这样」的共识,沉淀成可复用的 token、组件和规则。当团队规模扩大、产品线变多时,没有设计系统意味着每个新功能都要从零开始决策颜色、字号、间距,大量时间被消耗在重复的微观判断上。好的设计系统把决策前置:一次定义,处处复用,让设计师和工程师把精力留给真正重要的产品问题。它同时也降低出错概率——一致的 token 保证对比度达标,统一的组件状态让用户在不同模块获得相同的心智模型。最终,设计系统让产品在扩张中保持克制与统一。

克制不是匮乏,而是把每一次表达都用在刀刃上。好的系统不是让设计师无事可做,而是让他们不再为同样的小事反复争论。

— Aham 设计原则

设计系统的核心组成

Token:决策的最小单元

Token 是设计决策的最小单元。Aham 把颜色拆成三层表面、四级墨色与单一强调蓝,把字号收敛为 11 个语义样式,把间距统一到 4 基网格。组件只引用语义层 token,不直接消费原始值。例如正文阅读宽度用 --content-read(65ch),CJK 行高用 --leading-cjk(1.75),段间距用 1em。这样改一处全端更新,暗色模式也能零改动适配。

组件与规则

组件是 token 的组合,规则是组件之间的约束。Aham 的核心组成可以归纳为以下几层:

落地的步骤

设计系统不是一次交付,而是一个持续演进的过程。建议按以下顺序推进:

  1. 先定义 token,建立 primitive → semantic → component 三层
  2. 沉淀核心组件,约定全状态与变体
  3. 写下组合规则与禁区,用预览页验证
  4. 接入暗色与无障碍校验,持续迭代

代码示例

长文排版的 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 对齐:

tier1 · tier2 · tier3 三层靠纯色层差区分深度:内容层(白)、面板层(浅灰)、线/选中层(灰),不依赖阴影或材质。

中西文混排的行高

在 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 与规则,让下一个功能不必从零开始。