上周五的 Zoom 通话里，那家刚上线两个月的创业公司首席设计师把屏幕共享过来时，脸上带着藏不住的得意——他用 Figma 变量搭出了四套完整的品牌主题，整整花了一周时间，把基础色 token 映射到语义 token 的矩阵做得密密麻麻。四种品牌、暗黑模式、高对比模式全配齐，唯独有一个问题：这四个品牌里，没有一个真正存在过哪怕一天。
当被问起为什么需要这些时，他的回答坦荡到让人心疼：“公司明年可能会推出一个衍生品，我想让架构先准备好。”就是这句话，立刻把整件事从一个技术备忘录拽进了一个经典的过度设计陷阱里。在连第二个品牌都没有落地之前，就去构建多品牌设计系统，这根本不是什么前瞻性，而是给团队全员装上了一个又慢又沉的认知副油箱。
你维护的早已不是一套设计系统，而是一笔每天都产生利息的复杂度债务。为了一个未必到来的未来，你把眼下手头最该快速交付的工作，活生生拖进了 tokens 的无底洞里。
代码层：一个按钮身上背了多少不该有的逻辑
一旦决定从第一天起就为多个品牌服务，技术栈的每一层都会立刻肿胀起来。拿 CSS 来说，本来一个按钮组件只需要一两行背景色、边框色就完事，现在却不得不绑上一整套主题上下文，把 brand props 顺着组件树一路透传，逼着每个组件都变成一个逻辑怪。React 里最常见的那套 multi-brand 设置代码，看起来体面，实则一量产就露馅：
import { createContext, useContext } from ’react’;import { themeA, themeB } from ’./tokens’;const ThemeContext = createContext(themeA);export const ThemeProvider = ({ brand, children }) => {const currentTheme = brand === ’brandB’ ? themeB : themeA;return ({children}
这个 Provider 看着不长，但只要试着把它往成百上千个组件里规模化，立刻就会暴露问题：每个新加入的开发者，连一张最简单的登录落地页都还没摸熟，就得先搞清楚品牌 token 的传递链路和含义变化。border-subtle 这个 token 在不同品牌下指代的颜色居然可以完全不同，意味着你必须时刻在脑子里挂载“当前激活的是哪个品牌”，仅仅是为了画一根很细的边线。
认知负荷就这么毫无价值地堆起来了。明明 99% 的团队现阶段只需要一套拿得出手的主色板加一套能用的暗黑模式，却偏偏要因为一个尚不存在的衍生品，提前写好三倍甚至五倍的 CSS 变量，乃至额外维护一套故事书（Storybook）里的主题切换演示。时间耗在这上面，还不算最亏的；最亏的是，这种复杂度会渗透到 PR 审查、结对编程、新人 onboarding 的每个环节，成为一种持续伤害。
设计工作流：从调一枚语义色，变成给每个虚无品牌做数据录入
麻烦绝不止步于代码。Figma 这边的设计流程，同样被这些幻想出来的品牌搅得寸步难行。
设计师想要增加一个新的语义色——“警告背景色”，这在任何只有单一品牌的项目里，只是一个两三分钟的操作：选好色值，挂上语义 token，收工。但当文件里已经预制了四个品牌主题时，情形就完全变了。你不仅要决定主品牌下的警告背景色是什么色值，还得分别给另外三个影子品牌也指定它们的警告背景色，然后再把每种组合下的暗黑态、高对比态通通配齐。这样一来，一个原本由设计直觉驱动的微调，直接沦为漫长的 token 矩阵填空和数据录入苦力活。
更荒谬的是，这些为了还没上线的品牌做的对比度检测，会占用掉设计师一整块下午。他们反复在 WCAG 的 AA 和 AAA 标准之间微调色值
热门跟贴