高效样式管理：基于CTI方法论的设计令牌架构与命名
设计令牌是现代设计系统的基础元素，确保设计师与开发者之间的无缝协作。它们能够标准化产品的视觉属性，如颜色、字体和间距，将原始值转化为命名的变量。一个精心设计的令牌系统能显著加速新界面的开发，简化扩展和定制，并通过消除在不同组件中手动更改硬编码样式值的需要，最大限度地减少技术债。在本文中，我们将深入探讨设计令牌的架构，并详细介绍使用流行的CTI方法论进行命名约定，该方法论是许多高级设计系统的基石。
设计令牌的多层抽象
为了构建一个灵活且可扩展的设计系统，值抽象的方法至关重要。现代系统采用三层模型（原始令牌 → 语义令牌 → 组件令牌），通常还会为了完整性增加一个零层——原始数据。这种模型确保了结构化的数据流，其中较低层的更改会自动传播到较高层，从而保证一致性并简化全局样式更新。
0. 原始值： 这些是基本的、未抽象的数据，例如十六进制颜色代码（#0055FF）、像素大小值（16px）或特定字体名称（'Inter', sans-serif）。它们作为起点，但不应直接在代码或设计中使用，以避免产生技术债。
1. 原始令牌： 这是第一层抽象。原始令牌将原始数据数字化，赋予它们有意义但仍抽象的名称。例如，#0055FF 可能变为 blue-500。如果品牌决定更改其企业蓝色的色调，只需在一个地方更新 blue-500 的值即可，此更改将自动应用于所有依赖的令牌。原始令牌通常描述调色板、间距刻度或字体大小。
2. 语义令牌： 这些令牌描述了资源在界面中的角色或目的，回答了“为什么？”这个问题。它们将原始令牌链接到特定的使用上下文。例如，blue-500 可以用于创建 color-bg-primary（主背景色）。语义令牌在实现主题（亮/暗）和适应不同模式方面发挥着关键作用，因为同一个语义令牌可以根据活动主题引用不同的原始令牌。
3. 组件令牌： 这一层描述了样式在单个元素或组件中的具体应用，回答了“在哪里？”这个问题。组件令牌允许对特定组件进行精细的样式调整，而不会影响可能使用相同语义令牌的其他元素。它们用于管理例外情况和特定的组件要求，同时确保继承通用语义。例如，color-button-bg-primary-hover 可能仅限于按钮使用，即使其基础语义令牌在其他地方也被使用。
CTI 方法论：命名架构
CTI（类别 → 类型 → 项目）是设计令牌最流行的命名模型之一，尤其与Style Dictionary工具结合使用时更为普遍，该工具推广了这种方法。CTI的核心思想是，令牌的名称优先考虑其物理属性或类别，而不是它所属的组件。这使得系统易于编译器和脚本解释。
CTI中的命名公式通常如下所示：Category-Type-Item-Subitem-State。
让我们分解每个元素：
- 类别（Category）： 定义令牌的基本物理性质。这始终是令牌名称中的第一个词，并指示数据类型。示例：
color（颜色）、size（大小）、font（字体）、spacing（间距）、radius（圆角）。 - 类型（Type）： 描述此类别适用于哪个UI属性。示例：
background（背景）、text（文本）、border（边框）、icon（图标）。 - 项目（Item）： 指定令牌所关联的特定界面元素或组件。示例：
button（按钮）、dropdown（下拉菜单）、container（容器）。 - 子项目（Sub-item / 修饰符）： 对项目进行澄清，指示其变体或角色。示例：
primary（主要）、secondary（次要）、success（成功）、warning（警告）、danger（危险）。 - 状态（State）： 描述元素的交互状态。示例：
hover（悬停）、active（激活）、disabled（禁用）、focus（聚焦）。
例如，处于激活状态的主按钮的背景颜色令牌将是 color-background-button-primary-active。
CTI 方法的优缺点
与任何方法论一样，CTI也有其优缺点，在设计设计系统时考虑这些因素非常重要。
CTI的优点：
- 编译器优化： 由于令牌的第一个词总是指示其类别（
color、size、font），编译器脚本（例如Style Dictionary）可以非常容易地理解它们正在处理什么数据。这简化了从JSON令牌定义自动生成CSS变量、SCSS mixins、Swift文件和其他格式的过程，最大限度地减少了自定义配置的需求。 - 高效审计和全局更改： 对于想要检查或修改应用程序中所有间距的前端开发者来说，只需搜索前缀
$spacing-或--spacing-就足够了。这能快速提供所有间距变量的完整列表，方便进行全局审计或批量更改。 - 标准化： CTI是Style Dictionary等工具的默认架构，这使得它有良好的文档支持，并且对于许多使用过设计系统的开发者来说易于理解。
CTI的缺点：
- 组件样式分散： 在现代面向组件的框架（React、Vue）中，像按钮这样的组件是一个独立的实体。使用CTI方法时，此按钮的样式会分散在整个设计系统中：颜色可能位于
colors.json中，间距位于spacings.json中，圆角位于radii.json中。要组装或移除一个组件，开发者必须在不同文件之间“跳转”，这会打破上下文并使工作流程复杂化。 - 搜索和自动补全困难： 对于为按钮设置样式的开发者来说，快速找到与
button和primary相关的所有内容通常比找到color或background前缀更重要。在长的CTI令牌中，这些关键字出现在中间。IDE中的自动补全最初会建议许多颜色，要求开发者输入令牌的很大一部分才能找到所需的组件。 - 组件重构工作量大： 如果业务决定重命名一个组件（例如，将
modal重命名为dialog），使用CTI方法，前端开发者将不得不在众多类别（颜色、阴影、z-index、间距）中搜索并重命名令牌。如果组件被优先考虑（例如dialog-bg-color），那么重命名单个文件夹或一组令牌就足够了。
语义令牌与组件令牌：划分角色
理解语义令牌和组件令牌之间的区别是构建灵活设计系统的关键。尽管它们的命名公式相似，但其目的却根本不同。
语义令牌 回答了“为什么？”这个问题。它们定义了样式的角色或意图。例如，color-bg-primary 意味着“主背景色”，无论它在哪里使用。这些令牌具有高度可重用性，用于确保整体一致性和主题支持。它们的命名公式是：[类别]-[属性]-[角色]-[重要性]-[状态]。
组件令牌 回答了“在哪里？”这个问题。它们描述了特定组件的样式。当需要偏离通用语义或将独特样式应用于特定元素而不影响系统其他部分时，就会使用它们。本质上，它们是受管理的例外。它们的命名公式是：[类别]-[组件]-[属性]-[角色]-[重要性]-[状态]。如您所见，[组件]只是简单地添加到了链中。
黄金法则： 如果一个令牌在不同地方被重用并定义了一个通用目的，那么它是一个语义令牌。如果一个样式只需要为某个特定元素或组件更改，那么它是一个组件令牌。
CTI 命名元素的详细说明
为了更深入地理解CTI命名，让我们通过示例更详细地检查其每个元素：
- 类别（Category）： 主文件夹或数据类型。这是组织令牌的基础。
* color – 用于所有颜色值。
* spacing – 用于内部和外部间距。
* radius – 用于圆角半径。
* shadow – 用于阴影参数。
* typography – 用于文本样式（大小、字重、行高）。
* size – 用于元素宽度/高度。
* z-index – 用于管理元素层叠顺序。
* opacity – 用于不透明度值。
* duration – 用于动画持续时间。
- 属性（Property）： 澄清令牌在其类别中与UI的哪个部分相关。
* bg / surface – 用于背景颜色。
* text – 用于文本颜色。
* border – 用于边框颜色。
* icon – 用于图标颜色。
* outline / ring – 用于焦点轮廓。
* overlay – 用于模态背景颜色。
- 角色（Role / 含义 / 目的）： 定义令牌的功能或情感意义。
* primary / secondary / tertiary – 用于层级指示。
* brand / accent – 用于品牌颜色。
* success – 用于成功消息（绿色）。
* warning – 用于警告（黄色）。
* danger / error – 用于错误（红色）。
* neutral – 用于中性元素（灰色）。
* inverse – 用于在深色背景下反转颜色的元素。
* static – 用于不随主题变化的颜色（白色/黑色）。
- 重要性（Prominence / 层级 / 强度）： 描述元素的强度或可见性。
* default / main / base – 参考点，基础状态（通常在名称中省略）。
* muted – 不太突出。
* subtle – 非常微妙。
* intense – 更显著。
* on-brand – 用于品牌背景上的对比内容。
- 状态 / 修饰符 / 大小（State / Modifier / Size）： 额外的细化。
* 状态： hover（悬停）、active（激活）、focus（聚焦）、disabled（禁用）– 用于交互状态。
* 大小： sm（小）、md（中）、lg（大）、xl（特大）– 用于各种组件或元素大小。
default 状态的重要规则： 如果令牌处于其基础、静止状态，通常会省略 -default 后缀。例如，color-text-primary 隐式指代默认状态。其他状态在角色之后添加，例如 color-text-primary-hover。
CTI 令牌结构的实际示例
为了巩固理解，让我们看几个构建按钮令牌的实际示例，演示从原始值到特定组件令牌的转换。
示例 1：accent 按钮的 default 状态
假设我们有一个带有强调色的主按钮。
- 0. 原始值：
#0055FF（原始蓝色） - 1. 原始令牌：
blue-500（原始值的抽象） - 2. 语义令牌：
color-bg-accent（主强调背景色，引用blue-500） - 3. 组件令牌：
color-button-accent-bg（强调按钮背景色，引用color-bg-accent）
在这里，我们看到了如何从一个通用值（blue-500）过渡到一个更具体的值（color-button-accent-bg）。重要的是，在组件令牌中，我们不写 -default，因为它是隐式存在的。
示例 2：accent 按钮的 hover 状态
现在，让我们考虑同一按钮在悬停状态下命名如何变化。
- 0. 原始值：
#0044DD（更深的蓝色） - 1. 原始令牌：
blue-600（更深蓝色的抽象） - 2. 语义令牌：
color-bg-accent-hover（悬停时的强调背景色，引用blue-600） - 3. 组件令牌：
color-button-accent-bg-hover（悬停时的强调按钮背景色，引用color-bg-accent-hover）
在这里，明确添加了 -hover 后缀，表示交互状态。每一层抽象都使设计系统更加灵活，允许在原始级别更改色调，而无需重命名数千个令牌。
示例 3：secondary 按钮的 default 状态
对于次要按钮，可能会使用不同的调色板，例如带有透明度。
- 0. 原始值：
#0055FF带有 10% 透明度 或rgba(0, 85, 255, 0.1) - 1. 原始令牌：
blue-transparent-100 - 2. 语义令牌：
color-bg-secondary（引用blue-transparent-100） - 3. 组件令牌：
color-button-secondary-bg（引用color-bg-secondary）
这种方法允许为不同类型的按钮轻松切换调色板，同时利用通用的令牌结构。
示例 4：secondary 按钮文本的 default 状态
让我们考虑次要按钮内文本的令牌。
- 0. 原始值：
#0055FF - 1. 原始令牌：
blue-500 - 2. 语义令牌：
color-text-on-brand（品牌背景上的文本颜色，引用blue-500）。这里出现了on-brand修饰符，表示使用上下文。 - 3. 组件令牌：
color-button-secondary-text-on-brand（次要按钮文本颜色，引用color-text-on-brand）
如您所见，类别（color、spacing、typography）始终排在首位，其次是属性或组件，然后是修饰符和状态。这种“从一般到具体”的原则确保了设计系统内的可预测性和易于导航。
关键要点
- 设计令牌 是创建可扩展、一致且易于维护的设计系统的关键元素，可避免与硬编码样式相关的技术债。
- 多层抽象模型（原始值 → 原始令牌 → 语义令牌 → 组件令牌）提供了灵活性和可管理性，允许从单一入口进行全局更改。
- CTI 方法论（类别 → 类型 → 项目） 是一种流行的命名方法，便于编译器自动化处理，但可能会使上下文搜索和组件样式重构复杂化。
- 语义令牌 定义了样式的角色和目的，确保可重用性和主题支持，而组件令牌 用于特定组件内的精细调整和管理例外情况。
- 使用类别、属性、角色、层级和状态的清晰命名规则 对于维护设计系统内的秩序和可预测性至关重要。
— Editorial Team
暂无评论。