设计系统：治理与采用

Source: Dev.to

引言

构建设计系统只完成了一半的工作。

是的，评估多种方案、收集利益相关者的反馈并将所有内容实现为代码是很有挑战性的——但这仍然是大多数工程师最为熟悉的部分。我们懂得如何探索技术、分析需求、编写规范，最终交付技术基础。

真正的挑战，至少对我而言，是把这个新方案融入其他开发者的日常工作。任何新系统都会带来摩擦：它需要时间、注意力以及愿意跨过学习曲线的意愿。当团队面临路线图压力时，人们自然会倾向于已经熟悉的做法——即使这些做法正是我们试图解决的问题的根源。

更甚的是，一些在开始时看似完全合理的决策，可能在实际跨团队使用后被证明不准确或不完整——而且现实世界的变化往往比预期更快。

这就是我想在本系列的最后一部分分享的内容：我们是如何处理治理、采纳以及让设计系统真正落地的人性化问题的。

为什么采纳困难（即使技术本身很好）

任何公司都熟悉的常见挑战

采纳很少是技术问题——它是人的问题。

即使新系统客观上更好，团队仍会面临熟悉的障碍：

• 人们倾向于使用熟悉的工具，尤其在路线图压力下。
• 新模式需要时间、注意力和思维转变。
• 旧代码感觉安全，即使它是导致重复问题的根源。
• 每个团队都有略微不同的习惯、优先级和约束。
• 设计系统的收益是长期的，而成本是即时的。

换句话说：即使是好技术也不会自动被采纳。

我们案例中的难点

我们的情况并未与典型情况有根本区别，但有几个挑战尤为突出。

1. 设计侧的复杂性——由于我们的唯一真相来源是 Figma，理解组件的正确含义和使用方式——比如何时使用 Menu、Select 或 Popover——如果没有深入了解以可访问性为驱动的模式并不总是显而易见的。当设计混合了多个组件的属性，例如一个弹出框既可以切换账户又能显示上下文操作时，情况会更复杂。

2. 学习曲线过载——设计系统的构建与前端架构的更广泛转型同步进行：新的 monorepo 结构、首个 ui-kit 包、从 styled-components 向 PostCSS modules 的迁移、引入 Radix Primitives、设计令牌、组件架构模式、Storybook 文档以及 Chromatic 可视化测试。每个变化单独来看都合理，但它们叠加在一起，使得采纳的难度远高于仅有少数变动时的情况。

迁移策略：缓慢、可控、可预测

渐进且一致迁移的主要原则

我们迁移策略的核心很简单：在不破坏已有功能的前提下前进。一次性“大爆炸”重写从工程视角看可能很诱人，但除非收益极为显著——比如显著的性能提升或关键的 SEO 改进——否则很少能为业务提供合理的正当性。我们并未出现这种情况，因此渐进式采纳成为最合理、最可持续的选择。

我们的主要原则如下：

• 所有新功能必须使用新组件
  这既适用于 Figma（唯一真相来源），也适用于代码。新工作应基于新系统；旧组件仅在已有的地方保留。这样可以自然推动新系统的成长，而无需强迫团队进行昂贵的重写。

• “触碰即改进”
  这条全公司通用的规则极其有用。每当有人修改或重构某段 UI 时，都是将该部分迁移到新组件的好时机。由于 PR 已经需要审查并进行视觉测试，将迁移合并到同一次变更中，往往比以后单独处理的成本更低。

这两条原则共同构建了一个可预测、可管理的采纳流程：慢到不会扰乱产品工作，却足够稳健以避免停滞。

将设计评审纳入采纳流程

在大多数团队中，新设计会在标记为 Ready for Dev 之前由 Design Head 或 CPO 进行评审。然而，这些角色最初并不完全掌握新引入的设计系统的全部上下文——包括其组件、约束、模式以及如何转化为代码。

为弥补这一缺口，我们在前几个月引入了额外的评审步骤：设计系统评审。该评审由两位完全了解系统架构和原则的人负责：

• 来自设计侧的 Design System Lead，以及
• 来自工程侧的 Project Lead。

此检查点的收益

• 提前捕获不一致——在任何代码编写之前，就标记出组件选择、命名和模式上的问题。
• 知识共享——设计师学习如何正确使用新系统——哪些组件该选、语义令牌如何工作、何时使用特定模式等。
• 更好的可预测性——交付给开发者的设计更一致、更加现实，并与系统的实际能力保持一致。

这段短暂的评审阶段显著加速了采纳，因为设计与工程在同一认知模型下前进。

开发者体验改进

人们自然倾向于熟悉的行为，因此我们引入了若干 DX‑导向的护栏，以促进设计系统的一致使用并降低摩擦：

• 自定义 ESLint 规则——强制正确使用组件和令牌（如 Part II 中所述）。它们在编辑器中即时提供反馈，远早于 PR 审查。
• 将所有旧组件标记为已废弃——即使组件尚未完全重构，也会被标记。这并非施压，而是提供一个明确的视觉信号：这条是旧路径。
• 文档（作为最后手段）——编写并维护了完整文档，但实际上文档更适合作为安全网，而非主要的采纳工具。
• 自动化脚本——将 Figma 变量导出为代码、为新组件生成模板、简化对设计系统的贡献等工具。
• 专用 Slack 频道——集中沟通帮助团队提问、分享示例并保持一致。更重要的是，它营造了一种社区感，而不是另一条必须遵守的规则。

这些 DX 增强措施共同降低了使用系统的认知负担，使正确的路径成为最容易的选择。提升 DX 确保采纳不单靠纪律，而是让系统本身引导开发者走向正确的模式。

AI：2025 年及以后迁移

随着大语言模型（LLM）变得更加精准且具备上下文感知，许多手动迁移工作现在可以交给它们完成。

我们采用了 Cursor 和 GitHub Copilot 作为迁移助理：

• 自动化迁移指南——只需一个简单的 Cursor 提示，我们就能生成结构化指南，展示如何将旧组件的配置调整为新 API。这些指南也可以直接作为转换提示复用，例如：

  “将所有旧的 Button 组件迁移到来自 ui-kit 的新 Button，使用 docs/migration-guides/Button.mdx。”

• 与设计系统对齐的 AI 规则——（内容截断）