🌏 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 necessary2. 透過 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 無樣式無障礙元件庫說明