从零构建设计系统：在混乱中建立秩序

当团队扩张到 5 个设计师和 20 个前端开发时，我们遇到了经典的“熵增”问题：同一个“主按钮”出现了 4 种不同的蓝色，圆角半径从 2px 到 8px 都有。

这不仅是视觉的不一致，更是沟通成本的黑洞。于是，我发起并主导了 Cosmos 设计系统的构建。

01 原子设计理论的实践

我遵循 Brad Frost 的 Atomic Design 方法论，但根据我们的业务做了改良：

• 原子 (Atoms): 颜色、字体、图标、阴影。这是最基础的视觉基因。
• 分子 (Molecules): 输入框+标签、头像+名字。
• 生物 (Organisms): 完整的卡片、导航栏、数据表格行。
• 模板 (Templates): 典型的 CRUD 页面布局。

我强制要求所有“生物”级别的组件必须由“原子”和“分子”组装而成，严禁出现 Hard-coded 的样式值。

02 Design Tokens：设计与开发的通用语

为了打通 Figma 和 React 代码，我引入了 Design Tokens。

我们不再说“把这个按钮改成 #0066FF”，而是说“使用 color.primary.action”。 我编写了一个自动化脚本，通过 Figma API 自动拉取 Token 定义，并生成前端项目所需的 theme.ts 和 CSS 变量文件。

这意味着，当我想调整品牌色时，我只需要在 Figma 里改一次，运行脚本，整个产品的颜色就会自动更新。这实现了真正的设计工程化。

03 约束与灵活性的平衡

设计系统最难的不是“建立规则”，而是“管理例外”。

在初期，我犯过“过度设计”的错误，把组件封装得太死，导致业务方无法满足特殊需求。后来我引入了 Slot（插槽）模式 和 Variant（变体）机制。

例如，我们的 Modal 组件只规定了遮罩、标题栏和底部的样式，中间的内容区域完全开放给业务方自定义。这种**“有原则的灵活性”**，让设计系统既能维持一致性，又不会成为业务迭代的绊脚石。

总结

构建设计系统是一场持久战。它需要的不仅是审美，更是系统性思维 (Systems Thinking) 和抽象能力。它让我从“画图的人”变成了“制定规则的人”。