在当今企业级软件产品与出海 SaaS 平台中，“多品牌（Multi-brand）”与“白标定制（White-labeling）”已经成为核心商业诉求。

无论是跨国集团旗下拥有定位不同的多个子品牌矩阵（如不同国家站、年轻版/旗舰版），还是 B2B SaaS 服务商需要为不同企业客户提供深度定制的企业主题与私有化界面，设计团队都必须面对一个巨大的工程挑战：如何用最低的维护成本，支撑成倍增长的品牌视觉差异？

在 Figma 变量功能（Variables）推出之前，传统做法往往是“直接复制整套 UI 组件库（Forking）”，为每个子品牌单独维护一份文件。这种做法在初期看似简单，但随着组件库迭代，任何一个按钮圆角的微调或弹窗逻辑的修改，都需要在 5 个甚至 10 个独立组件库中重复修改 10 次，维护成本呈指数级失控，最终导致不同品牌的组件库版本严重脱节。

借助 Figma Variables 变量、变量模式（Modes）与别名引用（Aliases）机制，我们只需维护一套单一的组件母本库，即可通过外部变量模式的动态注入，实现秒级切换品牌主题。

本文将深入拆解多品牌设计系统的底层架构，并提供从变量层级规划到跨端前端代码交付的完整落地方案。

---

多品牌设计系统三种治理方案选型对比

在决定推进多品牌体系前，我们需要充分评估不同架构方案的投入产出比与组织协同成本：

架构方案	实现机制	资产复用率	组件库维护成本	跨品牌切换体验	适用业务场景
独立分支/分库复制 (Forking)	每个品牌独立建立一份 Figma 组件库文件	★☆☆☆☆ (极低)	★★★★★ (极度繁重，随品牌数线性增加)	极差 (需手动逐个替换组件实例引用)	品牌间组件结构彻底异构、无任何共性（极少见）
样式覆盖与库交换 (Library Swap)	基于旧版 Styles，通过 Swap Library 功能批量替换	★★★☆☆ (中等)	★★★☆☆ (需维护多套同名 Style 库)	一般 (大文件易卡死、容易丢失连接断链)	尚未完成 Variables 改造的历史存量项目过渡期
Variables 变量模式矩阵 (推荐)	单一核心组件库 + 多维 Modes 矩阵 (品牌 × 明暗模式)	★★★★★ (极致复用)	★☆☆☆☆ (仅维护单一组件源文件)	极佳 (右键一键切换，秒级全画板无损切肤)	企业级 SaaS 白标系统、多子品牌集团、跨平台多端交付

可以看出，基于 Variables 变量模式的矩阵架构是当前兼顾复用性与维护效率的最佳方案。关于传统样式如何平滑过渡到新体系，可结合 Figma 样式转变量平滑迁移指南 协同推进。

---

多品牌 Tokens 三层拓扑架构设计

实现“一套组件、百变品牌”的关键，在于建立严格解耦的三层 Token 体系。品牌之间的差异绝不能直接硬编码在组件层，而必须收敛在基础层与语义层之间。

┌─────────────────────────────────────────────────────────────┐
│  Tier 1: Global Primitive Tokens (全局基础原子池)            │
│  - 调色板原始值: Blue/500 = #2563EB, Orange/500 = #F97316    │
│  - 纯物理数值，禁止直接在业务组件中消费                        │
└──────────────────────────────┬──────────────────────────────┘
                               │ 别名映射 (Alias Binding)
                               ▼
┌─────────────────────────────────────────────────────────────┐
│  Tier 2: Semantic Tokens (语义决策层 - 多品牌 Modes 矩阵)    │
│  Mode 1: Brand Alpha (Light)  ──► primary = Blue/600        │
│  Mode 2: Brand Alpha (Dark)   ──► primary = Blue/400        │
│  Mode 3: Brand Beta (Light)   ──► primary = Orange/500      │
│  Mode 4: Brand Beta (Dark)    ──► primary = Orange/400      │
└──────────────────────────────┬──────────────────────────────┘
                               │ 属性绑定 (Component Scopes)
                               ▼
┌─────────────────────────────────────────────────────────────┐
│  Tier 3: Core Component Library (通用核心组件母本库)          │
│  - Button, Input, Modal, Table                              │
│  - 所有填充、边框、文字均只绑定 Tier 2 语义 Token              │
└─────────────────────────────────────────────────────────────┘

1. Tier 1: 全局基础原子池（Global Primitives）

• 存放纯粹的原始色板阶梯（如 gray-50 到 gray-950、blue-50 到 blue-900、orange-50 到 orange-900）以及间距基础尺寸（spacing-4 = 16px、radius-sm = 4px）。
• 规则：此层集合不包含任何业务语义，也不设多品牌模式，仅作为纯粹的色卡底池。

2. Tier 2: 语义决策层（Semantic Tokens）

• 按照功能意图抽象变量，如 surface-brand（主品牌表面色）、text-primary（主文本）、border-accent（强调边框）。
• 核心秘密：在该集合（Collection）中开启多列 Modes。每一列代表一个独立的品牌环境（例如 Brand-A / Light、Brand-A / Dark、Brand-B / Light、Brand-B / Dark）。
• 别名关联：Brand-A 模式下的 surface-brand 绑定别名指向 Blue/600；而 Brand-B 模式下的 surface-brand 则通过别名绑定到 Orange/500。

3. Tier 3: 核心组件母本库（Core Components）

• 设计按钮、卡片、导航栏等公共组件时，只使用 Tier 2 中定义的语义 Token。
• 此时组件本身没有任何关于“蓝色”或“橙色”的感知，它只认“主品牌色 surface-brand”。详细规范可参考 Design Tokens 标准命名与结构对照手册。

---

5 步手把手实操：从零搭建双品牌 × 双模式设计系统

下面以构建一个包含 科技品牌（Alpha，科技蓝） 与 消费品牌（Beta，活力橙）、且各自支持 明暗双模 的完整案例，分步进行实操演练。

第一步：创建 Primitives 集合（原子池）

1. 打开右侧 Local Variables（本地变量）面板，点击 Create collection，命名为 01_Primitives。
2. 新增颜色变量（Color Variables）：
   • 创建 Blue/500 = #3B82F6，Blue/600 = #2563EB；
   • 创建 Orange/500 = #F97316，Orange/600 = #EA580C；
   • 创建 Gray/50 到 Gray/900 的中性色阶梯；
3. 新增数值变量（Number Variables）：
   • 创建 radius/none = 0px，radius/md = 8px，radius/full = 9999px。

第二步：创建 Semantic 集合并配置 Modes 矩阵

1. 新建第二个变量集合，命名为 02_Semantic。
2. 点击右上角 +（New Mode） 按钮新增模式列。为清晰管理，我们将列重命名为：
   • 模式一：Alpha-Light
   • 模式二：Alpha-Dark
   • 模式三：Beta-Light
   • 模式四：Beta-Dark
3. 新增核心语义变量 action-primary-bg（主操作背景色）：
   • 在 Alpha-Light 列中，右键选择 Alias（别名），引用 01_Primitives/Blue/600；
   • 在 Alpha-Dark 列中，别名引用 01_Primitives/Blue/500；
   • 在 Beta-Light 列中，别名引用 01_Primitives/Orange/500；
   • 在 Beta-Dark 列中，别名引用 01_Primitives/Orange/600。
4. 新增圆角语义变量 action-radius：
   • Alpha 品牌偏向严肃科技感，设为直角小圆角：在 Alpha 列均绑定 01_Primitives/radius/md（8px）；
   • Beta 品牌偏向年轻圆润，设为全圆角胶囊：在 Beta 列均绑定 01_Primitives/radius/full（9999px）。

02_Semantic 变量集合矩阵视图:
┌─────────────────────┬──────────────┬──────────────┬─────────────┬─────────────┐
│ Variable Name       │ Alpha-Light  │ Alpha-Dark   │ Beta-Light  │ Beta-Dark   │
├─────────────────────┼──────────────┼──────────────┼─────────────┼─────────────┤
│ action-primary-bg   │ Blue/600     │ Blue/500     │ Orange/500  │ Orange/600  │
│ surface-default     │ #FFFFFF      │ Gray/900     │ #FFFFFF     │ Gray/900    │
│ text-brand          │ Blue/600     │ Blue/400     │ Orange/500  │ Orange/400  │
│ action-radius       │ 8px          │ 8px          │ 9999px      │ 9999px      │
└─────────────────────┴──────────────┴──────────────┴─────────────┴─────────────┘

第三步：配置变量作用域与防混淆设置（Variable Scopes）

为防止团队设计师在为文字上色时误用了背景颜色，需对每个变量配置精准的作用域限制（Scopes）：

• 双击编辑 action-primary-bg 变量的设置小图标；
• 在 Scopes（作用域） 中，仅勾选 Frame fill 与 Shape fill，取消勾选 Text fill 与 Stroke；
• 这样当下游设计师选中文字图层时，拾色器中将自动隐藏该变量，从底层系统杜绝误用。

第四步：构建单一组件母本库

1. 绘制通用按钮组件母本 Button/Primary：
   • 填充色绑定 02_Semantic/action-primary-bg；
   • 圆角属性绑定 02_Semantic/action-radius；
   • 文字颜色绑定 02_Semantic/text-on-action；
   • 使用 现代 Auto Layout 进阶实战 设置水平内边距与居中对齐；
2. 结合 组件属性企业级实战 为其绑定 Label 文本属性与 Icon 图标切换属性。
3. 发布该文件为团队组件库（Team Library）。

第五步：画布与页面级一键切肤实战

1. 新建业务项目文件，引用上述组件库，拖入一个完整的登录卡片或商品详情画板；
2. 选中画板（Frame）或将页面放置在 Sections 分区 容器中；
3. 在右侧检查器（Inspector）中，找到 Layer 面板旁边的 Change Variable Mode（菱形图标）；
4. 选择 02_Semantic 集合：
   • 当点击 Alpha-Light，整张画板呈现沉稳科技蓝与 8px 圆角；
   • 当切换为 Beta-Light，瞬间所有按钮转变为活力橙且圆角变为胶囊弧形；
   • 当切换为 Alpha-Dark，底色自动反色为暗黑模式背景，文字与对比度自动适配！
5. 全程无需重新拖入任何组件，无需断开组件关联，真正实现“一次搭建，无限品牌衍生”。

---

跨端工程化交付：Tokens 导出与前端落地

设计系统在 Figma 中的优雅只完成了成功的一半，如何将多品牌变量无损交付到 Web、iOS 和 Android 代码工程中，才是检验系统闭环的核心。

1. Web 端的 CSS Variables 动态注入

通过 Figma REST API 或开源工具（如 Tokens Studio / Style Dictionary），将 02_Semantic 导出为前端 CSS 变量集：

/* 品牌 Alpha (默认明亮模式) */
:root[data-theme="alpha-light"] {
  --color-action-primary-bg: #2563eb;
  --color-surface-default: #ffffff;
  --radius-action: 8px;
}

/* 品牌 Alpha (暗黑模式) */
:root[data-theme="alpha-dark"] {
  --color-action-primary-bg: #3b82f6;
  --color-surface-default: #111827;
  --radius-action: 8px;
}

/* 品牌 Beta (白标定制客户，明亮模式) */
:root[data-theme="beta-light"] {
  --color-action-primary-bg: #f97316;
  --color-surface-default: #ffffff;
  --radius-action: 9999px;
}

在 React 或 Vue 前端工程中，只需在 HTML <html> 标签上切换 data-theme 属性（例如 <html data-theme="beta-light">），整站样式便能在运行时无感热切换，与 Figma to Code 生产级代码转换深度实战 的工程化标准实现完美对接。

2. Tailwind CSS 多主题配置集成

在 tailwind.config.js 中直接消费这些 CSS 变量：

module.exports = {
  theme: {
    extend: {
      colors: {
        action: {
          primary: 'var(--color-action-primary-bg)',
        },
        surface: {
          default: 'var(--color-surface-default)',
        }
      },
      borderRadius: {
        action: 'var(--radius-action)',
      }
    }
  }
}

前端工程师在编写组件时，只需声明 className="bg-action-primary rounded-action"，即可天然自适应全部子品牌与深色模式，彻底告别为特定客户写死硬编码的落后研发模式。

---

企业级多品牌治理的 4 大黄金法则

在推进大型多品牌架构的过程中，团队必须遵守以下治理铁律，防止系统在演进中退化：

法则一：严格阻断逆向跨层引用

禁止在 Tier 3 组件中直接越级绑定 Tier 1 原子变量（如按钮背景直接绑定 Blue/600）。一旦发生越级绑定，该组件在切换模式时将无法感知品牌变量的变化，造成局部“换肤失效”。

法则二：严控模式列的数量爆炸

Figma 企业版与组织版对单个变量集合的 Modes 数量有上限限制（基础专业版通常支持 4 个 Modes，企业版支持更多）。如果业务拥有 20+ 个白标客户，切忌将所有客户塞进同一个集合的一行中。应采用集合拆分策略（例如将 Brand 维度与 Platform 平台尺寸维度分为独立集合）。

法则三：结构同构，参数异构

多品牌设计系统的黄金边界在于：品牌之间允许差异化的是颜色、圆角、字号、间距与阴影等参数化 Token；但必须共享相同的核心交互结构与数据逻辑。若某个子品牌需要彻底颠覆操作流程与页面骨架，应单独设计业务变体，而不是强行在同一组件中塞入互斥的破坏性改动。

法则四：建立版本发布与权限管控

将 Primitives 与 Semantic 变量库的编辑权限仅开放给核心设计系统架构师（Design Ops）。业务线业务设计师仅拥有 Can view 权限并在下游文件中消费变量，防止任意业务线同学私自新增无序变量破坏全局统一性。版本发布需结合 Figma 企业级分支协同实战 进行严格的合并评审。

---

结语

Figma Variables 的多品牌架构彻底改写了数字产品设计的协同范式。它将原本琐碎、容易断链且耗资巨大的品牌维护任务，转变为高度清晰、可编程、可自动化同步的现代化数据流。

通过合理规划三层 Token 拓扑、善用 Modes 矩阵与精准的作用域配置，设计团队不仅能够以极轻量的人力支撑庞大的商业矩阵，更能与现代前端工程化无缝合流，真正释放数字资产的商业倍增价值。