by Rain Chu | 9 月 26, 2026 | AI, 圖型處理, 影片製作
想讓電腦桌面多一個會揮手、坐下、開口說話的角色,可以先做一段 AI 影片,再把影片設為動態桌布,我們可以用 ComfyUI 負責串接生成流程,MiniMax H3 產生影像與聲音,桌布軟體負責播放,把這三件事分開理解,製作時就比較不會卡在錯的地方。
這篇教學的成品是預先生成、循環播放的桌面角色。角色看似對著你說話,台詞其實已經寫在影片裡。
未來的目標是「我問一句,她能即時回答」,還需要另外建立對話系統。
先分清楚:會動的桌布,和能聊天的 AI 角色
動態桌布的核心是一個影片檔,角色何時眨眼、說哪一句話、什麼時候坐下,都在生成或剪輯時決定,播放時不會因為你突然發問,就改變下一句台詞,這種做法適合桌面裝飾、角色展示,以及固定內容的迎賓畫面。
即時互動則多了收音、語音辨識、語言模型、語音合成與嘴型同步。滑鼠互動或視線追蹤也要額外設計程式,不能只靠換一段提示詞。如果你要的是能接話的數位人,可以接著看本地 AI 數位人與語音互動流程。
第一步:先準備乾淨的場景與人物素材
準備一張適合當桌布的背景,以及一張有使用權的人物圖片。
人物若有透明背景,合成時比較容易調整大小與位置。建議先使用單一成年角色、簡單服裝與固定場景,讓第一輪生成只處理一個動作。
背景可以是沙發、房間或書桌,人物要有足夠空間完成動作。
放在桌面上時,還要避開常用圖示的位置。不要把真實桌面圖示與工作列一起烙進背景影片,否則 Windows 原本的圖示疊上去,會出現兩層圖示,後續改位置也容易露餡。
接下來要決定素材怎麼送進模型,使用圖生影片的 I2V 工作流時,最好先做成一張完整首幀,讓人物真的站在房間裡。把人物圖與背景圖左右並排後直接丟進 I2V,模型可能把拼貼版面也當成場景的一部分。
若希望分別提供人物、場景等參考素材,應改用支援參考輸入的 R2V 工作流,按模板指定的位置連接素材。
I2V 與 R2V 的輸入用途不同,不能只換檔名就當作同一件事。需要整理多張素材時,可參考ComfyUI 多圖參考與圖片編輯的處理思路。
第二步:從官方模板開始,模型檔案不要混用
先從ComfyUI 官方網站取得軟體,更新到支援 MiniMax H3 的版本,再從模板庫的影片分類找到 MiniMax H3,也可以下載 Comfy-Org 的 I2V 範例工作流,依畫面上的缺少模型提示補齊檔案。
桌面角色從一張完成的場景圖出發,可先用 I2V。若要改用多素材參考,再看官方 R2V 模板,先把一套官方範例跑通,再接作者自訂節點,排錯會容易很多。
以下是本次核對的官方 I2V 模板所使用的檔案配置。檔名可能隨模板更新調整,實際下載時以當前模板與 Comfy-Org 模型頁為準。
ComfyUI/models/
├── diffusion_models/
│ └── minimax_h3_fl2va_pruned_int8_convrot.safetensors
├── text_encoders/
│ └── qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors
├── loras/
│ └── minimax_h3_fl2v_turbo_8step_v1.0_comfyui_bf16.safetensors
└── vae/
├── minimax_h3_video_vae_fp16.safetensors
└── minimax_h3_audio_vae_fp32.safetensors
主模型負責生成,文字編碼器處理提示內容,影片與音訊 VAE 則各有用途。不要只下載最大的模型檔,就以為其餘元件可以省略。官方模型頁也區分量化格式與執行環境,應照自己的環境選擇,不能把所有較小的檔案都視為可互換版本。
H3 的本地部署還牽涉系統記憶體與模型載入方式,不能只看顯卡名稱。進一步的環境整理可接著看MiniMax H3 本地部署與記憶體配置,再對照你實際載入的模型與模板版本。
第三步:先做一段短動作,不要一開始就塞滿劇情
第一輪可以用橫向構圖、固定鏡頭與較低的預覽解析度,先生成一段約 6 秒的動作。這裡的 6 秒是起步設定示例,並非效能保證。先確認角色外觀、動作與音訊都正常,再增加畫質與情節。
MiniMax H3 官方模型卡標示的生成時長為 4~15 秒。想做 30 秒的完整演出,可以先拆成數段鏡頭再剪輯,或另外研究延伸工作流,不能把 30 秒當作標準模板必然支援的單段設定。
解析度也要跟著模板的選擇器走。ComfyUI 的 H3 教學提醒,尺寸有對齊與像素量限制。初次嘗試不要任意輸入螢幕的完整高解析度,也不要把 API 提供的高解析度處理能力,直接套用到本地開放權重工作流。
提示詞示例:讓角色自然揮手,再回到休息姿勢
下面是為本文撰寫的起步提示詞,未經本機生成實測,重點是場景、動作與鏡頭都簡單,而且首尾姿勢接近,方便後續整理成循環影片。
固定鏡頭,橫向構圖,柔和的室內日光。
一名穿著藍綠色針織衫的成年女性坐在深灰色沙發上,人物外觀與參考圖一致。
她先自然地看向鏡頭,接著微笑並輕輕揮一次手,最後把手放回膝上,恢復安靜坐姿。
整段只有一位角色,背景保持穩定,動作平緩。
輕微室內環境聲,無對白、無背景音樂、無字幕。
先生成無對白版本,能比較容易看出畫面本身的問題。
等角色穩定後,再加一句短台詞,並參照官方提示詞指南處理說話者、台詞與發聲時機。不要在第一輪同時要求換裝、走路、坐下、唱歌與密集字幕,否則很難判斷是哪一項條件讓結果失控。
若需要字幕,建議在影片確認後再用剪輯軟體加入,把字幕直接交給影片模型生成,仍可能出現字形錯誤或時間不準,後製文字也比較容易修改。
第四步:確認加速 LoRA 真的有進入生成路徑
下載加速 LoRA,只完成了準備工作。還要確認載入節點選到正確檔案、節點沒有被略過,並且輸出確實接到後面的模型與採樣流程。若節點被停用或旁路,硬碟裡有那個檔案也不會自動產生加速效果。
H3 的工作流與任務模式有對應關係,加速設定也有自己的採樣配置。
先依官方原生工作流文件保留一整套相容設定,不要只因為想更快,就把不同任務的 LoRA、步數與模型任意混搭。加速後仍需重新檢查動作與聲音品質。
第五步:輸出影片,再用 Lively 設成動態桌布
生成完成後,先用一般播放器打開輸出的影片,檢查人物是否變形、背景有沒有漂移、聲音是否正常,以及片尾接回片頭時會不會突然跳動,如果首尾差異很大,可以縮短片段、重新安排動作,或在剪輯時做適度轉場。
Windows 使用者可以用免費開放原始碼的 Lively Wallpaper播放影片桌布。
從官方專案提供的管道安裝後,開啟 Lively,把輸出的 MP4 拖進程式建立桌布,再套用到指定螢幕。多螢幕配置可依官方入門說明調整。這是把成品落地到桌面的補充做法。
套用後,Windows 的圖示仍由作業系統顯示,影片只負責背景。
若桌布會反覆播放台詞,日常使用可能很干擾,建議先保留安靜版本,需要展示時再切換有聲版本。
跑不動、沒有聲音、下載要付費,怎麼判斷?
記憶體不足與藍畫面要分開處理
顯示記憶體不足時,先縮短影片、降低預覽解析度,並把批次數維持在 1。再確認是否載入了比預期更大的模型,以及系統記憶體是否也接近用滿。相同顯卡在不同模型格式、卸載策略與工作流下,結果可能差很多。
若整台電腦出現藍畫面,單憑這個現象無法判定就是顯示記憶體不足。先記錄錯誤代碼與當時設定,再檢查驅動、記憶體及系統穩定性。沒有完成實測之前,不應把某張 8GB 或 16GB 顯卡寫成一定可跑、一定不會當機的保證。
影片有畫面,卻沒有預期的聲音
先確認提示詞本來是否要求聲音,再檢查音訊 VAE、音訊相關節點及輸出是否接好。也要用播放器確認檔案音軌與靜音設定。最後才檢查桌布程式的音量,避免把生成端與播放端的問題混在一起。
先完成一段能穩定播放的短片
第一個里程碑可以很小:一張乾淨的場景圖、一個簡單動作、一段能順利輸出的影片。把它設成桌布後,再回頭調整畫質、循環接點與聲音。這樣每次只增加一個變因,比一開始追求長篇對話、換裝與高解析度更容易找到問題。
常見問題
桌面 AI 女友可以直接聽懂我說話嗎?
本文做法是播放預先生成的影片,不能即時接話。真正的語音互動還需要語音辨識、語言模型、語音合成與嘴型同步等元件。
MiniMax H3 可以用標準工作流一次生成 30 秒嗎?
官方模型卡標示的生成時長是 4~15 秒。30 秒成品可拆成多段再剪輯,額外的延伸工作流則要另外核對,不能視為標準模板的保證。
有 16GB 顯示記憶體就一定能跑嗎?
不能只憑顯示記憶體容量保證。模型格式、影片長度、解析度、系統記憶體與卸載方式都會影響結果,應先用短片及較低的預覽設定測試。
做好影片後,怎麼放到 Windows 桌面?
可以把輸出的 MP4 加入 Lively Wallpaper,再套用到指定螢幕。套用前先檢查首尾循環與音量,並避免把桌面圖示烙進影片背景。
by Rain Chu | 9 月 25, 2026 | AI, Stable Diffusion, 圖型處理, 影片製作, 繪圖
Stable Diffusion 的基本做法,是從隨機雜訊開始,在文字條件引導下反覆更新潛在表示,最後解碼成圖片。
輸入「一隻卡通柴犬」,模型便逐步生成符合描述的輪廓、色彩與細節。雜訊裡並沒有藏著一張等待被找回的柴犬照片。
理解這個流程,可以分別看 UNet 怎麼學習預測雜訊、CLIP 怎麼處理文字,以及 VAE 為何能減少運算負擔。負
向提示詞與 CFG,則是在生成過程中調整方向的工具。
本文以經典 SD 1.x 的架構為主,不同版本會更換文字編碼器、預測目標或去噪網路,不能把同一套零件規格套到所有模型。
例如 Stable Diffusion 3 採用 Transformer 架構與 rectified flow,若還沒接觸過這類工具,可先看站內早期的 Stable Diffusion 繪圖示例,其中舊服務的額度與介面以當前官方資訊為準。
UNet 怎麼學畫圖?先學習估計加進去的雜訊
把一張柴犬照片加入高斯雜訊,就能得到模糊、顆粒很多的版本。訓練程式知道原始資料、抽到的雜訊與時間步,因此有明確的答案可以用來評估模型。
- 先用 VAE 把訓練圖片編碼成潛在表示。
- 抽取時間步與高斯雜訊,按照排程把雜訊加進潛在表示。
- 把帶噪潛在表示、時間步與文字條件送進 UNet。
- 比較 UNet 預測的雜訊與實際加入的雜訊,更新模型參數。
這裡採用經典的雜訊預測訓練目標,DDPM 論文 說明了前向加噪與反向生成的關係,而 CompVis 原始實作 將去噪工作放進潛在空間,並以文字條件引導。把訓練過程說成「看帶噪圖片,猜出雜訊」容易理解,但實際送進經典 SD UNet 的資料並非 RGB 像素。
從雜訊生成柴犬,為什麼需要反覆更新?
文字生圖時沒有原圖可還原,起點是一份隨機潛在雜訊,UNet 先估計目前狀態中的雜訊,再由 scheduler/取樣器依排程計算下一個狀態,重複後才得到可以解碼的結果。
所以,UNet 的單次輸出不應直接理解成「完成降噪的新圖片」。
預測與更新是兩個步驟。Hugging Face 的流程解說 將 UNet、取樣器與最後的 VAE 解碼分開呈現,有助於看懂 ComfyUI 的節點分工。
示範若把中途結果依序解碼,可能看到柴犬輪廓逐漸清楚。這不代表每一輪都必須經過 VAE,也不代表所有模型都固定需要相同的步數。
CLIP 的工作:把提示詞轉成可用的文字特徵
「卡通柴犬」和「動畫風格的小黃狗」不是同一句話,卻可能描述相近的畫面。
文字編碼器把提示詞轉成數值特徵,讓去噪網路能利用描述中的資訊,相近語意可能得到相關表示,但不同寫法不保證生成同一張圖片。
CLIP 原始研究 使用圖文配對做對比式學習,讓匹配的影像與文字表示更相近,並區分不匹配的組合,拿柴犬照片與汽車照片,分別和「a Shiba Inu」比較,就是直觀的教學案例。這種相似度是表示之間的相對關係,不能直接當成辨識正確率。
在經典文字生圖流程中,主要使用 CLIP 的文字編碼器,透過 cross-attention 把條件交給 UNet,CLIP 的影像編碼器並不是每個去噪步驟都要使用的零件。這也不表示所有圖像生成應用都不需要影像編碼器,加入參考圖的其他管線可能另有設計。
VAE 的工作:在較小的表示中生成,再還原成圖片
VAE 包含 encoder 與 decoder。前者把圖片編碼成潛在表示,後者把潛在表示重建成可見圖片。訓練與圖生圖會需要影像編碼,從純雜訊開始的標準文字生圖則主要在最後使用解碼器。
Latent Diffusion 原始論文 的關鍵,是把反覆進行的擴散運算移到較低維度的表示中,兼顧運算成本與視覺細節。這是經過學習的表示,和把照片縮成小張的縮圖不同。
1024 × 1024 的影像,為什麼會出現 1/48 和 1/12?
以寬、高各縮小 8 倍、潛在通道數為 4 的經典 VAE 為例,可做以下尺寸計算。這只說明表示大小,不表示 SD 1.x 原生訓練解析度就是 1024 × 1024。
| 表示方式 | 寬 × 高 × 通道 | 數值個數 |
|---|
| RGB 影像 | 1024 × 1024 × 3 | 3,145,728 |
| VAE 潛在表示 | 128 × 128 × 4 | 65,536 |
依經典 VAE 的尺寸規則計算,並非生成速度或顯存用量的實測比較。
只比數值個數,比例是 1/48。如果原始 RGB 每個數值用 1 byte,而潛在表示使用每個數值 4 bytes 的 FP32,則是 3 MiB 對 256 KiB,資料儲存量才是 1/12,兩個比例用了不同的比較基準,不能混為一談。實際顯存還包括模型權重、中間運算與其他元件,不會直接照這個比例下降。
反覆重建與旋轉潛在表示,能看出什麼?
把同一張圖重複編碼、解碼,可以觀察有損重建造成的細節變化。但單張示例不能證明每次都會以相同程度劣化,也不能把 VAE 訓練簡化成只有一項逐像素比對。VAE 的原始方法 還包含對潛在分布的約束,實際影像自編碼器也可能使用感知與對抗式目標。
負向提示詞怎麼用?以不戴墨鏡的柴犬為例
想要一隻不戴墨鏡的柴犬,可以先把正向提示詞寫成 a Shiba Inu, clear eyes,負向提示詞填 sunglasses。這是方便測試的起點,不是保證成功的固定配方。
把「不戴墨鏡」整句放在正向提示詞裡,可能無法穩定排除墨鏡。較準確的說法是,這類模型對否定與複雜語意關係的遵循有限,不能推論 CLIP 永遠只懂肯定句,Diffusers 的負向提示詞說明 把它定位為讓生成方向遠離不想要的內容或特徵。
CFG 調整的是兩份預測之間的差異
在支援負向條件的常見 CFG 實作中,模型會估計正向條件與負向條件下的雜訊預測,再依下式組合,沒有填負向詞時,通常使用空文字條件作為基準。
引導後預測 = 負向預測 + CFG ×(正向預測 − 負向預測)
這裡相減的是雜訊預測張量,不是把一張「戴墨鏡的狗」從圖片上剪掉,也不是對文字做算術,基礎概念來自 Classifier-Free Guidance 研究,正負條件的組合方式可對照 Diffusers 管線實作。
CFG 提高會加強兩份預測的差異,但數值過高可能出現失真或不自然的色彩。若負向詞寫得太廣,也可能干擾想保留的元素。先用少量具體詞彙測試,比整串貼上負向詞更容易判斷哪個設定有效。
把完整流程接起來,就能看懂主要設定
- 提示詞先經 tokenizer 與文字編碼器,形成文字條件。
- seed 參與決定初始隨機雜訊,作為生成的起點。
- UNet 接收潛在表示、時間步及文字條件,估計雜訊。
- 依需要使用 CFG,取樣器再更新潛在表示,反覆進行到設定步數。
- 最後以 VAE decoder 轉成 RGB 圖片。
想測提示詞效果,先固定模型、seed、尺寸、取樣器與步數,每次只改一個條件,相同 seed 有助於比較,但跨軟體版本、硬體或不同管線,不保證逐像素重現,步數也不是越高越好,應依所用模型與取樣器的設計調整。
下載模型時,還要分清主模型、文字嵌入與附加權重,站內的 Stable Diffusion 模型類型整理 可用來辨認常見檔案類型,實際相容性仍以各模型說明為準。
LoRA 與蒸餾,和去噪有什麼不同?
LoRA 是調整模型參數的方法。LoRA 論文 以低秩更新減少需要訓練的參數。用在擴散模型時,它可能調整去噪網路或其他部分的行為,但 LoRA 本身不等於一次去噪,也不是另一種取樣器。想觀察權重怎麼影響風格,可延伸看 LoRA 權重與分層設定,留意文中外掛與模型版本的適用範圍。
蒸餾則是利用教師模型的訊號訓練學生。在圖像生成裡,目標之一是讓學生以較少步數完成生成,例如 Adversarial Diffusion Distillation。這需要額外訓練,不能靠把一般模型的步數直接調低就獲得同樣效果,也不一定讓參數量變少。站內 模型蒸餾原理整理 說明了更廣泛的教師與學生關係,圖像模型的具體訓練目標仍要另外看。
Stable Diffusion 原理常見問題
Stable Diffusion 是從雜訊中找回原本的圖片嗎?
標準文字生圖從隨機雜訊開始,沒有一張特定原圖等待還原。模型依文字條件與訓練中學到的規律,逐步生成潛在表示,再解碼成圖片。
UNet、CLIP、VAE 分別做什麼?
在經典 SD 架構中,UNet 預測雜訊,CLIP 的文字編碼器提供文字條件,VAE 負責圖片與潛在表示之間的轉換。取樣器另行決定每一步怎麼更新。
負向提示詞可以保證排除指定物件嗎?
不能保證。它會影響生成方向,但效果取決於模型、正負條件、CFG 與其他設定。應使用具體詞彙逐項測試,而非把它當成物件刪除指令。
VAE 會讓圖片變模糊嗎?
VAE 重建有損,細節與色彩可能改變。是否明顯取決於模型與圖片,反覆編碼解碼也可能累積差異。它不是一般圖片縮放或完全無損壓縮。
生成步數越多,圖片一定越好嗎?
不一定。超過適合的範圍,增加步數可能只有額外耗時。蒸餾模型也可能針對少步數設計,應使用該模型建議的取樣方式與設定。
從一個可比較的小實驗開始
用同一個模型生成柴犬,固定其他設定,依序比較正向描述、負向詞與 CFG 的變化。知道每個元件在做什麼之後,調整設定就能帶著問題進行,不必只靠反覆抽圖。
by Rain Chu | 9 月 21, 2026 | AI, TTS, 圖型處理, 影片製作, 模型, 虛擬人, 語音合成, 語音辨識
AI 女友本地部署,可以做成真正接得上話的語音數位人:當麥克風收音後,由語音辨識轉成文字,Qwen3 產生回答,Qwen3-TTS 合成聲音,再交給 LiveTalking 生成嘴型畫面。角色的回答隨當下對話產生,不只是播放固定台詞。
最實用的起步方式,是先把「聽得懂、答得出、播得出聲音」跑通,再加入人物形象。
這套系統有好幾個服務,任何一層沒啟動,都可能看起來像整個網頁壞掉。
先看懂整套流程:聊天模型只是其中一站
語音互動可拆成五個環節:VAD 判斷你是否正在說話,faster-whisper 辨識語音,Qwen3 組織回覆,Qwen3-TTS 產生音訊,LiveTalking 把音訊轉成嘴型並傳回瀏覽器,畫面與對話分工之後,才有辦法逐層測試。
Hugging Face speech-to-speech採用可替換元件的語音流程,語言模型可以接自己的 llama.cpp 服務,初次接觸這類架構,可以先看本地即時語音 Agent 的元件分工,再加上數位人畫面。
「免 API 費」比較精確的意思,是不必向雲端模型服務支付推理費,程式之間仍可能透過本機 API 溝通,電腦硬體、用電與安裝時間也不會因此消失。
8GB 顯卡能跑嗎?先算所有常駐元件
只看 Qwen3 能不能載入,會低估整套系統的需求。語音辨識、語音合成、嘴型模型、上下文快取與桌面顯示,都可能一起使用顯示記憶體。素材生成階段的 ComfyUI 也有自己的負載,完成底片後應釋放它的資源,再測常駐對話服務。
下表採用作者教學頁列出的 RTX 4090 配置估算,方便理解資源分配。這些近似值不是本文實測,也不是官方最低需求。
| 元件 | 範例配置 | 約用顯示記憶體 |
|---|
| 語言模型 | Qwen3-14B Q4_K_M | 9GB |
| 語音辨識 | faster-whisper large-v3 | 3GB |
| 語音合成 | Qwen3-TTS 1.7B | 4GB |
| 嘴型同步 | wav2lip256 | 1.3GB |
作者配置的近似值,僅供理解各元件負載,不能視為最低硬體門檻。
因此,不能把這份完整配置原封不動套到 8GB 顯卡,容量有限時,先選較小的量化 Qwen3、縮短上下文,再評估語音辨識模型與運算位置,faster-whisper 官方效能資料也顯示,精度與批次設定都會改變記憶體需求,光是模型名稱一樣,佔用量仍可能不同。
步驟一:準備 WSL,先確認 GPU 與資料夾
以下以 Windows 搭配 NVIDIA 顯卡及 WSL 2 為主。先安裝 Windows 端的 NVIDIA 驅動,再安裝、更新 WSL,NVIDIA 官方文件明確說明,WSL 使用 Windows 驅動映射的 CUDA 支援,不要在 WSL 裡另外安裝 Linux 顯示驅動。
Windows PowerShell 的起步指令如下,若已有 Ubuntu,不必重複安裝。
依畫面要求完成重啟與帳號設定後,在 Ubuntu 執行 nvidia-smi 確認顯卡可見。
wsl --update
wsl --install -d Ubuntu-24.04
Python 環境、模型處理與執行檔案,建議放在 WSL 的 Linux 家目錄下,Microsoft 的檔案系統建議是讓 Linux 工具優先使用 Linux 檔案系統,可減少跨系統讀寫負擔,環境基礎可參考Windows 與 WSL 的 AI 開發環境整理。
WSL 網路設定不是一個開關解決全部問題
Windows 11 22H2 以上可在使用者目錄的 .wslconfig 啟用 mirrored 網路,Microsoft 說明指出,這種模式支援 Windows 與 WSL 透過 127.0.0.1 互連。記憶體上限則應按實際機器調整,不要照抄別人的容量。
[wsl2]
networkingMode=mirrored
hostAddressLoopback=true 是額外允許透過主機其他 IPv4 位址互連的設定,只在 mirrored 模式下適用,官方設定文件並未說所有 WebRTC 失敗都必須靠它修復。改完設定後,可在保存其他 WSL 工作後執行 wsl --shutdown,再重新啟動環境。
步驟二:先讓 Qwen3 單獨回答文字
從 llama.cpp 官方專案選擇適合 Windows 與顯卡的版本,下載對應的 GGUF 模型,容量有限時,可先研究 Qwen3-4B 官方 GGUF,而不是直接載入較大的模型。檔名應以實際下載結果為準。
下面是啟動本機文字服務的設定範例,請把模型路徑換成自己的檔案。這組命令只用來說明參數,未在本文中進行 GPU 實測。
llama-server -m "C:\AI\models\your-qwen3-model.gguf" -ngl 99 -np 1 -c 4096 --host 127.0.0.1 --port 8090
先開啟 http://127.0.0.1:8090 測試文字回覆,再把語音服務的模型端點指向同一個位址與連接埠,llama-server 文件列有模型路徑、上下文與監聽位址參數,若使用 NAT 網路跨 Windows 與 WSL 連線,位址安排會不同,應按前一節的網路模式處理。
連接埠不是非 8090 不可。若無法綁定,先看錯誤與 Windows 保留區間,再選可用的埠,也不必為了單機測試直接監聽全部網卡,只有確實需要其他位址連入時,才調整監聽範圍與防火牆。
步驟三:接上語音辨識與 Qwen3-TTS
先用一句短句測試語音辨識,再讓 TTS 單獨唸出固定文字,兩者各自正常後,才把它們接到文字模型,這樣能分辨「沒聽見」「辨識錯」「模型沒回覆」與「音訊沒播出」是哪一段出問題。
若使用作者整合包,install-voice.sh、start-voice.sh 與後續的橋接檔案應維持同一版本,這些是教學包的客製腳本,並不是所有官方專案都有的通用指令,下載入口可由原作者部署教學取得,本文未執行或驗證該整合包。
自行安裝目前官方 speech-to-speech 時,要明確選定本機 LLM 端點與本地語音元件,單獨執行預設服務命令,不代表一定選到全本地配置,首次啟動還需要下載模型與完成載入,前端頁面能打開,不代表語音後端已準備好。
聲音復刻要選 Base,固定音色則看 CustomVoice
Qwen3-TTS 官方說明區分 Base、CustomVoice 與 VoiceDesign,想根據參考錄音復刻聲音,應使用支援 voice clone 的 Base 路徑,CustomVoice 提供預設說話者,不能把兩者的參數直接互換。
參考音訊使用自己錄製或有授權的聲音,保持單人、背景乾淨,並準備正確的逐字內容,
不要只把 MP3 副檔名改成 WAV,也不要假設所有模組都用同一取樣率,應在需要的交接點真正轉換格式。更多音色選擇可參考Qwen3-TTS 音色設計與聲音復刻。
步驟四:用 LiveTalking 驗證聲音與嘴型
LiveTalking 官方專案支援 Wav2Lip 等嘴型模型,並提供 WebRTC 輸出,先依目前 README 安裝相容環境與權重,使用官方範例形象測試。舊教學的 Python、PyTorch 版本可能和目前文件不同,不要任意混裝兩套依賴。
完成官方安裝與模型放置後,範例啟動命令如下。開啟 http://localhost:8010/index.html,建立連線後先測畫面,再測文字或音訊驅動。官方文件要求把對應權重放到指定目錄,檔名也要相符。
python app.py --transport webrtc --model wav2lip --avatar_id wav2lip256_avatar1
這一步的目標是確認嘴型服務本身能工作,範例能出聲音,不足以證明聲音是本地生成的。仍要核對選用的 TTS 後端,確保正式串接時收到的是前一層本地 TTS 的音訊。
步驟五:準備自己的形象,最後才做整合
人物底片使用嘴部清楚、沒有手遮擋、動作平穩的素材。可以自己錄製,也可先用 Wan2.2 等圖生影片工具製作一小段待機畫面。鏡頭固定、人物稍微呼吸或眨眼即可,避免原片持續大幅說話,讓後續嘴型替換更容易處理。
底片長度、解析度與幀率要配合生成模型及後續預處理,不能把某份模板的幀數與匯出設定,說成整個 Wan2.2 系列只能產生固定秒數,若模板有提示詞擴寫功能,先確認它是否改寫了你要保留的場景。
LiveTalking 提供 /avatar.html 形象建立頁面,可上傳影片並產生角色資料,完成後,用新形象的 ID 啟動服務,再確認嘴部邊緣、遮擋與音畫同步。底片是角色外觀素材,實際回話的嘴型仍依當下音訊產生。
完整整合需要橋接語音輸出與人物服務。作者教學包中的 avatar-sync.js 承擔這部分工作,因此不能只安裝兩個官方專案,就假設它們會自動連接。建議依序啟動文字模型、嘴型服務、語音服務,再開前端檢查每一層日誌。
讓對話更自然:回覆長度比華麗人設更有用
語音回答先控制在一兩個重點,避免長篇條列與會被唸出來的格式符號。以下是可自行調整的原創人設示例,重點是語氣與回覆形式,不需要要求角色否認自己是 AI。
你是一位名叫小晴的虛擬聊天夥伴。
使用自然的臺灣繁體中文口語,回覆以兩三句為主。
先回應對方剛說的內容,再視情況提出一個簡單問題。
不要使用 Markdown、編號或表情符號。
不知道的事情直接說不知道,不要虛構共同經歷。
支援思考切換的 Qwen3 模型可以用 /no_think 控制模式,但仍要依模型與聊天模板確認,若換成不同的 Instruct 版本,不能假設同一控制文字都有相同效果。
聲音很自然,回答就一定聽懂了嗎?
聊天時最容易混淆的是語氣與理解能力。角色能用自然音色談論喝奶茶、工作很累等日常話題,並不代表它穩定追蹤了誰在說話、誰與誰是什麼關係。多人輪流發言或連續追問身分時,回覆可能仍然流暢,內容卻已經接錯人或繞回固定話題。
驗收時應把「聲音像不像真人」與「答案有沒有回應問題」分開。用幾句意思相近但主詞不同的問題測試,再核對辨識文字。如果前一層把話聽錯,先修收音與轉錄。如果轉錄正確而回覆混亂,再調整對話歷史、角色規則或模型,不能只因為聲音很順就判定整套系統成功。
搶話、沒反應、WebSocket 失敗,分層排查
一直顯示「等待語音後端就緒」
先查看後端是否正在下載模型,或已經因套件、CUDA、磁碟空間而退出。檢查真正的錯誤訊息與下載進度,再決定是否重啟。只重整前端頁面,無法修復後端缺少權重的問題。
網頁打得開,但 WebSocket 連不上
官方瀏覽器示範文件區分前端頁面與語音後端。例如頁面可位於 7860,而語音連線使用另一個埠與 /v1/realtime 路徑。依實際版本核對位址、連接埠、路徑及協定,不能把前端網址直接當成 WebSocket 端點。
WebRTC 失敗則要看服務端、ICE 候選、網路模式與防火牆。
前端出現 JSON 解析錯誤,可能只是收到錯誤回應,不能僅憑這句話認定是某個 WSL 開關沒開。
麥克風有權限,卻完全沒有辨識結果
先確認選到正確輸入裝置與收音電平,再調整 noise gate 與 VAD 門檻。
門檻過高可能把正常說話擋掉,降得太低也可能讓環境聲觸發回應,瀏覽器麥克風規則要求安全環境,本機可用 localhost,其他裝置連入通常應使用 HTTPS。
還沒說完就被搶答,或聽起來像在等很久
先調整結束發言的靜音等待,再測辨識與合成速度。等待較長,較能容忍句中停頓,但回答也會更晚開始。這是輪流說話的取捨,不能單靠加大模型解決。使用耳機也能避免喇叭聲再次進入麥克風,造成誤觸發。
衡量延遲時,要從你停止說話算到真正聽見第一個字,包含等待、辨識、文字生成、音訊生成與播放緩衝。嘴型影片播放流暢,只代表畫面跟得上,不等於對話回覆沒有延遲。
離線與免費,最後要驗收哪些條件?
首次安裝與模型下載通常需要網路。若要斷網使用,先讓選定的全本地配置完整啟動一次,再檢查模型快取、前端資源、語音後端,以及是否仍依賴外部 STUN 或其他服務。外網通道與雲端語音服務也不能算成純離線方案。
原始 Wav2Lip 專案對其開源模型的商用有明確限制,不能因整合框架使用 Apache 授權,就推論整套權重都可任意商用。對外使用前,應核對實際下載模型的來源與授權。
第一個完成標準可以很簡單:連續問幾個新問題,辨識內容正確、回答有關聯、聲音完整、嘴型能跟上。這些都穩定後,再增加個性設定、外觀與更長的對話記憶。
常見問題
要復刻聲音,Qwen3-TTS 該用哪一版?
應使用支援參考音訊復刻的 Base 路徑。CustomVoice 提供預設音色,與聲音復刻的輸入方式不同。
為什麼 localhost 頁面能開,語音卻連不上?
前端頁面與語音後端可能使用不同連接埠。應先確認後端啟動完成,再核對 WebSocket 位址、路徑、協定與網路設定。
AI 女友本地部署後可以斷網聊天嗎?
選定的模型、依賴與前端資源都已備妥,而且語音、對話與串接服務不依賴雲端時,才可能離線使用。應先跑通完整配置,再做斷網測試。
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 | 7 月 28, 2026 | AI, skills, Tool, 圖型處理
AI Agent 很會理解「月份、營收、百分比變化」代表什麼,卻不一定能穩定處理座標軸、刻度、色階、標籤間距與版面配置,直接要求模型輸出完整 Vega-Lite 或 ECharts 規格,常見結果不是設定冗長,就是參數彼此衝突,甚至渲染後只得到空白畫布。
Flint Chart 的做法,是讓 AI 只負責描述資料的意義與圖表意圖,再由確定性的編譯器完成幾何與渲染細節,這不只是圖表工具的改良,也是一種值得用在 AI Agent 系統的架構。模型產生小型、可驗證的中介格式,程式再負責執行可重現的工作。
如果你正在用 Codex 製作視覺內容,可以先參考站內的Codex 動態圖表與短影音工作流程,Flint 則更專注在資料圖表的語意、驗證與多後端輸出。
Flint Chart 是什麼
Flint 是微軟研究院與中國人民大學 IDEAS Lab 合作開發的開源視覺化中介語言,它不是另一套直接把圖畫到畫布上的函式庫,而是位在 AI Agent 與 Vega-Lite、Apache ECharts、Chart.js、Plotly、Excel 之間的語意層。
- AI Agent 判斷欄位代表月份、價格、利潤、國家、排名或百分比變化
- Flint 規格 保存資料、語意型別、圖表種類與欄位映射
- Flint 編譯器 推導日期解析、聚合、刻度、色彩、標籤與版面
- 繪圖後端 接收原生規格並渲染互動圖表、PNG、SVG 或 Excel 原生圖表
截至 2026 年 7 月 28 日,官方 GitHub 顯示 JavaScript 與 TypeScript 函式庫已能輸出 Vega-Lite、ECharts、Chart.js、Plotly 與 Office.js 使用的 Excel 原生圖表。7 月 11 日的 iThome 報導只列出前三種,是因為後續 0.4.0 版才加入 38 種 Plotly 圖表與 18 種可編輯 Excel 範本。
為什麼 AI 直接產生圖表容易失敗
製作圖表其實包含兩種不同工作。第一種是理解語意,例如 revenue 是金額,month 是年月,growth 是百分比變化。第二種是安排幾何,例如軸的範圍、刻度密度、文字旋轉、圖例位置與色彩映射。
語言模型擅長第一種工作,第二種工作卻牽涉許多互相依賴的數值與規則。Flint 把兩者拆開後,AI 不必一次猜完所有低階設定。規格也從難以檢查的大段設定,縮成可閱讀、可修改、可在渲染前驗證的小型 JSON。
模型負責意義,編譯器負責數學。真正的價值不是少寫幾行,而是讓每一步都能被驗證與重現。
Flint 規格的三個核心部分
一份 Flint 輸入主要由資料、semantic_types 與 chart_spec 組成。下面用季度營收長條圖示範最小結構。
{
"data": {
"values": [
{ "quarter": "Q1", "revenue": 1200 },
{ "quarter": "Q2", "revenue": 1450 },
{ "quarter": "Q3", "revenue": 980 },
{ "quarter": "Q4", "revenue": 1800 }
]
},
"semantic_types": {
"quarter": "Quarter",
"revenue": "Price"
},
"chart_spec": {
"chartType": "Bar Chart",
"encodings": {
"x": { "field": "quarter" },
"y": { "field": "revenue" }
},
"baseSize": { "width": 480, "height": 320 }
}
}
data 可以直接放入列資料,也能在本機 MCP 模式下引用 JSON、CSV 或 TSV 檔案。semantic_types 告訴編譯器每個欄位的實際意義。chart_spec 則決定圖表種類,以及欄位要放在 x、y、color、size、shape、column、row、group 或 detail 等通道。
語意型別可以重複使用。探索同一份資料時,多半只要更換 chart_spec。例如把 Quantity 改成 PercentageChange,編譯器就能改用適合正負變化的發散色階、百分比格式與對應的軸設定。這比每次都讓模型重新生成完整圖表設定更穩定。
在 Codex 安裝 Flint MCP
本機版本需要 Node.js 18 以上。Codex 可以用一行命令加入 stdio MCP 伺服器。
codex mcp add flint -- npx -y flint-chart-mcp
接著確認伺服器是否已經出現在清單。
codex mcp list
如果資料不需要從本機檔案讀取,可以關閉檔案引用。這個設定要求代理把資料列直接放進 data.values,能縮小不受信任工作流程的檔案存取範圍。
codex mcp add flint-safe -- npx -y flint-chart-mcp --disable-file-reference
官方也提供遠端 MCP 端點,適合只能連接 HTTP MCP 的客戶端。處理私有資料時,仍建議優先選擇本機 stdio 版本。
codex mcp add flint-remote --url https://flint.data-formulator.ai/mcp
第一次使用的提示詞
安裝後不要只下「幫我畫圖」。把資料來源、語意、圖表目的、驗證方式與輸出格式一起交代,結果會更可靠。
請載入 flint://agent-skill,並呼叫 list_chart_types 檢查 vegalite 後端是否可用。讀取目前資料夾的 sales.csv,把 month 判定為 YearMonth,revenue 判定為 Price,growth 判定為 PercentageChange。先用 validate_chart 驗證,再建立每月營收折線圖,並用顏色標示成長率。若支援 MCP Apps 就使用 create_chart_view,否則用 render_chart 輸出 SVG。最後列出所有警告與被截斷的資料。
Flint MCP 提供五個主要工具。create_chart_view 適合互動調整,validate_chart 用來檢查規格與警告,render_chart 產生 PNG 或 SVG,compile_chart 回傳後端原生 JSON,list_chart_types 則用來確認可用的圖表與通道。
這套做法和讓 Codex 用 Playwright CLI 操作瀏覽器有相同精神。模型不必自己模擬每個底層步驟,而是呼叫邊界清楚、結果可檢查的工具。
在 JavaScript 與 TypeScript 專案使用
若你正在開發產品,而不是只在對話中產生圖表,可以直接安裝函式庫。
npm install flint-chart
import { assembleVegaLite } from "flint-chart"
const input = {
data: { values: myData },
semantic_types: {
weight: "Quantity",
mpg: "Quantity",
origin: "Country"
},
chart_spec: {
chartType: "Scatter Plot",
encodings: {
x: { field: "weight" },
y: { field: "mpg" },
color: { field: "origin" }
},
baseSize: { width: 400, height: 300 }
}
}
const spec = assembleVegaLite(input)
相同輸入可以交給 assembleECharts、assembleChartjs、assemblePlotly 或 assembleExcel。後端若不支援指定圖表,組裝器會在渲染前拋出錯誤,因此產品端應先查詢範本支援狀態,再把錯誤與警告顯示給使用者。
Excel 原生圖表特別適合需要後續人工編輯的報表工作。如果工作流程還包含 Word、PowerPoint 或試算表處理,可以延伸閱讀OfficeCLI 與 AI Agent 的 Office 自動化教學。
Flint、Vega-Lite、Mermaid 與一般 Chart MCP 的差異
| 工具 | 主要用途 | AI 要處理的細節 | 適合情境 |
|---|
| Flint | 語意中介格式與編譯 | 資料意義、圖表意圖與欄位映射 | 需要可靠生成、多後端與可驗證規格 |
| Vega-Lite | 統計視覺化文法 | 較完整的編碼、比例尺與版面設定 | 需要精細控制與成熟生態 |
| Mermaid | 流程圖與軟體圖解 | 節點、關係與圖形語法 | 架構圖、流程圖與文件 |
| 一般 Chart MCP | 把特定繪圖服務包成工具 | 視工具設計而定 | 已有固定渲染服務或單一後端 |
Flint 並不是 Vega-Lite 的替代品,因為它可以直接編譯成 Vega-Lite 規格。它處理的是更前面的一層,讓模型先表達「這些資料是什麼」,再由編譯器決定「如何正確畫出來」。
目前限制與使用前要知道的事
- 仍是研究專案 官方論文尚未正式公開,產品決策不能只靠宣傳數字
- Python 套件尚未發布 目前只有原始碼預覽,正式套件仍以 JavaScript 與 TypeScript 為主
- 後端支援並不完全相同 同一圖表不一定能在所有後端輸出,MCP 指南目前列出的編譯後端仍以 Vega-Lite、ECharts 與 Chart.js 為主
- Flint 不負責完整資料整理 聚合、過濾、關聯、樞紐與衍生欄位最好先在上游完成
- 自動版面可能截斷資料 離散項目超過空間預算時會套用保留策略,整合端必須顯示 _warnings
- 本機渲染仍要管理權限 預設會讀取代理指定的本機檔案,不受信任的環境應啟用 –disable-file-reference
iThome 整理的測試顯示,Flint 在 GPT-5.1、GPT-5-mini 與 GPT-4.1 三組 LLM 評分中,都優於直接產生完整 Vega-Lite 規格的 DirectVL。不過官方仍標示研究論文即將公開,因此比較結果適合視為早期證據,不能取代自己的資料集與視覺驗收。
真正值得帶走的是代理系統的分工方式
Flint 最值得學習的不只是圖表規格,而是代理系統的分工。讓模型輸出小型、結構化、可以先驗證的意圖,再讓確定性程式負責計算、渲染與錯誤處理。這個模式也能延伸到 UI 元件、文件排版、測試流程與自動化操作。
但「成功回傳 JSON」不等於任務完成。視覺工作必須真的渲染,再檢查畫布是否空白、文字是否重疊、顏色是否誤導、資料是否被截斷。AI Agent 的可靠性,來自可驗證的中介格式與最後一哩的實際驗收,而不是更長的提示詞。
常見問題
Flint 可以取代 ECharts 或 Vega-Lite 嗎
不會。Flint 是位在 AI 與繪圖函式庫之間的中介語言,最後仍會輸出 ECharts、Vega-Lite 等後端可使用的原生規格。
Flint MCP 會把資料上傳到外部服務嗎
本機 stdio 版本會在主機上執行,內嵌資料與本機檔案不會送到遠端渲染服務。若改用官方 HTTP 端點,資料會透過遠端連線處理,因此敏感資料仍應優先採用本機版本。
Codex 看不到互動圖表怎麼辦
create_chart_view 需要客戶端支援 MCP Apps。若目前介面不支援,可以要求 Flint 使用 render_chart 輸出 SVG 或 PNG,再直接檢查成品。
Flint 適合什麼工作
它適合需要大量產生資料圖表、希望規格可被人工修改、需要切換不同後端,或不能接受偶發空白與錯誤圖表的 Agent 工作流程。若只是一次性的簡單圖表,現有大型模型或熟悉的圖表函式庫可能已經足夠。
參考資料
近期留言