很多团队做组件库失败，不是因为不会画按钮，而是没有把“要解决的痛点”说清楚。建议先把目标写成三句话：
（1）让页面搭建更快：常见模块 80% 直接拼装；（2）让视觉更一致：字号/间距/圆角/颜色有统一来源；（3）让协作更顺：设计与研发对同一套命名和状态有共识。
目标一旦明确，后面每一次“要不要做这个组件”“要不要拆更细”都会更容易判断。
组件库的地基是 Tokens（变量）。在 Figma 里，你可以先把这四类整理成清晰的层级：
颜色：建议用“语义”命名而不是“红1、红2”。例如：Color/Text/Primary、Color/Brand/Default、Color/Border/Muted。这样当品牌色调整时，你只需要替换变量，不需要全局找颜色。
字号：用 Typo/Body/14、Typo/ /20 这种结构，把字号、行高、字重做成 Text Styles，避免每个组件里单独改。
间距：常见做法是 4 或 8 作为基础单位，Spacing/4、Spacing/8、Spacing/12…在组件的 Auto Layout 里只用这些数。
圆角：Radius/4、Radius/8、Radius/12 统一约束。圆角最怕“到处都是 6”，最后没人知道为什么。
把组件拆分得过细，会让使用者在搭页面时不断“找零件”；拆分得过粗，又会导致每次复用都要改内部结构。一个更稳的原则是：
（1）优先做“高频且稳定”的基础组件：Button、Input、Select、Tag、Badge、Modal、Toast。
（2）对“变化大”的组件先做模板：比如复杂卡片、首页模块，先做可复用的布局骨架（栅格、间距、信息层级），再逐步抽出可复用子组件。
（3）任何组件如果出现 3 次以上同类需求，就考虑抽象；如果只是偶发需求，先用局部组件解决。
命名不是形式主义，它直接影响检索效率和沟通成本。推荐一个简单可执行的结构：
Component/Variant/State
例如：Button/Primary/Default、Button/Primary/Hover、Button/Primary/Disabled。Input/Filled/Focus、Input/Outlined/Error。
如果你的组件层级较多，可以再加一个“场景”或“尺寸”：Button/Primary/L、Button/Primary/S。
关键点：尽量避免“按钮1、按钮2”或“最终版、可用版”这种不可维护的命名。
Figma 的 Variants 能把同一组件的不同状态放进一个集合，使用者只需要切换属性，不需要换组件。建议把常见状态抽成属性：
（1）Type：Primary / Secondary / Text
（2）Size：S / M / L
（3）State：Default / Hover / Pressed / Disabled / Loading
（4）Icon：None / Left / Right
做 Variants 时要控制组合爆炸：优先保证高频组合可用，低频组合用“可覆盖”的方式处理（例如允许替换图标、允许改文案宽度）。
第一，组件内部尽量全部用 Auto Layout，并把 padding、gap 固定为 Tokens 的值，这样组件缩放时结构不会散。
第二，给组件设置合理的 Resizing：文本容器用 Hug contents，按钮整体在横向用 Hug 或 Fill（根据场景），这样开发对齐时也更容易理解。
一个小技巧：把“最常用”的尺寸设置为默认值，减少使用者每次插入后还要改属性。
组件库不是一次性工程。发布前建议做三件事：
（1）做一个“Quick Start”页面：列出常用组件、推荐用法、禁用用法；
（2）做一个“变更说明”页面：每次更新写清楚新增/调整/废弃；
（3）找 1-2 位同事用组件库搭一个真实页面，记录他们卡住的点，回头优化命名、属性或默认值。
只要能让团队里第二个人顺利用起来，组件库就开始进入正循环。
（1）颜色用绝对值而不是变量；（2）同一状态在不同组件里叫法不一致；（3）组件默认尺寸不符合真实业务；（4）属性过多导致使用者无从下手；（5）没有维护节奏，久了就和业务脱节。
建议每两周做一次小维护：整理新增需求、合并重复组件、更新说明文档。组件库的价值，来自持续地把“共性”沉淀下来。
