ExplainThis 全端開發雙週報 #88 為什麼在 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 也分享目前 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 的例子：

這種寫法在社群中受到很多人喜愛，因為這種表達方式簡潔有力，人眼看過去速度很快。過去社群中就很多人提過，寫過 Tailwind CSS 後會回不去。然而，雖然從個人開發者角度看，這種寫法很不錯；但從團隊角度看，就會有一些問題。

Tailwind CSS 的一大特點就是自由度很高，所以不同的人使用 Tailwind，都能用自己偏好的方式。舉例來說，下面這三種方式在 Tailwind CSS 都是可行的，不會被擋下來。

相對來說，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 代理根據爬梳過的程式碼庫寫出以下的樣式：

這時候很可能畫面看起來是正常的，跑 TypeScript 型別檢查也沒錯，前端要建構也完全沒問題，但直到設計端驗收時，才發現圓角怪怪的，一查才知道設計系統只有 sm = 8 / md = 12 / lg = 16，但是 AI 代理卻用了 14。這種「看起來好像對，但其實有些細節不對」的結果，是多數開發團隊希望能避免的。

很多人可能會認為，只要在 AGENT.md 等檔案中註明，AI 代理就能按照設計系統去實作；然而，當今天上下文窗口被佔據越高比例，AI 代理就越可能不會按照原本系統提示詞定義地執行任務。

反過來說，如果今天是透過 StyleX 這類手段，只要有不符合設計系統定義的值出現，就能在有工具檢查下不會通過，而 AI 代理就會從報錯中知道自己用了不該用的值，並調整直到使用正確的值為止。如果能夠透過靜態分析檢查的，就務必要設置，然後把這一層防禦加到 pre-commit hook 或 CI 當中。

透過靜態分析檢查，真正重要的規則，就不只是寫在文件上，而是會有自動化的檢查，因而能夠避免「明明某個值不該出現，但最終只能透過人工方式發現」。這樣將能夠大幅降低人類工程師在做 Code Review 時的心智負擔，因為可以相對放心這些問題會被自動化檢查找出來。

閱讀更多

此篇內容為 E+ 主題文中的三分之一，如果想要閱讀完整版本，歡迎加入 E+ 會員 (連結)。除了有會員專屬的深度文與影片，探討前後端開發、AI 工程、職涯發展，同時有 Discord 社群一同交流與成長。

許多 E+ 會員透過所任職公司的教育訓練補助 (E+ 會開立有統編的發票)，也能每週透過深度主題文與社群交流，用穩扎穩打的方式拓展技術視野。

本期推薦

• 《On learning programming in an age of LLMs》一文中 (連結)，作者分享自己補足基礎的經驗，以及為什麼偏好向 AI 提出能驗證答案的問題。如果你仍拿捏不定什麼該自己學，什麼又可以直接交給 AI，推薦一讀
• Shopify 近期分享了把庫存預留系統從 Redis 搬到 MySQL 的技術文《We replaced Redis with MySQL for inventory reservations—and it scaled》 (連結)，談到過程中如何撐過購物高峰，以及分享資料設計、效能排查與逐步遷移的過程
• 《How to Write an Effective Software Design Document》一文 (連結) 解析技術設計文件的寫法，包含提供真實專案的完整範例，並分析哪些事情該先在技術設計文件中寫清楚，哪些可以留到實作時再決定
• 最近社群許多人重新轉發 Google 的經典好文《This Code is CRAP》(連結)，如果需要接手既有專案、不知道從哪裡開始補測試或重構時，可以參考這套評估方式
• OpenAI 在《Rapidly scaling online storage to serve over 1 billion ChatGPT users》中，分享儲存平台 Habitat 如何從 Python 函式庫，擴展為支援十億使用者的獨立服務 (連結)，文中有具體分享團隊如何追查背景工作、負載不均與連線管理造成的延遲，相當精彩
• 《Doing everyone else’s job》一文談到一個工程師常見困境，當自己的部分做完了，卻因為其他團隊沒空整合或補功能，讓事情一直推不動 (連結)。文章用主動協助整合、提交修改等例子，說明跨出職責範圍如何幫專案落地。非常推薦想在工作上創造影響力的人一讀
• 最近看到 JS Crossword 這款用 JavaScript 程式碼作答的填字遊戲，題目給你執行結果，你得反過來填出能產生這個結果的算式或表達式 (連結)。想挑戰自己對 JavaScript 型別轉換與古怪語法熟悉度的人，推薦一玩