用 AI 寫程式做動畫影片的 Token 避坑指南：從單檔 Canvas 到 CSS/DOM 模組化架構

Max — Mon, 05 Oct 2026 05:42:33 +0000

近年來，「用程式碼寫動畫，再透過 Playwright 逐格截圖渲染成 4K/60fps 影片（Code-to-Video）」的工作流逐漸成為獨立創作者與工程師的熱門利器。搭配 Cursor、Claude、ChatGPT 或 Antigravity 等 AI 程式助理，只要給出大綱與腳本，AI 幾分鐘就能為你寫出一個包含時間軸控制、字幕對位與動畫渲染的網頁。

但在實際反覆迭代、微調設計風格時，很多人會遇到一個痛點：「為什麼我只是想改場景 3 的文字顏色，或者把某個元素往上移 20px，AI 卻花費了天量的 Token，甚至因為上下文過長開始遺漏程式碼？」

本文將以真實專案經驗為出發點，分析這個「Token 吞噬黑洞」的成因，提供第三方動畫框架的完整選型評估，並給出優化後的最佳實踐架構與升級版 Prompt 範本。

一、血淚經驗：原本的工作流與 Prompt

在製作一支主題為《別拿未來的焦慮，懲罰現在還在努力的自己》的教學動畫時，我們最初給 AI 的 Prompt 如下：

原版 Prompt

幫我製作一支教學動畫解說影片，主題是「別拿未來的焦慮，懲罰現在還在努力的自己」。
用程式逐格渲染成 MP4（HTML Canvas 的 seek(t) + Playwright 截圖 + ffmpeg），並用我的聲音配旁白。

# 一、規格
- 16:9，1920×1080，30 fps，旁白參考 file:@code-v10.md
- 字幕在畫面下方，深色膠囊底、象牙白字；字幕顯示原文（英文、數字照寫）
- 不加背景音樂；旁白會由我真人配音, 下一段字幕的顯示的觸發是按 mouse click or keyword space key.
- 直接隱藏面, 讓我可以直接錄畫面同時配音產生影片, 並要支援我使用 click or space 切換 subtitle.

# 二、旁白稿（8 段，畫面以段落為單位）
1. 段落清單：
- 別拿未來的焦慮，懲罰現在還在努力的自己。
- 一個關於焦慮的小故事
- 修好性格，成為靠得住的人
- 練好本事，別成為破水桶
- 停止內耗，掌控不了的交給上天
- 做完你能做的，剩下的就別煩惱了
- 歡迎留言分享：你最近最想卸下的內耗是什麼呢？
2. 先不要寫程式，給我六格分鏡。讓我看過、改過最後確認過，等方向對了再動手。
3. 顯示風格為 dark theme 有高級質感的簡報風格的動畫, 避免太花俏的用色, 每個場景之間要有一致性.
  目標受眾為一般民眾, 避免於 dark theme 使用太暗的前景文字, 會造成閱讀困難.
4. 渲染之前，先抽開頭、中間、結尾三格檢查，沒問題再整支輸出。
5. 避免最下面的字幕overwrite 畫面顯示的元素, 字幕上緣約在 y≈940，使所有元素都在 y≤870 以內，留有約 70px 安全距離。

二、為什麼這個工作流程會變成「Token 吞噬黑洞」？

當 AI 依照上述提示詞生成檔案時，通常會產出一個 單一且龐大的 scene.html（長達 1,200 ~ 1,500 行），裡頭包含：

CSS Reset 與控制面板樣式
預設的旁白時間軸陣列
Playwright 逐格渲染輔助鉤子
錄音模式與快捷鍵邏輯
龐大的 Canvas 2D 命令式繪圖代碼（drawScene1 到 drawScene6）

核心問題剖析：

單檔肥大（Monolithic File）
AI 助理每執行一次修改（例如「把文字調亮」），工具必須把這 1,300+ 行程式碼送入 Context Window。若經過 4~5 輪微調，單次對話就消耗了數萬甚至數十萬 Tokens。
命令式（Imperative）Canvas 繪圖對 AI 極不友善
Canvas 是像素與命令導向的：ctx.fillStyle = "rgba(148,163,184,0.7)"; ctx.fillText("能力不足，機會留不住", x, y + 200); 文字、顏色、排版全寫死在 JS 運算中。當你要調整邊界或對比度時，AI 無法透過 CSS 選擇器全域修改，必須逐行用正則搜尋每條指令並手工計算座標（如 y - 280 + i * 60），極易出錯且耗損算力。
資料、樣式、邏輯三者混雜
旁白文案、色票（Design Tokens）、場景布局和時間軸驅動全部混在一起。改動文案等於改動動態繪圖代碼。

三、第三方框架選型評估

在決定下一步架構前，我們針對市面上常見的動畫與影片生成方案進行了深入評估：

方案	特色與優勢	缺點 / AI 維護成本	適合場景
原生 DOM/CSS 模組化 (強烈推薦)	0 第三方依賴，極速啟動直接保留既有的 Playwright + ffmpeg 渲染工作流支援 CSS 變數，修改全域樣式極度省 Token宣告式 HTML/CSS，AI 解析與修改代碼成功率最高	不適合極其繁複的三維流體或物理碰撞粒子運算	首選推薦：文字講解、高級商務簡報、Motion Graphic 圖表動畫。
Remotion (React)	業界最成熟的 Code-based 影片框架支援 React 元件生態與強大的時間軸（`useCurrentFrame`）伺服器端確定性渲染優秀	專案初始化門檻高（Node.js, Webpack, TSX）修改單一元件容易牽涉跨檔案依賴與編譯錯誤除錯時 Context 回傳的錯誤日誌較長	團隊標準化生產、數據驅動影片、高頻次自動化短影音。
Openslide / Sli.dev / Reveal.js	Markdown 驅動，改文案幾乎不花額外 Token簡報版式現成，社群主題豐富	本質是「投影片切換工具」，非「逐格動態影片引擎」難以做出流暢細膩的貝茲曲線（Easing）過渡與自訂動態圖形	演講投影片、單純圖文口播講解，非精緻動態設計。
Video-podcast-maker / 自動短影音工具	開箱即用，提供完整 GUI 或一鍵腳本自動對齊音訊與字幕波形	黑盒子架構，自訂視覺細節極其困難無法彈性調整「特定場景的同心圓旋轉速度」等自定義需求	快速產出 Podcast 口播轉影片、低客製化需求場景。

四、最佳解法：現代化「DOM/CSS + 資料分離」架構

如果你的訴求是「高質感簡報動態 + 本地 Playwright 渲染 + AI 極致維護性」，最完美的方案不是引進沉重的框架，而是將 HTML 架構由 Canvas 命令式重構為「宣告式 DOM/CSS 模組化」：

為什麼這個架構大幅節省 Token？

改文案：AI 只要讀取 subtitles.json（約 50 行），改完即生效，不碰到任何繪圖代碼（省 90% Token）。
改配色：AI 只要讀取 theme.css 修改 CSS Custom Properties（例如 --text-muted: #cbd5e1），全域場景同步更新（省 95% Token）。
改特定場景：需要微調第 3 場景的立柱動畫？AI 只需要讀取 scenes/scene-3.html，完全不需要看其他 5 個場景的代碼。
定義安全防護區（Safe Area）：透過 CSS calc(100vh - 140px) 或 Grid 版型，天然保證內容不會與底部字幕碰撞，不需要在 Canvas 中手算座標。

五、優化升級後的 Prompt 範本（直接複製使用）

套用「實踐成效預估」與「AI 架構維護優化」後，下次啟動專案可以直接使用以下 Prompt：

請幫我製作一支現代網頁架構的教學動畫解說影片。

主題：【請在此替換你的影片主題，例如：別拿未來的焦慮，懲罰現在還在努力的自己】
技術架構：採用「宣告式 DOM + CSS 動畫 + 獨立模組化」設計，支援即時麥克風配音打點，並透過 seek(t) + Playwright 截圖 + FFmpeg 渲染成含音訊的 1080p MP4。

# 一、專案模組化結構規範
為維持程式碼易讀性與 Token 利用率，請將各模組職責拆分於獨立檔案（單一檔案保持在 400 行以內）：

my-project/
├── data/
│   ├── subtitles.json       # 旁白內容與時間軸數據（AI 文字調整專用）
│   └── theme.css            # 統一 Design Tokens（色彩、字體、Safe Area 變數）
├── scenes/
│   ├── scene-1.html & scene-1.css  # 各分鏡獨立 HTML 結構與 CSS 動態
│   ├── scene-2.html & scene-2.css
│   └── ...
├── js/
│   ├── engine.js            # seek(t) 時間軸解析與全域 CSS 變數注入 (--scene-progress)
│   └── recorder.js          # 鍵盤/滑鼠打點控制器與 MediaRecorder 錄音控制
├── index.html               # 1920x1080 舞台主容器、Safe Area 與控制面板
└── render.mjs               # Playwright 逐幀截圖與 FFmpeg 影音合軌自動化腳本

# 二、詳細技術與動態規範

1. 畫面與動態設計：
   - 解析度與幀率：16:9，1920×1080，24 fps。。旁白參考 file: inputfile.txt
   - 安全區域（Safe Area）：底部 140px 留給字幕專用，主視覺內容區域限制在 y <= 870，確保視覺內容與字幕完美分隔。
   - 驅動機制：動畫以 CSS Transitions / Transforms 為主，由全域 seek(t) 注入的 `--scene-progress (0~1)` 變數驅動。
   - 渲染效能最佳化：位移與縮放一律採用 GPU 加速屬性 `transform: translate3d(x, y, 0) scale(...)` 與 `opacity`，並標註 `will-change: transform, opacity;`，確保無頭瀏覽器逐幀截圖順暢無效能瓶頸。

2. 焦點微動畫（Focus Micro-Animation）原則：
   - 視覺節制原則：貫徹「少即是多」，每個場景僅設定**一個最核心的焦點元素**進行持續微動畫，引導觀眾注意力集中於關鍵訊息。
   - 文字圖層動態規範：包含文字的元素（標題、卡片、膠囊、列表、說明文字）採用靜態呈現，如需視覺強調，**僅限使用 `box-shadow` 與 `border-color` 的光暈呼吸變化**（維持元素位置與尺寸穩定，提供舒適閱讀體驗）。
   - 焦點動畫類型選擇（每個場景擇一套用）：
     - 背景光暈層（純視覺）：`scale3d(1,1,1) → scale3d(1.06,1.06,1)` 與 `opacity` 0.85→1，週期 5~6 秒。
     - 幾何圖形 / SVG 圖示（無文字）：`scale(1) → scale(1.035)` 配合 `box-shadow` 擴張（週期 4~5 秒），或 `translateY(0) → translateY(-5px)` 柔和浮動（週期 3.5 秒）。
     - 金句 / CTA 膠囊（含文字）：`box-shadow` 與 `border-color` 的光暈呼吸效果（週期 3.5~5 秒）。
   - 動畫管理機制：所有持續性動畫的 `@keyframes` 與 class 統一管理於 `index.html` 的 `

Max的每一天

用 AI 寫程式做動畫影片的 Token 避坑指南：從單檔 Canvas 到 CSS/DOM 模組化架構

一、血淚經驗：原本的工作流與 Prompt

二、為什麼這個工作流程會變成「Token 吞噬黑洞」？

核心問題剖析：

三、第三方框架選型評估

四、最佳解法：現代化「DOM/CSS + 資料分離」架構

推薦檔案結構

為什麼這個架構大幅節省 Token？

五、優化升級後的 Prompt 範本（直接複製使用）

Max的每一天

用 AI 寫程式做動畫影片的 Token 避坑指南：從單檔 Canvas 到 CSS/DOM 模組化架構

一、 血淚經驗：原本的工作流與 Prompt

二、 為什麼這個工作流程會變成「Token 吞噬黑洞」？

核心問題剖析：

三、 第三方框架選型評估

四、 最佳解法：現代化「DOM/CSS + 資料分離」架構

推薦檔案結構

為什麼這個架構大幅節省 Token？

五、 優化升級後的 Prompt 範本（直接複製使用）

一、血淚經驗：原本的工作流與 Prompt

二、為什麼這個工作流程會變成「Token 吞噬黑洞」？

三、第三方框架選型評估

四、最佳解法：現代化「DOM/CSS + 資料分離」架構

五、優化升級後的 Prompt 範本（直接複製使用）