AI 会写组件之后，我们还需要组件库吗？

AI 已经可以根据一句描述、一个设计稿或一张页面截图，生成组件和可运行的页面初稿，也能够读取现有组件库的代码、规范和文档，按照组织已有的技术约束继续完善实现。

与此同时，许多前端团队仍在投入精力维护组件库：继续补充组件，完善文档和测试，清理历史 API，把 Vue 2 升级到 Vue 3，或者推动旧版 React 向 React 19 迁移。

两件事放在一起，多少有些矛盾。当 UI 实现越来越容易生成，组件库还有没有长期价值？当 AI 可以批量修改旧代码，技术栈升级是否也会变成一件轻松的事情？

这些问题看似分别属于组件建设和技术栈治理，背后指向的其实是同一个问题：当代码生产越来越便宜，什么还值得成为长期资产？

过去，组件库最显性的价值，是复用已经封装和验证过的实现。按钮、弹窗、表单等能力由一支团队统一建设，其他业务直接调用。组件覆盖越完整，重复开发越少，产品体验和工程质量也更容易保持一致。

随着 AI 开始参与组件实现、使用和迁移，这些价值依然存在，但支撑组件库建设的成本结构已经开始变化。

首先下降的是实现成本。过去，开发者可能需要较长时间完成一张信息卡片，处理结构、样式、状态和响应式适配；现在，AI 可以结合当前页面的代码和设计要求，很快生成一个可用版本。对于状态简单、风险较低的局部 UI，重新生成一份实现的成本已经明显下降。

组件的使用成本也在下降。组件库过去需要投入大量精力设计简洁的 API、编写示例和使用教程，因为开发者要亲自查找组件、理解属性，再将多个能力组装成最终页面。AI 可以同时读取类型定义、文档、示例乃至组件源码，辅助完成组件选择和调用。一个对人来说不够直观的 API，对能够同时读取类型、示例和相关上下文的 Agent（智能体）来说，未必具有同样高的使用门槛。

这也会动摇组件 API 的一些传统假设。过去，团队会通过大量语法糖降低人工调用成本，也会尽量避免 Breaking Change，以免几十个项目、几百处调用都要逐一迁移。现在，AI 可以扫描调用关系、修改参数与事件、生成兼容代码，再通过构建和测试不断修正结果。API 仍然需要清晰和稳定，但为了避免人工迁移而长期保留历史包袱，未必还是唯一选择。

Atomic Design 方法提出者、长期从事设计系统实践的设计师与开发者 Brad Frost，在 2024 年的文章 《AI and Design Systems》 中，与 Big Medium 团队展示了 AI 生成组件代码、转换不同框架实现、编写单元测试、检查无障碍以及生成文档等实践。他们观察到，组件属性、状态、功能、Storybook 示例和样式等内容可以在跨框架转换中延续，与具体技术栈相关的实现则由 AI 调整。

这并不意味着框架已经失去价值。不同框架依然会影响运行时模型、性能、生态和研发体验，但这些实践已经提示我们，组件库长期遵循的一些原则需要重新评估：一个组件是否仍要依靠不断增加的属性和插槽覆盖所有业务差异？公共 API 是否必须为了避免迁移而永久保持不变？一些只用于减少手工编码的轻量封装，是否还值得进入公共组件库？

因此，更准确的判断不是“重复代码不再重要”，而是：仅仅为了减少重复编码，已经不足以支撑一个能力进入公共组件库。

一个只服务于少数页面、没有复杂状态和业务规则的信息卡片，即便未来再次出现，重新生成的成本也可能低于设计公共 API、维护文档、发布版本和承担兼容责任的成本。对于这类业务语义较弱、状态简单、出错影响有限的 UI，继续公共化的必要性会逐渐下降。

AI 降低了单次实现的成本，也会让组织内部出现更多实现。过去，一个页面从设计到开发需要较长时间，能够被实际尝试的方案数量有限；现在，产品、设计和开发都可以借助 AI 快速生成界面，同一个任务可能在短时间内出现多种布局、交互和技术实现。

更多方案能够带来更大的探索空间，但每一份生成结果也包含新的局部判断：加载状态如何处理，失败后是否允许重试，埋点放在哪里，权限如何控制，空状态使用什么文案，移动端和桌面端是否保持相同行为。

这些局部答案单独看都可能合理，进入同一个产品之后却容易产生分歧。相同的业务规则被实现成多个版本，异常和边界场景在不同页面中反复遗漏，设计和研发需要不断校正生成结果，后续修改还要分别定位和验证。

Figma 在 2026 年发布的 Decagon 案例 中提到，在缺少设计系统时，每个组件都会重新变成一次局部判断，产品一致性以及设计与研发之间的往返成本也会随之上升。Decagon 后续建设了自己的设计系统，明确组件的禁用、只读、错误和警告等状态，并将组件同步到 Storybook，供 Coding Agent 在实现设计稿时直接使用。

这个案例来自 Figma，其产品和业务立场天然倾向于强调设计系统的价值，不能单独证明所有团队都应该建设大规模设计系统，但它至少呈现了一个现实问题：生成速度提高后，局部决策并不会自动收敛。

Google 的 A2UI v0.9 则给出了一个更直接的工程方向。A2UI 允许 Agent 描述界面意图，React、Angular、Flutter 等客户端再使用自己的组件目录完成渲染。Agent 可以根据任务灵活组合界面，但能够使用哪些能力、表达哪些状态以及最终如何渲染，仍然由客户端和组件资产控制。

组件目录由此成为 Agent 的受约束行动空间。它既是一套供开发者复用的运行时能力，也为 Agent 提供了理解产品和生成界面的词汇，并限定了它可以调用的能力范围。

这里需要注意，“受约束”并不意味着所有页面都必须使用唯一的标准答案。AI 仍然可以生成不同布局和交互，但业务事实、关键规则和已经验证过的行为，不应该在每次生成中被重新改写。

因此，AI 带来的变化并不只是“组件更容易写了”。当实现数量快速增长后，组织更需要明确哪些内容可以自由生成，哪些能力必须复用，哪些约束不能由每一次生成重新决定。

过去，组件库最直观的价值是代码复用；AI 时代，它更需要保存组织已经做过、并且不值得反复重做的判断。

以一个审核操作区为例，表面上可能只是几个按钮、状态标签和确认弹窗，真正重要的内容却包括：当前对象处于什么状态，谁可以执行什么操作，哪些操作需要二次确认，提交失败后能否重试，操作结果如何记录，状态又将流转到哪里。

这些知识如果只藏在组件源码的条件分支中，AI 每次生成新页面时都需要重新推测。如果状态、动作和权限已经被明确表达，AI 才能在新的界面中可靠地复用这些规则。

组件还保存着大量难以从视觉稿中获得的工程约束。一个按钮可能自动处理重复提交、埋点和无障碍属性；一个信息展示组件可能包含脱敏和国际化规则；一个跨端组件可能已经处理不同宿主环境下的行为差异。AI 能够生成相似的外观，却不会天然知道这些要求来自哪些历史问题、合规规定或团队共识。

更难替代的是已经完成的验证。以文件上传为例，生成按钮、进度条和请求代码并不困难，更难、也更消耗工程投入的，是把文件类型与大小限制、失败重试、弱网恢复、安全检查、浏览器兼容和性能边界逐一处理并验证清楚。

如果每个业务都重新生成一份上传能力，团队也需要重新完成这些验证。成熟组件将复杂边界的处理逻辑和验证结果集中在同一个位置，出现缺陷或者规则变化时，还可以统一升级、灰度和回滚。AI 可以帮助修改几百份局部代码，但能够批量修改，并不意味着能够以相同成本确认几百份代码都保持正确。

因此，组件库未来复用的内容会逐渐从代码实现扩展到业务语义、产品规则、工程约束、验证结论和统一演进能力。我们可以将其概括为“确定性复用”，但这里的确定性并不要求界面呈现完全固定，而是要求业务事实、关键规则和已经验证的行为，不必在每次生成中被重新推断，更不能被随意改写。

一个能力值得稳定沉淀，是因为组织不愿意在每次生成时重新理解它、重新验证它，再重新承担一次风险。

当“是否存在相似实现”不再是组件化的主要标准，不同资产会走向不同形态。

一张页面专用的信息卡片，业务语义较弱，状态和边界较少，即使样式存在少量差异，也不会带来严重后果。这类 UI 可以更多地留在页面内部，由 AI 根据当前上下文直接生成。主动允许一部分代码局部化，不再试图把所有相似实现都纳入组件库，可能成为更合理的工程选择。

筛选列表、审核工作台和复杂表单则是另一类情况。它们在多个业务中反复出现，却很难使用一段完全相同的运行时代码。过去，团队经常将整块页面封装成一个大组件，再通过大量属性、插槽和回调适配不同场景。随着需求增加，组件的抽象边界逐渐失控，业务方也开始绕过组件实现自己的逻辑。

这类经验依然值得复用，只是未必需要固化成一个庞大的公共组件。团队可以保存页面如何分区、基础组件如何组合、常见状态如何呈现、哪些交互应当保持一致，再由 AI 结合当前业务完成最后一公里实现。在设计系统语境中，这类页面层级的可复用经验常被称为 Pattern，可以理解为“页面模式”；具体场景中的组件组合示例常被称为 Recipe，可以理解为“场景组合示例”。它们复用的是解决一类问题的结构和经验，并不要求所有业务运行完全相同的代码。

上传、地图、日期选择和大数据列表等基础能力，则拥有大量边界条件，重新完成验证的成本较高，出现问题后也需要统一修复。这类能力仍然适合以稳定运行时组件存在。AI 能够提高组件的开发和维护效率，却难以消除集中验证和统一治理的价值。

审核、支付、准入、权限和风险提示等领域场景，还需要进一步拆开来看。同一个“审核页面”并不只对应一种资产形态：页面如何分区、信息怎样排列，可以沉淀为页面模式；按钮、弹窗和状态标签可以使用稳定的基础组件；什么状态允许通过、谁能够操作、操作后如何流转，则应当沉淀为领域契约、规则和测试。

这也是资产分化真正重要的地方。未来不一定需要一个覆盖全部审核业务的巨大组件，但必须保存审核业务中不可随意改变的领域事实。AI 可以根据页面环境生成不同呈现，却不能自行改写状态、权限和风险规则。

讨论到这里，需要区分组件库和更广义的组件资产体系。组件库主要保存项目可以直接依赖和运行的组件代码；组件资产体系还包括 Design Token、状态契约、页面模式、业务规则、测试用例、兼容结论和设计决策记录。

AI 时代可能出现的变化，是传统组件库的边界收缩，同时更广义的组件资产体系扩展。低风险 UI 转向按需生成，页面级经验沉淀为模式和示例，验证成本较高的基础能力继续以稳定组件的形态存在，领域知识则更多通过契约、规则和测试独立保存。

进入公共组件库的代码可能变少，围绕组件的语义、约束和验证反而会更加完整。所谓“代码层变薄，资产体系变厚”，指的正是这种变化。

当语义、规则和验证开始从具体组件代码中分离出来，Vue、React 等技术栈的升级，也会出现新的判断方式。

AI 的确正在降低迁移中的机械成本。Vue 官方提供了 Migration Build，React 19 的官方升级指南也提供了弃用警告、Codemod 和分步迁移路径。AI 可以在这些工具之上继续完成代码扫描、调用修改、构建修复和测试补充。

但框架迁移从来不只是语法转换。假设一个 Vue 2 组件的业务规则全部藏在条件分支中，状态含义没有说明，交互行为没有测试，边界场景依赖维护者的个人经验。即使 AI 很快生成了一份 Vue 3 代码，团队仍然难以确认迁移前后的行为是否一致。

Thoughtworks 在 《Legacy Modernization meets GenAI》 中也强调，生成式 AI 的价值不仅在于产生新代码，还在于理解长期运行的复杂系统、提取底层需求和高层业务能力。遗留系统现代化真正需要保存的是业务行为和系统意图，代码转换只是其中一部分。

如果组件已经拥有明确的状态与属性契约、完整场景、行为测试和视觉基线，Vue 2 到 Vue 3 才更接近一次可验证的实现替换。此时，组件资产可以逐渐形成两个层次：相对稳定的一层保存业务语义、状态、规则、设计决策和验证证据；更容易替换的一层负责将这些内容实现在 Vue、React、RN、小程序或者其他运行时中。

这不代表框架失去价值。不同框架依然会影响运行时模型、性能、生态、基础设施和研发体验，但具体框架实现可能变得更容易替换，业务意图、组件契约和验证资产的生命周期则会相对更长。

AI 对升级决策的影响还是双向的。它可以帮助团队升级 Vue，也可以帮助新同学理解和维护旧版项目；可以批量迁移 React 代码，也可以继续在旧项目中定位问题、生成补丁和补充文档。

因此，AI 同时降低了升级旧系统和继续维护旧系统的成本。“AI 让升级更容易”无法直接推出“所有旧系统都应该升级”。是否升级仍然取决于新版本带来的实际收益、旧生态造成的阻碍、系统未来的生命周期，以及迁移后的业务行为能否得到验证。

AI 会让“因为改不动，所以不升级”越来越难成立，却不会让升级天然成为正确选择。

回到最初的问题，AI 会写组件之后，我们还需要组件库吗？

我们仍然需要组件库，但需要的未必还是过去那种不断扩张、主要依靠组件数量和代码复用率证明价值的组件库。

一部分局部 UI 会转向按需生成，一部分复杂页面会以页面模式和组合示例的形式被复用，验证成本较高的基础能力仍应沉淀为稳定组件，领域知识和业务规则则会更多地沉淀为状态模型、契约和测试。

组件库不会简单消失，它在整个前端资产体系中的位置会发生变化。运行时代码仍然重要，但不再承载全部价值；组织真正需要长期保存的内容，会逐渐从具体实现延伸到生成时必须遵循的语义、约束和验证依据。

Vue、React 等技术栈的升级也是如此。AI 降低了修改实现的成本，却没有替团队回答为什么升级、升级后能够获得什么，以及如何证明业务行为没有改变。

过去，团队建设组件库时，最常强调的是减少重复实现和提升交付效率。接下来，组件资产更重要的作用，将是减少重复决策、重复验证和重复承担风险。

未来衡量一项前端资产，不应只看它复用了多少代码，还要看它保存了多少已经形成的业务判断、组织约束和验证证据。代码生成降低的是实现成本，而这些内容决定了生成结果能否真正进入产品。

实现可以重新生成，业务意图、组织约束和验证证据不能每次从头猜。