site-motion：網站動態評估與版本選擇
使用者說網站「死板」時，問題通常不是缺動畫，也不一定是載入慢，而是每個動作都要離開再重來，頁面又是一堆彼此無關的方塊。所以先判斷問題在哪，再決定要動什麼。
用使用者的語言回覆。技術名詞保留原文。
原則
- 選定前不動正式程式碼：先給診斷、方案和原型，使用者明確選版本後才實作。
- 預設不動版面：沒有明確要求就不換配色、字體和排版，只改互動。整站換風格是另一件事。
- 手機優先：以 375px 判斷與驗收，桌機是附帶。
- 動態要能點才算數：靜態圖看不出手感，版本要做成可以實際操作的原型。
- 動效要有目的：每一項都要說得出在回答使用者什麼問題，例如「我按到了嗎」「我從哪來」「資料更新了嗎」。答不出來就刪。
- 靠搜尋和廣告賺錢的站，SEO 與變現優先於炫技：動畫不能換掉獨立網址、首屏 HTML 內容或廣告可見度。登入後的後台與內部工具不受這條限制。
- 換內容就真換頁，調整同一份內容才原地：看另一篇文章要有新頁面，因為它帶來新的網址和廣告請求；展開、篩選、排序才原地做。
- 動效不能越過站的紅線：先看專案的規範與法遵限制。不拿缺值欄位做視覺，不用動畫暗示沒有根據的訊息。
流程
第 1 步：判斷他要的是哪一種動態
「動態」可能是四件事，解法完全不同。
| 類型 | 可能的說法 | 實際要做的 |
|---|---|---|
| 資料動態 | 內容要自己更新、要即時 | cron、API、輪詢，主要是後端工作，再搭配更新訊號 |
| 回饋動態 | 按下去沒感覺、太死 | 壓感、狀態變化、更新閃爍 |
| 連續動態 | 像跳頁、很原始、像一堆物件 | 頁面轉場、原地展開、共享元素、手勢 |
| 敘事動畫 | 首頁要有氣勢、滾動特效、GSAP | Hero 動畫、捲動敘事、品牌時刻 |
明顯屬於資料動態時，直接說明這不是動畫問題並改走資料方案。其餘情況不要反問，先做第 2 步，用實際觀察回答。
第 2 步：看現況
有專案原始碼時，從這個 skill 的根目錄執行：
python3 scripts/motion_audit.py <專案目錄>
腳本結果是線索，不是判決，命中項要逐筆確認。
能開瀏覽器時，在 375px 走一遍主要路徑：首頁、內頁、切換分頁、點一個列表項、回上一頁。記下實際感受：
- 哪些動作是整頁重載，哪些是原地變化
- 頁面是一個主體，還是一堆獨立方塊
- 資料更新時使用者看不看得到
- 回饋有沒有延遲，有沒有動畫在幫倒忙，例如每次進頁都重跳的數字
沒有網站時（新站），或專案只是空殼、沒有實際頁面時：讀規劃文件，判斷站型，跳到第 3 步，並說明現階段無法診斷實際畫面。
看不到網站也沒有程式時：用使用者提供的資訊往下做，「問題在哪」全部標明是推論，「未驗證」列出缺的資料。不要編造觀察。
第 3 步：依站型定調
| 站型 | 重心 | 避免 |
|---|---|---|
| 資料與工具站（比分、查詢、儀表） | 連續動態、更新訊號、密度 | 捲動淡入、擋住資料的動畫 |
| 內容與文章站 | 輕回饋、閱讀不被打斷 | 任何干擾閱讀或推擠廣告的動效 |
| 品牌與行銷頁 | 一個精心的敘事時刻 | 到處都動 |
| App 型服務 | 手勢、原地操作、狀態連續 | 只換皮不改互動 |
| 登入後後台與內部工具 | 回饋、狀態變化、減少換頁 | 拖慢重複操作的動畫 |
第 4 步：規劃 2 到 3 個版本
讀 references/recipes.md 取用動效配方，讀 references/pitfalls.md 評估風險。
先過導覽閘門，它決定哪種換頁做法可以進提案：
| 站況 | 導覽做法 |
|---|---|
| 有或將有展示廣告（如 AdSense） | 預設用跨文件 @view-transition，保留真實換頁，廣告與分析行為不變 |
| 已開自動廣告、錨定廣告、插頁廣告，或無法驗證換頁後的廣告行為 | 同文件軟導覽不列為推薦；要列就標明必須先實測，並給退路 |
| 沒有廣告，或已驗證廣告與分析做法 | 可用同文件軟導覽或框架路由，仍要驗證分析與登入狀態在切頁後正常 |
既有站已開軟導覽且準備上廣告時，把這件事列在「問題在哪」，不要當成已解決。
版本之間要有實質差異，而且是互動範圍的差異，不是顏色差異。階梯從站的現況往上算，已上線的項目不要重複列。預設階梯：
- A 輕量手感版：不動導覽架構，只加回饋與更新訊號。風險最低，當天可完成。
- B 連續版：A 再加頁面轉場、共享元素、原地展開。導覽做法依閘門決定。通常是推薦版。
- C 完整 App 感版：B 再加手勢滑動、原地切換資料、即時通知，或品牌站的敘事時刻。手感最強，成本和風險最高。
版本要通過第 3 步的站型過濾：文章內容站通常到 A 或輕量 B 就停。只有兩個版本真的有差別時就給兩個，不要湊數。若 A 已是全部需求，也要直說。動畫工程費要和網站收入相稱。
第 5 步：做可點的原型
照 references/prototype.md 做。原型用真實資料和現有外觀，一個檔案內可切換版本，手機寬度實際點過再交出去。起手可用 assets/prototype-template.html。
第 6 步：提案
依下方「輸出格式」回報，然後請使用者選版本。環境有選項工具就用，沒有就列編號選項，推薦版本放第一個。第 1 步的「不要反問」只適用於診斷階段，這裡要停下來等選擇。
第 7 步：實作與驗收
使用者選定後才開始。照 references/acceptance.md 的順序實作並跑完驗收。交給其他 agent 時用該檔的交接範本。
輸出格式
提案固定用這個結構，短而具體：
## 動態評估：<站名>
**問題在哪**
<2 到 4 條，每條都是看到的現象，附頁面位置。不講空泛的「缺乏互動」。>
**版本比較**
| | A 輕量手感 | B 連續 | C 完整 App 感 |
|---|---|---|---|
| 使用者會感覺到 | | | |
| 主要改動 | | | |
| 工程量 | 檔案數與大約時間 | | |
| SEO 與 CWV 風險 | 低／中／高，一句原因 | | |
| 廣告與分析影響 | 寫明導覽做法與前提 | | |
| 維護成本 | | | |
**建議**：<選哪個，一句理由；若有前提就寫前提>
**原型**：<連結或路徑，並列出 3 到 5 個該試的動作>
**版面變動**：<需要使用者同意的項目；沒有就寫「無」>
**不提案**：<使用者要求但這次不做的項目與原因；沒有就省略>
**不會動到**：<版面、配色、網址、SEO 紅線等>
**未驗證**：<沒有實測的項目，例如廣告實際行為、真機手感>
只給兩個版本時，表格拿掉用不到的欄。工程量寫實際數字，例如「改 4 到 5 個檔案」，風險要說清楚理由，不要只寫「低」。數字標明是實測還是估算。使用者的要求被條件擋下時，直接說明擋在哪裡、什麼條件下可以重來，並給替代做法。推薦版本以閘門和效能條件為準，不必一定是 B。
參考檔
| 檔案 | 什麼時候讀 |
|---|---|
| references/recipes.md | 第 4 步，挑動效與參數 |
| references/pitfalls.md | 第 4 步評估風險、第 7 步實作時 |
| references/prototype.md | 第 5 步 |
| references/acceptance.md | 第 7 步，含交接範本 |
| assets/prototype-template.html | 做原型時的起手範本 |