从组件库到业务设计系统：一个跨六国钱包产品的一致性治理实践

一套组件库已经存在，为什么同一个钱包产品里的按钮、弹窗和操作习惯，仍然会越来越不一样？

在阿里负责钱包业务期间，我担任技术架构负责人，主导过一个跨国家、多团队的一致性保障项目。钱包产品覆盖六个国家，不同团队都在交付业务，也都在复用自己的组件。问题恰恰出在这里：局部复用已经发生，共同的业务设计系统却没有真正建立起来。

下面以实际项目回顾为主，统计口径和任务级验证的进一步建议会单独说明。

这个项目最后不只交付了组件库。我们把设计稿中的组件识别、研发中的组件准入、线上页面的覆盖检测接起来，又通过设计团队的预算、渐进迁移计划和业务指标，解决了“谁来持续维护、谁愿意安排资源”的问题。

我从中得到的判断是：组件库解决复用，一致性治理还要解决规则如何进入工作流，以及团队为什么愿意采用它。 技术工具要帮助设计师和开发者完成工作，而不是只给他们增加一个分数和一道门禁。

放大查看图表

项目方法示意。三类工具围绕同一套共享组件体系工作，覆盖率用于观察采用进展，业务与研发指标用于评估价值。

一、六个国家的产品，为什么不能只发一套组件包

当时我们看到的差异很具体：同样的按钮在不同页面中，样式与位置不统一；确认弹窗的操作排列也会变化。这些问题单独看不一定严重，但在同一个产品里反复出现，用户就需要重新判断熟悉的操作。

设计和研发并非没有组件化意识。每个人都可能有自己的组件，问题是来源不同，接口、样式和交互规则也不同。某一团队修好的问题，不一定能进入其他团队；一种成熟做法，也不一定能被其他人发现。

推动公共组件时，又会遇到很现实的阻力：

• 不知道该选什么。 有相似组件，却缺少清晰的适用范围和场景示例。
• 不敢轻易替换。 旧页面已经能用，迁移需要研发与测试时间，也可能影响业务排期。
• 不敢改公共能力。 为自己的需求改一个组件，担心影响其他使用方。
• 看不到采用收益。 设计系统团队认为应该统一，业务团队却要解释为什么现在值得投入资源。

因此，我没有把目标定成“做一套更完整的组件”。需要建立的是一条持续路径：发现不一致，提供可靠的公共能力，让它进入设计与研发流程，再观察它有没有带来实际变化。

跨国家并不意味着强迫所有业务完全相同。公共层应该稳定同类操作的约定，业务层仍要表达真实差异。如果每出现一个不同需求就复制整套组件，公共体系会失去作用；如果每个特例都塞进基础组件，又会让它越来越难维护。这是后面分层和治理共同要解决的问题。

二、从设计稿开始，让采用情况可见

设计师使用 Figma，我们就从现有工具里切入。我主导开发了一个插件，自动识别设计稿中的三类组件：全局组件、业务共享组件和私有组件，并计算共享组件覆盖率，输出 0—100 的一致性评分。

当时的关键，不是发明一个精密的“体验质量模型”，而是让过去难以讨论的采用情况变得可见。设计与研发可以指着同一份结果，讨论哪里已经使用共享能力，哪里仍然是单独实现。

计算的是覆盖元素，而不是组件数量

以一个便于理解的例子来说：页面有 100 个元素，使用了 3 个共享组件，这些组件合计覆盖 50 个元素，那么评分是：

共享组件覆盖率 = 共享组件覆盖的元素数 / 页面元素总数 × 100%
              = 50 / 100 × 100%
              = 50%

对应的 0—100 评分：50 分

这里的分子是被覆盖的 50 个元素，不是 3 个组件。这个例子用于解释算法，不是项目效果的实验样本。

同样的思路可以用于设计稿与前端页面：识别共享组件覆盖了多少元素，再观察比例变化。我们追求的不是绝对节点数量，而是在持续使用的口径下，看共享能力的采用是否相对提升。

不过，设计图层与 DOM 不是天然相同的单位。嵌套组件是否重复计算、容器与装饰元素如何纳入、统计粒度是否变化，都会影响结果。今天重看这套方法，这些都应成为进一步完善的测量说明。两端即使都输出百分比，也只有在统计口径可比时，才能进行直接比较。

分数负责找问题，不负责替代设计判断

我们把分数带进设计评审与研发交接，让设计师展示标准组件使用情况，让团队能够观察采用趋势。它提供了一种共同语言：这份稿件覆盖率偏低，究竟是公共组件缺少能力，还是已有能力没有被找到和使用？

但覆盖率只是治理代理指标。一个页面完全使用共享组件，也可能把主次操作安排得很差；一个必要的业务特例使用私有实现，也不必然是坏设计。不能把提高分数变成唯一目标，更不能用组件覆盖率宣称无障碍、交互正确性或业务效果已经得到全面验证。

Figma 的组件与实例关系提供了实现基础，相关机制可参考官方 InstanceNode 文档。真正重要的仍是组件分类与识别规则要明确，检查结果能指向具体位置，而不只是给出一个难以解释的总分。

三、最重要的一次推进，发生在组织协作里

插件做出来以后，谁负责继续维护？设计师遇到问题时，能不能及时找到一个理解他们工作方式的人？如果这两件事没有答案，工具很容易停在一次演示。

我与设计团队沟通，争取到由设计团队提供预算，在设计团队内招聘一位前端同事，继续推动这项工作并与设计师协作。在我所在组织当时的实践中，这是首次这样安排。

这件事的意义，不只是“多了一位开发者”。设计工具与组件规范有了更贴近使用者的技术投入，问题不必每次都跨越设计与研发团队的排期边界。技术同事能够围绕设计师的日常工作继续改进工具，设计团队也从使用方进一步成为共同建设者。

这也是我不把项目理解为纯前端基础设施的原因。如果设计规范只由研发单方面推行，设计稿与代码很容易各自演进；如果工具只是临时支持，持续使用中的问题又很难得到解决。把资源与协作方式一起安排好，才能让工具真正留下来。

四、我们没有重新发明 Ant Design

组件体系以 monorepo 组织，分为三层：基础组件、业务共享组件、解决方案级组合组件。基础组件包含 Button、Input、Modal 等通用能力；更高层则承接业务共性和完整场景组合。

我们的定位不是简单套壳 Ant Design，也不是把它已经解决的基础 UI 能力全部重写一遍。Ant Design 负责基础 UI 能力，我们建设其上的业务设计系统（Business Design System），负责业务规范、交互规则和组件治理。

放大查看图表

职责示意，不代表所有业务都必须穿过完全相同的封装层。分层的目的，是让共性有稳定归属，让差异留在合适的位置。

一个弹窗能显示、关闭、承载内容，是基础能力；在我们的业务里怎样表达主要操作、如何组合业务内容、团队应采用哪种约定，则需要自己的设计系统承接。若只是换一个包名导出底层组件，这些问题仍会散落在各个页面。

统一的不只是组件，也包括设计变量

我与设计团队协作，引入 Design Token 体系，覆盖颜色、字体、间距、圆角和动效参数，并通过 CSS Variables 全局注入。

这样，公共视觉约定有了集中表达的位置，不必在每个组件和页面里分别维护一套字面值。但 Token 解决的是变量与表达的一致性，并不会自动决定一个页面的信息层级。什么是主操作、危险操作该怎样强调、什么状态需要提示，仍属于设计规则与使用场景。

公共组件必须值得被依赖

为了减少业务团队的顾虑，我们同时建设了：

• TypeScript 强类型 API，明确组件的使用约定。
• 包含 API 与示例的文档、交流渠道及团队培训，降低寻找和学习成本。
• 自动化测试、版本管理和变更日志，为组件演进提供基本保障。
• ESLint 强制规则，限制非标准组件来源，并在 CI 阶段阻断违规代码。

这些措施各有职责。类型检查帮助开发者正确调用，测试检查被覆盖的行为，版本与变更记录帮助评估升级影响，准入规则防止旧入口继续无声扩散。它们不能互相替代，也不应被包装成对用户体验的自动认证。

五、有准入规则，还要有渐进迁移

一条禁止非标准组件的规则，很容易写出来；让已有业务迁过去，则需要面对真实的页面、测试资源和交付计划。

我们使用 ESLint 识别不合规组件使用，并设立渐进式迁移计划。重点是让偏离变得可发现，让替换成为有安排的工作，而不是要求所有团队立刻重写已有页面。

这里需要同时处理两个方向：新增实现不要持续制造相同的问题，存量实现又要能够按节奏消化。具体启用范围应与迁移计划匹配；不能只把全部告警变成发布阻断，然后把业务团队留下来处理没有排期的工作。

今天总结这段实践，我会用三个问题来判断一次迁移是否值得推进：

1. 替代能力是否就绪？ 公共组件能否承担原业务需求，有没有明确的使用示例与版本说明？
2. 迁移成本由谁承担？ 研发修改、测试验证和业务排期有没有被一起考虑？
3. 差异能否回流？ 遇到公共能力缺口，是完善共享组件，还是保留有理由的业务差异？

这三个问题是我对经验的归纳：组件推广需要解决实际交付条件，不能只提出“我们有规范，所以你必须改”的单向要求。

六、把线上观察与业务支持接起来

设计稿中的采用率，无法回答上线后是否真正使用了同一套能力。因此，我们又开发 Chrome 插件扫描线上页面的组件覆盖率，并通过埋点统计组件真实使用情况。

我们还应用当时最新的埋点系统，把业务指标的变化与组件使用关联起来。这一步有一个很实际的组织目标：争取产品团队的支持。

新 UI 的应用需要测试和研发资源，可能改变原来的排期。产品团队需要知道这项工作为什么值得占用交付时间，而不只是听到“前端希望统一一下”。有了采用情况和业务变化的共同观察，讨论才有机会从抽象规范转向实际价值。

放大查看图表

度量与协作回路。业务变化与组件使用可以关联观察，但关联本身不等于因果证明。

具体衡量时，我把观察分成三个层次：

最后一层不能只看转化率。例如，操作时间帮助发现流程摩擦，误操作率关注理解与操作偏差，退出率需要结合退出位置分析，满意度调查和 UX 团队统计则补充行为数据看不到的体验原因。这些是衡量维度，不表示每一项都已经取得可量化的改善。

三层观察需要放在一起：覆盖率说明治理有没有推进，工程与任务指标帮助判断推进是否值得，任何一层都不能用一个总分代替其他层。

例如，业务指标可能同时受到流量、内容或其他改版影响。即便在同一时间看到组件采用率上升、业务表现改善，也应保留这些条件，不能把所有变化都归因于组件体系。工具的价值，是让团队有材料讨论，而不是用一张图替所有取舍作决定。

七、三个月后，哪些结果可以留下

根据我对项目上线三个月后的回顾统计，取得了这些结果：

这些回顾统计未展开原始样本、统计窗口细分和对照方法；尤其“页面加载提升 5%”未进一步指定性能指标，不能替换成 LCP 或首屏时间。它们可以作为当时判断项目价值的观察结果，不宜解读为每个国家、每类页面都取得相同收益，或由组件治理单独造成的净因果效果。

对我而言，结果的意义在于它们来自不同层面：设计稿中共享能力的采用、多个团队的真实使用、设计与研发时间，以及交付代码和页面表现。只看覆盖率，我们可能得到一个越来越好看的分数；把这些观察放在一起，才更能说明为什么值得继续投入。

八、这个项目真正建立的是什么

回看整个过程，技术架构负责人的工作并没有停在选择 monorepo、写一个插件或封装组件上。

我需要把原本分散的几件事连接起来：设计团队如何识别和使用共享能力，研发团队如何相信公共组件，业务团队如何安排迁移，产品团队为什么支持相应的资源投入。Figma 插件提供可见性，业务设计系统提供可复用能力，工程规则帮助维持采用，线上观察和业务度量支撑持续决策。

如果今天再做一次，我仍会保留这条主线，但会更早明确覆盖率的统计口径，并把“采用了共享组件”和“完整任务是否好用”分开验证。视觉层级、键盘操作、异常反馈、取消与恢复等体验问题，需要在真实任务中检查，不能从组件来源推导出来。这些是进一步完善这套方法的方向。

对于准备推动类似项目的团队，我会先做三件事：选择一条确实存在重复与差异的业务路径；让设计、研发和产品共同约定可复用能力与迁移安排；同时观察采用进展和交付价值。工具可以逐步增加，但每增加一个工具，都应该说明它帮助谁作出什么判断。

一套业务设计系统能留下来，靠的是团队在日常工作里持续使用它、修正它，并从中获得价值。跨团队的一致性，也正是在这个过程中建立起来的。

延伸阅读：从前台对话到后台研究的交互设计讨论长任务中输入、调整与结果之间的关系。本文聚焦设计系统如何从公共组件走向跨团队采用与持续治理。