Presentation: Building and Scaling UI Systems for Internal Tools at Meta

在 Meta 构建和扩展内部工具的 UI 系统 - InfoQ

InfoQ 首页 演讲 在 Meta 构建和扩展内部工具的 UI 系统

Web 开发

QCon 旧金山（11 月 16-20 日）：深入的技术会议。改变你思维方式的同行对话。

在 Meta 构建和扩展内部工具的 UI 系统

Like

新下拉阅读列表

• 阅读列表

查看演讲

• 垂直

• 水平

• 全屏

速度：

• 1x

• 1.25x

• 1.5x

• 2x

33:53

摘要

Cindy Zhang 讨论了 XDS 的演变，这是一个统一的 UI 系统，为 Meta 的 10,000 多个内部工具提供支持。她分享了架构师和工程领导者在管理大规模社区贡献、使用 JS AST 和 AI codemods 执行安全的 monorepo 重构、通过功能标志缓解破坏性更改，以及将 UI 库扩展为全栈平台系统的可行见解。

个人简介

Cindy Zhang 是 Meta 的前端工程师，负责内部工具基础设施和设计系统。她专注于构建可扩展的用户界面和基础设施工具，以帮助 Meta 的工程团队更高效地工作。Cindy 热衷于提供高影响力的解决方案，并与跨团队合作，推动开发者体验的创新。

关于会议

软件正在改变世界。QCon 旧金山通过促进知识和创新在开发者社区中的传播，推动软件开发。作为以实践者为主导的会议，QCon 专为技术团队负责人、架构师、工程总监和项目经理设计，他们影响着团队中的创新。

演讲稿

Cindy Zhang：欢迎来到在 Meta 构建和扩展内部工具的 UI 系统。我叫 Cindy，是 Meta 的前端工程师，隶属于内部工具产品平台团队。六年前，Meta 的内部工具看起来是这样的。它们是建立在现有的网络基础设施和当时为 Facebook 所设计的组件之上，但在表格和搜索、密度以及你可能在社交媒体应用中找不到但在工具应用中可能看到的常见布局模式等复杂组件方面还有许多不足之处。你也可以看出它们看起来相当过时。现在，我们的内部工具看起来是这样的。我们有一个共享的组件系统和库，提供更现代的外观和感觉。我们还支持在工具中找到的更复杂的组件和模式。这是 Meta 内部工具团队以及我们团队的辛勤工作的结果。我们在 Meta 构建了名为 XDS 的内部工具组件库。

XDS 代表跨设计系统，表达了我们希望在 Meta 的所有组织中开展工作的意图，并为构建内部工具产品体验提供统一的解决方案。我们的旅程始于少数几个人的基层努力，他们只是真的希望改善公司在工具方面的运作方式。我们希望提高构建工具的效率，提供更好和更一致的用户体验。我们希望我们的工具在处理公司独特的和多样化的运营需求方面达到最佳水平。

除了设计系统，我的团队现在还支持整个内部工具产品平台，包括路由基础设施、工具管理和可观测性，以及用于构建通用模式的后端系统。以下是一些数据，供你参考。目前，我们有超过10,000个内部工具和页面，支持Meta的所有员工。每半年，有数千名工程师来自超过100个组织，为内部工具的编写做出贡献。内部工具的更新占我们网页代码库总量的50%。超过95%的所有产品团队都在使用我们的组件来构建他们的内部工具。我们的平台由大约10名工程师维护，他们在这个规模下支持所有这些工具和构建者。

大纲

这次演讲是关于我和我的团队如何走到今天的故事。它讲述的是我们如何构建了一个基层框架，这个框架最终被整个公司使用，以及在这个过程中我们所面临的挑战和学到的经验教训。这次演讲的目标是向你展示我们的旅程，并给你一些启示，告诉你如何让一个大型公司采纳你的基层框架。我会将这次演讲分成几个部分，我们会讨论在这一过程中我们遇到的主要挑战以及我们是如何克服它们的。

1. 初步起步

首先，我们将讨论我们是如何起步的。在开始之前，了解你所处的环境和其中的机会是很有帮助的。这是当时我们对Meta内部环境的评估。Meta有一个内部的黑客文化。我们看到很多内部工具是在实习、黑客马拉松中构建的，或者如果有人真的想以某种方式改进他们的工作流程，他们可能会为这个目的创建一个工具。任何工程师都可以在几乎没有限制的情况下构建内部工具。我们还有一个单一仓库，这使得分发变得容易得多。Meta的内部工具大部分是内部构建的，我们很少购买SaaS解决方案。这为我们提供了一个巨大的机会，帮助工具构建一个更加互联、更加符合我们运营需求的用户旅程。当我第一次加入这家公司时，我也在内部工具团队工作，我们需要一遍又一遍地重新制作相同的组件。

事实证明，这是一个在公司多个组件和内部团队中都存在的挑战。这些团队分布在公司各处，因此他们对彼此的工作内容并没有很好的可见性。这为我们提供了一个机会，可以将这些努力集中起来，减少重复。我们还研究了现有的解决方案。当时有一个被广泛使用的组件库，但这些组件也与我们的外部产品共享。这意味着如果我们需要为一个内部特定的用例进行更改，对这些组件进行更新会带来很多风险。工具构建者希望能够快速创建和启动工具。他们希望能够在风险极低的情况下进行实验和迭代。当前的系统无法满足这些需求。鉴于这些条件，我们可以设想出一个理想的内部工具系统的场景。我们希望帮助Meta构建定制化、互联的工具，这些工具能够适应运营需求。

一个理想的系统应该能够帮助集中所有工具及其专业技能的各种碎片化努力。它应该与我们的外部系统分开，以降低对这些系统的风险，并专门用于工具需求。它还应该融入我们现有的内部工具文化，即快速行动和快速开发。一旦你评估了你独特的处境，你也可以推导出适合你所在领域的理想解决方案的特性。

这是我们第一个组件，即令牌。在我们开始XDS之前，还有另一个内部设计系统的创建项目，但它失败了。失败的原因是它从未走出设计阶段，花费了太多时间试图打造一个完美的设计和流程。当时有两名工程师和四名设计师兼职参与这个项目，他们只完成了初始系统的半部分，并制作了超过100个组件。不要过于纠结于创建一个完美的系统，而是直接去做。作为我们采用策略的一部分，我们确保在第一阶段解决几个难题，并使工作可见。例如，我们升级了一个名为PowerSearch的复杂筛选组件，使其使用XDS，并在此过程中改进了可访问性和可用性。这个组件被数百个工具使用，构建者并不希望重复这项工作并维护一个新组件，因此，一旦我们完成迁移，这些工具立即开始运行XDS的一部分。

我们还解决了许多工具中常见的新功能。例如，一个基于上下文的表单系统，它有助于管理表单状态。我们还添加了一些工具之前没有的功能。这些是全新的功能，例如支持深色模式和主题。当你构建一个系统时，你也需要使你的工作可见，因此我们选择在我们团队拥有的一个工具上进行试点，并确保它在XDS中完全运行。这个工具叫做Butterfly，公司使用它来创建“如果这样，那么那样”的工作流，并且它包含了许多表单字段，每月有数千名用户。通过迁移这个现有界面，我们能够立即使工作成果可见。你可以在一个足够复杂的工具上进行试点，这样我们才能启动系统并确保合理完成。

以下是我们如何开始的一般总结。寻找一个合适的时机引入一个系统。确保在第一阶段解决一些难题。专注于为你的领域带来价值。通过在使用率高的产品上进行试点，使你的工作可见。最后，不要过于纠结于追求完美，而是直接完成它。

2. 让每个人都能使用

现在我们已经启动了一个系统，如何扩展它并让它在整个公司中发挥作用？以下是我们的组件系统多年来的发展增长图。在XDS之前，我们使用的组件系统叫做FDS。猜猜我们花了多长时间才超过旧系统？有人猜了吗？两年？六个月？你的公司愿意让你在一个框架上工作多久，直到它超过这条线？六个月。我们花了两年时间，所以你们大多数人的猜测都相当准确。你可以看到，从使用情况来看，旧系统在大部分时间里保持相对平稳。一个策略是，你可以针对那些投入大量精力和努力的新用例进行目标定位。在你使系统跨过这个转折点之前，你需要持续支持系统。如果你只有六个月的时间线，尝试找到一种方法来延长它。

如今，XDS 在 Meta 的代码库中已有超过 100 万个导入。这种增长令人欣喜，但也带来了一些扩展方面的挑战。以下是其中的三个挑战。首先，每个人都需要对系统进行更新以满足各自产品的需求。我们不希望我们的团队成为这些团队的瓶颈。其次，如果我们的组件被广泛使用，我们所做的任何视觉或行为上的更新都可能影响到多个工具。我们需要找到一种安全的方式来处理这些更新。最后，我们并不总是能一开始就设计出完美的 API。我们需要能够在整个代码库中进行调整。我们的组件可能被使用数千次，而且我们使用的是单体仓库。我们如何一次性更新所有内容？

为了解决庞大的用户群体问题，我们首先做的一件事就是建立了一个社区模型，并鼓励社区成员积极参与其中。这是我们为社区提供的一个价值主张。我们确保这个模型能够让贡献者得到适当的奖励和认可。每半个季度，我们都会在一篇汇总文章中列出表现突出的贡献者。这给我们带来了不少好处。一个显而易见的好处是，系统中可以完成工作，而这些工作对做出贡献的团队来说立即就有用。另一个好处是，我们可以实现双向的情境共享。系统团队可以持续了解产品团队正在做什么以及他们最感兴趣的内容，而产品团队则可以了解系统是如何发展以满足他们的需求。这有助于两个团队之间建立信任。最后，这还可以作为招聘工具。我们团队中的许多现任成员之前也曾是系统的贡献者。

这是我们贡献模型的一个片段。起初，我们的模型非常简单，只需将更改发送给我们，我们会对其进行审核。但最终，我们的流程扩展到了能够容纳多种类型的贡献者和请求。我们有一些框架团队希望更紧密地合作，共同进行更新，但我们也有产品团队试图承担超出他们能力范围的任务，实际上他们可以从我们团队的额外协调和资源支持中受益。我们需要为不同类型的贡献设定一些明确的期望和限制。这是最终的结果。社区贡献占我们系统中提交的代码量的一半以上，这实际上使我们的团队规模翻了一番。然而，拥有一个社区并不是免费的，你需要能够管理大量的贡献。我们实现这一点的方式是，我们努力以一种能够促进贡献的方式构建和管理系统。每半个季度，我们都在支持超过 150 位个人尝试将自己的更改引入系统，他们每周共同提交大约 45 个更改集，供我们的团队进行审核。

为了应对这一规模，我们利用了自动化系统。还记得我们之前在试点项目中更新的那款工具吗？这是一款“如果这样，那么那样”的自动化工具，我们用它来设置规则，帮助我们管理社区。以下是一些简单的规则，主要围绕确保我们的团队能够看到系统中所做的每一项更改，并确保这些更改的质量。我们还建立了一套结构化的支持表单，因为我们发现许多支持请求缺乏适当的上下文，需要团队之间来回沟通很多次。这帮助我们优化了支持和贡献的接收流程。我们还开发了一个代理程序，帮助我们突出显示贡献，用于演示和中期总结文章。我需要大约一周的时间来收集所有贡献，阅读更改内容，统计数据，并撰写这些文章的摘要，我们真的希望可以庆祝我们的贡献者。这大大减少了庆祝社区成就所需的人力。

最后，作为贡献者，学习一个庞大而复杂的代码库可能非常困难。为了使我们的贡献者更容易上手，我们编写了API指导和系统中组件的标准。我们还花时间思考我们的组件应该如何启用某些行为或修改，以及最低要求应该是什么，以确保我们的贡献指导清晰明确。其中一些API指导由Lint规则辅助，因此贡献者甚至不需要去查找它们。它们会直接出现在代码编辑器中。自定义ESLint规则是帮助你管理大规模贡献的一种很好的方式，也有助于新成员学习你的代码库。ESLint还提供了如何编写这些规则的教程。

我们现在已经处理了社区的反馈，那么我们如何在如此大规模和高频率的更改下实际进行更改而不破坏现有功能呢？只是提醒一下，我们正在处理超过10,000个不同的界面。我们有一个单一仓库，其中只运行我们系统的最新版本。我们实际上无法手动检查我们所做的更改是否在所有地方都是安全的，尤其是我们从贡献者和团队那里以如此高的频率进行更改。作为基准，我们为所有组件都提供了全面的示例，可以在隔离环境中手动评估。我们还使用一个名为“End-to-End”的内部端到端测试框架，为每个示例生成截图测试。此外，一些交互式组件的行为会通过一组无障碍规范测试进行测试。这些手动检查和测试是我们系统更改的预期测试计划的一部分。

并非所有更改都可以通过测试来捕获，有时在代码审查过程中必须依靠良好的判断力。我们来玩个小游戏。将 1,000 个 CSS 变量声明添加到一个 div 中，这是否具有风险？你们觉得呢？不觉得有风险？对于这个例子，事实证明它确实引发了一个事件。在某个工具中，包含这些变量导致 Chrome 的内存消耗速度比正常情况更快，从而导致浏览器崩溃次数增加。有时，判断你所进行的更改是否会严重破坏现有功能真的非常困难。为了应对可能出现的问题，我们也会在进行较大更改时加入一些缓解措施。在内部，我们有一个名为 Gatekeeper 的系统，这与 A/B 测试框架类似。我们使用它来通过针对不同用户组逐步推出功能。我们还可以在出现问题时，通过它快速关闭某些功能。最后，没有什么比运用良好的判断力和依靠经验来准确评估风险更有效了。

我们的代码中有数百万个调用，有时我们需要对组件进行 API 更新。我们使用的是单体仓库，因此所有内容都使用同一个版本。我们是如何管理这种更新的？我将向你们讲述一次我们需要进行大规模代码转换的经历。大约在 2021 年，无障碍团队向我们反映，内部工具中使用了太多标题。我们查看后发现，很多地方都在使用我们的标题来强调文本。这是因为 XDS 文本组件只提供了这些类型。由于较小的标题样式看起来与加粗文本非常相似，人们开始使用它们来添加强调效果。结果，这污染了页面上的地标元素，使使用辅助技术的用户更难导航。我们需要解决这个问题，但不能只在个别地方解决。我们需要清理代码库中的地标元素，同时还需要改变人们在未来产品代码中使用 XDS 文本类型的方式。

我们决定将常规文本与标题分开，以促使构建者在添加地标时更加谨慎，并为他们提供更贴近其实际使用意图的文本类型变体。下面是代码中的实现方式。这个新版本很好，但我们需要想办法将旧的 XDS 文本类型迁移到新的类型上。XDS 文本恰好是我们系统中使用最频繁的组件，因此每天都有新的调用被添加到代码库中。我们能做的一件事是弃用当前的 XDS 文本，但我们真的不希望对这样一个使用频率如此高的组件这样做，因为这会导致代码库中出现大量弃用标志。那我们还能做些什么？在不进行任何更改的情况下，我们可以添加新的标题组件和我们想要支持的新类型。现在新类型已经准备就绪，我们就可以开始进行代码转换了。

这是一个允许你编写脚本来更新代码库中代码的过程。这是我们为 XDS 文本到 XDS 标题或其他 XDS 文本类型所应用的映射。它还解决了页面上标题过多的原始问题，通过将较小的标题重新转换为文本，未来添加的标题也将更加谨慎和有意图。

以下是 codemod 的样子。这里的迁移类做了大量的工作，但你可以了解到如何通过 JS AST 来转换组件的属性。我还有一些我们编写过的其他 codemod 示例，帮助我们管理代码库和更新 API。我们用它来处理诸如属性转换、管理组件的实验性生命周期，以及将旧组件迁移到 XDS 等任务。如果你有兴趣构建 codemod，有一些开源项目可以帮助你创建它们。jscodeshift 是创建 codemod 的主要库。我最喜欢的是使用 ESLint 的修复器，因为它们还可以作为 lint 规则，因此你可以在更新现有用法的同时，也能发现新的用法并遏制其扩散。最后，你可以使用 AST Explorer 来在编写 codemod 时检查 JS AST。

不过，随着 AI 工具的出现，我们还可以利用大语言模型（LLMs）来帮助大规模管理大型代码库。与依赖 JS AST 的静态分析来推断上下文的传统 codemod 相比，AI codemod 可以跨多个文件进行操作，读取并理解这些文件中的上下文和意图。因此，它们不需要那么多静态分析。你可以用它们实现更复杂的迁移。它们也相对容易编写。然而，它们的缺点是非确定性，因此在审查时需要格外小心。最后，有时通过设计可扩展的 API，你可以主动避免需要 codemod、迁移或弃用。以下是一些我们随着时间积累下来发现有用的策略。如果你有一个具有大量可选功能的组件，可以考虑将这些功能进行分组，并创建帮助器来帮助你控制 API 签名。此外，如果你的组件中的某个功能本质上不是布尔值，可以考虑避免使用布尔标志。相反，你可以创建一个变体枚举，这将允许你以后扩展到更多的使用场景和版本。

这是我们管理规模时发现效果良好的一些策略的快速回顾。利用你的社区力量，帮助他们自助解决问题。你可以设置项目、lint 规则和自动化，以帮助你管理这些输入。为你的组件使用示例、截图和行为测试。此外，寻找方法来设置“关闭开关”以缓解潜在的风险。最后，如果你在管理一个大型代码库，你应该投入学习如何编写 codemod，并考虑更全面地进行设计。

3. 创建一个稳定的团队

在你的项目发展的某个阶段，你将需要从基层、分布式的努力转向一个更加集中、稳定的团队。2023 年 4 月，Meta 正在经历大规模裁员，尽管我们的工程团队幸免于难，但后来我们收到了一条消息，说我们的项目被取消了。这对我们来说是个巨大的冲击，因为当时 XDS 正在获得越来越多的采用和影响力。为什么会发生这种情况？如果你回顾我们到目前为止的策略，大部分对我们的工作可见性都集中在构建者本身以及他们的直接经理身上。所有直接参与构建工具的人都熟悉我们，但这并不等同于在高层管理中获得可见性，他们甚至可能根本不知道这个基层项目。这种模式带来了我们之前未曾考虑过的组织风险。

被取消迫使我们思考其他模型，以保持系统的稳定性和可维护性。正是在那时，我们开发了委员会。这是一个我们邀请公司内部贡献者组成的虚拟团队。委员会帮助我们确保系统可以持续维护，并随着时间的推移保留上下文，从而在类似这样的时刻拥有更高的稳定性。最终，我们成功地在一家新组织中找到了新的归属，因此我们得以复兴核心团队。在组建自己的团队时，请确保你有来自领导层的向上可见性和支持，或者寻找一个致力于你成功的领域。一个大型的分布式系统在公司内部有众多潜在的归属，因此你很可能可以与领导者沟通，看看谁可能希望帮助支持这一领域。组织结构至关重要，建立稳定的结构有助于保持我们平台的长期稳定性和可靠性。

4. 避免停滞

到目前为止，我们的设计系统已经达到了采用的饱和点。我们能够处理扩展挑战，并拥有一个稳定的团队。那么，如何在成熟系统中继续找到有趣的事情来做呢？与停滞作斗争是我们接下来面临的最大挑战。现在我们有了一个成熟的系统，很容易陷入面向内部的维护工作，或者追逐组件的长尾问题。我们是否可以重新激发我们最初起步时的活力呢？事实上，我们可以在这里应用同样的策略，但这一次，我们拥有更大的杠杆，即社区的影响力。我们联系了我们的社区，并提出了一个一般性问题：在构建内部工具时，你们最大的挑战是什么？我们收到了关于需要解决的最大问题的反馈。结果发现，最重要的主题并不是关于设计或使用我们的组件，而是将UI组件与后端和周围平台连接起来。

构建者认为这太困难和复杂了，尤其是在路由和预加载方面。他们还对提高工具性能感兴趣，但缺乏观察和调试这些问题的能力。我们如何注入系统来从根本上解决这些问题呢？我们重新审视了我们创建统一解决方案的使命，现在我们正以与设计系统相同的方式，致力于统一整个平台。我们正在复兴旧的基础设施，整合并连接不同的部分，同时利用系统的影响力来保持势头。作为集中工具平台的一部分，我们做的第一件事之一就是将工具作为一等公民。我们利用对代码库的了解和丰富的代码转换经验，将每个工具都迁移到该平台上。这使我们能够将中央数据源连接到工具，并提供诸如这些功能，从而实现更好的可观测性和工具管理。

我们能够与公司内部各个平台和工具团队合作，交付集成的功能并推动项目进展。我们还创建了UI组件的模式和组合方式。这些都是我们所见到的常见页面类型的布局。我们不仅仅停留在构建模板或制作组件上，我们还确保这些页面能够与我们的后端和路由系统端到端地协同工作，以解决复杂的问题。有时，你的工作会与新兴技术交叉，这使得这个领域始终保持趣味性。我们现在看到越来越多的代码是由AI编写的。目前的编码大语言模型（LLMs）在构建UI方面已经做得相当不错。然而，它们需要被教导如何在特定的环境中构建，例如Meta的内部工具生态系统。我们正在投资于教导这些AI如何构建内部工具，并提升它们的上下文理解能力。我们发现的一个有效策略是生成模板以引导AI，然后在此基础上进行修改。这项工作与我们之前在模式和后端系统方面的工作很好地契合。这里还有很多工作要做，但我已经看到设计师和非技术人员成功地生成了工具。

如果你正在寻找解决系统停滞的方法，可以问自己以下几个问题。花些时间重新连接你的使命和社区，以找到机会。然后看看你的平台是如何在构建者流程中与其他部分端到端地连接的，以及这些连接带来了哪些结果。接下来，你需要为你的空间如何长期发展以解决这些问题设定一个愿景，并思考如何利用或更新系统以实现这一目标。你如何让你的公司使用你基层的框架？我们与社区一起构建，并在良性循环中合作。我们的工作使他们能够构建工具，而他们构建的工具又使我们能够构建更好的平台。我们持续创造机会并相互支持。归根结底，你写的任何代码或设计都可能来去匆匆，但你建立的文化会留下来，这才是你真正的影响。

问答环节

参与者1：我很好奇，当你们将职责范围扩展到可观测性和其他领域时，是否遇到了诸如竞争性的基层努力或已有团队正在从事类似工作的现象？如果是，你们是如何与他们合作并确保不出现碎片化或重复工作的？

Cindy Zhang：我认为对我们团队来说，有趣的一点是我们已经在构建一些平台组件，而很多工具都依赖于这些组件，还有其他团队也对这个领域感兴趣。我们启动这项工作的方法也是与这些团队进行合作。我们被公司另一部分的一个独立组织联系，我们共同制定了这一新倡议的职责和合作意愿。这也促成了两个团队之间的相互支持，之后摩擦就减少了。

参与者2：你提到Meta使用了他们的单一仓库（monorepo），你们能够看到这些常用工具的所有使用情况，并强制更新它们。如果你没有这样的条件，你有什么建议或想法吗？你在构建这个设计系统，但你不知道其他人在哪里使用它。他们可能以一种非常奇怪的方式使用它，而你无法看到他们的代码，但你需要对某个特定内容进行破坏性变更。你如何推动这次迁移？

Cindy Zhang：这听起来非常具有挑战性。我认为大多数开源系统都是通过语义版本控制（semver）等方式来处理的，但你很难轻易保证这些内容真的会被更新。这些人甚至在你们公司吗？

参与者2：是的，假设他们在你们公司。

Cindy Zhang：如果他们在你们公司，你总是可以与这些团队进行沟通，这始终是一个选择，但如果没有良好的方式来观察他们的使用情况，要发现他们可能会有些挑战。你可能至少需要找到一种方式进行观察。我自己并没有遇到这个问题，所以无法告诉你在那里可能有哪些选择，但如果你能够找到这些使用场景，它们对你来说会容易得多。

查看更多带字幕的演讲

录制时间：

2026年6月11日

由

- Cindy Zhang

#### 相关赞助商

#### 本内容属于Web开发主题

##### 相关主题：

- 文化与方法

- QCon旧金山2025

- 字幕

- 前端

- 工件与工具

- QCon软件开发大会

- 案例研究

- Web开发

- InfoQ

- 相关编辑

- InfoQ上最受欢迎的内容 Netflix如何实时映射数千个微服务 AWS发布下一代Amazon OpenSearch Serverless OpenAI如何为Codex代理构建安全的Windows沙盒 从MCP和Vibe编码到Harness工程：AI原生工程在一年内是如何演变的 Terraform 1.15在动态源和弃用方面缩小了与OpenTofu之间的差距 Cloudflare识别出ClickHouse中的查询规划瓶颈