为什么在 AI 智能体时代，越来越多设计系统选择 StyleX？

在 2023 年，Meta 开源了内部使用的 CSS 解决方案 StyleX，在当年引来社区的一阵讨论后，StyleX 的话题沉寂了一阵子。然而，到了 2026 年，行业内越来越多公司选择把设计系统迁移到 StyleX。

举例来说，Linear 团队的**《Moving Linear from styled‑components to StyleX》与 Polar 团队的《Building an LLM safe design system》** 都通过专文分享为何他们把设计系统迁移到 StyleX。

Meta 全新打造的开源设计系统 Astryx 基于 StyleX。HubSpot 在首席前端工程师的招聘信息中，提到前端设计系统基于 StyleX 构建。Cursor 团队的工程师 Lauren 也在 Jared Palmer 的讨论串中分享，目前 Cursor 与 Grok Bot 也已全面迁移到 StyleX。

之前我们曾写过**《StyleX 是什么? 解决了什么问题? 适用在什么场景?》**一文，介绍过 StyleX 与原子 CSS 的相关概念。

在当时的社区中，比起 StyleX，Tailwind CSS 是更多团队与独立开发者的选择；然而这个风向在 2026 年开始有了转变。很多团队的新设计系统选择 StyleX，甚至前面提到的 Polar 团队，也是从 Tailwind CSS 迁移到 StyleX。

这不禁让人想问「为什么？」。

Cognition 工程副总裁 (同时也是前微软工程副总裁) Jared Palmer 在帖子中表达的观点，很好地总结了目前行业内的趋势。他提到「在用了大约十年的原子 CSS 框架，从 BuzzFeed Solid、Basscss 一直到后来的 Tailwind，我现在大概已经被说服，对 AI 智能体来说，StyleX 是更好的选择」。

他进一步解释原因：「StyleX 本身施加的各种限制，会让代码库随着规模增长，依然能维持更高的一致性与正确性」。他提到，如果是人类自己手写 (或他自己要亲手写)，他仍认为 Tailwind 带来更好的体验，但是在 AI 智能体时代，几乎不太有人还会亲手去改 CSS 或类名，因此取舍也跟以前不一样了。

让我们通过一个实际的例子来理解为什么 Jared Palmer 这么说。

以下是一个 Tailwind CSS 的例子：

<div className="flex gap-3 px-4 pt-2 bg-zinc-900 rounded-xl"></div>

这种写法在社区中受到很多人喜爱，因为这种表达方式简洁有力，读起来很快。过去社区中就有很多人提过，写过 Tailwind CSS 后就回不去了。然而，虽然从个人开发者的角度看，这种写法很不错，但从团队的角度看，就会有一些问题。

Tailwind CSS 的一大特点就是自由度很高，所以不同的人使用 Tailwind，都能用自己偏好的方式。举例来说，下面这三种方式在 Tailwind CSS 中都是可行的，不会被拦下来。

<div className="p-4" />
<div className="p-[13px]" />
<div className="bg-[#123456]" />

相对来说，StyleX 就严格许多。如果在 StyleX 中按下面这样定义，这时写了 padding: 13，搭配 StyleX ESLint 的配置，就会收到 ESLint 检查失败的报错，因为 13 不在 type Spacing = 4 | 8 | 12 | 16 当中。

const styles = stylex.create({
  card: {
    padding: spacing.medium,
    backgroundColor: colors.surface,
  },
});

type Spacing = 4 | 8 | 12 | 16;

因此，虽然在阅读速度上，人类看 Tailwind CSS 会比较快，但这个优势对于 AI 智能体来说几乎不存在。反过来，StyleX 严格的限制与检查，搭配 AI 智能体，稳定性就会远比用 Tailwind CSS 来得好。特别是从幻觉 (hallucination) 的角度来看，假如今天要 AI 智能体写一个符合公司设计系统的新卡片组件，然后 AI 智能体根据梳理过的代码库写出以下样式：

<div className="rounded-[14px] px-5 py-3 bg-[#18181b]">

这时很可能页面看起来正常，跑 TypeScript 类型检查也没错，前端构建也完全没问题，但直到设计验收时，才发现圆角怪怪的，一查才知道设计系统只有 sm = 8 / md = 12 / lg = 16，但 AI 智能体却用了 14。这种「看起来好像对，但其实有些细节不对」的结果，是多数开发团队希望避免的。

很多人可能会认为，只要在 AGENT.md 等文件中注明，AI 智能体就能按照设计系统去实现；然而，如同我们曾在《1-1 为什么你的 AI 智能体总是越做越笨? 如何解决这个问题?》提过的，当上下文窗口被占据的比例越高，AI 智能体就越可能不按照原本系统提示词定义的方式执行任务。

反过来说，如果通过 StyleX 这类手段，只要出现不符合设计系统定义的值，就无法通过工具检查，AI 智能体就能从报错中知道自己用了不该用的值，并调整直到使用正确的值。这也呼应我们在《1-4 如何打造让 AI 智能体更有效运作的代码库?》中谈过的概念：能够通过静态分析检查的，就务必设置检查，然后把这一层防御加到 pre-commit hook 或 CI 当中。

通过静态分析，真正重要的规则，就不只是写在文档上，而是有自动化的检查，从而避免「明明某个值不该出现，但最终只能靠人工发现」。这将能大幅降低工程师在做 Code Review 时的心智负担，因为可以相对放心，这些问题会被自动化检查找出来。

加入 E+ 会员方案

如果你觉得这篇分享有帮助，想阅读更深入的内容，欢迎加入 E+ 会员。除了有会员专属的深度文与影片，探讨前后端开发、AI 工程、职业发展，同时有 Discord 社群一同交流与成长。

许多 E+ 会员通过所任职公司的教育训练补助 (E+ 会开立有统编的发票)，不用花自己的钱，也能每周通过深度主题文与社群交流，拓展技术视野、加速职业成长。