沒有一杯咖啡解決不了的 CSS；如果有，就交給 AI——然後你可能會發現，它把整頁都寫成 position: absolute。版面跑到懷疑人生，只好再沖一杯。

你是不是也遇過這種情境：打開 Cursor 或 Claude，輸入「幫我做一個響應式產品頁」，幾秒後就得到一大串看起來很漂亮的 CSS。你心想：「太好了，以後不用學了！」結果換個螢幕寬度，版面像被貓踩過一樣。

結論先講：CSS 還是要學，但學習重點已經改變。 你不必把每個屬性和值背成咖啡店菜單；你需要建立版面與效能的心智模型，能看懂 AI 的決策、驗證結果，並在必要時把它拉回正軌。這篇會帶你整理這套學法，還會示範怎麼寫出比較可靠的 CSS Prompt。

目錄

你不只要寫 CSS，也要審 CSS

以前學 CSS，很大一部分時間花在記屬性與語法。現在查文件很方便，像 align-content 的值或 flex-shrink 的預設行為，都可以在需要時查清楚。這不代表基礎不重要，而是學習時間應該從「背答案」移到「理解問題」。

真正重要的是，你能不能看出 AI 寫的版面為什麼不穩，並用清楚的條件請它修正。否則就會陷入經典循環：和 AI 來回對話十輪，Bug 還在，咖啡倒是喝了三杯。這不是咖啡因不足，是驗收條件不足。

AI 是乘數：底子越厚，幫助越大

把 AI 想成乘數會比較貼近實際：它可以加快產生草稿、改寫重複程式碼，但不會替你承擔需求不清、驗收錯誤或維護困難的後果。

  • 概念不清 × AI：很快得到一個能展示的版本，但遇到不同內容、不同寬度或下一次修改，就不知道該從哪裡修。
  • 概念清楚 × AI：你可以把重複工作交給 AI，再用版面、可及性、效能與可維護性的原則檢查成果。

白話說，AI 會放大你的能力，也會放大你的盲點。底子不夠，它幫你「快」；底子夠，它才比較有機會幫你「又快又穩」。

AI 越強，你越需要 CSS 心智模型

AI 能產生程式碼，但它不會替你確認需求，也不會自動知道這個元件在真實內容與各種螢幕下是否合理。因此，它可能交出看起來對、實際很脆弱的解法——像自動咖啡機做出一杯外表像拿鐵、喝起來像苦水的飲料。

常見警訊包括：

  1. 亂用 position: absolute：為了對齊就硬拉座標，內容一變或視窗變窄，版面便可能重疊。絕對定位不是禁忌，但應該用在確實需要脫離正常流的情境。
  2. 無止境堆 @media 斷點：若每個元件都只依賴視窗寬度，元件放到不同容器時就難以重用。Container Queries 可以在適合的情況下，讓樣式依祖先容器的尺寸調整；前提是先正確設定查詢容器。
  3. 把 z-index 加到 9999 還是沒用：z-index 受層疊上下文影響，數字大不等於一定顯示在最上層。這時候再來一杯咖啡也沒用，得先找出是哪個元素建立了新的層疊上下文。

這幾件事，AI 真的替不了你

概念AI 常犯的錯你要會的
正常流（Normal Flow）版面一亂就加定位硬撐知道元素預設如何排列，再判斷是否真的要脫離正常流
佈局選型不分情境套用 Grid 或 FlexFlexbox 適合一維排列，Grid 適合同時處理列與欄；實際選擇仍要看內容
Intrinsic Sizing直接把 width、height 寫死理解內容如何影響尺寸，再用 min()、max() 或 clamp() 等方式設計彈性
設計系統（Tokens）到處硬編碼顏色與間距使用像 --color-primary 這類變數，讓修改有一致的入口

CSS 會影響體驗，也可能牽動搜尋表現

CSS 不只影響外觀，也會參與版面配置與瀏覽器渲染。Core Web Vitals（CWV）是用來觀察載入、互動與視覺穩定性的使用者體驗指標；Google 說明這些指標會在相關工具中呈現，也可能作為搜尋排名系統考量的一部分，但它們不是「CSS 分數」，更不是分數一掉就必然失去流量。真正的目標，是讓使用者感覺網站穩定、快速、好操作。

AI 產出的 CSS 可以從這些角度檢查：

  • CLS（累積版面位移）：圖片或嵌入內容若沒有預留空間，載入後可能把既有內容推開。可以確認媒體尺寸、aspect-ratio 或其他空間預留方式是否符合實際版面。
  • INP（互動至下一次繪製）：它反映使用者互動後，頁面回應並完成下一次繪製的延遲。動畫若頻繁改動會影響版面配置的屬性，可能增加瀏覽器工作量；在適合的情況下，可優先評估 transform 或 opacity，但仍要用實際測量驗證，不能保證換了屬性就一定改善。
  • LCP（最大內容繪製）：主要內容的載入與呈現也會影響體驗。不要只看 CSS，還要一起檢查圖片、字型、HTML 與 JavaScript 的載入路徑。

想搞懂門檻跟優化清單，可以看這篇：PageSpeed Insights 與 Core Web Vitals 2026 完全指南。

四階段學習路線（邊做邊跟 AI 練，別乾讀）

如果你現在要重新學 CSS，我會建議照這張地圖走。每完成一階段，可以獎勵自己一杯咖啡；只是別邊喝邊讓 AI 無限制自由發揮：

  1. 階段 1：先建立心智模型——先用正常流做出可閱讀的 HTML，再觀察什麼時候需要 Flexbox、Grid 或定位。你會逐漸理解「流」不是玄學，而是瀏覽器的預設排版方式。
  2. 階段 2：練習 Flexbox 與 Grid 的分工——先問自己是在處理一個方向，還是同時管理列與欄，再選擇工具。可以要求 AI：「請說明為什麼這個區塊適合使用 Flexbox 或 Grid。」
  3. 階段 3：練習元件級響應式——學會 Container Queries 的基本條件，理解它和 Media Queries 解決的是不同層級的問題，再請 AI 產生小範例並逐行審查。
  4. 階段 4：加入效能與可及性驗收——用 PageSpeed Insights、瀏覽器開發者工具或其他合適工具觀察 LCP、CLS、INP 與可及性問題。content-visibility 可以是進階研究題目，但要先理解它的適用情境與限制，不要把它當成長頁面的萬用咖啡粉。

別只說「幫我做一個卡片」——給它一個好 Prompt

模糊指令 = 模糊產出。就像你走進咖啡店只說「給我一杯好喝的」，店員也只能猜。你可以複製下面這個結構，再依專案改寫：

請為我實作一個響應式文章卡片元件：
1. **佈局**：使用語意化 HTML；圖片在上、標題在下、按鈕靠底對齊。請說明為什麼選 Flexbox 或 Grid。
2. **設計系統**：優先使用專案既有的 CSS 變數；如果沒有，先列出需要的變數，再提供暫時值，禁止散落難以維護的硬編碼色碼。
3. **響應式**：若使用 Container Queries，請補上必要的容器設定，並說明查詢條件；不要只複製視窗斷點。
4. **效能**：只在適合的情況使用 `transform`、`opacity` 等動畫方式，並說明仍需如何測量驗證。
5. **a11y**：確保鍵盤 focus 狀態可見、互動元素有清楚名稱，並檢查文字與背景對比是否符合 WCAG 2.2 的要求。
6. **要求**：請先解釋佈局與響應式策略，再提供 HTML 與 CSS 程式碼，最後列出需要人工驗收的項目。

重點不是 Prompt 越長越好，而是把決策權留給你。先讓 AI 解釋為什麼這樣排、有哪些假設，再決定要不要採用。AI 可以當外骨骼，但方向盤還是你的；不然它很可能一路開向 !important 的荒野。

結語：會寫 CSS 的人變多了，會審 CSS 的人更值錢

「會寫 CSS」這件事本身，不代表價值消失了；只是單純產生一段能跑的樣式，已經不是完整能力。真正有差的是：你能不能交付一個能上線、好維護、在真實情境下穩定的成品。

下次請 AI 寫 CSS 時，先給它清楚的限制，再逐項驗收。沒有一杯咖啡解決不了的 CSS，如果有，就交給 AI——但記得，審完再來一杯。

參考資料