北京
过去十年里，但凡一个工程组织在成长，几乎都会收到同一条建议：建一个全公司统一的组件库。把按钮、弹窗、数据表格和表单控件放进一个带版本号的包里，每个团队就能继承一致性、无障碍支持和速度。这几乎被当成理所当然的事——复用有利于一致性和速度。
但到了2026年，这个建议值得重新审视。它曾经是好建议，只是当初让"一个共享库"成为显然选择的前提条件已经变了。当编码智能体能在很短时间内产出一个带样式、基本可用的组件时，为整个公司维护一个权威组件库所能换来的东西，已经不如从前。对很多组织来说，共享库现在没那么必要了。真正值得集中化的，是设计系统、令牌、指南和测试，而不是发布出去的组件代码。
共享库当初到底为了什么
一个共享库，总是把四个承诺打包进了同一个产物里：
- 复用——没人需要第五次写日期选择器
- 一致性——A团队的按钮、表格或表单控件和B团队的行为一致，这对一致的体验很重要
- 封装的专业知识——无障碍、键盘操作、组织特有的情况以及那些棘手的边界情况，由在意这些的人一次性解决
- 单一事实来源——品牌改一次，处处生效
这四条里，只有两条真正需要"发布出去的代码"。一致性和单一事实来源属于设计系统及其设计令牌——那些共享的颜色、字体、间距值，组件只是引用它们。而复用和封装的专业知识，才是当初支撑起整个组件包的理由，也恰恰是AI现在能帮上忙的部分。
维护才是真正的账单
搭一个库从来都费时间，无论是在冲刺零阶段做，还是当成一个专门项目来做，但共享库最贵的部分从来不是第一次发布，而是之后的十年。一旦有消费者开始用它，你就得同时支撑一堆应用，每次改动都要反复掂量。
daisyUI一篇讲抽象归属的文章里有一句话：你拥有的每一行代码，都是你要维护、测试、修复、更新的一行。这也是为什么在抽象这件事上，遵循"避免草率抽象"（AHA）这类原则是有益的——被抽象出来的代码需要维护，而维护成本往往配不上抽象带来的收益。在写代码和重写代码都比以往更便宜的时代，选择抽象什么反而更重要了。
Hacker News上一个讨论"如何推行内部UI组件库"的高赞帖子里，有人建议干脆别做组件库。他说自己所在的公司已经是第二次尝试推行了。他的原话大意是：内部UI组件库的产出和维护都很贵，比一般的增删改查应用复杂得多，需要既有能力又守纪律的人才能真正做成，因为你得往未来想好几年，而且人员流动要尽可能小。
当采用范围从一个产品团队扩散到其他团队，归属就变得棘手：维护者被拉去做别的交付工作，消费者之间优先级打架，团队明明只需要两三个变体，最后却做出了每一种变体。你不得不把组件库当成一个完整项目来运营——有需求池、有对齐会、有规划。这些都是开销，是首次发布之后还要交很多年的税。
Griffiths Waite在多团队的大型环境里跑共享库时，亲身经历过这些问题。库被广泛采用之后，依赖管理变成走钢丝：要让多个版本的组件保持对齐，否则单一事实来源会随着团队漂移到不同版本而悄悄碎裂。当共享组件包裹了特定的第三方库，升级推送就变得困难，升或换这些依赖很难理清，每个消费者都得同步迁移，而不能按自己的节奏来。哪怕是一个善意的改动，也可能波及每一个使用方，于是版本管理和沟通的重要性不亚于代码本身，而一个组件积累的变体往往超过任何单个消费者的需要。整个共享库只有在清晰、持续的归属下才能保持健康，而这恰恰是维护者被拉去别的交付工作时最先流失的东西。
这种持续归属并不意味着共享库没有价值。一个全公司范围的库，本质上是一个有路线图、有支持负担、有废弃策略、有团队的产品。
该集中的是设计系统，不是组件代码
所以结论不是"拆掉一切"。设计系统、令牌、指南和测试应该保持中心化——它们才是真正买来一致性的东西。重新生成的代码在信任之前必须经过验证，视觉回归测试、无障碍测试、令牌一致性测试就是干这个的。
还有一个容易被忽略的点：如果放任模型用默认状态，它们会收敛到一个平庸的平均值。这恰恰是有主张的设计系统成为差异化优势的原因。另外，无障碍、真正复杂的控件、跨团队的功能一致性，仍然是保留一部分精心维护的共享代码的好理由。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
