unvibe

unvibe 是做什麼的？

這個技能將看起來像生成的介面轉變為看起來經過設計的介面。它不是發明一種新的風格：而是應用一份專業介面共有、生成介面缺失的小型可測量細節目錄，並將其對應到專案自己的顏色。它萃取自一個真實的、為期兩天的拋光作業（references/case-study.md）；每一條規則之所以存在，是因為打破它會被注意到。

對應你的顏色，保留數值。 比例（圓角半徑、內距、尺寸、持續時間、字重）承載品質。顏色是你唯一需要調整的東西。

開始之前

1. 閱讀 references/tells.md（什麼讓 UI 看起來像生成的，以及每個問題的替代方案）。
2. 閱讀專案的設計 Token 及任何設計文件。在 references/porting.md 中填寫 Token 表格。
3. 詢問專案擁有者哪些畫面最困擾他們，以及他們喜歡什麼。保留他們喜歡的東西；永遠不要移除他們理解的內容（「我喜歡這個，它很容易理解——只要格式更好」意味著重新調整樣式，而不是刪減）。
4. 確認技術棧：是否使用 React、Tailwind 3/4 或純 CSS、是否有現成的元件庫、是否使用無頭部元件庫（React Aria）。

工作流程

階段 1 · 基礎（一次遍歷，整個應用程式）

Token（assets/css/unvibe.css 第 1 節，已對應）、品牌色的原生殘留元素、表格數字、減少動畫、動畫曲線。然後是文字：移除追蹤大寫標籤、表情符號標題、徽章中的 ✓ 字形、驚嘆號（目錄 §0–§1）。快速、可見、零風險。

階段 2 · 控制項（一次遍歷，整個應用程式）

具有立體感的按鈕，每個畫面一個主要按鈕（§2）· 填滿欄位，每行統一高度（§3）· 真正的選單取代原生 select（§4；先審查所有呼叫點，references/pitfalls.md）· 每個是/否選項使用開關，重要的使用開關卡片，可見的選項使用單選卡片，標籤（§6）· 分段控制項的滑塊可滑動（§5）。

階段 3 · 根據參考文件重建最常見的畫面

選取人們最常看到的 3–5 個畫面，並根據最接近的專業模板進行測量重建（references/method.md）：分析概覽 → KPI 磚塊（§9）；AI 畫面 → 代理執行緒（§12）；活動 → 饋送（§11）；設定 → 行（§7）；大量列表 → 資料網格（§10）；長時間作業 → 日誌（§13）；日期 → 預設值 + 兩個月（§15）。

階段 4 · 全面掃描

每個剩餘畫面都套用相同的細節：一種表格表頭帶、一種欄位樣式、一種選單、一種徽章樣式、使用填滿區域的提示框、使用邊框區塊的列表、所有列表頁面上相同的篩選器高度（§8, §10, §16）。兄弟畫面之間的不一致性本身就是一種特徵。

階段 5 · 證明

使用 scripts/capture.mjs 取得生產環境與分支環境的前後對比截圖，並使用 scripts/compare.mjs 建立並排對比頁面。只保留一眼就能看出差異的組別。然後在推送到主分支之前，執行 references/verification.md 中的完整無回歸測試。

黃金規則

1. 選中 ≠ 動作。 一種冷靜的顏色標記被選中的內容；響亮的品牌色用於每個畫面上的一個主要動作。
2. 懸停 ≠ 選中。 懸停是中性的；選中是淺色調加上一個勾選標記。
3. 三種表面：畫布、用於浮動元素的白色、用於欄位和磚塊的較暗下沉填色。
4. 沒有追蹤大寫字母、沒有表情符號標題、沒有勾選字形、沒有彩色左側邊條。
5. 同一行上的每個控制項共享相同的高度和填色。
6. 每個是/否選項都是一個開關；核取方塊用於列表和同意書。
7. 一個設定就是一行：左邊說明功能，右邊是控制項；鎖定的行用灰色文字說明原因。
8. 填滿的磚塊中數字為 24/34，帶有圖示晶片和一個根據意義顏色標示的 Delta 藥丸（成本上升顯示為紅色）。
9. 所有地方使用統一的表格表頭帶，句子大小寫，位於 16px 邊框中；選中的行有 3px 的內嵌邊條。
10. AI 答案是執行緒中的文字，包含讀取的內容和實際經過時間；永遠不要偽造步驟。
11. 動畫跟隨狀態變化，而不是懸停；按下時縮放到 .985；選單和模態框出現。
12. 永遠不要猜測數值，永遠不要使用裝飾性控制項。 如果資料缺失，顯示「未確定」；如果一個欄位不做任何事，就移除它。
13. 在同一次遍歷中處理兄弟畫面。
14. 只顯示可見的差異，並證明沒有回歸。

這個技能包含什麼

路徑	用途
references/catalogue.md	每個細節及其精確數值（§0 基礎 → §17 永不列表）
references/tells.md	生成 UI 的特徵及其替代方案
references/method.md	參考驅動的重新設計：選取、測量、對應、重建、證明
references/pitfalls.md	拋光會帶來的錯誤（模態框中的選單、重複鍵、遺失的名稱、CSS 圖層、測試）
references/verification.md	前後對比和無回歸測試
references/porting.md	Token 對應、Tailwind 3/4、其他框架、改造順序、暗色模式階段
references/case-study.md	這個技能的真實案例，附帶專案擁有者的評論
assets/css/unvibe.css	可直接套用的樣式表（純 CSS，uv- 類別，Token 在 :root）
assets/react/*	Select、NativeSelect（可替代 <select>）、Switch/SwitchCard、SettingsRow、Accordion、NumberField、Segmented（可滑動的滑塊）、RollingNumber、ThinkingIndicator、DateRangePicker、useFlipToFit
scripts/capture.mjs	使用無頭 Chrome 拍攝 [data-shot] 元素或應用程式畫面的截圖，並進行主控台檢查
scripts/compare.mjs	並排前後對比頁面
demo/index.html	每個模式的「前後對比」，使用虛構資料

使用資產

• CSS：將 assets/css/unvibe.css 複製到專案中，將第 1 節對應到專案的 Token，在基礎樣式之後匯入它。直接使用類別或將其轉換為專案自己的類別名稱（保留數值）。
• React：複製你需要的元件；它們依賴於 react-aria-components（以及用於日期範圍的 @internationalized/date）。它們不包含 Tailwind 類別。
• 現有元件庫：使用目錄中的數值重新設定其元件的樣式，而不是取代它。

要交付的內容

1. 前後對比頁面（僅可見的差異）。
2. 一份簡短的清單，按類別說明更改了什麼，以及觸及的畫面。
3. 無回歸報告：審查了哪些內容、在瀏覽器中測試了哪些互動、主控台狀態、測試、建置。清楚說明哪些沒有被檢查。