前言
最近看到 GitHub 上的 oso95/scroll-world，示範畫面像是在一個微縮 3D 世界中飛行：使用者往下捲動，鏡頭便穿過不同場景，文字和品牌故事也跟著展開。
研究原始碼後，我發現它最值得注意的地方，不是用了哪套 3D framework，而是它根本沒有在瀏覽器中即時渲染 3D。它先用 AI 產生圖片和鏡頭影片，再讓網頁捲動位置控制影片時間，利用一連串預先渲染的片段做出連續飛行的感覺。
Scroll World 是什麼？
Scroll World 是一個提供給 Claude Code、Codex 與其他支援 SKILL.md 之 AI coding agent 使用的工作流程。它不是 npm 套件，也不是 Three.js、React Three Fiber 這類即時 3D 引擎。
專案主要提供以下內容：
- 一份從需求訪談、預算確認到產出驗收的 Agent Skill。
- 圖片、鏡頭與場景連接影片的 prompt 範本。
- Higgsfield CLI 與 FFmpeg 的素材處理流程。
- 一套零相依的 vanilla JavaScript 捲動播放引擎。
- 最小 HTML 範例與選用的圖片去背工具。
因此安裝這個專案，不會立刻得到一個完成的 3D 網站。它更像是一份讓 AI Agent 帶著使用者完成企劃、素材生成、影片處理和前端整合的製作手冊。官方 README 也說明，完成品使用的 MP4 與 WebP 素材需要依每個專案另外生成。
看起來是 3D，實際上是捲動控制影片
它的核心可以簡化成以下流程：
- 將品牌或產品故事拆成數個有順序的場景。
- 為每個場景生成一張風格一致的圖片。
- 以圖片為起點，生成鏡頭飛入場景的影片。
- 生成銜接前後場景的 connector 影片。
- 使用 FFmpeg 抽格、壓縮並調整影片的關鍵影格間距。
- 以 JavaScript 將頁面捲動進度映射到
video.currentTime。
瀏覽器負責的是播放與 seek，不是即時計算模型、材質、燈光或物理效果。這能讓 AI 生成的複雜畫面直接出現在網頁中，也代表使用者無法像真正的 WebGL 場景一樣自由改變視角或操作物件。SKILL.md 的實作說明 明確將網頁端定位為預先渲染影片的 scroll scrub。
最關鍵的技巧：讓接縫使用相同畫面
多支 AI 影片直接串在一起，最容易出現的問題是接縫跳動。即使使用相同 prompt 與參考圖，每次生成的構圖、光線和物件位置仍可能略有差異，切換影片時就會產生明顯的「跳一下」。
Scroll World 的做法是從已經生成完成的影片中抽取實際 frame：
- connector 的第一格，使用前一支影片的最後一格。
- connector 的最後一格，使用下一支影片的第一格。
也就是不拿原始場景圖猜接縫，而是直接傳遞前後影片真正輸出的像素。這項 frame handoff 規則是整套流程中最有價值的部分；官方文件 也把接縫畫面必須一致列為成敗關鍵。
兩種鏡頭架構
專案目前整理了兩種串接方式：
連續向前飛行
每段影片都以前一段的最後一格作為起點，鏡頭維持相同方向前進。這種方式比較適合室內導覽或寫實的第一人稱旅程，畫面自然，但影片必須依序生成，製作時間較長。
Dive-in 加空中 connector
每個場景先由外往內飛，再透過 connector 拉遠並前往下一個場景。這種方式適合低多邊形、黏土模型或微縮島嶼，能呈現很強的「小世界」感。不過鏡頭會在往內與往外之間反轉速度，不適合所有寫實場景。兩種鏡頭架構的取捨 在 Skill 中有更完整的說明。
前端播放引擎如何運作
scrub-engine.js 會自行建立 DOM、注入 CSS，並將場景影片和 connector 組成交錯的時間軸。頁面捲動時，常駐的 requestAnimationFrame loop 會平滑追蹤進度，再更新目前影片的播放時間。
<div id="world"></div>
<script src="scrub-engine.js"></script>
<script>
mountScrollWorld(document.getElementById('world'), {
brand: { name: 'Example' },
sections: [
{
id: 'intro',
still: 'assets/intro.webp',
clip: 'assets/vid/intro.mp4',
title: '第一個場景'
}
],
connectors: []
});
</script>
影片會先以 fetch() 完整下載成 Blob，再交給 <video> 播放。好處是不依賴主機是否正確支援 HTTP Range，影片一定可以 seek；代價是已載入的片段會占用瀏覽器記憶體。scrub engine 原始碼 可看到 Blob 載入與 lazy fetch 的處理。
引擎也處理了幾個手機常見問題，包括合併過密的 seek、首次觸控後預熱 iOS 影片、手機停用粒子，以及讀取 prefers-reduced-motion。不過專案沒有公布正式的瀏覽器支援表，也沒有跨瀏覽器自動化測試，正式上線前仍需要用真機驗證。
安裝與前置需求
Codex 可以透過 Vercel skills CLI 安裝：
npx skills add oso95/scroll-world -a codex
完整製作流程還需要已登入並有 credits 的 Higgsfield CLI、ffmpeg／ffprobe，以及 Python 3 與 Pillow。Codex CLI 是選用項目，可用 image_gen 產生場景 still；鏡頭影片仍要走 Higgsfield 的 image-to-video 流程。官方安裝與需求 可查看各種安裝方式。
由於 Skill 會引導 Agent 執行 Bash、生成服務、下載和影片編碼命令，實際使用前應先檢查內容並固定到特定 commit，不要直接把未公開素材、個資或 secrets 放進外部生成服務的 prompt。
成本與行動版不能忽略
若有 N 個場景，dive 加 connector 架構大致需要：
- N 次圖片生成。
- N 次場景影片生成。
- N−1 次 connector 影片生成。
- 額外預留生成失敗與風格不一致的重試額度。
換句話說，影片生成次數約為 2N−1。如果要製作真正適合手機的 9:16 版本，還要再生成一套直式影片，成本和等待時間都會顯著增加。官方不建議直接把桌面 16:9 影片裁成直式，除非清楚把它當成預算不足時的替代方案。手機版 pipeline 說明了原生直式 chain 的製作方式。
網頁效能也需要實測。影片雖然採 lazy load，但目前引擎沒有提供完整的 destroy() 或卸載 API，也沒有在離開場景後釋放 Blob URL。長頁面捲到底後，多支影片可能同時留在記憶體；若放在 React 或 Vue SPA 中反覆 mount，還要注意 event listener 和動畫 loop 重複建立。這是依目前原始碼做出的工程判讀，正式導入前最好補上清理機制，並設定影片流量、記憶體與 scroll FPS 的效能門檻。
適合與不適合的情境
Scroll World 適合：
- 品牌首頁、產品發表頁與短期活動網站。
- 可以拆成數個連續場景的製程、服務或品牌故事。
- 重視電影式敘事，並願意投入素材生成與視覺 QA 的專案。
- 需要高質感 3D 視覺，但不需要使用者自由探索的頁面。
它不適合：
- 需要即時改變模型、材質、燈光或鏡頭的產品 configurator。
- 對首屏下載量、低階手機效能與內容更新速度非常敏感的網站。
- 需要經常修改場景內容，卻不希望重新生成影片的長期內容頁。
- 把「安裝一個套件」當成全部製作成本的專案。
專案成熟度與我的看法
截至 2026 年 7 月 21 日，這個 repository 仍很新，沒有 GitHub Release、tag、測試目錄或 CI workflow；plugin manifest 顯示的版本也和最新 commit 訊息不一致。GitHub commits 與 Releases 可以查看目前狀態。專案採 MIT License，可以修改與商業使用，但仍需保留授權聲明。
我認為 Scroll World 最有意思的地方，是把生成式 AI 不穩定的素材，整理成一套可重複操作的製作流程。它對接縫、鏡頭速度、手機 seek、iOS 預熱與 reduced motion 的考量相當細，不只是丟一段 prompt 產生漂亮影片。
但它目前比較像適合 prototype、campaign page 或客製品牌案的早期創作工具，而不是已經具備穩定 API、版本管理與測試保護的 production library。若要導入長期維護的正式網站，除了看示範效果，也要把生成預算、影片流量、手機解碼、記憶體清理、瀏覽器 QA 和素材權利一起納入評估。