從第一次打開 Remotion，到 Mografy 變成現在的樣子，我花了快半年。
很多人問我「做一個動畫工具要多久」。我的答案是：寫程式不是最花時間的部分。
想清楚它應該是什麼，才是。
這篇不是教學，而是開發筆記。我會把這半年拆成幾個階段，老實寫出哪些東西做了又砍、哪些決定花最久，還有如果重來一次我會怎麼做。
從一場 Remotion 分享，到第一個作品 SwiftClip
我之前做過一場和 Remotion 相關的分享，準備的過程中，我對「用程式寫動畫」這件事完全入迷。影片是 React 元件、時間是一個變數，這個觀念直接改變了我看動畫的方式。
入迷之後，我做的第一個東西其實不是 Mografy，而是 SwiftClip：一套建立在 Remotion 上的開源影片模板庫。它用 React 和 TypeScript 寫成，網站上有 32 個模板，複製 .tsx、改 props、一行指令就能輸出 MP4。我也替它做了一套 Claude Code 工作流，讓 AI 規劃、產生並註冊影片。
但做完 SwiftClip，我發現我想要的東西和 Remotion 的定位不同：
- 我是做設計和教課的人。我要的是能拿來上課、讓學生直接上手的工具，而不是一個需要先懂 React 專案架構的框架。
- 我想讓 AI 來寫動畫，人負責看、判斷、修改。Claude 負責產生，工具負責預覽、檢查和輸出。
- 我在意動畫本身的設計品質。緩動、節奏、分鏡、中文字排版，這些比「能不能渲染出影片」更重要。
所以 Mografy 不是「另一個 Remotion」，而是想回答一個不同的問題：當 AI 會寫程式之後，動態設計的工作流應該長什麼樣子？後來這句話被我縮成 Mografy 的標語：
Claude creates. Mografy shows.
SwiftClip 沒有白做。模板的概念後來變成了 Mografy Templates，那套讓 AI 寫影片的 Claude Code 工作流，也成了 Mografy Skill 的雛形。
第一版長得像傳統動畫軟體
第一版的 Mografy，我照著 After Effects 的直覺去做：專案是一份 JSON，裡面有圖層、有 keyframe，動畫交給 GSAP 跑。看起來很合理，因為設計師都懂圖層和關鍵影格。
問題是，這個結構對人友善，對 AI 不友善：
- AI 要改一個動畫，得去改一大串 JSON 數值，很容易改壞，也很難說清楚「為什麼這樣動」。
- 圖層和 keyframe 能描述的動畫有限，遇到粒子、程序化圖形、跟著資料變化的動畫就卡住。
- GSAP 是為網頁互動設計的，拿來逐格渲染成影片，時間控制總是差一點。
這一版不是白做。它讓我確定了一件事：
資料格式決定了 AI 能做到什麼程度。
這也是下一個階段我願意整個砍掉重來的原因。
砍掉重練，場景變成「時間的純函數」
重寫之後，Mografy 的每個場景都是一個 TypeScript 模組，只匯出三樣東西：meta、params，以及 renderFrame(ctx, time, params)。給它一個時間點，它就畫出那一格。同樣的時間永遠畫出同樣的畫面。
這個決定讓很多事情一次變簡單：
- AI 寫得出來。寫一個函數，比維護一份巨大的 keyframe JSON 自然得多，也能把「為什麼這樣動」寫成程式碼。
- 預覽和輸出是同一套。播放器拖到哪一格，輸出影片時那一格就長那樣。
- Canvas 什麼都能畫：文字、圖形、粒子、資料動畫，不用遷就圖層模型。
mografy.json 從此只放專案設定，舊的 JSON 圖層格式和 GSAP 全部刪掉。接著我把伺服器設計成唯一的寫入者：場景改完會先編譯、先在無頭 Chromium 裡試渲染一次，確定沒壞才更新播放器，而且播放頭會停在原本的位置。
這一段花的時間不在寫程式，而在更難的事：
下決心刪掉已經能動的東西。
從 MCP 到 Skill，讓 AI 真的懂動畫設計
早期我用一個 MCP 套件把 Mografy 接到 Claude，讓 AI 透過工具呼叫去操作專案。後來我把 MCP 整包拿掉，改成一份共用的 mografy Skill。
原因很簡單：AI 缺的不是「能呼叫哪些工具」，而是「怎樣才叫好的動畫」的知識。工具它本來就會用，但它不會自己知道緩入緩出該怎麼選、轉場該停多久、中文直排怎麼排才好看。
所以 Skill 裡寫的大多是設計知識，而不是 API：
- 動畫的 12 個基本原則
- 分鏡怎麼寫
- 場景的寫法與鏡頭、轉場
- 中日韓文字的直排與橫排
- 影片壓縮與輸出設定
現在同一份 Skill 同時給 Claude Code 和 Codex 用。Claude 的流程校準得比較完整，Codex 則多一份專屬的動態設計參考。
這一階段我花最多時間的地方：
把自己腦中的設計判斷寫成 AI 讀得懂的文件，而且要反覆跑、反覆修。
先有分鏡，再有動畫
做到這裡，AI 已經能寫出會動的東西，但「會動」和「好看」差很遠。直接叫 AI 做一支 15 秒的影片，它常常把所有東西一次丟上畫面，沒有節奏、沒有重點。
我的解法是把動態設計師本來就在做的事搬進流程：
每一次對話都先交換分鏡。
Skill 會先寫出 storyboards/storyboard.md，Claude 再做一份視覺分鏡給我看，我確認鏡頭、節奏、文字之後，才開始寫場景。
這個改變對成品的影響，比任何一次技術重構都大。它也讓我確定 Mografy 的核心不是渲染引擎，而是工作流。
輸出、模板、音樂、3D，還有社群
核心穩定之後，接下來是讓它真的能拿去用：
- 輸出格式：MP4、WebM、Lottie、SVGA，一行
mografy export搞定，網頁、App、社群影片都能用。 - 上手門檻：安裝就是
git clone加pnpm install，再打mografy dev。我刻意拿掉預設的起始專案，播放器打開就有 16 個內建元件場景可以看。 - 擴充包：鏡頭運動與轉場、中文直橫排、動態設計教學場景，放在
extras/，需要時才複製進專案。 - 模板：Mografy Templates，分 9:16 和 16:9 兩組，讓大家不用從零開始。
- 更多可能：依場景內容生成配樂、Three.js 3D 圖層，還有簡報。
同一時間，我也開始經營 Discord、Buy Me a Coffee 和官方部落格。老實說，這部分比寫程式難：
做出來不難，讓人知道它存在才難。
所以，構思一個動畫產品要多久？
我的答案是快半年，而且大部分時間不是在寫程式，而是在想清楚三件事：
- 它是給誰用的？我花了一段時間才承認，Mografy 不是要跟 Remotion 搶開發者，而是給設計師、學生，以及想用 AI 做動態設計的人。
- AI 和人怎麼分工？答案是 AI 產生、工具呈現、人判斷。這句話一旦定下來，資料格式怎麼設計、MCP 該不該留，都有了答案。
- 什麼東西要刪掉？JSON 圖層、GSAP、MCP、預設起始專案，這些都是做好了才刪的。每一次刪除都比當初寫它更花時間。
如果只算「從零寫到能輸出影片」，其實不用半年。花時間的是那些做錯了才知道錯的方向。
改寫成純函數那一步，是整個專案的分水嶺：在那之前我在做一個「動畫軟體」，在那之後才是「讓 AI 做動畫的工作流」。
給想做動畫產品的人的幾個建議
- 先做一個醜的版本，再決定要不要砍。第一版的 JSON 圖層讓我學到的，比任何規劃文件都多。
- 資料格式比介面重要。尤其在 AI 時代，格式決定了 AI 能幫你做到哪裡。
- 把你的設計判斷寫下來。你腦中「這樣比較好看」的直覺，是產品真正的護城河，也是 AI 最缺的東西。
- 把專業流程搬進產品，而不是取代它。分鏡不是多一道手續，它是讓成品變好的關鍵。
- 早點開始分享。做出來之後，最難的是讓人知道它存在。開發過程本身就是最好的內容，就像這篇。
結語：半年只是開始
Mografy 的開源版本會一直免費，MIT 授權，放在 GitHub 上。接下來我會用課程帶著產品往前走，付費的 Mografy Pro Triangulum 也在路上。
如果你也在做動畫或設計工具，或只是好奇開發過程，歡迎來 Discord 聊聊。我很想知道：
你覺得做一個產品，最花時間的是哪一段？
一起來做動態設計
加入 Mografy Discord，分享你的作品、提出問題，一起決定我們接下來要做什麼。