Uber 设计系统的反直觉一课：数据越多，越要相信“心”

Uber 的设计系统团队做过一个看似正确、却几乎毁掉插件体验的决定：把“自动校验”做成永远开启。数据一度看起来很美，但真正让系统进化的，是他们随后做出的那个反直觉选择。这是一堂所有 AI 从业者都该听的课。

最反直觉的失败：一个“正确”的功能，为什么被关掉了

在 Base 插件中，Uber 团队做过一个他们自己也深信不疑的功能：Auto-lint（自动校验）。逻辑听起来无懈可击——像拼写检查一样，实时告诉设计师哪些地方不符合设计系统或无障碍规范，越早发现问题，代价越小。

他们为此争论过性能、体验、时机：是立刻校验，还是操作后再校验？是扫选中节点，还是整个文件？这些问题在设计评审里都“想清楚了”。插件上线后，数据也一度支持他们：大量 lint 行为发生，没有人抱怨性能慢。

但真正的用户反馈却刺耳得多。设计师说这个功能“不自然”，打断思路；更致命的是，很多人干脆把插件关掉，让 Auto-lint 根本无法运行。最终，团队做了一个极其反直觉的决定：关掉 Auto-lint。

五周后，结果出来了：插件性能提升 80%，日活跃用户增长 50%，lint 行为翻倍，修复了 450+ 个设计问题。这个功能不是失败在技术，而是失败在对“人”的理解上。

数据曾经“背叛”他们：为什么三倍日活是个陷阱

在 Auto-lint 之前，团队已经遇到过一次数据的误导。

Base 插件来自两个老工具：Configurator（偏设计创建）和 Basify（偏设计交付与校验）。从分析面板看，Configurator 的日活是 Basify 的三倍，结论似乎很清晰：资源应该全部投向前者。

但当团队真正和 150+ 设计师聊完一轮后，故事完全变了。问题不在于 Basify 不重要，而是它根本“进不了工作流”。不同团队的设计交付流程不一致，设计阶段和交付阶段严重脱节，导致 Basify 在现实中无处安放。

这是 Uber 团队反复强调的一句话："只有数据，容易假设行为；只有‘心’，又容易带着偏见。" 他们所说的“心”，不是拍脑袋，而是 1：1 访谈、问卷、长期观察。数据告诉你发生了什么，但人才能告诉你为什么。

真正的难题不是选功能，而是选“立场”

当你有足够多的数据、访谈、工作坊产出时，真正困难的问题才出现：到底先做哪个？

Uber 的解法并不复杂，但极其克制——回到团队目标本身。对他们来说，有一个目标优先级始终高于“功能受欢迎”：让设计师在设计一开始就考虑无障碍，而不是最后补救。

这直接影响了他们的取舍：
- 不追逐 Figma 很快就会原生支持的功能
- 优先做更“Uber 特有”、能改变设计习惯的能力

Auto-lint 正是这个立场的产物。它不是为了让插件更炫，而是为了塑造一种新的设计行为。即便后来发现实现方式错了，这个方向本身并没有被否定。这也是成熟团队和功能工厂的根本区别。

当 AI 成为“系统观察者”，人该做什么

在对未来的判断上，Uber 团队并没有鼓吹“AI 会解决一切”。他们更现实，也更危险。

他们认为，随着数据越来越容易收集，设计系统维护者的角色会发生变化：从“等问题出现”变成“被系统提前提醒”。例如，算法可以在你睡觉时扫描 Figma 文件，发现第 20 个被私自造出来的组件模式，然后提醒你：也许该官方支持它了。

这类“自动化系统观察”会极大放大维护者的能力，而插件本身也会因为真实使用数据而变得更聪明。但他们同样强调：数据永远不是银弹。再强的模型，也替代不了和用户对话、以及你对系统的直觉判断。

AI 能看到模式，人要决定方向。

总结

这场分享最重要的启示，并不是某个插件或功能，而是一种决策方法论：在数据和直觉之间反复拉扯，本身就是成熟的标志。对 AI 从业者来说尤其如此——你会拥有越来越多指标、日志和模型输出，但真正的竞争力，在于你是否愿意停下来问一句：这些数字背后的人，真的在更好地工作吗？

可以从三件小事开始：和真实用户对话；给工具加上最基本的分析能力；尝试用自动化观察系统使用方式，而不是只看结果。然后不断重复：判断、试错、修正。这个过程没有银弹，但它会让你的系统——以及你自己——持续进化。

关键词： 设计系统， AI应用， 深度学习， 数据驱动， 用户体验

事实核查备注： 需要核查：1）Base 插件关闭 Auto-lint 后性能提升 80%、DAU 提升 50%、lint 行为翻倍、修复 450+ 设计问题；2）Configurator 与 Basify 日活对比为约 3 倍；3）团队规模提到 150+ 设计师；4）发布时间 2022-11-18；5）演讲来自 Figma Config，Uber 设计系统团队。