Web UI 工藝
通用的 UI 不是一種風格。它只是填滿了每個無人做出的決定：模型、模板或框架提供了它最常見的答案，結果可以屬於任何產品。外觀最優美的網站（Linear、Vercel、Stripe、Family、Awwwards 獲獎作品）幾乎不留下任何預設值。它們計算一個小系統，專注於一個想法，並將功能細節維持在可衡量的標準。
因此，工作就是做出決定、記錄下來，並將每個決定追溯到主題、用戶或感知原理。請按順序遵循以下五個步驟，並根據任務規模進行調整：單一按鈕只需要一句話的簡報和快速的評審，而一個登陸頁面則需要完整的處理。
1. 理解主題
在任何視覺選擇之前，先確定：
- 主題：產品、組織或內容實際上是什麼，以及它所屬的世界（其行業、材料、詞彙、人工製品）。
- 受眾：誰會來，他們已經知道什麼，他們可能使用哪種裝置。
- 主要任務：頁面或畫面必須完成的唯一一件事。其他一切都為此服務。
- 現有限制：品牌資產、現有設計系統、權杖（tokens）、元件庫或儲存庫中的框架。如果已存在權杖，請使用它們並在此技能限制內應用。除非被要求，否則不要將新的識別強加於已建立的產品。
如果用戶提供的資訊很少，請從主題推斷，並在簡報中陳述你的假設，而不是問一串問題。
2. 撰寫設計簡報
在編寫程式碼之前，在你的回應中撰寫一份緊湊的簡報。它就是設計本身，所以必須足夠具體，讓其他人也能僅憑這份簡報建構出相同的東西。
方向： 一個命名的美學風格及其為何適合此主題（一到兩行）
簽名元素： 此頁面令人印象深刻的唯一想法，承載該想法的英雄元件，以及該元件
將如何製作（提供的素材、生成的圖像或透過程式碼建構）
色板： 中性色（偏向於……）、一個強調色（角色）、語義色彩；使用 OKLCH 值
字體： 每種字體（展示用、內文用、等寬字體，如需要）的字體家族和角色，以及每種字體與
主題的共通點；展示用字體在構圖中如何作用；比例；內文大小
佈局： 第一個畫面的兩到三種選項，每種包含一行概念描述和一個 ASCII
線框圖；所選方案及其原因；網格、欄寬、密度、章節節奏
深度： 各表面如何分離（色調層級、細線邊框、陰影），光線從何處來
以及落在何處
動態： 層級（產品或品牌）、簽名時刻及其主導元素、還有什麼
會動、持續多久，以及什麼元素刻意保持靜止
圖像： 攝影、插圖、3D、產品 UI 或純文字；一行描述的藝術指導方向
文案： 為此受眾撰寫的標題和主要行動呼籲；行動的名稱，
從按鈕到確認訊息保持一致
預算： 整個頁面的壓縮後腳本大小，以及特效層可以佔用的份額
（預設總計 365 KiB；無特效的頁面為 75 KiB）
簡報規則：
- 推導，而非裝飾。 每一行都要回答「為什麼是這個，並且是為了這個主題？」。色板取自產品的材料，字體源自其領域風格，英雄元件則以該世界中最具特色的事物開場。
- 一個簽名，其他一切保持低調。 Stripe 有其漸變波浪，Apple 有其滾動式產品照片，Family 有其飛舞的托盤。將大膽用在同一處。圍繞它的克制才能讓它被注意到。
- 克制本身就是一個有效的方向。 一個冷靜、以文字為主、單色調並搭配一個強調色的系統，和一個 WebGL 英雄元件一樣都是深思熟慮的設計，通常對於工具和文件來說是正確的選擇。
- 低調不等於簡陋。 克制限制的是頁面上有多少個想法，而不是每個想法有多豐富。簽名元素應該經得起細細品味：為此主題繪製的插圖、精心呈現的真實數據、紋理、以真實展示尺寸呈現的文字。美食、文化、消費品和品牌主題通常需要圖像或插圖來傳達溫度，因此純文字的頁面需要陳述理由。
- 英雄元件是投入努力的地方。 備受讚譽的網站違反了許多規則，但看起來仍然昂貴，因為它們將一個元件做到了非常高的標準：一個帶有可信數據的產品螢幕、一個打光的物體、一個原創插圖。請使用
references/artefacts.md來選擇和建構它。一個帶有灰色條紋的圓角框不是產品截圖。 - 字體是構圖的一部分，而不是承載構圖的載體。 在展示尺寸下，字體設定本身就是設計：它與頁面上最小文字的比例、字重、字寬、大小寫、斷行位置、標題所襯托的背景。Linear 的 64 px 標題搭配 12 px 的介面文字是其效果的重要組成部分。
- 在選擇佈局之前先進行比較。 草繪兩到三個真正不同的第一畫面（不是移動了圖片的同一種佈局），並根據主題的主要任務來選擇。通常第一個想到的佈局就是模板。
- 主張、證明、行動。 大多數頁面需要一個清晰的陳述、一個真正的證據（產品視圖、實時數據、客戶、演示）和一個主要行動。結構應跟隨內容，而非模板。
- 每個行動一個名稱。 寫著「發布」的按鈕應該產生一個寫著「已發布」的確認訊息，而不是「已儲存」。介面的詞彙是用戶導航的方式。
在選擇方向或簽名元素時閱讀 references/exemplars.md，在設定色板、字體、佈局和深度時閱讀 references/visual-system.md，在撰寫「動態」行時閱讀 references/interaction.md 的動態章節。
3. 挑戰簡報
在建構之前，先攻擊它：
- 替換測試。 競爭對手的名稱能否替換當前名稱而無人察覺？如果可以，則表示簡報尚未做出決定。
- 逐項測試。 對於每一行，問它是否可能屬於任何產品。如果可能，它必須是一個深思熟慮、調整良好的（來自下方建構表的）預設值，否則就必須更改。
- 收斂測試。 用幾行草繪你會為一個鄰近主題撰寫的簡報：同一類別中的另一個工具，同一行業中的另一個製造者。每一行如果完全相同，那就是預設值，而非決定。更改它，並在簡報中說明更改了什麼以及為什麼。一行只有在兩個主題共享一個事實（例如，兩個產品都是硬體，兩個受眾都閱讀程式碼）時才能保留；說出這個事實。
- 痕跡檢查。 與
references/slop-tells.md進行比對，包括整體外觀的集群。不要僅僅將一個常見預設值替換為下一個最常見的（例如，用 Space Grotesk 取代 Inter，用紫色取代深青色）。用一個有理由的選擇來取代它。
修改簡報，然後建構。
4. 建構
- 先定義權杖。 在任何元件之前，先將色板、字體比例、間距、圓角半徑、陰影和動態寫成 CSS 自訂屬性（或項目的權杖系統）。元件只使用權杖名稱，絕不使用原始值，如
bg-indigo-500或#6366f1。 - 其次是結構。 語義化的 HTML，導航使用真實鏈接，標題按順序排列，然後是樣式。
- 套用建構表以及
references/visual-system.md和references/interaction.md中的細節。 - 設計每一個狀態。 懸停、點擊、焦點可見、禁用、載入、空狀態、錯誤、成功、長內容和短內容。生成的 UI 在這些地方最薄弱，而修復成本也最低。
- 保持特效輕量且可選。 重特效（WebGL、影片、大模糊）僅存在於一個隔離的層中，並且在簡報的預算內，在首次繪製後開始加載，具有靜態後備方案，並置於
prefers-reduced-motion: no-preference之後。
5. 評審與刪減
將第一次建構視為草稿。
-
執行靜態檢查器，使用技能自己的目錄作為腳本路徑。它需要 Python 3.12 或更高版本，且無需任何套件。將它指向整個前端源代碼，而不僅僅是你更改的文件：焦點和減少動態規則會在全域樣式中尋找設置，因此部分掃描會報告錯誤的缺陷。
python <skill-dir>/scripts/check_slop.py <front-end source folder>修復每一個
defect（退出碼 1 表示至少還有一個存在）。對於每個tell，更改它或在你報告中說明為何保留。檢查器只讀取源文本，因此結果乾淨是必要條件，而非充分條件。 -
渲染頁面，並在 1440 px 和 375 px 寬度下觀看，如果頁面有兩種配色方案則都檢查。如果會話中有瀏覽器工具，請使用它。否則，大多數機器都有無頭 Chrome 或 Edge；將螢幕截圖和瀏覽器設定檔寫入臨時文件夾，然後讀取圖像：
chrome --headless=new --hide-scrollbars --user-data-dir=<temp>/profile --window-size=1440,2600 --virtual-time-budget=4000 --screenshot=<temp>/desktop.png <file or http URL>螢幕截圖是給定大小的一個視口，而非整個頁面，因此請將視窗設得足夠高以容納你需要查看的內容。無頭 Chrome 無法讓視窗窄於約 500 px，因此 390 px 的螢幕截圖會從較寬的佈局中靜默裁剪。一個會自行播放的動畫片段會在其循環的隨機點被捕捉到：添加
--force-prefers-reduced-motion以獲得完成幀，並再截一張不含此參數的圖以查看循環中間的幀。對於手機檢查，請截取一個小型包裝頁面的螢幕截圖，該頁面在 375 px 寬的<iframe>中包含該網站。需要滾動才能顯示的元素可能不會出現在無頭螢幕截圖中；請在源代碼中檢查它們的隱藏起始狀態是由腳本應用的（參見references/interaction.md）。如果使用真實的瀏覽器工具，請逐一 Tab 瀏覽每個流程。 -
測量頁面，而非估計它。通過 HTTP 提供服務（對於靜態文件夾，在該文件夾中執行
python -m http.server），在其預設移動設定檔下執行 Lighthouse，然後使用預算讀取器讀取報告：npx [email protected] <http URL> --output=json --output-path=<temp>/report.json --quiet --chrome-flags="--headless=new --user-data-dir=<temp>/lh-profile" python <skill-dir>/scripts/check_budgets.py <temp>/report.json --script-kib <the brief's budget>它檢查 LCP（2.5 秒）、CLS（0.1）、總阻塞時間（200 毫秒，實驗室中代表 INP）、腳本權重是否符合簡報，並列出每個非合成動畫及其元素。修復每一個
breach（退出碼 1）。退出碼 2 表示某個數值unmeasured或報告無法使用：重新執行，如果仍然失敗，則將該數值報告為無法測量，絕不能報告為通過。http.server不會壓縮，因此腳本權重會偏高，這會偏向安全側。如果 Lighthouse 找不到 Chrome，請設置CHROME_PATH。如果 Node 或網路不可用，請在報告中說明。Lighthouse 不測量簽名時刻的幀率：如果會話中有瀏覽器工具，請記錄效能軌跡，否則請說明未測量。 -
詢問第一個畫面是否為眼睛提供了一些值得觀看的東西，並對英雄元件執行
references/artefacts.md中的保真度檢查清單。一個正確但容易被遺忘的頁面具有一個膽怯的簽名元素：應該加強簽名元素，而不是添加更多元素。 -
將頁面與參考進行比對。在選定的方向上選擇一個備受讚譽的網站，一個該領域設計師會欣賞的網站（
references/exemplars.md中列舉了一些），使用步驟 2 中的命令在 1440 px 下截取其第一個畫面，然後並排觀看兩張圖像。比較英雄元件的保真度、最大文字與最小細節之間的跨度、有多少可信的細節，以及光線。指出最大的差距並縮小它，或在報告中說明為何保留差距。參考設定了工藝的標準，而非外觀：不要從其表面獲取任何東西。如果網站無法訪問，請在報告中說明。 -
走查
references/interaction.md中的檢查清單（狀態、焦點、目標、表單、效能）。 -
針對建構好的頁面（而非簡報）再次執行
references/slop-tells.md中的痕跡檢查。它涵蓋了檢查器無法看到的結構性痕跡，例如居中徽章英雄區域、三個相同的卡片以及整體外觀集群。 -
刪除任何不服務於主題或用戶的內容：裝飾性分隔線、不言自明內容上方的標籤、徽章、發光效果、重複其文字含義的圖示、第二個強調色。刪除通常是可用的最大改進。
-
報告簡報、評審更改了什麼、與參考之間的最大差距、測量到的數值與其預算的對比，以及任何你無法驗證的內容（例如，在沒有瀏覽器的情況下渲染的對比度）。
建構表
有充分來源的起始值。它們保護好的決策；它們不取代簡報中的識別決策。
| 維度 | 預設值 |
|---|---|
| 內文 | 16 至 20 px，行高大約 1.5，欄寬 45 至 90 個字元（目標約 65） |
| 標題 | 行高 1.0 至 1.2，從 24 px 起字距約 -0.02em，text-wrap: balance |
| 段落 | text-wrap: pretty；粗體和斜體永遠不一起使用 |
| 字體比例 | 透過 clamp() 使用流體排版，小螢幕比例約 1.2，大螢幕約 1.25 |
| 全大寫 | 罕用，少於一行，字母間距 0.05em 至 0.12em |
| 顏色 | OKLCH；一個帶色調的中性色階，一個強調色，三到四個語義色，每個都有基於角色的級別 |
| 對比度 | WCAG 4.5:1 內文，3:1 大字型和 UI 元件；內文目標 APCA Lc 75 或更高 |
| 深色模式 | 單獨的色板：深灰色基底（約 oklch(0.18 0.01 h)），較亮的表面表示層級，降低飽和度的強調色 |
| 漸層 | 使用 in oklch 插值；相鄰色相；可選的精細紋理；最多一個刻意設計的漸層 |
| 間距 | 4 px 基準：4, 8, 12, 16, 24, 32, 48, 64, 96, 128；組之間的間距至少是組內間距的兩倍 |
| 深度 | 先使用色調層級和細線邊框；分層陰影，一個光源，偏向於表面色相 |
| 圓角半徑 | 兩到三個值；嵌套半徑 = 外部半徑減去內邊距 |
| 圖示 | 同一系列，同一網格，同一筆劃寬度，語義角色相同 |
參考文件
此技能附帶可選的參考文件，位於技能目錄的 references/ 資料夾中：
references/visual-system.md— 關於色彩、排版、佈局和深度的詳細大型參考references/interaction.md— 關於動態、狀態、焦點管理和表單的指引references/exemplars.md— 值得研究的方向和網站列表references/artefacts.md— 創建高保真英雄元件的指南（產品截圖、插圖等）references/slop-tells.md— 要避免的常見 AI 生成模式清單
如果存在這些文件，請在簡報和建構階段查閱它們。