AI影片 on KnightLi的博客

Gemini 3.5 Flash 和 Gemini Omni 怎麼免費用：普通使用者與開發者入口整理

Wed, 20 May 2026 23:13:35 +0800

Google 發布 Gemini 3.5 Flash 和 Gemini Omni 後，最實際的問題不是 benchmark，而是普通使用者和開發者到底怎麼用，哪些入口免費，哪些入口只是低門檻試用。

先說結論：

想聊天、寫作、看圖、日常問答：優先用 Gemini app。
想測試 Gemini 3.5 Flash 參數、提示詞和多模態輸入：用 Google AI Studio。
想寫程式呼叫 Gemini 3.5 Flash：用 AI Studio 產生 API key。
想在終端機裡免費試用：可以看 Gemini CLI。
想體驗 Gemini Omni 的影片編輯：優先看 Gemini app 和 Google Flow。
想做正式生產：不要依賴免費額度，應該轉到付費 API 或 Vertex AI。

注意：免費額度、地區開放、訂閱層級和模型下拉選單會隨時間變化。本文寫作時間是 2026 年 5 月 20 日，正式使用前要以 Google 當前頁面為準。

Gemini 3.5 Flash 免費用法一：Gemini app

最簡單的入口是 Gemini app：

https://gemini.google.com/

使用方式很直接：

打開 Gemini。
登入 Google 帳號。
在模型選擇裡找 3.5 Flash。
直接開始對話。

這個入口適合普通使用者。你可以用它做寫作、總結、圖片理解、檔案內容分析、日常問答和簡單規劃。根據公開報導，Gemini 3.5 Flash 已面向全球使用者開放，並可在 Gemini 的模型下拉選單中選擇。

限制也很明確：免費使用者通常會有每日訊息數量、地區和功能限制。如果超過限制，就需要等待額度刷新或升級訂閱。

Gemini 3.5 Flash 免費用法二：Google AI Studio

如果你不是只想聊天，而是想調提示詞、看參數、測試結構化輸出，Google AI Studio 更合適：

https://aistudio.google.com/

基本流程：

登入 Google AI Studio。
新建 prompt。
在模型下拉選單裡選擇 gemini-3.5-flash。
輸入提示詞並執行。

AI Studio 的好處是控制能力更強。你可以調溫度、系統指令、結構化輸出、多圖輸入，還能把測試好的提示詞匯出成程式碼或 API 呼叫。

對開發者來說，AI Studio 是免費的試驗台。先在這裡把提示詞和輸入格式調好，再進入 API 接入，會少浪費很多額度。

Gemini 3.5 Flash 免費用法三：免費 API key

開發者最關心的是 API。AI Studio 可以建立 Gemini API key，用來呼叫 gemini-3.5-flash。

基本流程：

打開 Google AI Studio。
找到 Get API key。
選擇或建立專案。
建立 API key。
把 key 儲存到本機環境變數。

Python 範例：

import os
from google import genai

client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])

response = client.models.generate_content(
    model="gemini-3.5-flash",
    contents="用三句話解釋 Gemini 3.5 Flash 適合什麼場景。"
)

print(response.text)

Node.js 範例：

import { GoogleGenAI } from "@google/genai";

const ai = new GoogleGenAI({ apiKey: process.env.GEMINI_API_KEY });

const response = await ai.models.generateContent({
  model: "gemini-3.5-flash",
  contents: "用三句話解釋 Gemini 3.5 Flash 適合什麼場景。"
});

console.log(response.text);

curl 範例：

curl "https://generativelanguage.googleapis.com/v1beta/models/gemini-3.5-flash:generateContent" \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"contents":[{"parts":[{"text":"Hello Gemini 3.5 Flash"}]}]}'

公開資料顯示，AI Studio 免費層通常會給 Gemini Flash 模型一定的每日請求額度。不同時間、地區和帳號狀態可能不同，常見說法包括每天約 1,500 次請求、每分鐘請求數限制和 token 限制。不要把這些數字寫死進生產計畫，正式上線前要查看 Google AI 當前定價和限制頁面。

Gemini 3.5 Flash 免費用法四：Gemini CLI

如果你喜歡命令列，可以看 Gemini CLI。它適合臨時腳本、程式碼庫摘要、檔案讀取和終端機裡的快速問答。

安裝方式通常是：

`1`	`npm install -g @google/gemini-cli`

然後執行：

gemini

CLI 更適合個人開發者日常使用，不適合生產整合。生產環境還是應該使用 API key、服務帳號、權限控制和可稽核的呼叫方式。

Gemini Omni 免費或低門檻用法：Gemini app 和 Google Flow

Gemini Omni 是面向影片創作和編輯的多模態模型。它的核心能力不是普通文字問答，而是用自然語言多輪修改影片，並引用圖像、文字、影片、音訊等輸入。

Google DeepMind 頁面給出的入口包括：

Gemini app。
Google Flow。
YouTube Shorts。

頁面也說明，需要 Google AI 訂閱，功能會因訂閱層級和地區不同而變化。因此，Gemini Omni 的「免費用法」要更謹慎理解：有些入口可能允許免費使用者看到或試用部分能力，但完整影片編輯能力可能需要訂閱、地區開放或產品灰度。

如果你只是想體驗，建議按這個順序試：

先打開 Gemini app，查看是否有 Gemini Omni 或相關影片編輯入口。
再打開 Google Flow：https://flow.google/
如果你做短影片內容，再關注 YouTube Shorts 裡是否出現 Omni 相關編輯能力。

如果入口不可見，通常不是你操作錯了，而是帳號、地區、訂閱層級或灰度範圍暫時不滿足。

Gemini Omni 適合怎麼用

Gemini Omni 更適合創作者，而不是普通聊天。

你可以嘗試這些方向：

上傳或選擇一段影片，讓它改變風格。
讓影片中的某個動作變得更誇張。
用一張參考圖替換場景裡的物體或角色。
分多輪修改鏡頭、動作、環境和風格。
把草圖、參考圖、音訊或影片組合成一個新輸出。

提示詞可以寫得像給剪輯師提要求：

`1`	`保持原影片的人物和房間結構不變，把鏡子觸碰後的效果改成液體波紋，動作要自然，光線不要突然變化。`

多輪編輯時，不要一次塞太多要求。更穩妥的做法是：

先改主體動作。
再改風格。
再改鏡頭角度。
最後調節聲音、文字和節奏。

這樣更容易保持一致性，也更容易定位是哪一步出了問題。

免費使用時最容易踩的坑

第一，免費額度不是生產額度。免費 API key 適合測試、個人工具和原型，不適合承諾穩定服務。

第二，不要把敏感資料發到免費或第三方入口。尤其是未公開程式碼、客戶資料、合約、密鑰、財務表格和內部文件。

第三，注意資料使用設定。免費層可能有不同的資料使用策略，使用前要查看 AI Studio 或 Google 帳號裡的相關設定。

第四，影片能力通常比文字能力更受限。Gemini Omni 這類影片編輯功能可能受訂閱、地區、排隊、時長、解析度和內容安全策略影響。

第五，第三方「無限免費 API」要謹慎。很多閘道會限速、轉發請求、記錄日誌，甚至要求不透明的支付方式。敏感任務不建議走這類入口。

應該選哪個入口

如果你是普通使用者：

Gemini 3.5 Flash：用 Gemini app。
Gemini Omni：先看 Gemini app，再看 Google Flow。

如果你是創作者：

用 Google Flow 體驗 Omni 影片工作流。
用 Gemini app 做腳本、分鏡、提示詞和素材說明。

如果你是開發者：

用 AI Studio 除錯提示詞。
用 API key 接入 gemini-3.5-flash。
用 Gemini CLI 做個人終端機工作流。
生產環境考慮 Vertex AI 或付費 API。

如果你是企業：

不要依賴免費額度。
重點看權限、日誌、稽核、資料駐留、合規和密鑰管理。
影片生成和編輯還要補充浮水印、內容審核和版權流程。

小結

Gemini 3.5 Flash 的免費使用路徑比較清楚：Gemini app、Google AI Studio、AI Studio API key、Gemini CLI 都可以作為低門檻入口。它適合聊天、寫作、編程、Agent 原型和多模態測試。

Gemini Omni 的重點是影片編輯和多模態創作，入口主要在 Gemini app、Google Flow 和 YouTube Shorts，但完整能力更可能受訂閱和地區限制。它適合創作者先做體驗和概念驗證，不適合一開始就按穩定生產服務來規劃。

最穩妥的策略是：文字和程式碼任務先用 Gemini 3.5 Flash 免費層試通；影片創作先用 Gemini Omni 在 Gemini app 或 Flow 裡驗證效果；真正要上線，再轉向可稽核、可計費、可控權限的正式方案。

參考來源：

Gemini Omni 是什麼？Google AI 影片多輪編輯模型完整解析

Wed, 20 May 2026 23:11:58 +0800

Google DeepMind 公布了 Gemini Omni 頁面。它的定位很直接：從任意輸入創作內容，目前重點從影片開始。

如果說 Nano Banana 更偏向圖像生成和編輯，那麼 Gemini Omni 更像是面向影片的多模態編輯模型。使用者可以透過自然語言一步步修改影片，讓後一次修改建立在前一次修改之上，並盡量保持場景、人物、動作和畫面邏輯的一致性。

專案頁面：https://deepmind.google/models/gemini-omni/

它解決的核心問題

傳統影片編輯往往需要時間軸、圖層、遮罩、關鍵影格、調色、音軌和大量手動操作。AI 影片生成工具雖然可以從提示詞生成片段，但經常存在兩個問題：

一次生成後不容易精細修改。
多輪修改時人物、場景、風格和動作容易漂移。

Gemini Omni 想解決的是第二步：不是只生成一段影片，而是讓使用者像和剪輯師溝通一樣，持續提出修改要求。

頁面給出的說法是，它可以透過自然、分步驟的對話編輯任何影片。每次編輯都建立在前一次結果上，目標是保持一個連貫、統一的場景。

主要能力

Gemini Omni 的能力可以分成幾類。

第一類是自然語言影片編輯。使用者可以直接要求模型改變影片裡的美學風格、動作或特效。例如讓鏡子像液體一樣泛起波紋，讓人物變成線稿、毛氈玩偶、透明全息線框，或者讓整個環境變成 3D voxel art。

第二類是重構動作。它可以改變影片中發生的事情，例如放大手部形成的孔洞、讓玩具發出對應動物聲音、讓建築燈光隨音樂點亮。

第三類是基於參考圖像編輯真實影片。使用者可以給出圖像參考，再要求模型把某種建築、太陽、飛行器或其他物體放進真實影片場景裡。

第四類是多輪編輯保持一致性。頁面展示了把小提琴手移動到參考圖像環境、讓小提琴消失、再把鏡頭改成越肩角度的連續編輯流程。這比一次性提示詞更接近真實創作過程。

第五類是多輸入引用。Gemini Omni 可以把圖像、文字、影片、音訊等輸入整合成一個輸出，支援風格遷移、動作遷移、角色替換、草圖轉影片等任務。

為什麼它強調世界知識

Google 在頁面裡反覆強調，Gemini Omni 不只是「畫面變得真實」，而是結合 Gemini 的世界知識、物理直覺、歷史、科學和敘事邏輯。

這點很重要。影片模型如果只追求畫面質感，容易出現動作不合邏輯、物體關係混亂、文字和畫面不同步的問題。Gemini Omni 的目標是讓影片不僅看起來像，還要在故事、物理和語義上更連貫。

頁面中的例子包括：

大理石在連鎖反應軌道上滾動。
用 claymation 解釋蛋白質折疊。
用擬物化 stop motion 解釋海馬體工作方式。
讓字母和畫面裡的物體對應出現。
讓螢幕文字按節奏逐詞出現。

這些例子說明它不是單純的短影片特效工具，而是試圖把知識表達、敘事和視聽生成放在一起。

和 Veo、Flow、Nano Banana 的關係

從 Google 目前產品線看，Gemini Omni 更像是多模態創作和編輯能力的一層入口。

Veo 更偏影片生成模型本身，強調電影感影片和音訊生成。Google Flow 是面向創作者的 AI 創意工作室，適合組織鏡頭、素材和影片專案。Nano Banana 更偏圖像建立和細節編輯。Gemini Omni 則強調「從任意輸入到一致輸出」的多模態編輯，尤其是影片上的多輪自然語言控制。

簡單理解：

想生成高品質影片：關注 Veo。
想在創作工作流裡組織影片專案：關注 Google Flow。
想編輯圖像：關注 Nano Banana。
想用對話方式修改影片，並引用圖片、文字、影片、音訊：關注 Gemini Omni。

使用入口

頁面給出的入口包括：

Gemini app。
Google Flow。
YouTube Shorts。

不過頁面也說明，需要 Google AI 訂閱，功能會因訂閱層級和地區而不同。也就是說，並不是所有使用者在所有地區都能立即使用完整能力。

對創作者來說，最值得關注的入口可能是 Google Flow，因為它更接近完整創意工作台。對普通使用者來說，Gemini app 和 YouTube Shorts 可能是更低門檻的體驗入口。

安全和內容標記

Gemini Omni 頁面專門提到安全流程。Gemini Omni Flash 的開發與內部安全、安全責任團隊合作，並進行了自動化評估、人工評估、人工紅隊、自動化紅隊和發布前倫理安全審查。

內容透明度方面，頁面說明透過 Omni 在 Gemini app、Google Flow 或 YouTube 建立或編輯的內容，會包含不可感知的 SynthID 數位浮水印和 C2PA Content Credentials。使用者可以透過 Gemini app 驗證內容，後續也會擴展到 Chrome 和搜尋。

這部分對影片模型尤其關鍵。影片生成和影片編輯越真實，越需要內容來源標識、濫用防護和驗證工具。

適合哪些人

Gemini Omni 適合幾類使用者：

想用自然語言快速修改影片的內容創作者。
需要把草圖、參考圖、音訊、影片素材整合成成片的設計團隊。
做短影片、廣告概念、教育解釋影片和產品視覺稿的人。
想在 Google Flow 中構建 AI 影片工作流的創作者。
關注多模態影片編輯能力邊界的開發者和研究者。

但它也不一定適合所有場景。嚴肅商業片、品牌主視覺、影視製作、產品發布影片仍然需要人工審片、版權檢查、事實校對和素材管理。AI 可以明顯加速概念生成和初稿迭代，但不應替代最終審核。

怎麼看 Gemini Omni

Gemini Omni 的意義在於，它把 AI 影片從「一次性生成」推進到「可對話修改」。這比單純提升畫質更接近真實創作流程。

如果它在多輪編輯、一致性、參考素材控制、音畫同步和內容標記上表現穩定，AI 影片工具的使用方式會發生變化：使用者不再只寫一條長提示詞賭結果，而是像導演、剪輯師、設計師一樣，逐輪修改場景、動作、風格和敘事。

目前仍要看實際開放範圍、價格、地區限制、生成時長、解析度、版權策略和商用規則。對於普通創作者，最實用的觀察點是：它在 Google Flow 和 Gemini app 裡能不能穩定完成多輪影片修改。

參考來源：

Google DeepMind：Gemini Omni

web-video-presentation：把文章做成可錄屏網頁影片的 Agent Skill

Fri, 15 May 2026 09:02:15 +0800

web-video-presentation 是 ConardLi/garden-skills 裡的一個 agent skill。它要解決的問題很具體：把一篇文章或一段口播稿，做成可以錄屏的影片化網頁演示。

專案地址：https://github.com/ConardLi/garden-skills/tree/main/skills/web-video-presentation

它不是普通 PPT 模板，也不是單純的 React 元件庫。更準確地說，它是一套面向 AI agent 的影片演示生產流程：先把內容改成口播稿，再拆成 outline，再選主題，再用 Vite + React + TypeScript 做一個 16:9 的點選驅動網頁，最後錄屏成影片。

它想做的不是幻燈片

README 裡有一個很關鍵的定位：這個 skill 生成的是 “video production surface”，不是 slide deck。

也就是說，它不希望每一頁只是標題加 bullet list，而是讓每一次點選推進一個口播節拍。每個 step 獨佔 1920×1080 的舞臺，畫面隨著敘事變化。進度 UI 平時隱藏，只有懸浮時出現，這樣錄屏畫面更乾淨。

這類形態很適合：

把部落格文章做成 B 站 / YouTube 解說影片
把已有口播稿做成動態視覺稿
做產品 demo
做教程影片
做 keynote 風格的視覺演講
做“動態 PPT，但不像 PPT”的內容

它的核心價值不在於省掉剪輯軟體，而是讓網頁成為一個可控的、可迭代的影片畫布。

核心設計原則

這個 skill 的幾個原則很清楚。

第一，固定 16:9 舞臺。內容在穩定的 1920×1080 座標系裡設計，再縮放到不同視口。這樣錄屏時不會因為瀏覽器視窗變化導致佈局漂移。

第二，全域性 step cursor。使用者點選或用鍵盤推進 (chapter, step)，本地儲存進度。它像影片時間線，但用網頁狀態來控制。

第三，一個 step 只講一個想法。每個節拍都應該是完整畫面，而不是在同一頁上不斷堆 bullet。

第四，指令碼節拍驅動結構。口播稿決定節奏，outline 決定章節和 step，畫面跟著敘事走。

第五，motion first。每個場景都應該有一個會動的視覺錨點。如果只是靜態段落，說明這一步還沒有被設計成影片語言。

第六，主題 token 化。主題不是簡單換顏色，而是透過語義 token 控制字型、顏色、卡片、背景、分割線、裝飾和整體氣質。

這些原則加在一起，能把 AI 從“生成頁面”拉到“設計影片節奏”。

工作流分四段

它的工作流分成四個階段。

第一階段是內容編寫。使用者給原始文章時，agent 要把它改寫成 script.md，再生成 outline.md。如果使用者已經給了口播稿，就直接落盤成 script.md，再生成 outline。

第二階段是網頁開發。agent 用腳手架生成 Vite / React / TypeScript 專案，然後按章節實現畫面。第 1 章必須由主執行緒完整做出來，並讓使用者驗收，因為它是後續章節的風格錨點。

第三階段是可選音訊合成。skill 支援從章節裡的 narrations.ts 抽取音訊片段定義，再走語音合成流程。

第四階段是錄屏和後期。網頁本身作為錄屏舞臺，使用者用錄屏工具把點選驅動的演示錄成影片。

這個流程裡有幾個硬檢查點：指令碼、outline、主題、素材計劃、開發模式要先對齊；第 1 章做完必須驗收；是否合成音訊也要停下來確認。它不允許 agent 從原文一路衝到最終程式碼。

為什麼 outline 不寫動畫

這個 skill 裡一個很有意思的約束是：outline.md 只規劃節奏和資訊密度，不規劃具體動畫。

也就是說，outline 可以寫：

章節切分
每章 step 數
每步螢幕內容
每章資訊池
素材清單
估計時長

但不應該寫：

用什麼 CSS 動畫
用 blur、wipe 還是 spring
每個動效多少毫秒
具體 clip-path 或 filter 實現

原因很合理：如果 outline 把動畫寫死，後面的章節開發 agent 就會退化成“按說明翻譯頁面”。真正的影片感應該在實現單章時，根據內容關係即時設計。

這也是它比普通模板更有意思的地方。它把“結構”和“視覺決策”分開，讓 AI 有空間做內容驅動的設計，而不是機械套版。

narrations.ts 是唯一真相源

專案結構裡有一個關鍵檔案：narrations.ts。

每章都有自己的 narrations.ts，它儲存 step 數和對應口播文字。skill 明確要求，章節 .tsx 裡出現的最大 step 數，必須和 narrations.length 對齊。

這樣做是為了避免五處內容漂移：

script.md
outline.md
章節程式碼
chapters.ts
音訊檔案

如果口播、畫面、音訊和 step 數不一致，影片生產會非常難維護。把 narrations.ts 作為唯一真相源，是這個流程裡很實用的工程約束。

內建主題不是簡單換皮

README 裡列了一組內建主題：

paper-press
warm-keynote
midnight-press
blueprint
chalk-garden
terminal-green
bauhaus-bold
sunset-zine
newsroom
monochrome-print

這些主題不是“紅色版”“藍色版”這種換皮，而是不同視覺方向。比如 paper-press 偏編輯紙張和印刷質感，blueprint 偏技術圖紙，terminal-green 偏老式終端，newsroom 偏媒體桌面。

agent 在 Checkpoint Plan 階段要根據稿子的主題和語氣，主動推薦 2 到 3 個合適主題。使用者也可以要求自定義新主題。

這點很重要。影片類網頁最怕所有主題都長一個樣：大標題、漸變背景、卡片、幾個圓角按鈕。主題系統如果能約束視覺語言，就能減少 AI 生成內容常見的同質化。

開發模式有三種

第 1 章無論如何都必須主執行緒做完並驗收。之後可以選擇三種模式。

模式 A 是逐章確認。每章做完都暫停驗收，風險最低，也最適合對成片質量要求高的內容。

模式 B 是順序開發。第 2 章到最後一章由主執行緒順序做完，最後統一驗收，速度中等。

模式 C 是並行開發。第 1 章透過後，把後續章節交給 subagent 並行實現。它最快，但各章風格可能會有差異。skill 認為這是預期，因為主題 token 負責兜底統一，章節內部可以自由發揮。

這個設計很現實：影片生產既需要風格錨點，也需要生產效率。第一章先定調，後續章節再按風險承受能力選擇速度。

適合誰用

這個 skill 特別適合已經有內容素材的人。

如果你手裡有一篇文章、一段指令碼、一個產品介紹、一份教程、一篇技術解讀，它可以把這些內容轉成可錄屏的網頁影片。

但如果你只是說“幫我想一個影片主題”，它並不適合直接接手。SKILL.md 裡也明確說了：使用者什麼都沒有時，agent 應該反問，讓使用者先給素材或大綱。它不是創意選題工具，而是內容轉影片的生產流程。

小結

web-video-presentation 的價值，不是幫你生成一套好看的 React 頁面，而是把內容影片化這件事拆成可協作、可驗收、可複用的流程。

它把文章、口播、outline、主題、章節實現、音訊合成和錄屏串起來，同時用硬檢查點防止 agent 一路跑偏。

如果你經常把技術文章、產品介紹或教程做成影片，這個 skill 值得研究。即使不直接使用它的腳手架，裡面關於“一個 step 一個想法”“先定第 1 章風格錨點”“narrations.ts 做唯一真相源”“outline 不寫死動畫”的方法，也很適合遷移到自己的 AI 內容生產流程裡。

米哈遊 LPM 1.0 解讀：AI 影片模型如何重塑遊戲 NPC

Fri, 08 May 2026 22:27:10 +0800

LPM 1.0 最容易被誤解成又一個 AI 影片生成模型。只看展示，它未必像一些文生影片產品那樣追求宏大的鏡頭調度和誇張的視覺衝擊；但如果把它放回論文裡的目標，就會發現它真正想解決的不是「生成一段好看的影片」，而是「讓一個數位角色在互動中像是在場」。

這也是 LPM 1.0 和普通影片模型最大的區別。普通影片模型更關注畫面品質、鏡頭連續性和文字指令還原；LPM 1.0 關注的是角色表演：說話時口型、節奏、表情要同步，傾聽時也要有點頭、視線、停頓和微表情，長時間互動中還要保持角色身份穩定。

從生成影片到生成表演

LPM 是 Large Performance Model，也就是大型表演模型。這個命名很重要，因為它把任務邊界從「影片」改成了「表演」。

在真實對話裡，一個人是否顯得自然，並不只取決於他說了什麼。很多時候，傾聽本身就構成了交流：對方是否在合適的時候點頭，眼神是否跟得上語境，表情是否隨著情緒輕微變化，都會影響我們對「這個角色是否活著」的判斷。

現有很多數位人方案，本質上仍是在把文字、語音和口型拼接到一個人物形象上。角色會說話，但不一定會聽；能輸出台詞，但不一定能根據上一秒的輸入做出連續反應。LPM 1.0 的目標，是把這種被動播報改造成即時互動。

論文裡的三個難點

LPM 1.0 論文把問題概括為 AI 角色表演裡的三角矛盾：表現力、即時性和長時身份一致性。一個系統可以畫面細膩但很慢，也可以回應很快但動作僵硬，或者短時間穩定但長時間後身份漂移。要同時做到三者，難度會明顯上升。

為了解決這個問題，LPM 1.0 採用了更複雜的角色條件輸入。它不是只給模型一張參考圖，而是引入多粒度身份參考，包括整體外觀、多視角身體和多表情面部參考。這樣做的目的，是減少模型對側臉、牙齒、表情紋理、身體比例等細節的「腦補」，讓角色在長時間生成中不容易變形。

論文中還區分了說話和傾聽兩類行為。說話音訊主要驅動口型、語速、頭部和身體節奏；傾聽音訊則更多觸發視線、點頭、姿態變化和微表情。如果把兩類訊號混在一起，模型很容易學亂。LPM 1.0 的思路是把 speaking 和 listening 分別建模，再在線上系統裡把它們接到同一套互動流程裡。

Base LPM 與 Online LPM

從公開論文看，LPM 1.0 的底座是一個 17B 參數的 Diffusion Transformer。Base LPM 負責學習高品質、可控、身份穩定的角色表演影片；Online LPM 則是經過蒸餾後的串流生成器，用來支撐低延遲、長時互動。

這個拆分很關鍵。離線模型可以追求品質，但互動場景不能讓使用者等很久。使用者一開口，角色就應該開始「聽」；角色開始說話時，口型、表情和身體動作也要立刻跟上。Online LPM 的價值，就在於把複雜的影片生成壓縮到更接近即時互動的形態。

因此，LPM 1.0 不是單純給創作者做短影片素材的工具。它更像是對話智能體、虛擬直播角色和遊戲 NPC 的視覺引擎：語言模型負責理解和生成內容，語音模型負責聲音，LPM 負責讓螢幕裡的角色以可信的方式「表演出來」。

對遊戲的意義

如果把它放進遊戲產業，LPM 1.0 指向的並不是更漂亮的過場動畫，而是下一代可互動角色。

傳統遊戲裡的 NPC，大多依賴預寫腳本、固定動畫和有限分支。玩家可以和它對話，但它對玩家的反饋通常是被設計好的。AI 時代的目標會更進一步：同一個世界觀下，不同玩家可能獲得不同故事線；同一個角色面對不同玩家，也能產生更貼合語境的動作、情緒和回應。

這就是「千人千面」遊戲體驗真正需要的底層能力。語言模型可以生成台詞，行為系統可以決定目標，但如果角色在螢幕上的表現仍然僵硬，玩家很難相信它是一個正在理解自己的對象。LPM 1.0 試圖補上的，正是這塊視覺和表演層。

不要把它看成萬能成品

當然，LPM 1.0 目前更適合作為技術路線來理解，而不是馬上等同於可大規模商用的完整產品。論文和展示證明了一種可能性：即時、全雙工、身份穩定的角色影片生成正在接近可用狀態。但真正進入遊戲，還要解決成本、延遲、端側部署、內容安全、角色版權、多人場景和引擎整合等問題。

更現實的落地路徑，可能不是一上來替換所有 NPC，而是先進入虛擬主播、AI 陪伴、劇情互動、角色客服、教育陪練等單人角色場景。等模型成本下降、延遲進一步降低，再逐步進入更複雜的遊戲系統。

總結

LPM 1.0 的價值，不在於它能不能生成最驚豔的一段影片，而在於它把 AI 影片的目標從「畫面生成」推向了「角色存在感」。

如果未來的遊戲真的走向更個性化、更動態、更依賴 AI 角色的形態，那麼語言、語音、動作、表情和身份一致性必須被合在一起考慮。LPM 1.0 提供的正是這樣一條路線：讓數位角色不只是會說話，而是能傾聽、能反應，並在長時間互動中保持像同一個人。

參考連結：

Pixelle-Video：一句主題生成短影片的開源 AI 引擎

Thu, 07 May 2026 20:25:17 +0800

Pixelle-Video 是 AIDC-AI 開源的全自動短影片生成引擎。它的目標很直白：使用者輸入一個主題，系統自動完成影片文案、AI 配圖或影片、語音解說、背景音樂和最終合成。

這類工具適合短影片批量創作、知識科普、口播內容、小說解說、歷史文化類影片和自媒體素材實驗。它不是單一的「文生影片模型」，而是把多種 AI 能力接成一條生產流水線。

它能自動做什麼

Pixelle-Video 的預設流程可以概括為：

輸入主題或固定文案；
由大型語言模型生成解說詞；
根據分鏡規劃生成配圖或影片素材；
使用 TTS 生成語音解說；
添加背景音樂；
套用影片模板並合成最終成片。

README 中給出的流程是「文案生成 → 配圖規劃 → 逐幀處理 → 影片合成」。這種模組化設計的好處是清晰：每一步都可以替換模型、調整參數或改用自訂工作流。

功能亮點

專案支援的能力相當完整：

AI 智慧文案：根據主題自動生成影片解說詞；
AI 配圖：為每句話或每個分鏡生成插圖；
AI 影片生成：支援接入 WAN 2.1 等影片生成模型；
TTS 語音：支援 Edge-TTS、Index-TTS 等方案；
背景音樂：可以使用內建 BGM，也可以放入自訂音樂；
多尺寸輸出：支援直式、橫式等不同影片比例；
多模型選擇：可接入 GPT、通義千問、DeepSeek、Ollama 等；
ComfyUI 工作流：可以使用預置工作流，也可以替換生圖、TTS、影片生成等環節。

最近更新裡還提到動作遷移、數位人口播、圖生影片、多語言 TTS 音色、RunningHub 支援、Windows 一鍵整合包等內容。這說明專案已經不只是一個腳本，而是在往完整創作工具方向發展。

安裝和啟動方式

Windows 使用者可以優先看官方提供的一鍵整合包。它的定位是降低安裝門檻，不需要手動準備 Python、uv 或 ffmpeg，解壓後執行 start.bat，再在瀏覽器裡打開 Web 介面配置 API 和圖像生成服務。

如果從源碼啟動，README 給出的基本方式是：

1
2
3

git clone https://github.com/AIDC-AI/Pixelle-Video.git
cd Pixelle-Video
uv run streamlit run web/app.py

源碼方式適合 macOS、Linux 使用者，也適合需要修改模板、工作流或服務配置的人。前置依賴主要是 uv 和 ffmpeg。

配置重點

第一次使用時，關鍵不是先點「生成」，而是把幾個外部能力接好。

LLM 配置決定文案品質。你可以選擇通義千問、GPT、DeepSeek、Ollama 等模型，並填寫對應的 API Key、Base URL 和模型名。如果想盡量降低成本，本地 Ollama 是一個方向；如果追求穩定效果，雲端模型會更省心。

圖像和影片生成配置決定畫面品質。專案支援本地 ComfyUI，也支援 RunningHub。懂 ComfyUI 的使用者可以把自己的工作流放進 workflows/ 目錄，用來替換預設生圖、影片或 TTS 流程。

模板配置決定最終成片的視覺形態。專案用 templates/ 目錄組織影片模板，靜態模板、圖片模板和影片模板按命名規則區分。對內容創作者來說，這比只生成一段素材更實用，因為最終交付物是可以直接預覽和下載的影片。

適合什麼人

Pixelle-Video 比較適合三類使用者：

短影片創作者：想快速把選題變成可發布的草稿影片；
AIGC 工具玩家：想把 LLM、ComfyUI、TTS 和影片合成串起來；
開發者和自動化使用者：想基於開源專案改模板、改工作流，甚至接入自己的素材和模型。

如果你只想偶爾做一支高品質精品影片，它未必能直接替代人工剪輯；但如果你想批量生成結構一致的解釋類、口播類、科普類內容，它的流水線思路很有價值。

需要注意的地方

這類工具的上限由多個環節共同決定。文案模型不好，內容會空；配圖模型不好，畫面會散；TTS 不自然，影片會顯得粗糙；模板不合適，最終成片也會缺少辨識度。

所以使用 Pixelle-Video 時，建議先從一個固定場景開始調試，比如「60 秒知識科普直式影片」。把 LLM、畫面風格、TTS 音色、BGM 和模板固定下來，再逐步擴大到其他主題。

另外，專案雖然支援本地免費方案，但本地方案通常需要顯卡、ComfyUI 配置和模型檔案。沒有本地推理環境的使用者，可以用雲端 LLM 加 RunningHub 的方式降低部署難度，但要留意呼叫成本。

簡短判斷

Pixelle-Video 的看點不只是「輸入一句話生成影片」，而是它把短影片生產拆成可替換的模組：文案、畫面、語音、音樂、模板和合成。對普通使用者，它是一個低門檻 AI 影片工具；對開發者，它更像一個可改造的短影片自動化框架。

如果你正在研究 AI 短影片流水線，或者想把 ComfyUI、TTS、LLM 和模板合成串成一個可用產品，Pixelle-Video 值得試用和拆解。