motion-web
以動畫為首的創意網頁。此技能處理所有階段：參考 → 概念 → 規格 → 構建 → 審查。
此技能構建完整的網頁。 動畫是讓網頁變得優秀的原因，但它並非唯一的工作。一個完全沒有動畫的請求——「做個落地頁」、「幫我把這個官網做出來」——仍然屬於此技能，其交付物是一個完成的網站：技術棧、設計標記、章節、文案、組件、狀態、元資料、部署。
優先順序 —— 1 和 2 同等重要：
- 動畫概念與互動編排
- 頁面設計 —— 結構、字級、調色板、間距韻律，任何東西移動之前的樣子
- 作為建構物件的頁面 —— 章節及其文案、組件詞彙表、設計標記層、非理想路徑的狀態（
page-blueprints.md、components.md、project-setup.md、production-polish.md） - 僅在能強化頁面時使用輕量 3D 或 canvas
- 效能、無障礙、減少動畫的替代方案
一個預設外觀頁面上的絕佳動畫機制是一個失敗的頁面。 動畫是優勢，而非藉口。此技能最常見的失敗是將一個精巧的互動黏貼在一個未經設計的版面上——如果關閉動畫後頁面會讓你難堪，那它就還沒完成，再多的彈簧調音也無法解決。設計不是時間上的第二步；它是在最後也必須成立的第二件事。→ references/page-design.md、references/design-slop.md
這是一個針對特定類型網站的設計與建構技能：創意與行銷網頁——登陸頁面、產品頁面、作品集、工作室網站、活動頁面、編輯頁面、輕量文件。它從頭到尾建構它們。它不是一個儀表板/管理後台/數據密集型應用 UI 技能，也不是一個完全的 3D 場景生成器（這些會導向 3d-scene-studio）。一個包含應用程式形狀片段——例如定價表、登入按鈕、控制台截圖——的創意頁面屬於範圍之內；但一個已登入的產品介面則不是。
代理意圖檢測（至關重要 —— 請先閱讀此項）
用戶通常只會說很少。從最少的輸入中檢測他們的意圖，並自主行動。
訊號 → 意圖對照表
| 用戶發送的內容 | 檢測到的意圖 | 該怎麼做 |
|---|---|---|
| 「做個網頁」/「做個落地頁/官網/作品集」加上一個主題，沒有參考資料 | full-build | 整個網站，而非一個動畫機制。page-blueprints.md → project-setup.md → page-design.md → 建構 → components.md → production-polish.md |
| 「這頁要放什麼」/「該有哪些 section」/「資訊架構」/「文案怎麼寫」 | blueprint | page-blueprints.md — 選擇一個主幹，撰寫真實文案，標記每一個虛構的事實 |
| 「導航」/「按鈕」/「表單」/「卡片」/「footer」/「FAQ」/「定價表」/「彈窗」/「組件」 | component | components.md — 先看方言對照表，然後是狀態矩陣。一個沒有定義狀態的組件是不完整的 |
| 「用什麼技術棧」/「Astro 還是 Next」/「怎麼起項目」/「design token」/「字體」/「部署」 | setup | project-setup.md — 頁面階梯 ≠ 動畫階梯；從第 0 階開始攀爬 |
| 「像 demo 不像成品」/「OG 預覽是空的」/「沒有 favicon」/「404」/「空狀態」/「暗色模式」/「表單沒校驗」 | polish | production-polish.md — 所有項目都是可檢查的；執行第 §9 節而不是估計 |
| 一個裸 URL（無其他文字） | url-drop | 打開它並解構（複製模式步驟 1–2），然後詢問：重建這個，或者用它作為用戶自己東西的參考？ |
| 一個 URL + 「做個網頁」或「參考這個」 | replicate → build | 先解構該 URL（複製模式），然後為用戶自己的內容提出一個動畫概念 |
| 參考 + 「復刻出來並收錄成 case」/「存進 skill」/「做成案例」 | case-authoring | cases/AUTHORING.md — 先通過階段 0 閘門：從參考中剝離圖像；如果沒有任何東西存活，請在建構之前處理好素材，而不是之後 |
| 一個 URL + 「復刻」/「做一個類似的」/「參考這個做」 | replicate | 解構 → 映射到模式 → 立即建構。 |
| 一個指向論文/文章/部落格的 URL | doc-drop | 閱讀它，用可提取的值命名技術，如果被要求則從一個開始建構（文件/文章丟置） |
| 一個模糊的簡報（「做個很酷的網頁」/「做個 portfolio」） | freeform-build | 透過 composition-guide.md 進行編排 → 獨立選擇風格+脈絡 |
| 僅一個主題（「做一個關於 AI 的落地頁」） | spec → build | 透過 composition-guide.md 進行編排 → 提出視覺方向，立即建構 |
| 附有參考資料的詳細簡報 | spec → build | 撰寫 MOTION_SPEC.md → 獲得批准 → 建構 |
| 「審查」/「有什麼問題」/「gap」 | audit | 檢查現有作品中的動畫/效能/無障礙差距——包括靜止幀，依據 design-slop.md |
| 「不好看」/「太醜」/「像 AI 做的」/「沒設計感」/「普通」 | design-audit | 在動畫關閉的狀態下截圖，並運行 design-slop.md 中的閘門。不要調整彈簧——抱怨來自於靜止幀 |
| 「版式」/「排版」/「字太小」/「留白」/「結構」/「section 都長一樣」 | design | page-design.md — 鉅觀結構、字級、間距韻律，對照當前獲獎作品進行衡量 |
| 在現有頁面上「加上…」 | incremental-build | 用新的動畫擴展現有實作 |
| 一個影片參考（Pinterest/Dribbble/X 剪輯） | video-ref | 停止 —— 在撰寫任何程式碼之前，先執行下面的影片參考協議 |
| 在現有動畫上「手感差」/「太生硬」/「不跟手」/「四平八穩」 | handfeel-tune | 根據 handfeel.md 進行審查——彈簧、速度耦合、次級動畫 |
| 「跟手但總差一點」/「一抖一抖」/手感隨幀率變化，出現在任何跟隨的東西上（相機、游標、軌道、工具提示） | handfeel-tune | 不是 §1 的彈簧——handfeel.md §7: 1-exp(-k·dt)，speed/k 領先項，並且在濾波後絕不進行修正 |
| 「能不能不用 GSAP」/只是個入場或視差/想要更輕 | build | 先檢查階梯 1.5 — 原生 animation-timeline / animation-trigger / sibling-index() → build-mode.md 階梯 + pattern-recipes.md #16。Firefox 獲取靜態結束狀態 |
| 素材是一個真實存在的地方（實拍/掃描），要走進去 | build | 階梯 5.5 — 先於模型使用 3D Gaussian splats → build-mode.md 階梯 |
| 卡片/圖片要彎折、旗幟、翻頁、把截圖釘進立體面、「skew 不夠用」 | warp | 角落釘點透視變換 → pattern-recipes.md #17。守護每個四邊形並將邊緣傾斜夾在 asin(h/w) ——一個未受守護的四邊形會畫出一個螢幕大小的區塊而無錯誤提示 |
| 在現有動畫上「點不開」/「只有一個能點」/「沒人會發現」/「看不到」 | affordance-audit | 不要先碰觸命中測試程式碼。 根據 affordance.md 進行審查——機制通常是好的；邀請訊息遺失或已過期 |
| 一堆圖像素材 + 「做成一個 3D 場景」/「要有縱深」/「camera 要能走進去」 | image-plane-3d | 不要使用模型。 從真實透視相機中的平面構建場景 → image-plane-3d.md（階梯第 5 階） |
| 在渲染場景上「有拼接感」/「沒融進去」/「像貼上去的」 | image-plane-3d | 在修改美術之前先測量：每組素材的平均 R−B 和亮度、接觸陰影是否存在 → image-plane-3d.md §6–7 |
| 「這個該用什麼畫」/「DOM 還是 canvas」/頁面只會輸出 div 和系統字體/參考明顯不是 DOM 能做的 | render-layer | 先決定圖層再決定機制 → render-layer.md §1。圖層是一個聲明，寫入 case README，由 verify_case.py --layer 核對 |
| 手繪 / 墨線 / 描邊風的 3D，「像畫出來的不像渲出來的」，boil / 抖線 / 紙紋 | ink-render | render-layer.md §3 — 深度不連續描邊（關閉法線摺痕）、靜態 warp 與動態 boil 分離、boil 時脈 11Hz 對 60fps 渲染 |
| 原始圖層 / 需要去背的渲染圖，「摳圖」/「素材怎麼進場景」/「圖糊了」 | asset-pipeline | 根據圖像自身的背景進行去背，裁切至 alpha 邊界框，編寫元資料腳本，列印每個元素的解析度預算 → image-asset-pipeline.md |
| 任何無頭檢查；一個數字與你看到的不符；「怎麼驗」 | verify | 先構建探測表面——可固定的時鐘、__seek、__hold、狀態退出——然後測量 → verification-harness.md |
| 在滾動時間軸上「這一段什麼都沒發生」/「節奏不好」/「一堆字一下就出來了」 | timeline-audit | 將每個軌道與一個滾動軸對齊；無效的節拍是重合的平台，而不是一個緩慢的圖層 → timeline-orchestration.md |
| 帶有許多素材的長滾動場景；「卡」/「加載慢」/「記憶體爆了」，數百個圖層 | scene-streaming | 按螢幕視窗啟動，分割大型上傳，在掃描中讓步，完全釋放 → scene-streaming.md |
| 任何有聲音的東西——背景音樂、環境音、互動音效、「音效太少」/「氛圍音聽不清但也別吵」 | scene-audio | 三個匯流排（bgm / hand / world），每個場景的曲線，在較大襯底之上的離散事件 → scene-audio.md |
永遠不要問用戶該使用哪種模式。 檢測它。繼續。僅在簡報在兩個非常不同的輸出之間確實模糊不清時（例如，規格 vs. 立即建構）才停止。
影片參考協議（硬規則 —— 不許猜）
觸發條件：參考是一個你實際上無法觀看的影片——Pinterest pin、Dribbble 鏡頭、X 剪輯、站外短鏈。一個標題或文字描述並非動畫資訊。
- 在得出沒有實際頁面的結論之前，先閱讀討論串。 作者幾乎總是會在回覆中發布 URL，而回覆也會告訴你這部作品是否甚至是一個網頁。測量於 2026-09-02：先前的會話將七個影片參考宣告為無 URL，並將其階段 1 用於幀測量；這七個全部都有實際網站，由作者本人發布，並且一個貼文中的四個剪輯中有三個被發現是 Jitter / Figma Motion / Rive 的渲染，根本沒有網頁實作（
cases/AUTHORING.md階段 1）。safe-x tweet <url> --json，然後解析回覆中的所有t.co連結。 - 永遠不要根據猜測來建構動畫。 如果你只提取了一個標題/描述，你只知道主題，而不是動畫。無論如何都建構會浪費一次完整的迭代——這是一個有記錄的失敗模式（2026-07-06，海鮮英雄頁面：猜測「環繞」，實際是上升的對角線；經歷了兩次重建）。
- 立即索取 2-3 個關鍵幀。 一句話：「這個影片我打不開，截 2-3 幀關鍵畫面（入場/中間/離場）發我」。
- 在編碼之前，將軌跡描述為明確的幾何形狀，並獲得確認：
- 錨點：元素入場 / 達到頂點 / 離場的位置（角落、三分之一處）
- 姿態：旋轉跟隨路徑切線 / 保持恆定 / 落後
- 次級反應：還有什麼會移動（背景形狀、線條、文字）以及如何移動
- 範例：「右下入場 → 中心 → 左上離場的上升對角線，魚頭恆定朝向左上」——錯誤的猜測在此處消亡，而非在程式碼中
- 只有這樣才映射到 pattern-recipes / handfeel.md 並進行建構。
單張截圖遵循相同規則：一個幀只給出姿態，而非軌跡。如果路徑很重要，請索取更多幀。
複製模式
當用戶發送一個帶有「復刻」/「做一個類似的」/「能不能做這種效果」的 URL 時——解構它，然後建構。沒有儲存步驟；交付物就是頁面。
複製執行路徑
-
打開頁面並將其作為三個圖層來閱讀，使用任何可用的瀏覽器工具（Claude Preview、
browser-use、Playwright）：技術棧（函式庫、緩動函數、關鍵幀、CSS 變數——套件名稱會顯示它們）、滾動編排（哪個元素在哪個區段上被 pin 住、導軌及其 px 距離、視差速率、被擦寫的屬性、入場點——在大約 9 個滾動位置進行取樣，並比較getBoundingClientRect以及之間的計算樣式）、以及 WebGL 圖層（程式數量、繪製呼叫、自訂 uniform 名稱；如果你需要著色器原始碼，在頁面腳本執行之前包裹getContext）。兩個腳本涵蓋了可測量的部分：scripts/measure_structure.py <url>用於靜態頁面（章節、導航、按鈕、設計標記尺度、媒體、元資料、行動版溢出）和scripts/measure_churn.py <url>用於在實際滾輪下頁面有多少實際移動。URL 必須是作品本身，永遠不是畫廊列表（awwwards.com/sites/<slug>）：一個列表頁面會給你畫廊自己的 chrome，並且六個不同的獲獎者會回來具有相同的函式庫、相同的關鍵幀和相同的字體。 -
解構——說明你發現了什麼，並引用數字而非印象：
- 「GSAP 3.12 + ScrollTrigger + Lenis；
.home-animate__wrapper在 0.25–0.50 被 pin 住，期間.icon橫移 +1545px，出場是 0.25/0.38/0.62 三段 stagger」 - 「背景是原生 WebGL2，14 個 program、944 個 draw calls，uniform 裡有 bloomStrength/blurTexture1-5 和 cloudCoverage/cloudDensity —— 是 UnrealBloom + 體積雲」
永遠不要僅憑一個 context 就報告「用了 WebGL」——一個沒有指定尺寸、300×150、沒有連結到任何程式的 context 是 Modernizr 風格的功能檢測，而非場景。計算連結的程式數量和繪製呼叫次數。
- 「GSAP 3.12 + ScrollTrigger + Lenis；
-
映射到 pattern-recipes——在
references/pattern-recipes.md中找到最接近的配方 -
填補差距——參考中使用的、但我們配方中沒有的內容，根據提取的值從頭編寫
-
立即建構——建立頁面架構，運行它，進行視覺驗證
-
報告——「復刻了 [site] 的核心動效，用了 [X] 實現 [Y]，和原版差異是 [Z]」
複製 ≠ 複製貼上
- 要做：重現互動模式、動畫特徵、時序感覺
- 不要做：複製專有品牌顏色、確切副本文案、可識別的產品 UI
- 要做：將該技術改編為用戶自己的內容和調色板
- 在報告中註明哪些部分被改編了，哪些部分忠於原作
自由形式建構模式（當用戶未給予任何方向時）
當用戶說「做個網頁」/「隨便做」/「自己想一個主題」或給出一個簡單模糊的主題（例如「做一個 AI agent 平台落地頁」）時，這是一個發揮創造力的邀請。 不要預設使用通用模板，不要使用僵硬的 1 對 1 路由映射，也不要提問澄清問題。
自由形式行動路徑（運行時創意循環——創造發生在執行中）
…
[為翻譯已截斷]