Communitygithub.com

kasonye/ui-aesthetics-skill

提升網頁介面的前端視覺判斷力,偏好精緻的產品級構圖、精準的組件工藝、嚴謹的互動狀態、受控的動態與連貫的深度系統。可在任何支援的代理或 IDE 中,於生成、審查或重構泛型、雜亂、扁平、過度樣式化、劇場式動畫、視覺不精確或看起來像 AI 生成的 UI 時使用,或當使用者要求更乾淨、更高級、更精煉、更簡約或更具產品感的介面時使用。

ui-aesthetics-skill 是什麼?

此技能旨在引導 AI 代理生成或評估前端 UI 時,遵循一套嚴謹的設計原則,產出專業、穩定且具產品感的介面。它支援生成、審查、重構、組件打磨、狀態/動態優化及深度/光影調整等任務路徑。技能強調視覺層級、間距節奏與色彩克制,避免常見的反模式,如無故擴張範圍、使用暖白背景或過度裝飾。透過結構化的自評機制與參考文件(如設計原則、色彩系統、互動狀態),此技能確保 UI 在灰度模式下依然穩固,並在行動裝置上提供重新構圖而非擠壓的體驗。

相容平台~Claude Code~Codex CLI~Cursor
npx skills add kasonye/ui-aesthetics-skill

在你喜歡的 AI 中提問

開啟一個已預先載入此 Agent Skill 的新對話。

說明文件

UI 美學

意圖

使用此技能讓網頁 UI 的輸出感覺更專業、穩定且具產品感。

預設目標:

  • 保留使用者請求的成品範圍與內容足跡
  • 在加入裝飾前,先產出平衡的構圖
  • 讓層級結構一目瞭然
  • 保持色彩克制但看起來昂貴
  • 僅在陰影、模糊、光暈與亮點能清楚說明深度時使用它們
  • 讓動態簡短、流暢且有用
  • 讓組件在感覺有風格之前先感覺精準
  • 將狀態、動態與深度保持在一個連貫的系統內

此技能與框架無關。不僅要評判頁面構圖,也要評判組件精準度、狀態行為、動態語法與深度紀律。先用設計判斷主導,再進行實作。

任務路由

在行動前對請求進行分類:

  1. 生成 當使用者想要一個新的頁面、區塊或組件時使用。
  2. 審查 當使用者想要評論、發現問題或診斷 UI 為何感覺薄弱時使用。
  3. 重構 當使用者希望直接改寫現有實作時使用。
  4. 組件打磨 當結構可接受,但控制項、卡片、表格、模態框或覆蓋層仍感覺泛型或廉價時使用。
  5. 狀態 / 動態優化 當 hover、focus、pressed、selected、loading、success、error 或轉場感覺雜亂、薄弱或劇場式時使用。
  6. 深度 / 光影優化 當陰影、亮點、光暈、模糊或深色模式分離需要更嚴謹的紀律時使用。

如果請求混合了審查與重構,先診斷,再選擇改寫深度,然後才進行編輯。

不可妥協的原則

  • 精確遵循請求的範圍:組件就是組件,卡片集就是有界限的模組,區塊就是區塊,頁面只有在被要求時才成為頁面。
  • 在觸碰實作之前先決定視覺論點。
  • 在設計樣式之前鎖定成品類型:不要將卡片、小工具、模態框、面板或區塊的提示變成完整的登陸頁面或儀表板。
  • 讓佈局、間距與文字層級承擔大部分的品質。
  • 只要間距能承載關係,就優先使用空間分組而非預設邊框。
  • 將「高級感」視為克制、一致與精準,而非視覺噪音。
  • 使用更少的容器、更少的強調色與更少同時出現的想法。
  • 如果請求的成品是頁面,預設使用填滿螢幕寬度的全視口構圖,而非一個小的居中畫布。
  • 對於平台、市集、電子商務或入口風格的頁面,預設使用全寬頁面骨架,並有意識地約束內部內容,而不是將整個體驗困在一個居中的面板內。
  • 預設保留使用者的資訊密度與文案足跡。
  • 除非請求要求,否則不要添加英雄文案、行銷段落、導航、頁尾、功能區塊、徽章或 CTA 群組。
  • 保持普通卡片簡潔。偏好清晰的標籤、數值與緊湊的輔助文字,勝過憑空創造的宣傳文案。
  • 預設偏好清晰的中性色或略帶冷調的中性色表面;不要自動將奶油色、米色、象牙白或暖色調的米白作為高級感的信號。
  • 保持組件打磨從屬於頁面構圖。
  • 將相關的控制項視為一個幾何與行為系統的成員。
  • 保持預設狀態視覺上安靜;將較強的強調保留給互動與語義狀態。
  • 偏好平衡且穩定的佈局,勝過張力、不對稱或視覺挑釁。
  • 不要僅僅為了避免看起來像套版而引入不對稱或誇張的對比。
  • 區分持續的選中狀態與短暫的活躍或按下反饋。
  • 僅在深度能解釋圖層、材質分離或焦點時才使用它。
  • 將光暈視為例外,而非結構性的元素。
  • 讓行動版成為重新構圖的佈局,而非被擠壓的桌面版。
  • 保持結果可交付且可維護。

優先順序

除非任務明確需要不同的順序,否則按此順序進行:

  1. 請求的範圍與成品邊界
  2. 構圖與結構平衡
  3. 間距節奏與資訊密度
  4. 排版與文案適配
  5. 組件工藝
  6. 互動狀態與行為
  7. 色彩系統與語義克制
  8. 深度提示:邊框、陰影、模糊、亮點
  9. 動態、反饋與轉場

如果頁面在灰度模式下仍然失敗,表示結構問題尚未解決。

工作流程

生成

  1. 識別請求的成品類型與硬性範圍:單一組件、組件集、區塊或完整頁面。
  2. 在該範圍內推斷角色、受眾與密度,而不是擴大它。
  3. 用一個簡短的詞組命名期望的印象,例如 平靜的產品清晰度、企業級精煉 或 安靜的精準。
  4. 在撰寫標記之前,選擇一個穩定的主要區塊與輔助模組。
  5. 如果請求的是卡片或組件,僅使用清晰呈現它所需的最小周圍畫布。
  6. 保留文案足跡,除非使用者要求內容設計。如果需要,可緊縮措辭,但不要創造額外的說明文字。
  7. 如果請求的是頁面,讓外部佈局預設跨越視口,而不是浮動成一個狹窄的居中板塊。
  8. 對於平台或電子商務頁面,先展開頁面骨架:讓導航、英雄框架、分類軌道、活動區域與產品串流在視口中呼吸,然後再將個別模組卡片化。
  9. 定義色彩邏輯:中性色優先,強調色其次。
  10. 在添加打磨之前,先讓組件度量、狀態與行為感覺系統化。
  11. 僅在靜態構圖運作良好後,才添加深度與動態。
  12. 當請求的成品確實涵蓋桌面與行動兩種尺寸時,明確說明其行為。

當視覺方向仍模糊時,閱讀 references/design-principles.md。 當調色板感覺嘈雜、扁平或廉價時,閱讀 references/color-system.md。 當請求圍繞控制項、表單、卡片、表格或覆蓋層時,閱讀 references/component-aesthetics.md。 當 hover、focus、active、selected、loading、success 或 error 行為重要時,閱讀 references/interaction-states.md。 閱讀 references/motion-principles.md 以了解一般的動態紀律。 當轉場、hover 行為或揭示動態需要更多控制時,閱讀 references/motion-patterns.md。 當陰影、亮點、光暈、模糊或深色模式層級邏輯需要更嚴格的控制時,閱讀 references/depth-lighting-system.md。 當使用者要求更具體的視覺個性時,閱讀 references/style-archetypes.md。

審查

  1. 從最大的結構性失敗開始,而非 CSS 細節。
  2. 解釋問題是層級、密度、組件品質、狀態行為、調色板、深度還是動態。
  3. 將每個發現與可讀性、信任、焦點或行動清晰度聯繫起來。
  4. 偏好直接修正,而非泛泛的品味評論。

使用 references/review-rubric.md 來結構化發現。 當 UI 感覺像 AI 生成的或表面高級時,使用 references/anti-patterns.md。 當主要弱點是調色板紀律或強調色誤用時,使用 references/color-system.md。 當主要弱點是控制項、卡片、表格或覆蓋層品質時,使用 references/component-aesthetics.md。 當主要弱點是 hover、focus、active、selected、loading 或 error 行為時,使用 references/interaction-states.md。 當主要弱點是動畫品質、時序或反饋行為時,使用 references/motion-principles.md 和 references/motion-patterns.md。 當主要弱點是陰影模糊、光暈誤用、圖層薄弱或深色模式深度時,使用 references/depth-lighting-system.md。

重構

  1. 選擇 輕度打磨、中度重構 或 完全重建。
  2. 在組件美化之前,先修正佈局與分組。
  3. 當層級不明確時,將薄弱的樣式剝離回灰度結構。
  4. 在添加打磨之前,重建組件度量與狀態邏輯。
  5. 僅重新引入介面仍然需要的色彩、深度與動態。
  6. 如果桌面結構無法轉換,則有意識地重建行動版。
  7. 在編輯之前,說明改寫的層級、核心失敗與預期方向。

在進行廣泛的視覺更改之前,使用 references/rewrite-playbook.md。 在進行廣泛的控制項或覆蓋層改寫之前,使用 references/component-aesthetics.md。 在更改跨狀態的行為之前,使用 references/interaction-states.md。 在改寫嘈雜的調色板之前,使用 references/color-system.md。 在添加或簡化轉場之前,使用 references/motion-principles.md 和 references/motion-patterns.md。 在添加或移除層級、光暈或亮點邏輯之前,使用 references/depth-lighting-system.md。

反模式政策

拒絕依賴以下項目的輸出:

  • 範圍膨脹:將組件請求變成完整頁面、儀表板外殼或登陸佈局
  • 裝飾性文案膨脹:添加未請求的填充描述、徽章、統計數據或 CTA 區塊
  • 頁面級佈局被困在沒有內容理由的不必要狹窄居中外殼內
  • 平台或電子商務頁面被塞入一個 oversized 的居中卡片,而非使用全寬頁面骨架
  • 模板式的居中疊加英雄加卡片網格佈局
  • 不穩定或強制不對稱的佈局,用於製造張力
  • 權重相等的模組,沒有清晰的閱讀順序
  • 過多的表面、描邊、藥丸形狀與圓角半徑
  • 使用奶油色、米色、象牙白或暖色調米白作為「高級感」的預設捷徑
  • 不穩定的中性色上搭配刺眼的強調色
  • 預設狀態已經消耗了過多的強調
  • 將 hover、按下或揭示行為變成 choreography 的互動
  • 看起來像點擊反饋的選中狀態
  • 用於偽裝精緻度的光暈、陰影、模糊或漸層
  • 引起自身注意而非引導感知的動畫
  • 所有東西同時浮動的深度系統
  • 旨在給人留下深刻印象而非釐清結構的強烈視覺處理
  • 僅僅折疊欄位而未重新構圖強調重點的行動版佈局

當結果感覺精緻但仍然廉價時,閱讀 references/anti-patterns.md。

自我批判

在最終輸出之前,檢查:

  • 結果是否保持在使用者請求的範圍內,而沒有憑空創造一個頁面?
  • 第一眼是否在三秒內清晰可辨?
  • 沒有漸層和陰影時,佈局是否仍然感覺可信且平衡良好?
  • 如果這是個頁面,構圖是否預設佔據了螢幕寬度?
  • 如果這是個平台或電子商務頁面,外部骨架是否跨視口展開,而僅內部內容區域保持約束?
  • 文案是否保持任務允許的簡潔,特別是在普通卡片上?
  • 中性色是否足夠平靜且一致,讓強調色有意義?
  • 調色板是否避免了在沒有內容理由的情況下預設使用奶油色或暖白色豪華提示?
  • 相關控制項是否共享相容的高度、內邊距邏輯與圓角半徑紀律?
  • 預設狀態是否足夠安靜,為 focus、active 與 error 狀態留出空間?
  • 選中狀態與按下狀態是否清晰區分?
  • 組件看起來相關聯,但並非都具有相同的權重?
  • 陰影與亮點是否描述了深度,而不是製造迷霧?
  • 在深色 UI 中,深度是否來自表面層級與邊緣定義,然後才是模糊與陰影?
  • 光暈是否足夠罕見,以至於仍然有意義?
  • 動態時序是否感覺受控且簡短?
  • 動態是否強化了互動邏輯,而不是變成 choreography?
  • 構圖是否保持平衡,而不是為了吸引注意力?
  • 第一個行動版視口是否保留了相同的首要訊息或行動?
  • 升級是否移除了噪音,而不是添加了更多樣式?

參考資料

  • 核心設計規則:references/design-principles.md
  • 色彩系統規則:references/color-system.md
  • 組件工藝規則:references/component-aesthetics.md
  • 互動狀態規則:references/interaction-states.md
  • 動態規則:references/motion-principles.md
  • 動態模式規則:references/motion-patterns.md
  • 深度與光影規則:references/depth-lighting-system.md
  • 風格原型:references/style-archetypes.md
  • 失敗模式:references/anti-patterns.md
  • 審查結構:references/review-rubric.md
  • 改寫深度與輸出合約:references/rewrite-playbook.md
  • 精煉判斷範例:references/distilled-examples.md

相關技能