高品質 UI 原型設計

一、核心目標

一切為了做出好看的產品介面，同時保證好用。

交付應像成熟設計師完成的真實產品，而不是套模板、堆卡片、換配色的普通原型。重點關注整體氣質、視覺層級、字體表現、構圖、色彩關係、圖形語言、動效和細節完成度。

審美優先，但不犧牲可用性：視覺與功能共同設計，不以刪減功能換取表面簡潔。
風格由產品決定：允許克制、精緻、活潑、先鋒、華麗或富有實驗性，不把「高級簡約」當成唯一答案。
大膽自主設計：不要等待用戶提供顏色、字體、佈局和動畫參數。理解需求後主動探索更好的方案。
拒絕模板感：不預設使用常見 SaaS 佈局、固定配色、統一卡片和千篇一律的組件組合。
獨立推導：相同品類也應根據內容與定位形成自己的表達，不機械複用上一輪的視覺方案。

設計原則參考

設計判斷可參考以下成熟原則，但不要照搬其示例或轉化成固定參數：

視覺層級、比例、平衡、對比、格式塔與視覺焦點。
網格、構圖、節奏、留白、統一性與品牌識別。
一致性、可發現性、漸進披露、回饋和可及性。
字體性格、字形品質、閱讀場景和字體組合。
動效的連續性、自然加減速、空間關係和交互回饋。

參考：NNGroup 視覺設計原則 · Figma UI 設計原則 · IBM Design Language · Apple HIG Motion

不復用已有頁面

新頁面不讀取、不截圖、不分析 ui/ 下已有頁面，不複製其 HTML / CSS / JS 作為起點。
不復用上一輪的顏色、字體、佈局骨架、組件組合和動效參數。設計差異不能只靠換色、換文案或換圖片，應重新思考資訊結構和視覺表達。
只允許讀取本技能、skills/ui-metadata/SKILL.md、tools/ 用法說明及用戶當次提供的參考。
用戶明確要求修改已有頁面時，只讀取對應頁面。

二、先理解產品，再決定設計

先判斷產品定位、目標用戶、使用場景、內容特徵和品牌氣質，再確定視覺方向。不要將下面的分類當作模板，它們只是設計思路：

產品氣質	可探索的設計表達
國際化 / 英文品牌	精簡文案、富有表現力的字體、大尺度排版、字距與留白、攝影和符號
潮流 / 創意 / 年輕化	大膽構圖、強烈字體個性、圖標符號、幾何圖形、視覺化數字和靈活的色彩關係
專業工具 / 桌面軟體	清晰的資訊組織、精緻的字體、舒適的資訊密度、細膩的狀態回饋和克制的色彩
科技 / AI / 數據產品	現代字體、數據視覺化、結構圖形、動態回饋和有辨識度的科技視覺
文化 / 藝術 / 內容品牌	編輯式排版、襯線或特色字體、攝影、材質感、留白和富有情緒的色彩
高端消費 / 生活方式	精緻字體、產品影像、材質與光影、細節質感和克制但鮮明的品牌表達

可以混合不同方向，也可以提出更適合當前產品的原創方向。不要機械套用某種風格名稱。

交付容器

類型	判斷依據	外框與滾動	畫布邊界
A 軟體	後台、工具、儀表板	完整視窗展示；長列表和長文局部滾動	視窗內鎖死，浮層不越界
B 網頁	品牌、落地、內容站、作品集	自然文件流；整頁垂直滾動	視口即畫布，無邊界限制
C App	行動優先、點名 App / 手機 / 小程式	手機比例外框；只在框內滾動	手機框內鎖死
D 組件	播放器、燈箱、上傳框等單一控件	按內容自然尺寸展示；內部局部滾動	組件框內鎖死

用戶點明就按用戶要求，沒點明按功能推斷。容器只決定展示方式，不限制視覺風格。

容器設計要點

A 軟體

讓視窗、背景和內容形成完整的展示關係；外框服務於產品，不要為了懸浮效果添加多餘裝飾。
優先讓主要資訊和常用操作自然共存；複雜內容透過合理分區和局部滾動承載。
先做好空間分配和響應式佈局，再決定滾動區域；不靠裁切、隱藏滾動條或整體縮放掩蓋佈局問題。
窄螢幕優先重排、分組和調整資訊呈現，不得讓核心功能消失。
軟體寬度不超過整個視窗的 85%，高度不超過 90%，四周留出間距居中顯示。

B 網頁

根據內容選擇長頁敘事、模塊化瀏覽、沉浸式首屏或其他合適結構。
頁面應有視覺節奏和內容層次，避免每個區塊都重複同一種佈局。
可根據敘事需要加入滾動驅動動畫；不為滿足規則而強行添加滾動效果。

C App

採用符合行動裝置習慣的導航、單列或適合場景的佈局和易操作控件。
對原生控件進行必要的視覺客製，但不得損害可及性和操作體驗。
觸控區域、底部導航和內容滾動應符合真實行動端使用習慣。
建議採用 iPhone 手機尺寸設計（可不建立動態島、前置鏡頭組件）。

D 組件

按組件用途和內容自然成形，不套用完整軟體外殼。
重點設計空閒、懸停、聚焦、載入、完成、出錯等狀態，所有狀態變化應清楚、連貫且可理解。

以上四類的浮層邊界統一見下一節。

容器邊界：把介面鎖在畫布裡（軟體 / App / 組件強制）

這是硬約束，不是風格偏好。 網頁的邊界是瀏覽器視口，軟體、App、組件有自己的邊界。畫布之外只有「舞台」（看台背景），一旦對話框、抽屜、遮罩、高斯模糊跑到畫布外，介面就從「一個軟體」退化成「一張網頁截圖」——這是這類原型最常見的破綻。

三層結構

產品本體放在 canvas 裡，stage 只負責居中與背景，任何產品語義都不放在 stage 上。

body > .stage          舞台：居中 + 背景，不承載產品內容
       └ .canvas      畫布：產品的介面邊界
          ├ 產品內容（標題欄 / 主區 / 側欄…）
          └ .layer     浮層組：對話框、抽屜、下拉、Toast
              ├ .scrim  遮罩：變暗 + 模糊
              └ .dialog 對話框本體

關鍵屬性（偽代碼）：

.canvas {
  position: relative;    /* 浮層定位基準 */
  contain: paint;        /* 裁剪 + 讓 fixed 後代錨定到畫布，不可省 */
  overflow: hidden;      /* 越界內容一律剪掉 */
  isolation: isolate;    /* 層疊與背景取樣隔離在畫布內 */
  container-type: size;  /* 可選：內部可用 cqw/cqh 定尺寸 */
  width: min(1440px, 100%);
  height: min(900px, calc(100svh - 2 * var(--stage-pad))); /* 用了 container-type 就必須給顯式寬高 */
}

.layer  { position: absolute; inset: 0; }              /* 參照畫布，絕不用 fixed */
.scrim  { position: absolute; inset: 0;               /* 尺寸即畫布尺寸 → 模糊範圍嚴格等於畫布 */
          background: rgb(8 10 14 / .45); backdrop-filter: blur(10px); }
.dialog { position: relative; width: min(720px, 78cqw); max-height: 82cqh;
          display: flex; flex-direction: column; }
.dialog-body { flex: 1; min-height: 0; overflow: auto; }  /* 只讓內容區滾動 */

為什麼必須顯式寫 `contain: paint`

實測（Edge，1400×1200）：只有 overflow: hidden 時，畫布內的 position: fixed 元素依然相對瀏覽器視口定位並逃逸；只有加上 contain: paint（或 transform / filter / will-change: transform / contain: layout）後，fixed 才會錨定到畫布並被裁剪。container-type: size 單獨不生效，必須與 contain: paint 並存。不需要 cqw/cqh 時可去掉 container-type。

禁止

畫布內用 position: fixed 定位浮層——參照系是視口，天生越界。
用 vw / vh / dvh 給畫布內元素定尺寸——視口單位必然撐破畫布。
把遮罩、模糊、陰影施加在 body、.stage 或畫布之外的元素上。
用 transform: scale() 整體縮放畫布來「塞進」螢幕——文字、模糊、陰影會一起糊掉。正確做法是 min() 定尺寸 + 內部自適應。
讓畫布外的舞台出現產品語義內容（說明文字、按鈕、裝飾圖形都不行）。

對話框尺寸規範（軟體類強制）

預設橫向：寬 > 高。 軟體對話框應優先採用寬螢幕設計。

內容量	比例取向	建議尺寸（相對畫布）	說明
多（表格、圖表、長表單、編輯器）	寬 > 高，取 16:9 或 4:3	寬 60%–80% 畫布寬，高不超過 75% 畫布高	內容多時優先 16:9，其次 4:3；需要並排才不浪費橫向空間
中（設定面板、多欄位表單）	寬 > 高	寬 480–640px，高 320–420px	保持橫向，但不鋪滿
少（確認、單欄位、提示）	可接近方形	寬 320–420px，高 220–320px	縱向也合理，別為了比例硬撐寬
縱向列表（長列表、樹、選擇器）	高 > 寬	寬 320–400px，高 60%–80% 畫布高	縱向是允許的例外：單一列表天然豎排
工作區（日程、看板、編輯全螢幕）	接近畫布全尺寸	畫布內留 16–24px 邊距	仍然不是 fixed，仍在畫布內

判定順序：先問「內容是否需要並排」。需要並排、或有橫向可讀性要求的（表格、圖表、程式碼、時間軸）→ 橫向；單一列表 / 樹形結構 / 分步表單 → 可以縱向。

落地寫法：aspect-ratio 定比例、max-height 兜底、寬度用 cqw、高度用 cqh。

.dialog--wide   { width: min(72cqw, 860px); aspect-ratio: 16 / 9; max-height: 78cqh; }  /* 內容多 */
.dialog--panel  { width: min(56cqw, 680px); aspect-ratio: 4 / 3;  max-height: 78cqh; }  /* 內容多·緊湊 */
.dialog--compact{ width: min(32cqw, 380px); aspect-ratio: 5 / 4; }                        /* 內容少 */
.dialog--tall   { width: min(30cqw, 360px); height: min(72cqh, 620px); }                   /* 單一縱向列表 */

內容超高時 max-height 生效、比例允許被打破——這是有意的：寧可比例略變，也不要內容溢出畫布。

其他約束：

對話框在畫布內居中，四周留白不小於 24px；不貼邊、不跨出畫布。
內容超出時只讓 .dialog-body 滾動，頭部和底部固定。
變暗遮罩取 rgb(0 0 0 / .35) ~ rgb(0 0 0 / .5)，模糊 8–16px；作用範圍嚴格等於畫布。
同一軟體裡的對話框成組出現時尺寸成體系（同一類用同一尺寸），不要一個 16:9 一個窄高條。

三、設計流程

動手前讀取 skills/ui-metadata/SKILL.md，按其規範在頁面目錄寫入 metadata.json。

0. 圖片輸入的來源聲明（imageToUI）

當用戶用「一張 / 多張圖片」作為生成輸入（即「看圖做 UI」「以圖還原」「AI 識圖一比一復刻」）時，必須在 metadata.json 寫入 imageToUI 欄位，記錄該圖的來源，讓畫廊卡片能回溯原始參考圖並點擊查看。處理方式按輸入類型區分：

輸入是圖片 URL（http://、https:// 或 // 開頭的連結）：直接把該連結原樣寫入 imageToUI，例如 "imageToUI": "https://dribbble.com/shots/15820088-Furniture-Board-Desktop-concept"。畫廊會渲染一個圖片圖標，點擊在新標籤頁打開該來源。
輸入是 base64 編碼或本地圖片路徑：AI 必須先詢問用戶二選一，不得靜默處理：
1. 提供該圖的源連結位址（推薦用於有公開出處的參考圖，如 Dribbble / Behance / 設計稿連結）；或
2. 允許 AI 把這張圖複製一份到 ui/<slug>/assets/ 目錄作為來源存檔（強烈推薦——保證來源可追溯、離線可看、隨原型一起發布），隨後把 imageToUI 寫成相對路徑，如 "./assets/source-<slug>.png"。
⚠️ 禁止把 base64 字串或本地絕對路徑原樣寫進 imageToUI：本地路徑在畫廊伺服器上不可達、base64 無法被瀏覽器打開，卡片圖標會失效。用戶未明確選擇前，不要寫該欄位。

欄位取值規則（畫廊 catalog.mjs 據此解析，詳見 skills/ui-metadata/SKILL.md）：

以 http:// / https:// / // 開頭 → 視為外鏈，點擊跳轉。
其他（./assets/...、assets/...）→ 視為原型目錄內的資源，解析為 /prototypes/<slug>/... 並在新標籤頁打開圖片。
留空 / 不寫 → 卡片不顯示該圖標。

1. 明確設計任務

確定產品定位、用戶場景、核心任務、資訊優先級和首屏重點。先準備真實文案與合理數據，再設計呈現方式，避免空洞佔位內容。

2. 確定視覺方向

用簡短的設計說明明確本頁的氣質，不必填寫固定格式或參數表。至少想清楚：

整體視覺印象與品牌性格。
排版、構圖和資訊層級如何表達內容。
字體如何建立個性與品質。
色彩如何建立氛圍、識別和重點。
圖標、圖形、攝影或數據視覺化如何參與表達。
動畫是否能增強體驗，以及應該採用什麼動效語言。

3. 建立設計系統

根據當前頁面需要建立 CSS 變數和可複用樣式。顏色、字體、字號、間距、圓角、邊框、陰影和動效應有一致的設計邏輯，但不強制固定數量、數值或比例。

不要把設計系統變成限制創意的參數表。 可以靈活調整，但每個選擇都應服務於整體效果。

四、視覺設計重點

4.1 排版與構圖

讓用戶一眼知道應該先看哪裡，再自然理解其他資訊。
利用字號、字重、字體性格、色彩、位置、留白和對齊建立層次，不依賴卡片和邊框堆砌。
根據內容探索網格、不對稱、錯位、分欄、疊排、沉浸式、編輯式或其他構圖。
允許大膽的大小對比、特殊斷行和視覺張力，但整體必須協調、易讀。
頁面應有疏密、輕重和節奏變化，避免所有區域平均用力。
不要預設居中、對稱、等寬卡片或相同的區塊排列。
視覺設計應幫助用戶理解和完成任務，而不是只追求截圖效果。

4.2 功能與簡約的關係

功能完整與視覺美觀必須共同實現。簡約不是刪功能。

按產品品類提供用戶合理期待的完整能力，不得為了讓頁面更空、更簡單或更好截圖而擅自刪除功能。
先最佳化資訊架構、功能分組、入口位置、交互流程和視覺表達。
使用漸進披露、上下文操作、快捷入口、圖標化表達、選單和抽屜等方式降低視覺負擔。
高頻功能應容易發現和操作；低頻功能可以收納，但不能無故隱藏到難以發現。
圖標可以減少文字，但必須容易理解；重要操作必要時保留文字標籤。
只有用戶明確要求優先極簡、刪減冗餘功能，或某項功能確實不屬於產品範圍時，才考慮刪除，並說明原因。
功能入口、狀態和回饋必須完整；不能只做視覺上存在、實際沒有響應的控件。

4.3 文案與資訊表達

介面不是說明書。能簡潔表達就不要寫長段解釋，但不能為了少字損失必要資訊。
介面裡不得出現任何與「演示 / 原型 / 模擬」有關的文字或圖形：不寫「演示模式」「示例數據」「Mock 數據」「測試帳號」「這是原型」；不畫氣泡標註、箭頭提示、序號標記、教學高亮框；不用「示意圖」「佔位圖」「Lorem ipsum」「待補充」。介面裡的每個字、每個圖標，都必須是產品真實會有的內容。
把原型當成正式上線的產品介面設計：文案像真實業務數據，圖表有可信數值關係，空狀態寫產品自己的引導語，錯誤提示寫用戶真正會遇到的情況。實現不了的部分（伺服器端介面）在交付說明裡講，不寫進介面。
英文品牌或國際化頁面可使用精簡詞語、短標籤、大字號文字和視覺化符號。
潮流、創意頁面可以更多使用圖標、符號、圖形和視覺化數字；專業工具則優先保證資訊清晰。
中文表達自然準確，不為裝飾而硬塞英文或無意義縮寫。
文案要具體、有資訊量，避免空洞行銷詞、重複標題和自述式引導。
狀態、趨勢、流程、分類和比例可根據理解成本選擇圖標、圖表、結構圖或文字，不強制某一種表達方式。

4.4 字體設計（重點）

別把預設系統字體當最終方案。 除長篇正文、密集資訊、閱讀優先場景外，都要主動挑字體。

要高級感 / 設計感 / 品牌感時，主動找展示字體或字體組合，別用預設字體交差。
標題、字標、關鍵數字、正文、輔助資訊可用不同性格，但組合要協調，別堆太多字體。
英文：幾何無襯線、人文無襯線、Grotesk、襯線、窄 / 寬體、Display、手寫、實驗體，按氣質選，別預設 Inter。
中文：現代黑體、宋體 / 襯線、圓體、書寫體、特色展示體；展示體只用於標題短文本，長正文優先可讀性。
數字：基線、字面高度、寬度、對齊要統一，別用寬窄不一的藝術字體。
字重、字寬、字距、大小寫、斜體、斷行都能出設計感，別只靠換字體名。
預設最小字號 12px（下限，非死規則）；小 logo / 圖案內嵌文字可按需調小。排版靠寬度自適應換行，不主動斷行。

字體來源、CDN 引用、載入慢的處理見第六節「字體」。

4.5 配色設計

不要固定使用某套色值、配色比例或強調色。先判斷產品氣質，再大膽探索合適的色彩關係。

可考慮高級灰、中性色、低飽和色、自然色、冷暖對比、品牌色、明亮撞色、深色奢華、單色體系等方向。色彩可以克制，也可以鮮明；重點是協調、層次、識別度和情緒表達。

像霧綠、青綠、霧藍這種偏冷的青色調，別排在配色探索的前面——如今 AI 做的介面大多都是這一掛，太容易撞臉，留作最後兜底就好。

顏色要有明確職責，背景、內容、文字、重點和狀態之間形成清楚關係。
強調色不必固定為某種顏色，應根據品牌和頁面內容選擇。
可以使用漸變、透明、材質和光影，但必須有設計目的，不要把漸變、發光或玻璃效果當作預設高級感。
顏色對比必須保證文字和重要控件可辨識；不能為了氛圍犧牲可讀性。
不要因為追求低飽和或高級灰而讓頁面失去重點、層次和活力。

4.6 圖標、圖形與影像

圖標、符號、幾何圖形、插畫、攝影和數據視覺化都可以成為主要視覺語言，不限於文字和卡片。
根據產品氣質選擇圖形風格，確保線條、比例、質感和表現方式協調。
功能圖標優先易識別；品牌或創意圖形可以更有個性。
不要混用風格明顯不同的圖標庫，不用 emoji 代替正式功能圖標。
圖形必須有表達目的：幫助識別、解釋關係、傳遞狀態、塑造品牌或增強視覺張力。
影像應有明確的構圖、色彩和內容邏輯，避免隨意拼圖或無關素材填充頁面。

4.7 細節與完成度

關注字體渲染、字距、對齊、邊界、圖標比例、層級、交互狀態和內容細節。
邊框、分割線、陰影、圓角、紋理和透明效果按需使用，不為裝飾而裝飾。
組件之間既要保持一致，也允許關鍵區域擁有合理的視覺差異。
頁面不能只有首屏精緻，滾動區域、彈層、選單、空狀態和錯誤狀態也要完整設計。
不要為了「像設計稿」犧牲真實使用時的可讀性、可操作性和響應速度。

4.8 邊框不能被裁掉（裁剪容器必讀）

帶邊框的組件放進會裁剪內容的父容器時，父容器內邊距必須 ≥ 組件所有狀態的最大邊框寬度。 否則邊框被切掉一截，邊界缺失會直接讀作「渲染壞了」。

機制

overflow: hidden 裁的是容器的 padding box（內容盒 + 內邊距）：

容器內邊距能吸收子元素向外溢出 → 留夠內邊距即可露出邊框；
但 box-shadow 外擴與 outline 畫在邊框盒之外，內邊距救不回來。

解法（按優先級）

1. 全域 box-sizing: border-box（首選） —— 從根上消除溢出：

*, *::before, *::after { box-sizing: border-box; }

2. 父容器留出邊框餘量 —— padding ≥ 邊框寬 + 1px。實測：邊框 4px 時，padding ≤ 6px 右邊框被裁，≥ 7px 完整；恰等於邊框寬 4px 仍會被裁，務必留餘量。

3. 用 inset 陰影替代邊框 —— 不佔空間、永不被裁：

.card { border: 0; box-shadow: inset 0 0 0 1px var(--line); }

禁止

外擴 box-shadow / outline 當常駐邊框（畫在邊框盒外，一裁就沒）；
負 margin 合併相鄰邊框（有裁剪時必被切）。

hover 才出現邊框時

最高頻場景：預設態正常，一 hover 邊框就少一截。用透明邊框佔位、只切顏色，切換不跳動也不溢出：

.item { border: 1px solid transparent; transition: border-color .18s; }
.item:hover { border-color: var(--line); }

逐組件核對見第九節自檢第 13 條。

4.9 原生控件統一風格

瀏覽器原生控件（滾動條、select 下拉、input / textarea 聚焦態、checkbox / radio / range 強調色、日期選擇器等）由系統渲染，外觀與自繪 UI 脫節，是最容易被忽略、也最破壞整體感的破綻。凡是頁面裡出現的原生控件，都要收斂進產品視覺語言，不保留系統預設外觀。

滾動條：WebKit 用 ::-webkit-scrollbar* 系列、Firefox 用 scrollbar-width / scrollbar-color 統一軌道與滑塊的顏色、圓角和懸停態；只掛在局部滾動區，寬度克制（約 8–10px），不全域加粗。
輸入框：input / textarea / select 用 appearance: none 自繪邊框、圓角與 focus-visible 聚焦態，不沿用瀏覽器預設邊框和內陰影。
select 下拉：原生 option 面板無法深度客製；用 appearance: none + 自繪展開箭頭，並用 --control-* 變數與按鈕、輸入框保持一致。需要搜尋、分組、自訂高亮時，用自繪下拉替代原生 select。
強調色：checkbox / radio / range / progress 用 accent-color: var(--brand)，不保留系統藍。
複合輸入：顏色、日期、時間等面板無法客製，重要產品用自繪或限定輸入格式替代。

要點：所有原生控件的內邊距、字號、圓角、聚焦態都納入設計變數（如 --control-bg / --control-border / --control-radius / --control-focus），與卡片、按鈕保持同一套視覺，杜絕「兩套語言」。

五、動畫設計與實現

動畫是 UI 設計的一部分，不只是給按鈕添加 hover 效果。應根據產品氣質和用戶需求，主動判斷動畫在介面中的角色。

5.1 先判斷動畫需求

用戶明確提出優秀動畫、高級動效、流暢動畫、炫酷、花俏、沉浸式、電影感、動態視覺或類似要求時，應將動畫作為重點設計內容，主動使用 GSAP 等專業動畫庫實現複雜效果，不要只用簡單 CSS transition 敷衍。
對品牌官網、創意展示、產品發布、作品集、互動敘事等適合動態表達的頁面，可以主動設計有節奏的入場、滾動敘事、視差、文字動畫、圖形變形、遮罩揭示、分層運動和連貫轉場。
對專業工具、後台和高頻操作介面，動畫應幫助理解狀態、建立空間關係和提供回饋；可以精緻流暢，但不能妨礙效率。
用戶沒有明確要求複雜動畫時，根據產品氣質適度設計，不要為了炫技添加無意義動效。
不要把所有元素做成一種淡入上移，也不要讓每個組件都獨立表演。

5.2 動畫質感

避免機械線性運動：空間移動、縮放和介面轉場通常採用自然的加速、減速、非對稱緩動或彈簧效果。Linear 僅適合勻速旋轉、進度、持續滾動等確有需要的場景。
使用有質感的緩動：可根據運動距離、元素質量感和場景選擇 ease-out、ease-in-out、power、expo、back、spring 等曲線；克制使用誇張彈性，避免廉價的反覆彈跳。
適當加入阻尼感：大面積面板、浮層、拖拽、跟隨、磁吸和空間轉場可以有慣性、阻尼、回彈或彈簧感，讓動作更自然。
動作要有因果：進入、離開、展開、收起、切換、拖動和狀態變化應符合用戶對空間和物體的直覺。
編排要有節奏：可以使用錯峰、重疊、連續銜接和分層運動，但要有主次，不能所有元素同時亂動。
動畫應響應內容和操作：避免無意義的永久循環、持續漂浮和搶奪注意力的背景動畫。
性能優先：優先使用 transform、opacity 等適合合成的屬性；複雜濾鏡、模糊和大面積即時效果需謹慎，避免掉幀。

5.3 優先用 gsap-skills 與 GSAP

做 GSAP 動畫前先判定：若當前系統 / agent 已安裝 gsap-skills 技能，動畫設計盡量呼叫它取得最新 API 與寫法；若未安裝，主動向用戶發起確認，推薦其執行 npx skills add https://github.com/greensock/gsap-skills 安裝（由用戶決定是否安裝），安裝後再用於動畫設計。不要憑記憶手寫過時的 GSAP 用法。

複雜動畫（入場敘事、滾動驅動、時間軸編排、交互拖拽、多元素協同）優先使用 GSAP：

用 Timeline 統一編排一組動畫（標籤、重疊、嵌套、回調），不靠一堆互不相關的 delay。
滾動驅動用 ScrollTrigger；平滑滾動、逐字、路徑、翻轉等按需引插件。
簡單狀態回饋用 CSS transition / keyframes 即可，不為用庫而引庫。
透過 CDN 引入（如 gsap@3），遵循第八節技術約定；動畫模塊化管理，便於播放 / 暫停 / 反向 / 重置 / 清理。

5.4 連續操作、打斷與恢復

交互動畫必須考慮用戶連續操作：新操作到來時從當前視覺狀態自然銜接，不閃爍、不跳回初始位置，不讓動畫狀態與真實 UI 脫節。

可逆狀態（展開/收起、開/關）：複用同一 Timeline，reverse() / play() 自然反向，不重新建立。
連續變化目標值（拖拽、游標跟隨）：用 gsap.quickTo() 讓運動始終跟隨最新輸入，不每次新建補間。
多序列銜接：用 Timeline / 嵌套 Timeline / 回調 / 狀態機統一管理，不建立互相爭奪同一屬性的獨立動畫。
按交互語義區分「繼續序列 / 反向播放 / 轉向新目標 / 並行其他屬性」，不要一律追加或一律終止；只覆蓋真正衝突的屬性（GSAP 用 overwrite: "auto"，不隨意 kill() 或全域 overwrite: true）。

5.5 無障礙與性能

尊重 prefers-reduced-motion: reduce，為用戶提供減少動態效果的方案；減少動畫時，資訊和功能仍必須完整。
不用動畫隱藏關鍵內容或延遲用戶必須立即獲得的資訊。
避免高頻閃爍、快速大幅縮放和可能引起不適的視差。
滾動動畫不能影響正常滾動、鍵盤操作和觸控操作。
頁面離開或組件銷毀時，正確清理事件監聽器、ScrollTrigger 和不再需要的動畫實例。
首屏重要內容不能依賴動畫庫載入完成後才顯示。

參考：

六、素材

統一用 tools/resource-getter/get.py 取素材，不要手拼站點 URL，也不要在頁面裡散落一堆來源不明的外鏈。完整來源矩陣、許可與故障排查見 tools/resource-getter/README.md。

選型優先級

透明向量插畫：unDraw / Storyset / DiceBear / Doodle Ipsum
去背 PNG：Pixabay（--transparent）/ pngimg
攝影：Pixabay / Picsum / Unsplash / Pexels
手繪 SVG（幾何、裝飾、圖表）
AI 生圖（最次，規則見下）

預設熱鏈，慢則落盤。 get 的 auto 模式會實測 TTFB：> 0.9s 或讀取 > 2.5s 判定為慢，必須下載到 ui/<page>/assets/；再快也別把二十張遠端大圖堆進首屏。

…

[truncated for translation]

在你喜歡的 AI 中提問

說明文件