AI 时代,如何在作品集里展现组件库项目?

很多设计师一听到「组件库项目」，第一反应是：这是不是太偏执行了？

尤其现在 AI 已经可以快速生成页面、出原型、写代码，组件库这种项目会不会显得更弱？

我的判断刚好相反：

AI 时代，组件库项目反而更重要了。

因为 AI 能帮你快速搭页面，但前提是：你得先告诉它，什么是对的。

如果没有清晰的组件、规则、Token、设计规范，AI 生成得越快，错得也越快。

它可能看起来很炫，但不符合品牌，不符合系统，也不符合真实业务。

所以，组件库项目不是「我整理了一堆按钮和表单」。

它真正要展现的是：你有没有能力定义一个系统。

一个好的组件库项目，在作品集里至少要讲清楚三件事。

第一，为什么要做？

不要一上来就说「我负责搭建 Figma 组件库」。

这句话太轻了。

你要先讲问题。

比如：

原来的组件库不统一，不同团队各做各的页面，导致页面风格混乱；

设计师需要反复 review 别的团队的页面；

开发调用组件时经常要改代码；品牌升级后，原有颜色也无法覆盖真实界面场景。

这时候，组件库就不是一个「整理规范」的活了。

它变成了一个解决团队效率、设计一致性和开发协作的问题。

你的叙事可以变成：

「为了解决内部设计不统一、组件使用不规范、开发协作效率低的问题，我参与升级了设计系统，通过颜色体系、组件定义、使用规范和内部推广，提升团队交付效率和产品一致性。」

这句话的含金量，就比「我做了组件库」高很多。

第二，你如何定义系统？

组件库项目最怕写成流水账：

• 我做了颜色。

• 我做了按钮。

• 我做了表单。

• 我做了文档。

这不是作品集，这是工作记录😂

真正有价值的表达，是展示你的判断过程

比如颜色体系，不是说「我整理了一套色板」。

而是：

品牌方只给了少量品牌色，但真实 UI 场景需要覆盖字体、状态、图表、浅色模式、深色模式等更多情况。所以我先基于品牌色生成不同明度的色阶，再结合金融产品气质筛掉不合适的颜色，最后根据真实界面场景收敛出一套可维护、可开发实现的颜色系统。

这里面有一个很关键的判断：

不是颜色越多越好，而是先生成足够多的可能性，再收敛成更准确、更好用的系统。

组件定义也一样。

你可以用双钻模型来讲：

先从真实业务页面里发散，看看系统到底需要哪些组件；再收敛出组件分类。

然后研究 Ant Design、Material Design等成熟组件库，看它们如何定义组件

最后结合自己产品的真实场景，定义组件的属性、状态、使用规则和边界。

这样一写，面试官看到的就不是「你会画组件」。

而是：你会从混乱中建立秩序。

第三，结果怎么证明？

组件库项目不能只展示漂亮的规范页。

你要证明它真的让团队变好了。

比如：

• 组件使用错误减少了；

• 页面 review 次数减少了；

• 设计师搭建页面更快了；

• 开发调用组件更顺了；

• 颜色 Token 让后续维护更简单了

如果没有特别精确的数据，也可以用保守表达：

• 「减少重复 review 成本」

• 「降低设计与开发沟通成本」

• 「提升组件调用准确率」

• 「让组件库从一次性建设变成可持续维护的系统」

这比空泛地写「提升用户体验」要可信得多。

最后，回到 AI。

AI 时代，设计师的价值确实变了。

单纯画页面的价值会下降。

但能定义规则、建立系统、理解业务、连接设计和开发的人，会更重要。

因为未来很多页面，可能真的会由 AI 生成。

但 AI 用什么组件？遵循什么规范？颜色 Token 怎么映射？哪些场景该用哪个组件？什么时候不能乱生成？

这些都需要设计师来定义。

所以，组件库项目在作品集里不是弱项目。

它真正证明的是：

你不是只会做一个页面的人。

你是能定义一套系统，让团队和 AI 都能更高效工作的人。

以上是帮我的 Dream Offer 学员，梳理了组件库项目后，输出的经验总结

她原来觉得这个项目「很头大」，因为感觉项目很乱，又不知道自己的价值在哪里

梳理完，学员恍然大悟：原来组件库不仅仅是一次梳理，更是在帮团队真正的降本增效。

如果你也做了很多项目，但是不知道该如何展现自己的价值，不知道如何让作品集包含UX能力，可以找我聊聊

··········  学交互 找沐风 ··········