為什麼在 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 或 class 名稱，因此取捨也跟以前不一樣了。

讓我們透過一個實際的例子來理解為什麼 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+ 會開立有統編的發票)，不用花自己的錢，也能每週透過深度主題文與社群交流，拓展技術視野、加速職涯成長。