从可复用到可再生：重新思考共享 UI 组件库

在过去的十年中，在任何处于成长阶段的工程组织内部，有一条建议几乎始终都未曾受到质疑，那就是构建一个全公司通用的组件库。如果你将按钮、模态窗口、数据网格和表单控件整合到一个带版本控制的包中，那么每个团队都能从一致性、易用性和效率方面获益。这似乎已经融入了我们的基因；可复用性有助于提高一致性和效率。 在 2026 年，这个思路值得重新审视一下了。虽然之前的建议很有道理，但当初让“使用单一共享库”成为不二之选的条件如今已经发生了变化。当开发人员能够在短时间内生成一个带有样式设计且基本符合无障碍标准的组件时，为整个公司维护一个标准库所带来的价值已经大不如前。对于许多组织而言，共享库如今已经不再那么必要。值得集中管理的应该是设计系统、token、设计规范和测试，而非已发布的组件代码。 在 Griffiths Waite，对于这种集中化，我们有着切身的实践经验。过去十年间，我们大部分时间都致力于使用 React 构建共享用户界面，并为大型企业客户维护组件库和设计系统。我们亲眼见证了组件库所能带来的好处。如今，我们开始重新思考组件库和设计系统的未来发展方向。 共享库的真正用途是什么 共享库总是将四个独立的承诺整合到一个构建产物中： 可复用性：这样就没人需要第五次开发日期选择器了。一致性：确保一个团队的按钮、表格或表单控件的行为与另一个团队的一致，这对保持用户体验的一致性至关重要。编码化专业知识：使得无障碍访问、键盘操作、特定于组织的特殊情况以及棘手的边界情况，都能由真正关心这些问题的人一次性解决。单一可信来源：确保品牌变更能从一个地方同步到所有地方。 在这四项承诺中，实际上只有两项需要发布代码。一致性和单一可信来源属于设计系统及其 设计 token " 的范畴——它们提供可供组件引用的共享颜色、字体和间距值。可复用性和编码化的专业知识才是共享包存在的理由，而这正是 AI 如今能够提供帮助的部分。 维护成本才是真正的开销 无论是在零冲刺（Sprint Zero）期间构建，还是作为独立的项目进行开发，共享库在初始构建时总是既耗时又费力，但共享库成本最高的部分绝不是首次发布，而是随后的十年。一旦用户开始使用它，你就需要维护一大批应用程序，并且在变更时需要谨慎考虑。 在 daisyUI 官方博客上， 一篇讨论抽象所有权的文章 "指出： 你拥有的每一行代码，都意味着你必须对其进行维护、测试、修复和更新。 正是基于这一观点，在任何抽象过程中，遵循类似“ 避免草率抽象 "”（AHA）这样的准则往往大有好处，因为抽象后的代码需要维护，而维护成本通常会让人觉得不值得进行那样的抽象。当与以往任何时候相比，编写或重写代码都更加容易且成本更低时，选择抽象什么就变得尤为重要。 在 Hacker News 上一个高赞帖 "中，人们探讨了如何推出内部 UI 组件库，其中就有人留言建议避免使用组件库；他所在的公司当时正在第二次尝试推出这样的组件库： 内部 UI 组件库的开发和维护成本很高——它们比普通的 CRUD 应用要复杂得多，需要技术娴熟且自律性很强的团队才能真正实现，因为必须着眼于未来数年，并尽可能减少人员流动。 当共享库的使用范围从一个产品团队扩展到其他团队时，所有权归属问题就会变得棘手。维护人员会被其他交付工作所牵扯，不同使用团队的优先级会发生冲突，而基于该库进行开发的团队往往会为一个组件生成多种变体，尽管实际上只需要两三种。最终，你不得不将该库作为一个完整的项目来运营，包括需求列表、对齐会议、规划，所有这些都是额外的负担，是你在首次发布后仍然需要连续多年支付的代价。 在 Griffiths Waite，在大型多团队环境中运营共享库时，我们曾经亲身经历过这一问题。一旦某个库被广泛采用，依赖项管理就变成了一项平衡工作——需要保持多个组件版本的一致性，以免随着团队逐步转向不同的版本，单一可信来源悄然碎片化。当共享组件封装了特定的第三方库时，升级部署就会变得困难。提升或替换这些依赖项时往往会难以理清头绪。每个使用方都必须同步迁移，而非各自为政。即便是出于善意的变更，也会在每个使用该组件的应用程序中引发连锁反应。因此，版本控制和沟通最终变得与代码本身同样重要。而且，与只有一个使用方相比，共享库中的组件往往会积累更多的变体。只有明确且持续不断地履行维护责任，整个共享库才能保持健康地运行，而当维护者被调去参与其他交付工作时，这种问题往往就会被忽视。 当然，这种持续的所有权也并非意味着共享库毫无价值。一个全公司范围使用的库是一个产品，它有自己的路线图、技术支持开销、弃用政策以及专门团队。如果这个团队缺乏资源，那么在几个发布周期内，所有下游项目都将不得不围绕一个无人负责的库进行修补。 重新开发变得比复用更划算 多年来，复用一直是主流做法，原因显而易见，从头构建既耗时又容易出错。因此，编写一个优质的实现方案，并将成本分摊给每个使用者，显然是明智之举。生成式人工智能改变了这一系列问题。当实现成本降低时，我们的关注点就可以转向那些最初催生集中式设计系统需求的核心领域。 在一篇题为“ 组件库之死 "”的文章中，Marco Kotrotsos 描述了 Tailwind 自身的付费组件业务如何因其无处不在而遭到冲击：由于 Tailwind 在训练数据中占据了极高的比例，“当开发者需要一个 Tailwind 组件时，他们不会去查阅文档，而是直接向 AI 提出请求，AI 便会直接生成代码”。结果证明，共享库所提供的标准化功能，恰恰是导致该库作为代码交付变得多余的根本原因。 Denis Uraev 将这一变化描述为 从可复用代码向可再生代码的转变 "，即保留规范、按需重新生成实现，并借助测试让智能代理能够“独立验证正确性”。2026 年有一份关于 AI 编码中基于组件开发的 技术报告 "，从研究的视角提出了相同的观点，并描述了能够帮助智能代理“检查、修改、测试、调试和重新生成代码片段”的工具。 如果一个团队能够从共享的设计系统和明确定义的提示中快速生成所需的组件，那么那个必须进行版本控制、发布和升级的中央共享包的价值就会大打折扣。一致性依然得以保持，只不过现在是由设计系统来保障。 集中管理规则并生成组件 需要明确的是，这种方法需要更强的纪律性，而不是更弱。它只是将这种纪律性从代码转移到了规则上。工作的重心从共享的代码工件转移到了一套共享的约束条件上，而这些约束条件本身也是工件。 首先将设计系统及其 token 作为单一可信来源。团队已经以这种方式对待 token，并通过“样式词典”（ Style Dictionary "）这样的工具来处理定义，从而生成 CSS、iOS 和 Android 值。设计 token 的维护成本很低，而且它们正是很方便模型处理的那种结构化输入。 接下来，让我们讨论下机器可读的规范。设计系统团队已经开始 将持久化规则（例如，token 使用和无障碍要求）输入到模型中 "，而这些规则存储在代码旁边带版本控制的目录中，并在随后通过运行审核提示来检测硬编码的值以及对比度校验失败项。这些规范构成了新的组件库，你获得的不再是代码，而是核心指令。 工程原则（用通俗的语言表述、提供具有明确立场的默认值并允许有意识地偏离、在生成的代码和手动编写的代