从可复用到可再生：重新思考共享 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 使用和无障碍要求）输入到模型中，而这些规则存储在代码旁边带版本控制的目录中，并在随后通过运行审核提示来检测硬编码的值以及对比度校验失败项。这些规范构成了新的组件库，你获得的不再是代码，而是核心指令。

工程原则（用通俗的语言表述、提供具有明确立场的默认值并允许有意识地偏离、在生成的代码和手动编写的代码中保持定义的一致性和零漂移、将无障碍性视为不可妥协的要求）正是模型在编写任何代码之前必须遵循的持久化约束。对于这种方法，Griffiths Waite 提供了一个很好的例子：一个涵盖了广泛工程规则的原则库，用于管理组件的简洁性、开发体验和无障碍性。这正是我们如今会首先让编码代理调用的内容。这些库以可搜索、按领域分类的形式保存（而不是作为“部落知识”），从而成为每次代码再生过程中可重用的输入。

设计系统、token、组件说明和工程原则的结合，构成了智能代理生成组件的规范。每个项目都会根据这些规则生成所需的内容，并针对其自身的框架版本进行调整，同时跳过那些永远不会用到的组件，而不是将整个库纳入到项目中。

在基于设计进行组件再生方面，我们已经在 Griffiths Waite 的项目中采用了这一方法；我们使用 Figma MCP 服务器，并发现它能以惊人的精度直接从 Figma 设计生成 UI。我们将这个方法与我们为项目创建的技能相结合，从而将工程最佳实践固化为代码规范，确保生成的代码符合我们的标准，而非模型默认生成的结果。

最后一步是验证。如何确保生成的代码值得信赖？Chromatic、Percy 和 Playwright 等视觉回归工具会将组件与已批准的基线进行对比，从而发现单元测试中可能忽略的蓝色色调偏差或 4 像素的内边距偏移等问题。Playwright CLI 可以用于解决这个问题。智能代理可以通过 MCP 服务器将构建结果与 Figma 设计进行对比，并对两者进行截图对比测试，以确保它们是一致的。同一套工具还可以用于验证重新生成的标记是否符合所需的无障碍结构，而计算样式检查则可以确认颜色、间距和字体是否与设计 token 相符。

变更控制在技术栈中上移

如果规则现在就是产品，那么问题在于如何对其进行版本管理。在共享库中，变更控制体现在发布的代码中。共享库发布时会带上新版本号，用户只需要更新依赖项并进行迁移，而语义版本控制（SemVer）则会提示哪些功能会因此失效。在再生模式下，发布的代码是可丢弃的。因此，版本管理转移到了每次再生都会读取的工件上。

工程技能以及包括无障碍性、组件简洁性和开发体验等在内的横切面原则，可以与组件库分开处理，按照自己的节奏进行版本管理。这些技能应覆盖所有代码库，并独立管理。

组件规则、设计系统、token 以及各组件的操作指南，均可以像之前的代码包一样进行版本管理。每个打包文件都包含智能代理自主构建组件所需的一切内容，包括指向 Figma MCP 服务器和当前设计的链接。因此，重新生成和截图验证均基于一个固定的单一可信来源，而非一个已偏离规范的设计文件。重要的是，要确保该打包文件保持最新状态，与 Figma 中的正确版本保持一致，并进行正确的版本管理。

当版本号递增时，项目和团队可以选择重新生成受影响的组件并运行测试套件进行验证；他们也可以指示智能代理仅更新已更改的部分，而不是重新生成整个组件。此外，如果某个项目希望在其自己的仓库中对实际构建的组件进行版本管理，也仍然可以那样做。

同质化提升了个性化系统的价值

随着再生技术逐渐成为构建用户界面的主流方式，出现了一个新的问题：所有东西一开始看起来都一样。这一问题早在像 Material UI 这样的组件库出现时就已有所体现。模型是从公共 Web 中学习的，因此，“一个简洁的现代化首页”会返回训练数据的统计中值，而这正是设计所能达到的平均水平。在一篇题为“为什么 AI 生成的设计都千篇一律”的文章中，Curio 深入探讨了这一问题。模型“学习的是该分布的中心而非边缘”。提示语越模糊，生成的结果就越趋于平庸。

Northeast Times 近日报道称，两家初创公司的创始人分别带着使用 Anthropic Claude Design 工具制作的演示文稿出席了不同的会议。一位设计师表示，这些文稿看起来“似乎出自同一家公司之手”，就连四矩形布局和居中排版都如出一辙。开发者们之所以为这种现象起了一个名字“同质化之海”（Sea of Sameness），就是因为 Lovable、v0 和 Base44 等设计平台不断地产出相同的“Tailwind Blue”配色、相同的紫色到青色渐变，以及相同的卡片网格布局。

在许多项目中，默认设置往往是根据 AI 的建议决定的，这些建议通常会选用 Next.js、Tailwind 和 shadcn/ui 等技术。当所有人都使用相同的工具、框架和组件默认设置时，产出的结果往往就趋于一致。

蒂尔堡大学 2026 年一项题为“生成式 AI 会让我们思维趋同吗？人类与 AI 共同创作过程同质化效应的系统综述与 Meta 分析”的研究发现：

结果表明，AI 的使用存在一种微弱但具有统计学意义的同质化效应。该效应在敏感性分析中表现稳健，无法用发表偏倚来解释。调节变量分析表明，同质化效应与任务类型相关：与约束较少的发散性思维任务相比，该效应在语义有限的构思任务中更为显著。

2024 年一项关于构思过程的独立研究发现，与使用其他工具相比，人们“在使用 ChatGPT 时产生的更具语义独特性的想法会更少”。这是对模型行为的一种量化描述，而非一时的情绪波动。

这种同质化现象与任务相关，在语义有限的提示词中表现最为明显，例如只给出“现代登录页”这样一个简单的提示。而这恰恰是一个强大的系统最能让输出结果脱颖而出、超越平均水平的地方，这正是设计系统愈发重要而非不再重要的原因。一套强大且个性鲜明的设计，正是让模型摆脱平庸的杠杆。那些致力于对抗“平庸”的人给出的建议是：“在生成任何内容之前”先确定视觉约束，向模型提供具体的元素、布局结构和风格指引，而不是像“现代”和“简洁”这样的形容词——训练集中的每一种风格都已经宣称拥有这些特质。要生成与众不同的 UI，关键在于其背后的系统有多么具体且个性鲜明。

关于同质化是否真的重要

麦肯锡的研究“设计的商业价值”对医疗技术、消费品和零售银行业领域的 300 家上市公司进行了为期五年的追踪（2012 年 12 月至 2017 年 12 月），并根据基于 200 多万条财务数据和 10 万项设计举措得出的“麦肯锡设计指数”（MDI）对每家公司进行了评分。在这项研究期间，MDI 显示出，位列前 25% 的企业，其营收增长率比同行业其他企业高出 32 个百分点，股东总回报率高出 56 个百分点。千篇一律的设计会削弱企业在买家中建立起的信誉，因为买家能够分辨其中的差异。关于同质化的研究表明，这种趋同现象是可量化的，而非仅凭一些传闻作为证据。对于任何面向品牌的事物而言，在同质化的洪流中泯然众人是要付出代价的。

不过，熟悉感并不一定意味着失败。雅各布定律提醒我们，人们大部分时间都花在了其他网站（而不是你的网站）上。因此，常规且易于理解的布局能降低认知负荷，往往是有益而非有害的。即使在品牌独特性并不那么重要的场景中——例如内部管理面板或运维工具——用户体验的质量依然至关重要。清晰高效的界面能降低认知负荷，缩短任务时间并减少错误，从而提高日常工具在团队中的采用率和留存率。真正的分界线在于：品牌独特性（某些界面可以不考虑这一点）和体验质量（任何界面都不能不考虑）。一个强大的系统能够以较低的成本实现后者，这就是为什么即使是批评者也会将问题归结为同质化以及判断这种同质化在哪些场景下才真正值得重视。这种统一性大多源于懒惰、定义不充分的提示，而非硬性限制。因此，更好的输入就能解决这个问题。从长远来看，发展趋势可能会完全相反，朝着能够根据每位用户的需求进行自我调整的生成式用户界面（generative UI）迈进。

因此，应引导这种再生机制，而非抗拒它。让系统真正具有鲜明的个性，拥有真实的字重体系、色彩体系、间距节奏和动态效果，而不是仅仅对默认样式做微乎其微的重新设计。

共享库在哪里仍然更有效

在某些方面，Telerik 提出的关于维护一个精心打造的共享库的最佳理由确实站得住脚。其中最具说服力的是无障碍性。正如他们指出的那样，“AI 代码生成工具在无障碍性方面并不擅长”，而 AI 生成的 UI 默认情况下往往不具有无障碍性。解决这些问题的关键在于架构设计。用他们的话说：“与其依赖每一个提示来生成正确的基元，不如使用那些将无障碍性编码到 API 契约中的库”。键盘处理、焦点管理以及 ARIA 语义，正是你在重新生成代码时不经意间就会丢失的、已编码的专业知识。

还有一个参考资料的问题。AI “无法无中生有”。一个知名的库为它提供了数千个一致的示例作为依据，这往往比不同开发人员使用不同工具耗时数年拼凑而成的定制代码更胜一筹。输出结果仍然需要有人审核。配置一个可信的组件比阅读两千行手工编写的代码要简单得多，也安全得多。

2026 年发表的一篇题为“生成式 AI 时代的软件复用”的论文警告称，盲目信任生成的代码“在概念上与‘货物崇拜（cargo cult）开发’并无太大区别”，而且，复用“基于尚未被证明适合特定用途或未以复用为设计目标的资产，可能会导致严重的质量问题”。

验证很重要

关于无障碍性和质量的担忧，实际上正是支持进行验证的理由。编码化专业知识不只是存在于已发布的组件代码中；它还存在于设计系统、无障碍验收测试以及你精心维护的一小套真正复杂的基元中。所谓货物崇拜编程警告，其实只是要求对代码再生过程进行测试，而非盲目地信任。在人工智能辅助能力较弱的地方，应将其置于自动化检查的保护之下，并将少数几个控件（数据网格、下拉列表、日期选择器）作为经过人工审核的共享代码保留下来。

因此，我们的方案是将共享代码分为三个部分：

• 再生高使用量、低风险的部分：布局、排版、按钮、卡片和简单表单；这些元素的开发成本低，便于根据设计规范进行验证，但考虑到其性质，集中维护的成本却很高。

• 精心打造并共享那些在无障碍性和行为实现上真正存在难度且一旦出错代价高昂的少数组件。

• 将设计系统、token、设计指南和测试套件集中管理，因为这些才是真正确保一致性的关键，而且维护成本较低。

那么，要不要构建一个呢？

在构建或维护共享组件库之前，你应该能够明确地指出，其四大特性（即可复用性、一致性、编码化专业知识和单一可信来源）中，哪些是强大的设计系统加测试无法以更低成本实现的。

对于许多组织而言，尤其是那些没有资金充足的平台团队的组织，当前的发展方向正趋向于更精简的模式：仅保留一个标准的设计系统、机器可读的指南、按项目再生的机制、针对该系统的严格验证，并且仅将真正复杂的组件作为经过审核的共享代码保留下来。在这种模式下，设计系统并未消失，反而变得更加重要。真正会缩减规模的是共享组件库。对于没有平台团队提供资金支持的团队来说，这并不是什么值得惋惜的损失。

原文链接：https://www.infoq.com/articles/regeneratable-ui-component-library/