AI 寫的 UI 為什麼總差一點？因為沒人告訴它什麼算好

🌏 Read this article in English

確認視窗的動畫，慢了 600 毫秒。

前陣子，團隊裡發生了一件事。

Junior 用 AI 寫了一個設定頁面。功能跑起來了，介面也看起來乾淨。

但當他點擊「刪除帳號」時，那個確認視窗的淡入動畫，緩慢了整整 600 毫秒。

Senior 看了一眼，沒說話。只是把滑鼠移到「取消」按鈕，發現 Tab 鍵的焦點順序是反的。

Junior 著重展示生成速度：「你看，AI 寫得多快。」

Senior 終於開口：「不是它寫得慢。是沒人告訴它什麼算好。」

這很正常。

不是 Junior 不會、也不是 Senior 太挑。是 AI 沒有被告知什麼算好。

AI 沒有品味。它只是在猜下一個字。沒人告訴它「好」長什麼樣，它就會往訓練資料的平均值靠。而平均水準，就是平庸。

這就是為什麼我們需要「UI Skills」。

它不是建議。是強制。

UI Skills 是什麼？

先說清楚，這裡的概念層級容易混淆。

UI Skills 是一套針對 AI Agent 設計的約束文件目錄。其中最有代表性的是 baseline-ui，這是一套具體的 Skill 檔案。而 Claude Code 則是載入這些規範的機制。

簡單說：

UI Skills 像是一本菜單。
baseline-ui 是其中一道食譜。
Claude Code 是照著做菜的廚師。

它的定位很明確： 不是建議（Suggestion）。 是強制（Constraint）。

Definition: UI Skills refers to a set of opinionated constraints designed for AI agents to generate consistent and high-quality UI code.

關鍵詞解析

詞彙	含義	為什麼重要
Opinionated	明確取捨	不怕得罪人，選定一個立場，降低模型漂移
Constraints	約束	明確的規則，可驗證
AI Agent	AI 代理	給 Claude/Cursor 等工具使用

六大約束領域

以 baseline-ui 為例，它覆蓋了 UI 開發的六大核心領域：

堆疊規範：必須使用 Tailwind CSS（Token 化 utility）、motion/react（動畫抽象）
元件系統：必須使用可存取的元件基礎設施（Base UI、React Aria、Radix）
互動設計：破壞性操作必須用警告對話框、禁止阻止貼上
動畫原則：互動回饋不得超過 200ms；未被明確要求時不新增
排版標準：標題用 text-balance、數據用 tabular-nums
效能最佳化：禁止在大型模糊/背景濾鏡上動畫

為什麼這樣設計有效？

因為它具體。

模糊的最佳實踐	UI Skills 的約束
「動畫要快」	「互動回饋不得超過 200ms」
「要考慮無障礙」	「必須使用 React Aria 或 Base UI」
「效能要好」	「禁止在大型模糊濾鏡上動畫」
「互動要安全」	「破壞性操作必須有確認對話框」

具體數字（200ms）而非形容詞（快）。 指定工具（Tailwind）而非方向（用 utility-first）。 禁止事項明確而非「盡量避免」。

我觀察過很多團隊，他們以為寫了 Style Guide 就等於有規範。但 Style Guide 對人類有效，給 AI 則需轉為可載入約束。 Skill 的約束是「活的」。它直接嵌入在 AI 的 prompt 中。

從模糊到具體：設計模式的轉換

你可能會想：「這不就是寫規範嗎？」

不完全是。

轉換範例

場景：動畫

模糊的規範：「動畫要流暢，不要太長。」

UI Skills 的約束：「互動回饋不得超過 200ms。」

為什麼這樣設計有效？

因為它可驗證。

當規則寫成「不超過 200ms」「必須用 React Aria」這類具體形式時，人在 review 時可以一眼看出有沒有違規，搭配 lint / 測試也能在 CI 階段攔下來。

約束的價值在於「可驗證性」。規則一旦能被檢查，它就不再是建議，而是標準。

使用方式：從 Prompt 到 Review

UI Skills 的使用方式很簡單。

1. 嵌入 Prompt

在你的 AI 代理的 system prompt 中，加入 UI Skills 的約束。

You are an expert UI developer.
Follow these constraints strictly:

## Animation
- Duration must be <= 200ms
- Only animate composite properties

## Accessibility
- Use React Aria or Base UI
- No manual ARIA attributes unless necessary

2. 透過 Claude Code 載入 Skill

如果你使用的是 Claude Code，可以把 baseline-ui 當作 Skill 載入，讓 Claude 在 review 一個檔案時，依照約束清單逐項評估。

需要先說清楚一件事：這不是傳統意義上的 linter。它沒有確定性的 AST 解析，也沒有窮盡的規則引擎。它本質上是「Claude 帶著一份約束文件去讀你的程式碼」。

也因此，輸出的形式更接近一份 review note，例如：

## 可能不符合約束之處

1. **Animation Duration**
   - File: `src/components/Button.tsx`
   - 觀察：動畫 duration 設為 300ms，超過約束的 200ms 上限。
   - 建議：將 `duration={300}` 改為 `duration={200}`。

2. **Accessibility**
   - File: `src/components/Input.tsx`
   - 觀察：input 缺少 `aria-label`。
   - 建議：補上 `aria-label="Search"`。

注意：Claude 輸出的是「依約束做出的判讀與建議」，不會自動修改檔案，也不保證涵蓋所有違規。若要在 PR 階段強制攔下，需要另外把可程式化的部分接到 ESLint / 測試 hook 上。

與內部規範文件的對比

你可能在想：「我們公司已經有自己的規範文件了，這跟 Style Guide 有什麼差？」

差別不在「有沒有」，而在「給誰看」。

差異在哪裡？

面向	UI Skills	典型內部規範文件
定位	約束/規則	參考/指南
語氣	「必須」「禁止」	「建議」「推薦」
可驗證性	高（可自動檢查）	中（需人工判斷）
技術綁定	Tailwind、React Aria	較通用
使用方式	載入到 AI 代理的 prompt	給人類工程師閱讀

UI Skills 是「意見導向」的。它做了明確的取捨。它選定了一個立場，並堅持到底。

典型內部規範文件是「參考性」的。它試圖涵蓋所有情況。人工 review 有效，但給代理使用需轉成可執行約束。

具體來說，如果你希望 AI 生成的 UI 符合團隊的標準，你需要的是「約束」，而不是「參考」。

意見導向（Opinionated）是 Skill 設計的關鍵。不怕得罪人，選定一個立場，才能確保一致性。

可學習的設計原則

從 UI Skills 中，我們可以提煉出幾個設計原則。

這些原則不僅適用於 UI，也適用於其他類型的 Skill。

意見導向與具體數字

「中立」規範的可執行性較低。如果規範說「可以使用 A 或 B」，AI 就會隨機選擇。結果就是，代碼風格不一致。

如果你團隊使用 Tailwind，就說「必須使用 Tailwind」。不要說「建議使用 Tailwind」。

同樣地，「快」是主觀的。「200ms」是客觀的。如果你希望動畫快，就說「不超過 200ms」。不要說「動畫要快」。

工具綁定與禁止清單

指定用什麼，而非「選一個好的」。「選一個好的」需要判斷力。 AI 的判斷依賴上下文；團隊規則能減少模型在相近方案間漂移。

如果你希望使用無障礙元件，就說「使用 React Aria」。不要說「使用無障礙元件」。

「盡量避免」等於「可以做」。「禁止」等於「不能做」。如果你希望避免效能問題，就說「禁止在大型模糊濾鏡上動畫」。不要說「盡量避免大型模糊濾鏡」。

可驗證

規則需同時具備明確性、可檢查性、可落地流程。規則一旦能被檢查，它就不再是建議。

當約束寫成具體門檻（200ms、必須用 X 函式庫），你就可以把可程式化的部分接到 lint 或測試上，把不可程式化的部分留給 AI 與人共同 review。

如何應用到自己的 Skill

步驟 1：列出你團隊的「潛規則」

我們用什麼 CSS 框架？動畫通常多長？什麼情況要有確認對話框？

你可以開一個會議，讓團隊成員列出他們最常見的 UI 可優化處、風險場景或 review 檢查點。

步驟 2：把潛規則變成約束

「通常用 Tailwind」→「必須使用 Tailwind」「動畫不要太長」→「動畫不超過 200ms」「破壞性操作要有確認」→「破壞性操作必須有確認對話框」

「潛規則」是模糊的。「約束」是具體的。

步驟 3：加入檢查機制

這裡有兩條路。

路徑一：直接採用 baseline-ui 把公開的 baseline-ui Skill 加入專案，讓 Claude Code 在 review 階段依約束給出建議，團隊保留最後決策權。

路徑二：建立自己的 Skill Fork baseline-ui 或新增一份自家的 SKILL.md，放入團隊規則與檢查重點。能程式化的部分（如 duration 上限、禁用屬性）接到 ESLint / 測試 hook，不能程式化的部分（如「破壞性操作要有確認對話框」）交給 AI 輔助 review。

取捨與限制

過度約束會扼殺創意嗎？還是讓 AI 學會「有邊界的自由」？

限制一：市場訊號尚未明朗

UI Skills 是一個新興的概念。它的生態系還在發展中。未來可能會出現更標準化的做法。

如果你現在就全面採用 UI Skills，可能會面臨生態系標準收斂後的重寫成本。等更標準的規範出現，你需要重新對齊。

限制二：這不適用於所有框架

baseline-ui 偏 React/Tailwind，但 catalog 收錄多平台。

如果你使用的是 Vue 或 Angular，可能需要調整約束。你可以參考 UI Skills 的設計原則，但需要替換掉技術綁定的部分。

限制三：過去不代表未來

AI 模型在進化。今天的約束，明天可能不需要了。

五年後回頭看，這些約束多半會被新工具內化掉。但眼下，模型還沒學會替你選邊站。約束，還是得自己給。

你的團隊現在交給 AI 的，是規範還是運氣？

建立明確的約束，是讓 AI 真正融入專業開發流程的第一步。

目前判斷依據仍在累積，我會先用可驗證約束降低生成品質波動。

下次 AI 幫你產一個元件，停 5 秒問自己：它做出這個選擇，是因為我教過它，還是它在猜？

Sources

baseline-ui SKILL.md（UI Skills 官方 GitHub） — baseline-ui—UI 約束原文
Claude Code Skills Documentation — 技能建立、設定與分享指南
React Aria Documentation — 可及性元件、互動與國際化指南
Base UI Documentation — React 無樣式無障礙元件庫說明