從 CSS 演變史看 AI 時代：框架還需要解決什麼？

假設你請 AI 製作一組產品卡片。第一版有圖片、價格、購買按鈕，桌面上排成三欄，手機上變成一欄。接著，設計師要求更換品牌色，同一張卡片也要放進側欄，原有的鍵盤焦點與售罄狀態必須保留。

第二次修改開始暴露問題：哪些藍色代表品牌，哪些代表資訊提示？卡片該依視窗還是所在容器改變版型？AI 調整按鈕時，有沒有一併改掉其他頁面的互動狀態？

以下沿用這個假設案例。我想討論的是：當 AI 降低部分樣式實作成本，框架還能替我們降低哪些修改、驗證與協作成本？ 回顧 CSS 的演變，能幫助我們辨認工具真正承擔的責任，也讓對未來的預測有可檢查的依據。

CSS 的起點，就包含了控制權的分配

1994 年，Håkon Wium Lie 提出 CSS，Bert Bos 隨後參與；CSS1 在 1996 年成為 W3C Recommendation，CSS2 則在 1998 年接續發布。CSS 的關鍵設計包含 cascade：作者、使用者與瀏覽器的呈現需求，需要在同一套規則中協調。W3C 歷史回顧

這個起點值得放回今天的討論。樣式表可以表達作者的意圖，最終呈現仍受可用空間、字型與使用者設定影響。把畫面寫成宣告，並不代表每一個像素都能由作者單方面決定。

早期瀏覽器對標準的實作也不一致。寫下合法 CSS，和不同瀏覽器得到可接受的結果，是兩件事。團隊累積的相容性知識因而成為工具價值的一部分：把反覆遇到的差異收在共同做法裡，使用者便不必每次重新處理。

後來，頁面要適應更多尺寸。Ethan Marcotte 在 2010 年提出的響應式網頁設計，把流動網格、可伸縮圖片與 media queries 組合成一種工作方式。它要求設計師描述版面如何隨條件變化，也讓斷點與佈局規則成為團隊需要共同維護的資產。原始文章、出版日期回顧

從這裡看，CSS 的困難一直包含兩部分：瀏覽器如何解讀規則，以及人如何組織規則。前者進步，後者不會自動完成。

工具長出來，是因為團隊需要共同的做法

網站規模增加後，問題逐漸轉向重複、命名與變更範圍。Sass 讓變數、mixin、模組與運算在建置時整理成 CSS；團隊可以把品牌設定與共用規則集中管理。它增加了一個編譯步驟，也提供了原始碼的組織能力。Sass 指南

Bootstrap 則把選擇推進到介面層。它在 Twitter 內部作為樣式指南使用，於 2011 年公開發布；後續版本逐步納入響應式設計、Flexbox 與自訂屬性。採用這類框架，也是在採用一組既有元件與預設，減少各個頁面重新決定按鈕、表單與網格的工作。Bootstrap 歷史

另一條路線聚焦樣式的歸屬。BEM 用 block、element、modifier 的命名約定表達結構與變體；CSS Modules 則預設將 class 與動畫名稱局部化，透過匯入建立依賴。前者仰賴共同紀律，後者讓建置工具協助避免名稱碰撞。兩者都需要團隊繼續判斷：哪些規則應該共用，哪些應該留在元件內。

元件化也帶來了 CSS-in-JS。以 styled-components 為例，樣式可以靠近元件，並依 props 改變；但這個大類並不只有一種執行模型。vanilla-extract 用 TypeScript 描述樣式，在建置時輸出靜態 CSS。評估時應分別檢查撰寫介面、產物與執行時機，不能把所有方案的成本算在一起。

utility-first 又把組合位置移到 markup。以 Tailwind 的做法來說，開發者組合小型 class、狀態變體與設計尺度，能在使用處看見樣式選擇。重複組合仍需要整理，語意也仍可能由上層元件承擔。

把這些路線放回時間軸，可以看見責任如何逐漸擴大。下表是脈絡整理；同一時期的工具可以搭配使用。

這段歷史對 AI 的啟示是：寫字速度只占工具價值的一部分。框架也保存了共同決定，讓下一位維護者不用從零推理。

原生 CSS 接回能力，工具仍要重新定位

Flexbox 以一個維度分配空間，Grid 則直接描述行與列。當瀏覽器能承擔更多排版工作，團隊就能重新評估自己還需要多少網格封裝。

自訂屬性同樣改變了分工。Sass 變數在編譯時處理，CSS 自訂屬性則留在輸出中，可以依元素與 cascade 取得不同的值。切換品牌或主題時，這個差異比兩者都叫「變數」更重要；它們可以配合，卻不能只按語法逐字替換。Sass 的差異說明

原生 nesting 減少重複書寫選擇器，卻不會替專案建立命名隔離；@layer 可以安排樣式層的優先次序，仍需要團隊決定哪些來源屬於哪一層。規則同時存在時，仍須考慮來源、重要性、層、權重與順序，不能簡化成「後面寫的都會贏」。

對開場的卡片，container size queries 尤其有意義：卡片可以依所在容器的寬度切換排列，不必只看 viewport。同一個桌面視窗裡，主欄與側欄也能各自成立。這是瀏覽器新增了表達能力；卡片何時應該換版型，仍是設計決定。

這些能力已有使用經驗上的訊號。State of CSS 2026 的 All Features 圖表及其匯出資料中，:has() 有 3,822 位回答者，其中 3,198 人曾使用，圖表顯示 83.7%；CSS Nesting 則是 3,820 人中的 2,695 人，顯示 70.6%。分母是各功能題的回答者，百分比沿用官方顯示精度；它們不代表網站覆蓋率，也不表示正式專案持續使用的比例。

現代 CSS 也不是整包升級的單一版本。各模組分別演進，規格狀態與瀏覽器採用程度需要分開判斷。CSS Snapshot 2026也明確區分規格穩定性與瀏覽器普及情況。至於原生 @mixin，目前仍應作為實驗性草案閱讀；本站另有重用規則的導讀，不能把它當成現成的 Sass 遷移保證。

框架也會利用原生能力。Tailwind v4 採用 CSS-first 設定、原生自訂屬性與 cascade layers，並內建 container queries 支援。瀏覽器能力增加，可以讓工具縮減某些補強工作，也能讓它提供更完整的組合介面。

調查裡的現在：工具並存，AI 也還沒有接手一切

State of CSS 2026 詢問「你使用哪些 CSS 框架？」。此題有 3,697 位回答者，以下是部分選項的人數；它是複選題，各列可能重疊，不能相加當成市場分配。工具調查

這張表容納的是不同層次的選擇。shadcn/ui 與 Tailwind 可以同時使用；None 也不能直接推論成「完全不用工具」。調查的分類方便收集回答，架構分析仍應區分樣式生成、互動元件與程式碼分發。

同年的 CSS AI Code Generation 題目問的是「你產出的 CSS 有多少比例由 AI 生成？」。3,732 位回答者的自陳比例，官方顯示中位數約 13%；其中 980 人回答 0%，約占該題回答者的 26.3%。這個中位數描述每位回答者的比例，不能用來估算全世界 CSS 程式碼的生成量。

這使預測需要更精確的起點：AI 已進入部分人的工作流程，這份調查卻不足以支持它已承擔大多數 CSS 工作。受訪留言對生成品質的評價也不是控制實驗，不能據此宣告模型普遍勝任或不勝任。

同樣地，主辦方將無框架選擇與 LLM 聯繫起來的評論，是一種解讀。這些數據沒有排除專案類型、團隊偏好或原生功能進步等因素，不能單獨證明 AI 造成框架使用變化。本文據此提出假設，再用工程上的成立條件檢查它。

第二次修改，考驗的是規則能不能被辨認

回到產品卡片。下面是一段假設的初版 CSS，只呈現外框與留白：

.site-product-card {
  border: 1px solid #45687d;
  padding: 1.5rem;
}

要求「換品牌色」時，這段程式沒有說明邊框色的角色。即使 AI 能搜尋整個專案，也得判斷其他相同色碼是否應該一起改；相同的值，不保證相同的意圖。

如果需求已確認為「只有主打商品用品牌色邊框，其他卡片保留中性邊框」，可以把共同規則與變體寫出來。以下取代上一段；假設卡片位於 .site-product-slot 裡，主打卡片帶有 data-featured 屬性，品牌屬性則放在外層祖先：

:root {
  --border-neutral: #777777;
  --accent-brand: #45687d;
  --space-card: 1.5rem;
}
 
[data-brand="forest"] {
  --accent-brand: #406b57;
}
 
.site-product-slot {
  container: product / inline-size;
}
 
.site-product-card {
  display: grid;
  gap: 1rem;
  padding: var(--space-card);
  border: 1px solid var(--border-neutral);
}
 
.site-product-card[data-featured] {
  border-color: var(--accent-brand);
}
 
@container product (width >= 30rem) {
  .site-product-card {
    grid-template-columns: minmax(0, 1fr) 2fr;
  }
}

這裡假設卡片有圖片區與內容區兩個直接子元素；30rem 是案例選定的條件。查詢的是外層容器，寬度不足時維持單欄。它只示範邊框、間距與排列，按鈕的焦點、售罄行為仍由既有元件負責。

若上層以元件組合產品，還可以提供更窄的介面。以下是假設的元件 API，不屬於任何現成套件：

<ProductCard
  product={product}
  emphasis="featured"
  availability="sold-out"
/>

這些名稱有價值的前提，是實作確實把 emphasis 對應到樣式，把 availability 對應到文案及操作行為。型別可以限制可傳的值，仍不能證明售罄按鈕、鍵盤操作與畫面都正確。替任意值取名字，也只有在它代表穩定的共同決定時，才減少下一次修改的歧義。

原生 CSS、utility class 與元件庫都能承載這些規則。AI 所需的上下文也不只是一份語法表，還包含哪些元件已存在、哪些組合合法，以及如何確認修改沒有越界。

因此，我會把成本拆開看。撰寫成本可能降低；理解既有規則仍需要取得上下文；修改可能波及共用來源；驗證必須涵蓋主題、尺寸與狀態；維護則還包括升級與例外。這是分析方法，並非本文實測得到的時間分配。若生成更快卻讓審查更慢，團隊仍得計算整段流程。

2026–2029：我會觀察的三個變化

只靠縮短語法的採用理由，可能變弱

如果 AI 能可靠地產生並修改原生 CSS，額外語法所節省的手寫時間，可能不再足以抵銷學習與建置成本。功能單純、設計差異大的網站，便更有理由評估較薄的工具組合。

但 utility-first 還包含局部組合、設計尺度與團隊慣例。成熟工具也可能讓 AI 更容易沿用現有範例。因此，我預測承受壓力的是「只靠少寫幾個字」的理由，無法據此推導 Tailwind 或其他框架必然衰退。

可觀察的訊號是：完成相同需求與後續修改時，團隊是否能用更少依賴維持相同品質，並減少人工修正。若原生方案仍需要更多上下文與回歸處理，這項預測就應收斂；調查中 None 排名上升，本身不夠。

設計約束與驗證能力，可能取得更多價值

假如產生十種卡片變體變得容易，團隊就更需要決定哪幾種值得保留。token、合法變體、元件狀態範例與回歸檢查，可以把「應該長怎樣、怎樣才算正確」變成可重複使用的依據。

這份價值不限於大型框架。小團隊可能只需要一份清楚的 CSS、少量元件與檢查流程；多品牌產品則可能需要更完整的設計系統。共同前提是規則必須貼近實際需求，並有人維護。

我會觀察新增介面時，設計偏離與回歸問題是否減少，以及審查時間是否下降。若規則愈來愈多，例外卻更難處理，或更新測試的成本超過收益，重型約束就未必值得。AI 也可能協助驗證，讓較輕量的方案已經足夠。

框架會更重視 agent 如何找到並使用它

shadcn MCP 已提供查找、搜尋與安裝 registry 元件的介面，也可連接私有來源。這證明工具正在提供取得上下文的管道；它並不保證 agent 會選對元件或正確修改。

我的預測是，工具作者會更重視版本明確的文件、可取得的原始碼、組合範例與可執行的檢查。評估一個工具，除了人是否容易上手，也會問 agent 能否找到正確版本、辨認使用限制，並把產物放回既有專案。

主流生態可能因預設整合而受益，但更好的即時檢索，也可能讓小型工具不必依靠模型既有知識。可觀察的訊號是工具接入後，錯用 API、重造元件與人工返工是否下降；如果通用的程式碼理解已足夠，專用介面的優勢也可能縮小。

下一個框架選擇，從要保留的責任開始

對工程師而言，理解 cascade、尺寸計算與佈局仍然有用：生成結果偏離預期時，這些知識能把問題定位到規則本身。對框架作者而言，則可以重新說明自己的工具讓哪一種變更更容易完成、又如何被驗證。

既有專案還有遷移成本。即使新方案能少寫程式，也應先用一段真實修改確認收益，再決定是否替換已經穩定運作的共同做法。

回到那張卡片，我希望第二次修改能清楚回答：品牌色改在哪裡，側欄版型由誰決定，售罄與焦點狀態如何確認。只要這些責任仍需要被保存、傳遞與檢查，工具就有發揮價值的空間。接下來值得競爭的，是誰能讓一次修改更容易理解，也更容易證明它完成了需求。