by Rain Chu | 9 月 8, 2026 | Agent , AI , Apple , Mac , 程式開發
買 Mac 跑本地 AI,我會先考慮以下三件事:
模型能不能放進記憶體,送出長篇資料後要等多久,以及開始回答後每秒能生成多少 token。這三件事分別牽涉容量、運算能力與記憶體頻寬,不能只看晶片名稱裡的數字。
同一台電腦,短問短答很順,換成讀程式碼、查工具、反覆執行任務的 Agent 卻很慢,並不矛盾。
聊天介面讓你注意到的是持續輸出的速度,Agent 更容易暴露長輸入、多輪推理與工具等待的成本。
模型載入成功,只代表跨過容量門檻,還不代表這台機器適合你的工作流。
本文於 2026 年 9 月 6 日核對規格。Apple 已公布新款 Mac mini 與 Mac Studio,官方標示 9 月 22 日開始供貨。以下會把官方規格、推理原理與選購判斷分開,未取得的新機實測不會用推估值冒充。供貨資訊可查 Mac mini 公告 與 Mac Studio 官網 。
先分清 Prefill 與 Decode,才知道慢在哪裡
Prefill,預填充 ,是模型處理輸入內容、建立後續推理狀態的階段,系統提示詞、聊天記錄、工具定義、檢索文件與程式碼都可能算進輸入,並非只有你剛打的那一句話。長輸入通常有較大的矩陣運算需求。
Decode,解碼生成 ,則是在已有上下文狀態上逐步產生 token,單一請求、低批次的生成常受記憶體資料搬運限制,所以記憶體頻寬很重要,Token 不是固定的一個中文字,不能把 tokens/s 直接當成每秒中文字數。
觀察體感時,我會同時記錄 TTFT,也就是送出後到第一個 token 的時間,以及生成階段的 tokens/s,TTFT 還可能包含排隊、模型載入與服務端處理,不能把所有等待都歸因於 Prefill,Apple 的 MLX 與 M5 技術說明 也分別討論提示詞處理與生成效能,兩個階段應分開比較。
記憶體容量,是門票而不是速度保證
Apple Silicon 的 CPU 與 GPU 共用統一記憶體,跑較大模型時不必完全受限於一張獨立顯示卡的顯存容量,在這規格表上的 32GB 或 128GB 並不等於模型可以獨占同樣的空間,macOS、瀏覽器、開發工具、KV cache 和推理暫存都需要預算。
估算可以從權重開始:參數數量乘上每個參數的位元數,再除以 8,以約 27B 參數、理想化 4-bit 權重計算,純權重約 13.5GB,這只是十進位容量的粗估,還沒加入量化分組資訊、部分高精度權重與執行時開銷。
32GB 能否跑某個 27B 模型,答案是「有機會,但要指定量化檔、上下文長度與框架」。只拿 27B 這個名字,無法保證長上下文與多 Agent 都順暢。先核對實際模型檔大小,再測一個完整任務,會比只看成功載入的畫面更有用。
如果想先理解不同推理工具的定位,可以參考 MLX、llama.cpp、Ollama 與其他本地推理框架比較 ,格式、核心實作與快取策略都會影響同一台硬體的表現。
記憶體頻寬,影響持續輸出但不是萬用答案
可以把容量想成能放多少資料,頻寬則是每秒能把多少資料送到運算單元。當低批次生成需要反覆讀取大量權重,而硬體運算能力足夠時,頻寬往往成為主要限制。
但「頻寬加倍,速度就一定加倍」只適合當理想化的直覺,實際還有量化解碼、注意力、KV cache 存取、核心效率、批次大小與模型架構,MoE 也不是每個 token 都動用全部專家權重,所以不能把所有模型都套進同一條簡單公式。
M5、M6 規格怎麼看,先看配置再看名稱
以下整理 Mac mini 技術規格 與 Mac Studio 技術規格 中,和本地模型最直接相關的容量與頻寬。這是規格對照,不是速度排名,也不是實測 tokens/s。
機型與配置 統一記憶體 記憶體頻寬 Mac mini M6 基本配置 16GB 153GB/s Mac mini M6 較高記憶體配置 24GB 或 32GB 170GB/s Mac mini M5 Pro 24GB,可選 48GB 或 64GB 307GB/s Mac Studio M5 Max 32 核心 GPU 36GB 460GB/s Mac Studio M5 Max 40 核心 GPU 可選至 128GB 614GB/s Mac Studio M5 Ultra 96GB,特定配置可選至 512GB 1.2TB/s
2026 年 9 月 6 日核對,容量與頻寬不等同實測生成速度
M5 Max 的 32 核心與 40 核心 GPU 版本不只差核心數,頻寬與可選記憶體也不同,M5 Ultra 的 256GB、512GB 選項綁定更高階晶片配置,升級容量的成本可能同時包含晶片升級。選購時應核對最後的完整配置,不要把某個系列的最高值套到入門款。
供貨時間也要分開看。依 Apple 台灣的新款 Mac Studio 公告 ,一般配置自 9 月 22 日起供貨,512GB 統一記憶體配置則預計 10 月底推出,需要立即交付工作的團隊,應再確認實際可下單配置與交貨日期。
跑 Agent 為什麼更容易卡在等待
一個程式碼 Agent 可能先讀專案規則,再讀檔案,接著呼叫工具,最後把工具輸出帶回模型繼續判斷,每一輪都可能增加輸入,輸出卻只有一小段指令,讓「先讀懂,再動作」的成本更加明顯。
「每開一個子代理,就一定完整重算一次全部上下文」並不精確,是否能重用相同前綴,取決於服務端的 prompt cache、請求路由、模型支援與上下文是否一致,MLX LM 官方專案 就提供 prompt caching 功能,實際 Agent 框架有沒有用到,仍要另外確認。
把長期不變的規則放在穩定前綴,減少每輪重新排列內容
只提供當前任務需要的檔案與工具,避免把整個專案一次塞進提示詞
先測單 Agent,再逐步增加並行數,觀察排隊與記憶體壓力
同時記錄模型等待、工具執行與重試時間,避免把外部服務延遲算到 GPU 頭上
如果任務需要很長的推理輸出,Decode 仍可能占大部分時間,真正值得比較的是完成同一項工作要多久、成功率如何,而不只是某個階段的峰值數字。選擇 Agent 模型與本機部署方式 時,也應把工具呼叫品質一起放進評估。
M5 的加速器,要配合軟體才能發揮
M5 GPU 的 Neural Accelerators 是 GPU 內的矩陣運算加速能力,不應和晶片上另一個 Neural Engine 混為一談,對長輸入這類運算密集的工作,支援相應路徑的框架與核心可以帶來收益。
買到新晶片不代表任何模型、量化格式和舊版工具都會自動得到相同比例的加速,我會連同 macOS、MLX 或 llama.cpp 的版本一起記錄,並查看執行時使用的後端。Apple 早期公布的 M5 測試可以用來理解方向,但不能直接當成新款 M6 或 M5 Ultra 的實測成績。
MoE 為什麼值得看,但不能只看啟用參數
Mixture of Experts,混合專家模型,會依 token 選用部分專家,降低每步需要參與計算的參數量,它讓「保存很多知識容量」和「每一步動用多少運算」有機會分開,這和大容量統一記憶體的特性很搭。
以 Qwen 官方的 Qwen3-30B-A3B 為例,30B 指總參數量,3B 指啟用參數量,不能因為看到 A3B,就用一個 3B 稠密模型的記憶體需求來估算,通常仍要保存更大的整體權重。這是用來解釋命名與架構的例子,不代表它是目前唯一或最適合的選擇。
MoE 的速度還受專家路由、量化、核心最佳化與批次大小影響,也不保證同樣容量下的工具使用品質一定勝過稠密模型,我的做法是準備一組真實任務,用完成品質與總耗時一起決定。
三種使用情境,我會這樣安排預算
主要使用雲端 AI,優先顧好日常工作
如果主要運算都在雲端,Mac 更多是在跑瀏覽器、編輯器與本地工具,無須只為遠端模型購買超大記憶體。16GB 到 32GB 可以作為一般工作起點,但大型專案編譯、虛擬機與剪輯仍可能需要更多。這是用途判斷,不是所有人的最低規格。
本地聊天、寫程式與剪輯混用,先看 48GB 到 128GB 的實際需求
先列出最常用的兩三個模型,再加上平常同時開啟的軟體。M5 Pro 和 M5 Max 各有不同容量與頻寬選項,能否容納模型加上真實工作環境,比只追求最大 GPU 核心數更重要。若以 Agent 為主,要優先找長提示詞與連續工具呼叫測試,而不是只看短聊天跑分。
目標是超大模型,再考慮 Ultra 與多機
當權重、長上下文或多請求確實超出較小容量,才有充分理由看 256GB、512GB 或分散式部署。先問自己是否需要那個模型能力,以及它能否在可接受時間內完成任務,不要為了「裝得下最大模型」而買一台長期等待的電腦。
AI 生圖與生影片,要另做一份評估
剪輯影片和用生成模型產生影片,是不同的運算工作,ProRes 編解碼能力強,不能直接推論擴散模型也會很快。ComfyUI 官方支援 Apple Silicon ,但你的模型、量化與自訂節點是否支援 Mac,以及完整生成一段內容要多久,仍需逐項確認。
若主要目的是高頻率生影片,我會拿實際工作流比較 NVIDIA GPU、本地 Mac 與雲端方案,再把等待時間與每次產出的成本算進去。可從 LTX 2.3 的 ComfyUI 影音工作流 理解需要核對哪些模型與節點,不應只拿文字模型的速度替影音生成下結論。
不過可以肯定的是現在要生圖還是首選 Nvidia 畢竟 pyTouch 還沒有完整支援 MAC
DGX Spark 加 Mac Studio,是分工不是魔法加總
EXO 的異質推理示範 把 Prefill 放在 DGX Spark,再把 KV cache 傳給 Mac Studio 進行 Decode,並透過逐層傳輸,讓通訊與運算時間部分重疊。這說明不同硬體可以各做擅長的階段。
但 EXO 示範的是特定模型、輸入長度、硬體與網路,不能外推成任何組合都會同倍率變快。兩台 256GB 也不必然優於一台 512GB,模型如何分片、互連頻寬、框架支援與並行方式都會改變結果。多機還增加設定與維護成本,應以整個任務的實測決定。
對多機部署有興趣,可以接著看 雙機 EdgeXpert 與大模型工作負載 ,把單機容量、網路傳輸和軟體支援一起考慮。
購買前怎麼測,至少分開短提示詞與長提示詞
請測試者提供完整模型名稱、量化檔、框架版本、系統版本、上下文長度與 GPU 配置,相同模型換一種量化,或把長輸入改成一句問候,都足以改變結果。
已有 llama.cpp 與本地 GGUF 模型時,可參照 llama-bench 官方說明 使用下列命令。把路徑改成自己已下載的模型,這裡的參數是測試設定,不是我在新機上測出的數字。
llama-bench -m /absolute/path/model.gguf -p 512,8192 -n 128 -r 3 -o json
這會分別測試不同長度的 prompt processing 與文字生成,輸出中的 pp 與 tg 對應不同階段。合成測試適合比較核心效能,不能直接當成真實 Agent 的 TTFT 或任務總耗時。還要補一輪實際工具呼叫流程,並分別記錄冷啟動、快取命中和未命中的狀態。
同一份短問答,觀察穩定生成速度
同一份長文件,觀察首個 token 等待時間
同一個修改程式任務,觀察工具呼叫與完成率
同樣的並行數,觀察尖峰記憶體、swap 與排隊
若要生圖或生影片,使用完全相同的模型、尺寸、步數與節點
FAQ
32GB Mac 可以跑 27B 模型嗎
部分量化版本有機會,但要加上 KV cache、推理暫存、macOS 與其他程式的需求。能載入不等於長上下文或多 Agent 都能流暢使用。
M6 一定比 M5 Max 適合本地 AI 嗎
不一定。要比較完整配置的容量、頻寬、運算後端與實際工作負載,不能只用世代數字排序。
為什麼聊天很快,Agent 卻很慢
Agent 可能反覆處理長上下文並等待工具,瓶頸不只在生成速度。應同時檢查 Prefill、快取、排隊、工具時間與任務重試。
MoE 的啟用參數少,記憶體也只要那麼少嗎
不是。啟用參數主要描述每步參與計算的部分,通常仍要保存全部專家權重,容量估算不能只看 A 後面的數字。
我的選購順序:先定工作,再定模型,最後選配置
先確定主要工作是在雲端還是本地,再決定模型與上下文需求。容量不足先解決容量,等待第一個字太久就看輸入處理與快取,開始輸出後仍然慢才進一步比較頻寬與生成核心。用這個順序選 M5、M6 或 Ultra,比追規格表上最大的數字更能把錢花在真正的瓶頸上。
by Rain Chu | 8 月 29, 2026 | AI , claude , codex , OpenAI , 圖型處理 , 影片製作 , 繪圖
AI 做動畫已經不只是叫模型生一段畫面。更實用的方向,是把動畫規則、鏡頭語言、渲染流程和品質檢查包成 Skill,讓 Codex、Claude Code 或其他 coding agent 知道該怎麼完成一支片。
這次整理的七個 AI 動畫 Skills,剛好涵蓋七種常見需求,從網頁動效、Logo 開場、數據動畫,到產品廣告、手繪故事和動態設計原則都有。它們不是同一類工具,也不需要全部安裝。先看自己要做什麼,再選對 Skill,會比堆一大包能力有效得多。
先講結論,短片該選哪一個
如果目標是快速做社群短片,我會先選 HyperFrames,它讓 Agent 用 HTML、CSS 和 JavaScript 描述畫面,再輸出成影片,對 Codex 很直覺,若內容以數字、圖表或年度回顧為主,Remotion 會更適合。產品網站想做成有電影感的廣告,可以直接看 video-shotcraft。
Logo 動畫 選 Pixel2Motion,中文故事轉手繪 日記選 story-to-handdrawn-video。GSAP AI Skills 負責把網頁互動 做得更有彈性和節奏,LottieFiles motion-design-skill 則像一位動態設計導演 ,幫 Agent 先把時機、緩動和編排想清楚。
Skill 最適合的任務 主要輸出 我會怎麼選 HyperFrames 網頁式動畫、短影音、產品解說 HTML 影片工程 想用 Codex 快速做片先選它 GSAP AI Skills 網頁互動、滾動動畫、UI 動效 可執行的前端動畫 網站看起來太硬時使用 Pixel2Motion Logo reveal、品牌開場 SVG、HTML、GIF 或影片預覽 手上只有點陣 Logo 時使用 Remotion Agent Skills 數據、圖表、字幕、批次影片 React 影片工程 需要精準時間軸與可重複生成時使用 video-shotcraft 產品宣傳片、網站功能廣告 電影感 Remotion 成片 有真實產品畫面時最有價值 story-to-handdrawn-video 中文故事、手繪日記動畫 直式手繪無聲影片 敘事型短片可以直接套流程 motion-design-skill 節奏、緩動、動態設計審查 設計規則與改進建議 搭配其他 Skill 一起用
Skill 和動畫工具有什麼不同
GSAP、Remotion 和 HyperFrames 是能真正執行動畫或渲染影片的工具,Skill 則是給 AI Agent 的工作說明,裡面會放最佳做法、檔案結構、動效規則、操作命令、常見失敗和驗收方式,它不會讓模型突然變成動畫師,但可以減少 Agent 亂猜 API、亂排時間軸和做出模板感畫面的機會。
如果你還不熟悉這種能力包,可以先看我整理的自訂 Skill 完整教學 ,它的重點不是多一個聊天指令,而是把可重複的製作方法交給 Agent。
1. HyperFrames,把網頁變成可渲染的影片
HeyGen HyperFrames 的核心很簡單,先用 HTML 寫畫面,再把瀏覽器中的動畫確定性地渲染成影片,Agent 可以處理分鏡、CSS、GSAP、素材、字幕、音訊和輸出,因此很適合做產品解說、社群短片、動態圖表與網站展示。
它和傳統剪輯軟體的差別,是畫面本身可以被程式控制,只要資料結構固定,同一套模板就能換內容重新輸出,想深入理解它的架構,可以接著看HyperFrames 用 HTML 寫影片 。
npx hyperframes init my-video --example blank
cd my-video
npx hyperframes preview
npx hyperframes render
2. GSAP AI Skills,讓網頁動效不再只是淡入淡出
GSAP AI Skills 是官方提供給 coding agent 的動畫知識包,涵蓋核心時間軸、Tween、ScrollTrigger、Flip、MorphSVG 和常見清理方式。它適合處理會浮、會彈、會跟著捲動改變的網站互動。
GSAP 的價值不是特效多,而是時間軸和控制能力成熟。Agent 知道怎麼設定 easing、stagger、觸發條件和資源清理後,做出來的動畫會比隨手拼 CSS transition 穩定很多。
npx skills add greensock/gsap-skills
3. Pixel2Motion,一張 Logo 變成品牌動態開場
Pixel2Motion 會先把 PNG、JPG 或截圖中的 Logo 重建成平滑 SVG,再設計 motion、logo reveal 和 HTML 動態展示,它不是單純把圖片放大縮小,而是先處理向量結構,再對圖形部件安排動作。
這個流程很適合品牌開場、App 啟動畫面和社群短片片頭,官方專案也加入幾何比對、動作幀截圖和最終畫面檢查,讓 Agent 不只產出會動的檔案,也留下可審查的證據。
npx skills add nolangz/pixel2motion
4. Remotion Agent Skills,用 React 做精準影片
Remotion Agent Skills 把 Remotion 的動畫、字幕、音訊、3D、圖表、渲染與元件設計規則交給 Agent。Remotion 本身以 React 組成影片,每一幀都能由程式和資料決定,因此很適合年度回顧、排行榜、圖表動畫、批次內容和字幕短片。
它的學習成本比單純 HTML 高,但大型專案會更好維護。之前整理的Codex 動態圖表和短影片工作流 ,就很適合拿 Remotion 處理需要精準幀數與資料驅動的部分。
npx skills add remotion-dev/skills
npx create-video@latest
5. video-shotcraft,把產品畫面剪成電影感廣告
video-shotcraft 是一套以 Remotion 為基礎的產品影片製作 Skill。它提供超過一百張鏡頭配方卡、可預覽的動作樣式、2.5D 運鏡、節奏卡點、音效和可直接替換內容的完整模板。
最實際的用法,是把網站或桌面產品的真實畫面交給 Agent,再指定想使用的鏡頭卡。它會處理素材採集、分鏡、運鏡、轉場、聲音和品質檢查。相比只生成幾張氣氛圖,這條路更能把真正的產品功能講清楚。
npx skills add Vincentwei1021/video-shotcraft
6. story-to-handdrawn-video,中文故事轉手繪日記動畫
story-to-handdrawn-video 能把中文故事或排序好的圖片,轉成直式手繪日記動畫,它會安排手寫文字、黑白線稿、彩色插圖與翻頁轉場,輸出可再加入旁白的 H.264 畫面。
這個 Skill 適合個人故事、知識小品、品牌創辦歷程和情緒型內容。它的風格很明確,不適合硬套在科技產品展示,但用在敘事題材時能快速建立一致的視覺語言。
git clone https://github.com/gnipbao/story-to-handdrawn-video.git
cd story-to-handdrawn-video
npm install
7. motion-design-skill,先教 Agent 什麼叫手感
LottieFiles motion-design-skill 不綁定特定動畫框架。它教的是 timing、easing、choreography、情緒意圖和改寫成 UI 動效的經典動畫原則。CSS、GSAP、Framer Motion、Lottie 都能使用這套思考方式。
很多 AI 動畫技術上能跑,卻沒有重量、停頓和節奏,原因通常不是少一個套件,而是 Agent 沒先決定動作要傳達什麼。這個 Skill 最適合當成第二層能力,搭配 HyperFrames、GSAP 或 Remotion 一起使用。
npx skills add LottieFiles/motion-design-skill
可以直接貼給 Codex 的繁體中文提示詞
不要只寫「幫我做一支動畫」。先把目的、尺寸、時長、素材、節奏和驗收條件講清楚。下面這份可以直接改主題使用。
請使用適合的動畫 Skill,製作一支 15 秒直式短片,比例 9:16。
目的
用最短時間介紹我的產品如何把文字整理成可搜尋的知識庫。
素材
使用專案中的真實產品截圖與品牌色,不要使用無關的 AI 圖片。
結構
0 到 3 秒呈現使用者找不到資料的痛點
3 到 8 秒展示匯入、整理與搜尋流程
8 到 12 秒用數字動畫顯示節省的時間
12 到 15 秒顯示產品名稱與行動文字
動效
畫面轉場要乾淨
數字使用平滑遞增
卡片進場要有重量感與短暫停頓
不要讓所有元素同時移動
限制
不要藍紫科技風
不要粒子背景
不要讓文字互相遮擋
不要使用未授權素材
驗收
先做 5 秒風格原型
確認手機畫面可讀後再完成全片
最後檢查每一幀是否有文字裁切、元素重疊和空白畫面
我的建議組合
社群短片選 HyperFrames,加 motion-design-skill 控制節奏
網站互動選 GSAP AI Skills,加 motion-design-skill 做動態審查
數據影片選 Remotion Agent Skills
產品廣告選 video-shotcraft,再用真實頁面截圖
品牌片頭選 Pixel2Motion
故事內容選 story-to-handdrawn-video,再補旁白、字幕和音效
更完整的製作管線可以參考OpenMontage 本地 AI 影片工作流 。它把研究、腳本、素材、渲染和驗收串起來,而這七個 Skill 比較像其中的專業工位。先把一個工位用熟,再擴大成自動化流水線,成功率會高很多。
FAQ
完全不會寫程式也能用嗎?
可以從提示詞開始,但仍要看得懂 Agent 建立了哪些檔案、如何預覽和輸出。HyperFrames 與 video-shotcraft 對成品導向較友善,Remotion 更適合願意維護 React 專案的人。
只想做短片,最推薦哪一個 Skill?
一般社群短片先選 HyperFrames。數據類短片選 Remotion。產品宣傳片選 video-shotcraft。風格容易僵硬時,再加 motion-design-skill 幫 Agent 調整節奏。
安裝很多 Skill 會不會讓 Agent 更強?
不一定。能力太多會增加選擇和上下文成本。每次任務只啟用一個主要製作 Skill,再搭配一個設計或品質檢查 Skill,通常會比較穩定。
by Rain Chu | 8 月 28, 2026 | AI , GGUF , Stable Diffusion , 圖型處理 , 影片製作 , 繪圖
LTX 2.3 把畫面、聲音、人物動作與鏡頭運動放進同一套生成流程,還能透過 ComfyUI 在本機執行,對只有 8GB 顯存的使用者來說,社群 GGUF 量化工作流確實打開了一扇門,但「能跑」不等於完整模型全放進顯存,也不代表每台電腦都能在不到一分鐘內完成。
我會把 LTX 2.3 定位成一個適合實驗同步影音、角色短片與圖生影片的本地模型,它可以成為 OpenMontage 本地 AI 影片工作流 裡的生成引擎,也可以獨立放在 ComfyUI 裡反覆調整。真正要先弄清楚的,是權重版本、顯存、系統記憶體與工作流之間的關係。
LTX 2.3 改進了什麼
LTX 2.3 官方頁面 把這次更新整理成幾個核心方向。新的 VAE 改善髮絲、材質與邊緣細節,較大的文字連接器能理解多主體、空間關係、動作與鏡頭指令,圖生影片減少了畫面凍結與只做平移縮放的情況,音訊也換上新的 vocoder,降低雜音、靜音缺口與突然中斷。
支援文生影片與圖生影片
能在同一個流程生成畫面與同步音訊
改善人物微表情、動作與鏡頭運動
原生支援最高 1080×1920 的直式影片
提供完整權重、Distilled、FP8 與社群量化方案
官方也提醒,LTX 2.3 採用新的 latent space,舊版 LoRA 不能直接當成完全相容的資產,通常需要重新訓練。這點比單純更新模型檔更重要,已經累積大量 LTX 2 工作流的人要先做相容性測試。
8GB 顯卡能跑,但要先拆掉一句話裡的誤會
官方 ComfyUI 文件 把標準本地工作流的前置條件列為 32GB 以上顯存與 100GB 以上可用磁碟空間。8GB 顯卡路線使用的是社群 GGUF 量化權重、模型卸載與系統記憶體,不是把 BF16 完整權重硬塞進 8GB 顯存。
版本 適合用途 主要取捨 BF16 Dev 品質驗證與正式輸出 硬體需求最高 Distilled 快速迭代與工作流測試 速度優先 FP8 較低顯存的官方量化路線 品質與資源需求折衷 GGUF Q4 或 Q5 8GB 到 16GB 顯存的社群工作流 依賴 CPU offload、系統記憶體與相容節點
以 QuantStack 的 LTX 2.3 GGUF 為例,Q5_K_S 檔案約 18.5GB,已經大於 8GB 顯存。能在 8GB 顯卡執行的關鍵,是工作流不要求所有資料同時留在 GPU。代價是更吃系統記憶體與資料搬移時間。想進一步理解 GGUF 與量化的角色,也可以對照站內的本地模型推理框架比較 。
GGUF 檔案大小不等於最低顯存需求,但能直接看出為什麼 8GB 路線必須依賴卸載與系統記憶體
我的硬體建議很簡單。,GB 顯存可以從 Q4 或經驗證的低顯存工作流開始,系統記憶體最好準備 32GB 以上,12GB 到 16GB 顯存會比較有調整空間。若要使用 BF16、較高解析度、長片段或多階段放大,32GB 以上顯存才接近官方設定,實際速度還會受 GPU 架構、RAM、磁碟、解析度、影格數與節點版本影響。
最省事的安裝方法是官方模板
第一次安裝不要急著手動搬十幾個檔案,先把 ComfyUI 更新到支援 LTX 2.3 的版本,再用模板庫建立一條能正常執行的基準工作流,這和我整理 Ideogram 4 的 ComfyUI 本機部署 時採用的思路一樣,先跑通官方基線,再加入量化與自訂節點。
開啟 ComfyUI Desktop 或現有 ComfyUI
完成程式與前端更新後重新啟動
進入 Templates 並切換到 Video
搜尋 LTX-2.3
先安裝 Image to Video 與 Text to Video 模板
按下 Download all 取得必要模型
重新啟動後先用低解析度與少量影格測試
官方建議先用 480×720 與 41 到 81 個影格確認流程,工作流穩定後,再提高解析度、片長與品質。這一步看起來保守,卻能很快分辨問題來自模型、節點、顯存,還是提示詞。
手動安裝時,模型應該放在哪裡
ComfyUI Desktop、Portable 與自行安裝版的根目錄可能不同,最穩的方法是從 ComfyUI 介面打開模型資料夾,再依下面的相對路徑放置。不要直接照抄別人的 Windows 使用者名稱。
檔案類型 建議路徑 用途 官方主模型 models/checkpoints/LTX-Video BF16、Distilled 或官方檢查點 社群 GGUF models/unet 交給 GGUF Loader 載入 文字編碼器 models/text_encoders Gemma 3 與 LTX 文字投影 視訊與音訊 VAE models/vae 解碼影像、聲音與預覽 LTX 2.3 LoRA models/loras/LTX-2.3 Distilled、風格或控制能力
原始權重可從 LTX 2.3 Hugging Face 取得。官方推理程式與訓練工具位於 Lightricks LTX-2 GitHub ,ComfyUI 節點與範例工作流則在 ComfyUI-LTXVideo 。
匯入工作流後出現紅色節點怎麼辦
紅色節點通常不是模型壞掉,而是工作流引用了本機尚未安裝的自訂節點。先在錯誤視窗選擇 Install Missing Custom Nodes,完成後按 Apply Changes 並重新啟動,若仍缺少 Fast Groups Bypasser 類節點,可在 Manager 搜尋並安裝 rgthree-comfy 。
GGUF 權重還需要 ComfyUI-GGUF 。安裝後重新啟動,在畫布空白處搜尋 GGUF Loader,把原本模型載入器的輸出改接到工作流的 model 輸入,再重新整理節點並選擇 Q4 或 Q5 檔案。
一個可以直接改寫的繁中提示詞
LTX 2.3 的提示詞不要只寫「讓照片動起來」。把人物動作、對白、聲音、鏡頭、畫質與禁止項目分開,模型比較容易理解時間順序與同步關係。
場景與動作
一名年輕女子站在安靜的室內,先看向鏡頭,再輕輕吸一口氣,以略帶緊張但自然的神情說話。嘴唇清楚說出指定的中文台詞,嘴型與發音準確同步。
聲音
自然的年輕華語女聲,語氣柔和、真實、略帶緊張,像日常交談,不要誇張。保留輕微呼吸聲與安靜室內環境音,不要配樂。
鏡頭
鏡頭緩慢推近臉部,只有很輕微的手持感。淺景深,焦點穩定,自然室內光線。
畫面品質
寫實電影感,皮膚紋理自然,眼神與微表情細膩,髮絲運動合理,動作流暢,人物身份保持一致。
避免項目
不要字幕,不要畫面文字,不要額外人物,不要旁白,不要機械聲,不要誇張表情,不要臉部變形,不要嘴唇變形,不要突然移動鏡頭。
實際使用時,把第一段換成你的角色、場景、動作與台詞即可。先固定一個鏡頭與一個主要動作,再逐步增加人物、轉場與複雜聲場。一次要求太多事件,往往比模型能力不足更容易造成身份漂移。
中文對白可用,但字幕最好留給後製
實測裡最值得記下來的缺點,是中文畫面文字仍可能出現亂碼,即使官方表示文字渲染已改善,這不代表長句中文字幕已經可靠,若提示詞要求中文對白,模型有時還會自行生成錯誤字幕。
提示詞明確加入「不要字幕、不要畫面文字」
先生成乾淨畫面與聲音
輸出後再用剪輯軟體或字幕工具加入繁中字幕
若聲音品質不穩,可把畫面生成與語音生成拆成兩條工作流
需要更細的角色音色控制時,可以搭配Qwen3-TTS 音色設計工作流 ,讓 LTX 2.3 專注畫面,再由語音模型與後製負責台詞品質,這通常比強迫單一模型同時把中文聲音與中文字都做到完美更務實。
本地還是雲端,差別不只在費用
本地工作流的優點是素材不必上傳第三方、模型與節點可自行調整,而且安裝完成後沒有逐秒 API 費用,缺點是模型檔很大,節點版本容易衝突,還要自己處理顯存與輸出速度。若你比較在意快速試模板與交付,也可以對照RunningHub 的雲端 ComfyUI 工作流 ,再決定控制權與便利性哪個重要。
解除限制版本不是品質保證
社群常用「無審查」或「解除限制」描述修改版權重。這只代表輸入限制可能不同,不代表畫質、授權、安全性或商用條件比官方版本更好。下載前要確認模型來源、授權條款與檔案雜湊,人物照片與聲音也必須取得同意。
尤其是換臉、移除人物、替換台詞與生成擬真人物時,更要避免冒用身份、未經同意的私密內容與誤導性成品。LTX 官方也有商業授權條件,企業使用前應直接閱讀最新授權,而不是只看模型能不能下載。
下載與參考資源
我的結論
如果目標是直式角色短片、圖生影片、帶環境音的短場景,LTX 2.3 很值得測,若目標是穩定中文字、長篇敘事或大量商業輸出,仍要把字幕、語音、剪輯與品質檢查拆成獨立步驟。模型負責生成,工作流負責把結果變成可以交付的作品。
FAQ
LTX 2.3 真的能在 8GB 顯卡執行嗎
可以,但通常要使用 GGUF 量化權重、CPU offload 與足夠的系統記憶體。8GB 指的是可嘗試的顯存門檻,不代表完整模型全放在 GPU,也不保證固定生成速度。
新手應該選 BF16、FP8 還是 GGUF
先用官方 Distilled 或 FP8 模板確認工作流。顯存不足再改用 GGUF。BF16 適合硬體充足並且重視品質的人,GGUF 適合願意接受卸載、速度與相容性取捨的低顯存使用者。
為什麼匯入工作流後有紅色節點
多半是缺少自訂節點或節點版本太舊。先執行 Install Missing Custom Nodes,再更新 ComfyUI、ComfyUI-LTXVideo、rgthree-comfy 與 ComfyUI-GGUF,完成後重新啟動。
中文對白為什麼會出現亂碼字幕
模型可能把對白理解成需要同步生成的畫面文字,而中文長句仍不穩定。提示詞加入不要字幕與不要畫面文字,先生成乾淨影音,再於後製加入繁中字幕最可靠。
LTX 2.3 可以離線使用嗎
模型、節點與依賴下載完成後可以在本機執行。首次安裝、更新模型或補齊節點仍需要網路,並且要預留足夠磁碟空間。
by Rain Chu | 8 月 27, 2026 | AI , DeepSeek , 模型
把兩台小型 AI 超級電腦接在一起,最先增加的不是單一請求速度,而是可承載的模型規模、上下文長度與同時服務能力,MSI EdgeXpert 採用 NVIDIA GB10 平台,每台有 128GB 統一記憶體,雙節點可讓 284B 的 DeepSeek V4 Flash、397B 的 Qwen3.5 MoE 與 230B 的 MiniMax M2 進入本地推理測試範圍。
我會把這類設備看成桌上型 AI 伺服器,而不是高階遊戲電腦,它最有價值的地方,是統一記憶體、低功耗、200GbE 高速互連,以及把敏感資料留在本地的能力,若只想偶爾聊天或寫程式,雲端 API 通常更省錢,若要處理長時間視覺串流、企業內網資料、批次 Agent 或需要 100GB 以上權重,本地設備才開始顯出意義。
MSI EdgeXpert 是什麼
EdgeXpert MS-C931 是基於 NVIDIA DGX Spark 平台思路打造的小型 AI 工作站,核心採 GB10 Grace Blackwell Superchip,把 20 核 Arm CPU、Blackwell GPU 與 128GB LPDDR5X 統一記憶體放進 151mm 見方的機身,重量約 1.2kg,儲存空間為 4TB NVMe M.2。
項目 EdgeXpert 規格 實際意義 處理器 10 顆 Cortex-X925 加 10 顆 Cortex-A725 適合資料處理、服務調度與模型前後處理 GPU NVIDIA GB10 Grace Blackwell 6144 CUDA 核心,第 5 代 Tensor Core 統一記憶體 128GB LPDDR5X CPU 與 GPU 共用,適合大型權重 記憶體頻寬 273GB/s 容量很大,但頻寬低於高階獨立顯卡 高速網路 2 個 200GbE QSFP56 可用雙鏈路連接兩個節點 一般網路 10GbE RJ-45 管理、檔案傳輸與區域網路服務 其他連接 4 個 USB 3.2 Type-C、HDMI 2.1a、Wi-Fi 7、藍牙 5.4 方便接相機、儲存裝置與顯示器 功耗 140W TDP 比傳統多卡工作站更容易放進辦公環境
GB10 與 RTX 5070 都有 6144 CUDA 核心,但定位完全不同,GB10 有 128GB 統一記憶體與最高 1000 AI TOPS,記憶體頻寬約 273GB/s,RTX 5070 只有 12GB GDDR7,頻寬約 672GB/s,前者能裝下大模型,後者在權重能完整放入顯存時通常跑得更快,容量和頻寬不能只選一個數字判斷。
雙機互連不是把速度直接乘二
兩個節點透過 QSFP56 連接後,模型權重會分散到兩台機器,每完成一層或一段運算,節點之間就要交換張量,這讓單台放不下的模型能夠執行,也能增加併發量,但同時帶來網路同步、序列化與等待成本。
容量擴張 :雙節點約有 256GB 統一記憶體可供系統與模型使用。
模型並行 :大型權重被切到兩台機器,任何一台故障都會讓服務中斷。
鏈路聚合 :兩條 200GbE 能降低通訊瓶頸,但收益取決於模型本身的計算與通訊比例。
延遲代價 :併發越高,P95 尾端延遲通常越明顯。
有人實際把四台同類設備做環形連接,確實能執行更大的模型,但速度不一定理想,節點增加後,容量會先變大,通訊路徑與維運難度也一起增加。這也是為什麼 273GB/s 記憶體頻寬與網路拓撲,比單看 AI TOPS 更值得注意。
三個大型 MoE 模型的雙機測試
測試固定使用 200G RoCE,透過 OpenAI 相容的 completions 介面送出三組工作提示。併發從 1、2、4、6 增加到 8,每個設定重複三次,觀察聚合吞吐量、P95 延遲、失敗請求與異常輸出。
模型 總參數與啟用參數 量化 模型載入量 每節點記憶體 測試上下文 Qwen3.5 397B A17B 397B、啟用 17B INT4 AutoRound 約 226GB 98.24GiB 262K DeepSeek V4 Flash 284B、啟用 13B FP4 加 FP8 約 160GB 75.8GiB 500K MiniMax M2 AWQ 230B、啟用 10B AWQ 4-bit 約 121GB 56.38GiB 128K
雙鏈路對 Qwen3.5 與 DeepSeek V4 Flash 有明顯幫助,對 MiniMax M2 的增幅很小。資料為每組三次測試平均。
模型 單鏈路 tokens/s 雙鏈路 tokens/s 增幅 Qwen3.5 397B 42.3 48.1 13.5% DeepSeek V4 Flash 48.3 53.9 11.6% MiniMax M2 AWQ 123.4 124.2 0.6%
結果很清楚,雙鏈路只會改善被節點通訊限制的模型,Qwen3.5 與 DeepSeek 的吞吐量分別增加約 13.5% 與 11.6%,MiniMax M2 幾乎沒有變化,代表它在這組設定下的主要瓶頸不在互連。
這組數字也不能直接拿來比較模型聰明程度,三者的量化格式、啟用專家數、上下文與模型大小都不同,MiniMax 速度最快,不代表回答品質最高,Qwen3.5 能用 262K 上下文啟動,DeepSeek V4 Flash 能用 500K 上下文啟動,這些容量優勢本身就是雙機部署的重要價值。
本地部署和 API 到底怎麼選
設備畫面標示單台價格為台幣 20 萬元,兩台還要加上高速線材、交換器、儲存與維護成本,若每月只是少量使用,雲端 API 很可能更划算,若每天持續分析大量影像、處理敏感文件、需要固定延遲,或模型呼叫量足以抵銷硬體成本,本地部署才有機會回本。
我比較在意的是混合部署,一般聊天與高難度推理交給雲端模型,持續監控、文件整理、影像理解與私有資料處理留在本地,這比要求一套設備取代所有 API 更務實,推理框架的選擇也會直接影響吞吐量,可以延伸閱讀 vLLM、SGLang、llama.cpp、MLX 與 Ollama 比較 。若手上已經有 DGX Spark,也可參考 DGX Spark 搭配 llama.cpp 的部署筆記 。
JoyAI-VL-Interaction 不只是看圖問答
JoyAI-VL-Interaction 是京東 JoyAI 團隊開源的即時視覺語言互動模型。它採 8B 級規模,真正特別的地方不是再回答一張圖片裡有什麼,而是持續觀看直播流,自己判斷現在應該開口、保持安靜,還是把困難工作交給背景 Agent。
一般 VLM 是回合制。使用者先問,它才回答。JoyAI 把行動時機訓練進模型,每秒做一次決策。火爐上的鍋開始冒煙、運動員出現關鍵動作、商店貨架少了一項商品,都不必等人先提出問題。這讓它更接近監控助手、直播解說員與現場操作夥伴。
決策 輸出 適合情境 保持安靜 silence 畫面沒有重要變化,避免持續打擾 直接回應 response 加文字 即時提醒、解說、計數與操作指引 委派工作 delegate 加任務 需要搜尋、推理、程式或外部 API 的複雜問題
官方公開超過 400 萬筆時間對齊的視覺互動樣本,並用強化學習調整說話時機,系統以約 1 fps 接收影像,把短期畫面、問答紀錄與長期記憶一起交給 VLM,每累積一段畫面就壓成摘要,再把多段摘要整理成長期記憶。
這種架構很適合長時間串流,但仍要注意 token 成本,官方把 AdaCodec 描述為只對重要變化保留完整細節的預測式視覺編碼方向,實際部署時要確認目前下載的模型與服務版本是否已啟用對應能力,不能只看架構圖就當成預設功能。
JoyAI 可以做什麼
居家安全 :觀察煙霧、跌倒、危險區域與幼兒動作,在需要時主動提醒。
體育與直播 :即時解說、關鍵事件判斷、計數與彈幕式評論。
零售與操作引導 :辨識貨架、產品與手機介面變化,逐步帶使用者完成任務。
RTSP 監控 :接入網路攝影機,讓視覺模型持續理解而不只是傳統動作偵測。
企業背景 Agent :把需要查資料或產生報告的工作交給 Codex 或其他 API,同時不中斷眼前的畫面監看。
官方在 26 個離線理解基準的平均分數為 57.53,高於 Qwen3-VL-8B-Instruct 的 54.16。這不代表它在所有聊天問題都勝過大型閉源模型。它真正的優勢區,是視覺觸發的主動性、回應時機、時間感與長串流記憶。若想了解另一種文件與 OCR 導向的 VLM,可參考 InternVL3 本地多模態整理 。
JoyAI 完整部署命令
官方目前建議 Linux、NVIDIA GPU、CUDA 12.x、535 以上驅動與 Python 3.12。先從最小服務開始,確認視覺推理和 WebUI 能正常工作。
git clone https://github.com/jd-opensource/JoyAI-VL-Interaction.git
cd JoyAI-VL-Interaction
./install/install.sh --with-all
./install/download-models.sh --all
./services/scripts/run.sh minimal
啟動後在瀏覽器開啟以下網址。第一次使用會遇到自簽憑證提示,僅在確認是自己的主機後繼續。
https://127.0.0.1:8099
若需要語音輸入、語音輸出與背景 Agent,可以啟動完整服務。
./install/install-audio-runtime.sh --all
./services/scripts/run.sh all
完整系統預設把主 VLM 放在 GPU 0,摘要模型放在 GPU 1,ASR 與 TTS 放在 GPU 2。兩台 EdgeXpert 比較適合先跑最小服務,再把 ASR、TTS 或背景 Agent 改接另一台主機或外部 API。若把所有服務硬塞進同一組節點,記憶體餘裕與即時延遲都要重新測量。
需要完整語音體驗時,JoyAI 預設可搭配 Qwen3-ASR 1.7B 與 Qwen3-TTS 1.7B。想先了解本地聲音設計與 TTS 部署,可閱讀 Qwen3-TTS 音色設計與本地工作流 。
把雙機分工用在 JoyAI
雙機不一定要只跑一個超大模型。對即時視覺系統來說,服務分工可能更有效率。
節點 A :JoyAI 主視覺模型、WebUI、攝影機或 RTSP 輸入。
節點 B :摘要模型、ASR、TTS、向量資料庫與背景 Agent。
高速鏈路 :交換畫面摘要、長期記憶與委派結果,不必讓每一層模型張量都跨節點。
雲端補位 :只有複雜推理與大型搜尋才呼叫 API,平常監看留在本地。
這種拆法不會得到 256GB 的單一權重空間,但可減少模型並行的同步成本,讓即時互動更穩定。若目標是部署 284B 或 397B 權重,才改用跨節點模型並行。先定義工作負載,再決定是合併記憶體還是拆分服務。
隱私與維運不能省略
JoyAI 會持續接收相機與麥克風資料,本地部署能降低內容離開內網的機率,但不代表自動安全,WebUI、OpenAI 相容 API、RTSP、背景 Agent 與檔案權限都要分別控管。不要把服務連接埠直接暴露到公網,也不要讓背景 Agent 在沒有確認的情況下執行刪除、付款或外部發布。
模型判斷也會出錯。居家安全、工廠告警與醫療照護不能只依賴單一 VLM,重要事件應保留傳統感測器、規則引擎、人工複核與完整日誌。開放權重帶來可控性,也把測試責任交回部署者。
我的判斷
EdgeXpert 雙機最吸引人的不是把 tokens/s 翻倍,而是用 256GB 級統一記憶體打開大型 MoE、超長上下文與私有化多模態服務。雙 200GbE 對通訊密集模型確實有幫助,但 0.6% 到 13.5% 的差異也提醒我們,瓶頸可能在記憶體頻寬、模型計算、量化核心或排程。
JoyAI 更像這類硬體的合理應用,它不只等待問題,而是長時間留在場景裡,知道何時說話、何時安靜、何時交給另一個 Agent,真正值得做的不是把所有模型都搬回家,而是把持續、敏感、可重複的工作留在本地,把偶發而困難的任務交給更強的雲端模型。
參考資料
FAQ
兩台 EdgeXpert 會讓推理速度變成兩倍嗎?
不會。雙節點主要增加可用記憶體與併發空間。實測中雙鏈路讓 Qwen3.5 增加約 13.5%,DeepSeek V4 Flash 增加約 11.6%,MiniMax M2 只增加約 0.6%。
JoyAI 一定要三張 GPU 嗎?
最小服務只需要主視覺模型與 WebUI。官方完整預設才會把主模型、摘要模型、ASR 與 TTS 分配到三張 GPU。資源較少時可停用語音與背景 Agent,或把它們接到其他服務。
JoyAI 和一般 VLM 最大差異是什麼?
一般 VLM 多半等使用者提問。JoyAI 持續觀察即時畫面,每秒自主決定保持安靜、直接回應或委派任務,適合監控、直播、操作引導與長時間互動。
本地 AI 一定比雲端 API 便宜嗎?
不一定。低用量通常是 API 更便宜。本地部署適合高頻使用、敏感資料、固定延遲與需要客製化服務的人。評估時要把硬體、電力、儲存、網路與維護時間全部算進去。
by Rain Chu | 8 月 25, 2026 | 3D , AI , claude
用 Claude Code 或 Codex 產生 Remotion 專案並不難,真正困難的是讓動畫從「可以播放」進步到「看起來像專業設計」,只下一句提示詞,AI 通常能把元件放進時間軸,卻很難同時掌握分鏡、節奏、視覺層級、轉場與品牌質感。
比較可靠的方法,是先把 Remotion 的 Agent Skill 安裝到開發代理,接著把需求拆成分鏡、時間、版面與動態規則,先完成短片段,再逐幀檢查並反覆修正。本文會從安裝開始,整理一套 Claude Code 與 Codex 都能使用的流程,也會說明 GSAP、D3.js、Lottie、Three.js、Canvas 與 Blender 各自適合處理什麼工作。
Remotion 是什麼
Remotion 是一套以 React 撰寫影片的框架。畫面被拆成 Composition,每個 Composition 會定義尺寸、幀率與總幀數,元件再依目前幀數計算位置、透明度、縮放與其他狀態。最後可以在 Studio 預覽,也能透過命令列輸出影片。
這種逐幀且可重現的設計很適合 AI 代理。代理可以讀取程式碼、修改元件、調整時間點,再重新輸出指定幀進行比對。它也適合大量產生不同文案、數據或尺寸的影片,而不是每次都回到剪輯軟體手動修改。
為什麼一句提示詞通常做不好
空白專案只提供了一堆可以組合的零件,沒有現成的鏡頭語言、元件規則與品質標準,當需求只有「做一支有質感的 SaaS 動畫」,代理還要自行猜測品牌顏色、字級、轉場、每一幕的長度,以及什麼才算有質感,結果自然容易變成普通投影片。
沒有分鏡,所以所有資訊同時出現
沒有明確時間點,所以動畫速度忽快忽慢
沒有動態規則,所以每個元素使用不同節奏
沒有參考幀,所以代理只能猜測版面與層級
沒有驗收步驟,所以第一版直接被當成完成品
Agent Skill 的價值,就是先把 Remotion 的正確用法、常見陷阱與輸出流程交給代理,這和建立 Claude Code 自訂 Skill 的概念相同,先提供可重複使用的方法,再讓代理處理當次任務。
Claude Code 與 Codex 都能使用 Remotion Skill
Remotion 官方的 Agent Skills 文件 已列出 Claude Code 與 Codex 等開發代理。先確認電腦已安裝 Node.js,再建立空白專案並加入 Skill。
npx create-video@latest --yes --blank my-video
cd my-video
npm i
npx remotion skills add
npm run dev
如果希望把官方 Skill 安裝成全域能力,可以執行下面的指令。
npx -y skills@latest add remotion-dev/skills -g -y
官方能力不只包含基本規範,也有建立作品、字幕、地圖、SaaS 產品動畫、互動播放器、媒體處理、版本升級與輸出等分工
這表示 Codex 並不是只能修改既有 Remotion 程式,也能從規格開始建立專案並完成輸出。
可直接使用的繁體中文提示詞
提示詞不要只描述主題,也要同時定義格式、時間軸、視覺系統、動態語言與驗收方式.
下面這份範本可以直接貼給 Claude Code 或 Codex,再替換中括號內的內容。
請先讀取目前可用的 Remotion Skill 與專案規範,再建立一個可直接輸出的 Remotion Composition。
影片主題
[要傳達的產品或故事]
輸出格式
1920 x 1080
30 fps
總長 20 秒
Composition ID 使用 ProductLaunch
視覺方向
使用深灰、米白、青色與珊瑚紅
畫面安靜、精準、有產品發表會質感
禁止套用通用科技藍紫漸層
文字必須保留安全邊界並在手機縮圖中可讀
分鏡
0 到 3 秒顯示品牌名稱與一句核心價值
3 到 8 秒展示產品介面與主要操作
8 到 14 秒用三個步驟說明工作流程
14 到 18 秒顯示成果數據
18 到 20 秒收尾並顯示行動文字
動態規則
所有動畫都要由 useCurrentFrame、interpolate 或 spring 驅動
每次只讓一個主要資訊成為視覺焦點
入場使用淡入、位移與輕微縮放
不要使用無法由幀數重現的 CSS transition
不要使用 Math.random、目前日期或即時網路狀態
工作方式
先建立 5 秒的第一幕作為品質樣本
輸出第 0、30、60、90、120 與 149 幀供我檢查
確認沒有文字溢出、遮擋、跳動與空白畫面後,再完成全部分鏡
最後列出 Composition ID、預覽方式與輸出指令
這個範本刻意要求先做 5 秒樣本。若第一幕的字體、間距與動態節奏不對,先修正視覺系統會比做完 20 秒後重來省下更多時間。
若想深入理解 Codex 產生動態內容的提示架構,可以延伸閱讀Codex 做動態圖表和短影片的工作流程 。
模仿參考動畫時要先拆解畫面
把整段參考素材轉成大量截圖,再一次交給代理,通常只能得到顏色和版面大致相近的結果。,集畫面缺少元素對應、時間關係與動態方向,代理不容易判斷一個物件是移動、被遮罩,還是切換成另一個元件。
每 0.5 到 1 秒擷取一張代表幀
標記每個鏡頭的開始時間與結束時間
列出背景、主體、文字、裝飾與遮罩等圖層
描述物件從哪裡進入、移動到哪裡、使用何種緩動
先重建最具代表性的 3 到 5 秒
輸出相同時間點的幀並排比較
軌跡動畫也可以用一張乾淨的路徑草圖輔助。把路徑、起點、終點與移動方向畫清楚,再要求代理將路徑轉成 SVG 或座標資料,通常比只用文字描述「繞一圈再飛出去」更準確。參考作品應作為鏡頭與節奏研究,不要直接複製商標、字體、插圖或其他受保護素材。
Remotion 與各種動畫工具怎麼選
工具 擅長內容 適合情境 Remotion 原生能力 React 元件、分鏡、字幕、影片組合 產品介紹、教學短片、批次影片 GSAP 時間軸、緩動、複雜介面動態 SaaS 首頁、產品發表、投影片式轉場 D3.js 資料轉換、SVG、客製圖表 統計變化、架構圖、地圖與路徑 Lottie JSON 向量動畫 圖示、付款流程、節慶與微動畫 Three.js 即時 3D 場景與模型 低多邊形場景、設備與空間示意 Fabric.js 與 p5.js Canvas 繪圖與自訂視覺 白板、手繪、幾何圖形與實驗動畫 Blender 建模、材質、燈光與高品質 3D 產品模型、車輛、角色與複雜鏡頭
Remotion 加 GSAP
GSAP 的 Timeline 很適合管理多段 Tween,也方便安排重疊、標籤與緩動。它能讓產品頁面以投影片般的節奏逐幕展開。不過 Remotion 最終仍要對每一幀得到固定結果,因此整合時應由目前幀數控制 GSAP 的進度,避免依賴瀏覽器實際經過的時間。
Remotion 加 D3.js
D3.js 是自由度很高的資料視覺化工具,關於人口統計變化、系統架構、交通路線與歷史路徑都很適合先由 D3 計算比例尺、座標與 SVG,再由 Remotion 控制每一段資料何時出現,資料來源應保存在專案內或在輸出前完成下載,避免輸出時受到外部 API 波動影響。
Remotion 加 Lottie
Lottie 適合圖示、付款成功、條碼掃描與簡短節慶動畫,官方套件需要安裝 @remotion/lottie 與 lottie-web。部分 Lottie expression 無法保證逐幀一致,正式輸出前應特別檢查是否閃爍。
npm i @remotion/lottie lottie-web
Remotion 加 Three.js
Three.js 適合在 React Three Fiber 中載入 3D 模型,再用 Remotion 的目前幀數控制相機、模型與燈光,官方提供 @remotion/three 進行整合,低多邊形產品展示、工廠流程或地圖空間化很合適,複雜建模與擬真材質則應交給 Blender。
npm i three @react-three/fiber @remotion/three @types/three
Blender 與 MCP 的正確分工
Blender 可以完成建模、材質、燈光、相機與骨架動畫,透過合適的 MCP 連接器,Claude Code 或 Codex 可以呼叫 Blender 執行部分操作,但這不代表代理已具備專業 3D 美術判斷,最有效率的分工,是由 Blender 建立複雜 3D 資產與鏡頭,再輸出透明影片或圖片序列,最後交給 Remotion 疊加文字、圖表、字幕與音訊。
MCP 連接器屬於第三方整合時,要先檢查原始碼、權限範圍與維護狀態。不要讓來源不明的工具取得整台電腦或敏感專案的存取權。
如何輸出透明字卡與動畫覆蓋層
透明背景不能只把 CSS 背景設成透明,輸出格式也必須保留 Alpha 通道,若要放進 Final Cut Pro、Premiere 或 DaVinci Resolve,Remotion 官方建議使用支援 Alpha 的 ProRes 4444 或 4444 XQ,影格格式選 PNG,像素格式使用 yuva444p10le。
npx remotion render ProductLaunch out/overlay.mov --image-format=png --pixel-format=yuva444p10le --codec=prores --prores-profile=4444
網頁若需要透明影片,可以輸出 VP8 或 VP9 的 WebM,搭配 PNG 影格與 yuva420p,瀏覽器支援並不一致,正式網站最好同時準備不透明的備用版本。
從需求到成品的完整工作流程
寫清楚目的 先決定受眾、平台、時長與希望觀眾記住的唯一重點
拆分分鏡 每幕只安排一個主要訊息,標出開始與結束時間
定義視覺系統 固定顏色、字體、間距、圓角、陰影與安全邊界
安裝 Skill 讓代理先讀取 Remotion 的官方規範與相關能力
先做短樣本 用 3 到 5 秒確認設計方向,不要直接生成整支作品
檢查代表幀 至少檢查開頭、中段、轉場前後與結尾
加入專用工具 依需求選 GSAP、D3、Lottie、Three.js 或 Blender
加入音訊 最後才對齊旁白、音效與背景音樂
輸出與複查 完整播放成品,也要檢查文字是否溢出與畫面是否閃爍
預覽完成後,可以先列出 Composition,再輸出指定作品。
npx remotion compositions
npx remotion render ProductLaunch out/video.mp4
Remotion 與用 HTML 寫影片的 HyperFrames 都把畫面轉成代理可修改的程式碼。Remotion 更接近 React 生態與逐幀影片管線,HyperFrames 則適合直接以 HTML 組合動態內容。選擇重點不是哪一套比較新,而是哪一套更符合現有技術與交付格式。
一定要用 Remotion 嗎
不一定。若只是把現成網頁動畫輸出成一次性的短片,可以用 GSAP 或 D3 建立網頁,透過 Playwright 等瀏覽器工具逐幀截圖,再交給 FFmpeg 合成,這條路徑簡單直接,也能保留原本的前端互動程式。
Remotion 的優勢在於 Composition、時間軸、媒體同步、參數化、Studio 預覽與標準輸出流程,當作品包含多個分鏡、字幕、音訊、不同尺寸,或需要批次套用資料時,這些能力會明顯降低維護成本,單次實驗可以選瀏覽器截圖加 FFmpeg,長期內容管線則更適合 Remotion。
常見問題
Codex 可以取代 Claude Code 完成這套流程嗎
可以,Remotion 官方 Agent Skills 文件已把 Codex 列為適用代理,差異主要來自代理讀取到的 Skill、專案上下文、提示詞完整度與驗收流程,而不是只能使用某一個品牌的開發工具。
為什麼參考圖很多,結果還是不像
大量截圖不等於完整動態規格,需要補上每個圖層的名稱、時間區間、位移方向、遮罩關係與緩動方式,先重建一個短鏡頭,再逐幀對照,會比一次交付整段素材更有效。
什麼工具最適合動態圖表
D3.js 適合需要客製比例尺、座標、路徑與 SVG 的資料視覺化,一般長條圖或折線圖不必為了技術感增加過多特效,先確保數據正確、標籤可讀與變化有清楚的時間順序。
透明影片輸出後為什麼變成黑底
通常是編碼器、像素格式或影格格式沒有保留 Alpha,剪輯軟體可用 ProRes 4444 搭配 PNG 與 yuva444p10le,網頁則可測試 VP8 或 VP9 WebM 搭配 yuva420p。
結論
Claude Code、Codex 與 Remotion 的組合確實能做出高品質動畫,但品質不是來自一句神奇提示詞。真正有效的做法,是先讓代理掌握 Skill,再把需求寫成可驗收的分鏡與逐幀規則,最後依內容選擇 GSAP、D3、Lottie、Three.js、Canvas 或 Blender。
把第一版當成可以修改的動畫原型,而不是最終成品,先完成短樣本、檢查代表幀、修正視覺系統,再擴充完整時間軸,AI 才會從快速生成工具變成穩定的動態設計工作夥伴。
延伸資料
by Rain Chu | 8 月 24, 2026 | AI , claude
Claude Code 已經能在很短時間內完成網站骨架、元件組合、響應式版面與互動原型。真正拉開品質差距的地方,卻不是「會不會叫 AI 寫前端」,而是能否先定義網站要說服誰、希望對方採取什麼行動,再選擇正確的素材與技術。
一套實用的 AI 網站工作流,可以用 Claude Code 負責程式與整合,用 shadcn/ui 建立元件基礎,再依需求加入 Lottie、Three.js 或捲動圖片序列。最後仍要回到效能、無障礙、後端、安全與維護,才能把吸睛展示變成真的可用網站。
AI 做網站的真正分水嶺
如果只輸入「幫我做一個現代感網站」,AI 很容易回到訓練資料中最常見的版型。常見結果是大標題、三張功能卡、藍紫漸層、圓角按鈕與制式頁尾。這不是程式沒有寫好,而是需求沒有提供受眾、目的、內容優先順序與視覺判斷標準。
網站發展階段 常見特徵 對 AI 設計的提醒 1995 到 2000 表格排版、Frame、閃爍圖示與訪客計數器 技術限制會直接形成視覺語言 2000 到 2005 Flash 開場與高度裝飾性動效 效果醒目不代表資訊容易理解 2005 到 2010 CSS Float 與較自由的版面 排版技術改變後仍需要內容策略 2010 到 2014 響應式設計與 Bootstrap 普及 大量相似版型成為 AI 最熟悉的答案 2015 之後 SPA、元件化與設計系統 元件提高效率,但不會自動產生品牌差異
因此,Skill、設計規則與參考資料會直接影響生成結果,像 用 Impeccable 改善 AI 網站設計 ,就是把審美與常見問題整理成可重複使用的規則。它能減少模板感,但最後仍要由人判斷設計是否符合目的。
先決定網站屬於哪一種策略
同一份公司資料,可以做成完全不同的網站,寫程式前,我會先選擇下面三種策略之一,再決定資訊架構、動效密度與追蹤指標。
策略 資訊路徑 適合情境 主要指標 說服漏斗 看見、信任、理解、行動 接案、服務與銷售頁 CTA 點擊率、聯絡表單完成率 敘事閱讀 主張、方法、工藝、系統、合作 工作室、品牌故事與高單價服務 閱讀時間、捲動深度、案例點擊 最短路徑 價值、證據、精選作品、服務、行動 行動裝置優先與需要快速決策的網站 載入速度、行動版聯絡轉換率
動畫工作室可以用高密度動效展示能力,但代價可能是載入速度和無障礙表現,法律、醫療或在地服務網站通常更需要清楚、可信任與快速聯絡。設計不是把所有效果都放進來,而是保留最能支持目標的部分。
Claude Code 與網站工具分工
Google Whisk 原本能以主體、場景與風格圖片快速探索視覺方向,Google 已在 2026 年 2 月的 Flow 更新 中宣布把 Whisk 與 ImageFX 的主要能力整合到 Flow,因此新專案可直接從 Flow 開始。想了解原本的操作概念,仍可閱讀 Google Whisk 官方介紹 。
完整工作流一:先做策略與規格
第一步不要急著叫 Claude Code 產生首頁。先把商業目標、受眾、內容和成功標準整理成一頁規格。以下提示詞可直接交給 Codex、Claude 或 Gemini。
你是一位網站策略師與資深產品設計師。
請先不要寫程式,根據下面資料建立網站策略。
品牌或產品:[填入名稱]
主要受眾:[填入使用者]
希望完成的行動:[購買、預約、聯絡或訂閱]
現有內容:[貼上文字與素材清單]
限制:[技術、時程、品牌或法規限制]
請輸出:
1. 一句清楚的價值主張
2. 建議採用說服漏斗、敘事閱讀或最短路徑,並說明原因
3. 從首頁到主要行動的資訊架構
4. 每個區塊的目的、必要內容與 CTA
5. 建議追蹤的三個指標
6. 不應加入的內容與效果
7. 桌面版與行動版的驗收條件
資訊不足時先列出問題,不要自行虛構客戶、獎項或數據。
這一步完成後,再請 AI 挑戰規格中的假設,例如「為什麼一定要輪播圖」或「使用者能否在五秒內找到聯絡方式」。好的規格應該能回答為誰設計、為何這樣排,以及如何判斷有效。
完整工作流二:拆解參考網站但不複製
參考 Awwwards 等設計網站時,應拆解規則,不應下載別人的品牌素材後直接換字,可觀察版面比例、閱讀節奏、元素定位、字體層級、動效觸發條件與素材格式,再用自己的內容重建。
請分析我提供的參考網站截圖與網址,建立一份可實作的設計規格。
請拆解:
1. 頁面區塊順序與每個區塊的目的
2. 網格、最大寬度、留白與對齊方式
3. 字體層級、行高與閱讀節奏
4. 色彩角色,不只列出色碼
5. 圖片、Lottie、影片與 3D 素材的使用位置
6. 捲動、游標、進場與狀態切換的觸發方式
7. 行動版需要刪除、簡化或改排的內容
8. 可能使用的前端技術與效能風險
只提取設計原則與互動邏輯。
不要複製原站文案、Logo、商標、插圖、照片或可識別的品牌元素。
請提出三個能保留體驗但形成原創差異的方向。
這種方法比要求「做得一模一樣」更能長期使用,也降低著作權與品牌混淆風險。若想進一步建立 AI 設計規則,可以參考 UIUX Pro Max 與 WordPress 外觀設計 。
完整工作流三:用 Claude Code 與 shadcn/ui 起底
Claude Code 可從終端機讀取整個專案。安裝完成後進入網站資料夾,再啟動互動工作階段。
npm install -g @anthropic-ai/claude-code
cd my-website
claude
對電商、預約、點餐、聊天室或儀表板這類常見介面,shadcn/ui 能快速提供表單、按鈕、對話框、表格與導航元件。不過它只是原始碼與設計系統的起點。若沒有重新調整字體、密度、色彩、狀態和內容層級,網站仍會有明顯套版感。
請先閱讀現有專案結構與套件,不要重建整個專案。
根據已確認的網站策略,建立首頁與主要操作流程。
實作要求:
1. 優先沿用現有框架與元件模式
2. 使用 shadcn/ui 作為基礎,但重新定義色彩、字體、間距與互動狀態
3. 使用語意化 HTML,完整支援鍵盤與螢幕閱讀器
4. 桌面、平板與手機都要有明確版面
5. 不使用虛構數據、假客戶、假按鈕或沒有結果的表單
6. 不加入無助於目標的漸層、裝飾光球與過量動畫
7. 建立 loading、empty、error、success 與 disabled 狀態
8. 完成後執行測試,並列出尚未串接的後端功能
先提出實作計畫與檔案變更清單,確認後再開始修改。
對常見產品而言,先讓 AI 建立可操作底稿,再逐步替換品牌內容,通常比從空白專案慢慢刻元件更有效。若專案容易在連續修改後失控,可以搭配 Superpowers 開發紀律 ,把規格、測試與驗收拆成較小步驟。
Lottie、真 3D 與假 3D 怎麼選
方案 優點 限制 適合內容 Lottie 檔案小、向量清晰、容易控制播放 不適合複雜寫實 3D 圖示、插圖、載入與狀態動效 Three.js 加 3D 模型 可旋轉、換視角、改材質與即時互動 開發與效能成本較高 產品檢視器與需要自由互動的場景 圖片序列加 ScrollTrigger 視覺穩定、容易做出高質感捲動敘事 圖片數量大,需預載與壓縮 固定鏡位的拆解、變形與成長動畫
如果訪客不需要自由旋轉物件,真正的 3D 不一定划算。固定鏡位的產品炸開、植物生長、書本展開或日夜轉換,都可以先生成影片,再拆成圖片序列,用捲動位置控制幀數。這種方法的重點是首尾畫面的構圖、光線和物件位置必須一致。
產生首尾關鍵畫面的提示詞
建立兩張 16 比 9 的產品關鍵畫面,作為首尾幀動畫素材。
主體:一個放在深色石材桌面的精緻漢堡
起始畫面:漢堡完整組裝,置於畫面中央
結束畫面:麵包、蔬菜、起司與肉排沿垂直方向均勻分離,形成清楚的爆炸分解圖
兩張圖必須維持完全相同的攝影機位置、焦段、光線、背景、陰影與物件比例。
產品邊緣清楚,材質寫實,構圖適合網站主視覺。
不要文字、Logo、手、餐具、額外食材或鏡頭移動。
Flow 首尾幀轉場提示詞
固定攝影機與背景不動。
讓完整漢堡平順地分解成尾幀中的爆炸結構。
每一層食材只沿垂直方向緩慢移動,保持形狀、材質、光線與比例一致。
動作由慢到快再自然減速,沒有旋轉、彈跳、變形或新增物件。
首幀和尾幀必須精準對齊,適合拆成連續圖片序列。
轉場完成後,可用 ezgif 的 Video to JPG 或 Video to WebP 拆幀,只保留足以讓動作平順的圖片,統一尺寸和命名,再交給 Claude Code。圖片越多不一定越好,行動裝置的下載量與解碼記憶體必須一起評估。
用 ScrollTrigger 控制圖片序列
GSAP ScrollTrigger 的 scrub 能讓動畫進度直接跟著捲動位置。實作時可把 Canvas 固定在視窗內,依進度換算目前幀數。這裡最容易被忽略的是預載、視窗縮放、圖片比例與減少動態效果設定。
請在現有頁面建立捲動控制的圖片序列動畫。
素材位置:public/sequence
檔名規則:frame-0001.webp 到 frame-0120.webp
需求:
1. 使用 Canvas 繪製,不要一次建立 120 個 img 元素
2. 預載第一幀並立即顯示,再於背景載入其餘圖片
3. 顯示真實載入進度,載入失敗時提供靜態首圖
4. 使用 GSAP ScrollTrigger,將動畫區塊固定並用 scrub 對應捲動進度
5. 依照裝置像素比與容器尺寸重繪,圖片維持完整比例
6. resize 後重新計算 Canvas 與 ScrollTrigger
7. 支援 prefers-reduced-motion,停用動態時顯示最有資訊的靜態幀
8. 行動裝置使用較少幀數或較小圖片
9. 元件卸載時清除 ScrollTrigger、事件與圖片參照
10. 完成後檢查首頁載入量、記憶體與捲動是否流暢
先說明檔案與元件架構,再修改程式。
若畫面真的需要讓訪客旋轉、縮放或更換材質,才改用 Hyper3D 產生模型並匯出 GLB,再由 Three.js 載入。模型要先減面、壓縮貼圖並測試手機 GPU。寫實模型能帶來更自由的互動,也會增加載入、除錯與相容性成本。
漂亮原型不等於正式網站
AI 可以快速做出電商、點餐、音樂串流、旅遊規劃、預約與資料儀表板的外觀,要判斷能不能真的使用,不能只看畫面。每一個按鈕、表單、登入、付款與資料狀態都必須有完整路徑。
後端與資料:API、資料庫、搜尋、檔案上傳與交易一致性。
身分與權限:登入、角色、授權、工作階段與密碼重設。
安全:輸入驗證、輸出編碼、金鑰管理、速率限制與安全標頭。
可靠性:錯誤狀態、重試、備份、監控、日誌與復原方式。
品質:響應式、鍵盤操作、螢幕閱讀器、色彩對比與減少動態效果。
效能:圖片壓縮、程式分割、第三方腳本、Core Web Vitals 與低階手機測試。
維護:套件更新、文件、測試、部署流程與內容管理權限。
請把目前網站視為準備上線的正式產品,執行一次完整稽核。
逐項檢查:
1. 所有按鈕、表單、連結與導覽是否有真實結果
2. API、資料庫、登入、權限與錯誤處理是否完整
3. 是否暴露金鑰、個資、內部網址或敏感日誌
4. 是否存在 XSS、CSRF、未驗證輸入與越權風險
5. 鍵盤、螢幕閱讀器、對比與減少動態效果是否可用
6. 手機、平板與桌面是否出現溢位、遮擋或版面跳動
7. 首頁下載量、LCP、CLS、INP 與圖片序列記憶體是否合理
8. SEO、Open Graph、結構化資料與 404 頁面是否完成
9. 測試、部署、監控、備份與回復流程是否存在
請把結果分成阻擋上線、上線前修正、可以後續改善三個等級。
每個問題要提供檔案位置、重現方式與建議修改,不要只給原則。
熟悉前端與系統的人通常更能把 AI 用好,因為他們知道哪些地方看似完成,其實只是靜態假象。AI 壓縮的是產生程式碼的時間,需求澄清、架構、除錯、安全、效能與長期維護仍需要工程判斷。
如何整合到 WordPress
Claude Code 產生的網站不會自動變成 WordPress,但有三種常見整合方式。內容型網站可以做成自訂佈景主題或 Gutenberg 區塊。需要 React 互動但仍由 WordPress 管理內容時,可以採用 Headless WordPress,只有單一活動頁時,也能把整理後的 HTML、CSS 與 JavaScript 放進專用頁面模板。
Lottie 與 GSAP 應透過佈景主題或外掛載入,不要在每篇文章重複塞入完整套件。
表單、會員、購物與預約要串接 WordPress API 或成熟外掛,不能只保留前端畫面。
Three.js 與圖片序列要測試 Divi 或其他頁面編輯器是否重複載入腳本。
內容編輯者需要可理解的欄位,不應每次修改文案都回頭改程式。
如果想用 Codex 製作可互動的 HTML 視覺內容,也可以延伸閱讀 Open Design 與 HTML 簡報實戰 ,理解設計規格如何轉成可執行的前端成果。
我會怎麼安排這套流程
先寫受眾、目標、內容與成功指標。
選擇說服漏斗、敘事閱讀或最短路徑。
拆解參考網站的規則,不複製品牌素材。
用 Claude Code 和 shadcn/ui 建立可操作骨架。
依互動需求選擇 Lottie、Three.js 或圖片序列。
先完成一段代表性動效,再決定是否擴大使用。
以真實內容、資料與操作流程完成整合。
執行安全、無障礙、效能與跨裝置驗收。
部署後追蹤轉換與使用行為,再依數據調整。
這套流程的價值不在於證明前端工程師會消失,而是把工作重心從手動堆疊元件,推向需求判斷、設計系統、技術選型與品質保證。AI 可以讓第一版非常快,真正有價值的專業則是知道第一版離可用、可信任與可維護還差多少。
工具與官方資源
FAQ
Claude Code 可以一句話完成整個網站嗎
它可以快速建立完整度很高的原型與常見介面,但正式網站還需要真實內容、資料來源、後端、權限、安全、效能與部署驗收。一句話適合起步,不適合直接當成上線規格。
用了 shadcn/ui 就能消除 AI 模板感嗎
不能。shadcn/ui 提供高品質元件原始碼與良好基礎,但網站仍需要自己的字體、色彩、密度、內容層級、互動和品牌素材。設計策略比元件名稱更重要。
Lottie、Three.js 和圖片序列該怎麼選
簡單向量動效選 Lottie。需要自由旋轉或即時互動選 Three.js。只有固定動作且希望由捲動控制時,圖片序列通常更容易穩定呈現。
Google Whisk 現在要到哪裡使用
Google 已把 Whisk 與 ImageFX 的主要能力整合到 Flow。新工作流可以直接使用 Flow 建立圖片與影片,原本的 Whisk 操作概念仍可作為提示詞與視覺探索參考。
這套方法可以用在 WordPress 嗎
可以,但要先選擇自訂佈景主題、Gutenberg 區塊、Headless WordPress 或專用頁面模板。動態資料與會員功能仍要正確串接 WordPress 後端,不能只把 React 畫面貼進文章。
近期留言