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-webRemotion 加 Three.js
Three.js 適合在 React Three Fiber 中載入 3D 模型，再用 Remotion 的目前幀數控制相機、模型與燈光，官方提供 @remotion/three 進行整合，低多邊形產品展示、工廠流程或地圖空間化很合適，複雜建模與擬真材質則應交給 Blender。
npm i three @react-three/fiber @remotion/three @types/threeBlender 與 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.mp4Remotion 與用 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 畫面貼進文章。
by Rain Chu 8 月 6, 2026 | AI , 影片製作 , 繪圖
MiniMax H3 把文字、圖片、影片和音訊放進同一套生成系統，可以一次產生含有人聲、環境音與音樂的影片，它不只支援文生影片和圖生影片，也能指定首尾幀，或用多張圖片、參考影片與聲音控制角色、運鏡和音色。對本地 AI 影片工作流來說，這比單純追求畫質更重要。
先講結論。MiniMax H3 已經提供可下載權重，也有 ComfyUI 原生模板，但它不是一個只需要 8GB 的小模型。官方精簡量化工作流的主要檔案合計約 39.55GiB。8GB 顯存要依靠模型卸載、系統記憶體和虛擬記憶體，生成速度與穩定度都會受到影響。
MiniMax H3 是什麼
MiniMax H3 是通用型全模態生成系統。它可以理解由文字、圖片、影片和音訊組成的上下文，再共同預測影片與立體聲音訊，官方規格支援 4 到 15 秒、24 FPS、最高 2K 的輸出，並能處理中文、英文、日文、韓文等 11 種較穩定的對話語言。
項目 官方規格 實際意義 輸入 文字、圖片、影片、音訊 可混合角色、場景、動作、運鏡與聲音參考 輸出長度 4 到 15 秒 適合廣告鏡頭、短片段與分鏡 幀率 24 FPS 以電影常用幀率直接產生 本地基礎解析度 短邊 768px 16 比 9 約為 1344 乘 768 2K 透過 H3-Regenerate-2K 目前需要官方服務，完整模組尚未釋出 音訊 32kHz 立體聲 人聲、音效與音樂和畫面共同生成
Reference-to-Video 模式最多可接 9 張圖片、3 段參考影片與 3 段音訊。每段影片或音訊需要介於 2 到 15 秒，所有參考影片的總長度不超過 15 秒，混合輸入最多 12 個檔案。音訊不能單獨作為唯一參考，必須搭配圖片或影片。
Open weights 不等於完整開源
MiniMax H3 比較準確的稱呼是「開放權重」，完整系統由 H3-Context-IR、H3-Base 和 H3-Regenerate-2K 組成，目前可在本地執行的是 H3-Base。負責理解複雜多模態素材的 H3-Context-IR，以及把 768p 重新生成為 2K 的 H3-Regenerate-2K 都尚未釋出，只能透過官方 API 使用。
官方也說明，初始版本只提供 full attention 推理，用來降低長序列運算量的 sparse attention 會在後續更新，因此，本地工作流和官方線上 2K 成果不一定完全相同，提示詞越簡略，缺少 Context-IR 的差異越明顯。
H3 的架構為什麼這麼大
H3-Omni-Transformer 是 33B dense 單流 Transformer，其中約 13B 參數位於 AdaLN 相關分支，推理時可以預先計算並快取這些 AdaLN 調制結果，所以 ComfyUI 提供 pruned 版本，把不需要每次載入的權重移除，這就是 pruned INT8 主模型能從完整 BF16 的 61.73GiB 降到約 19.53GiB 的原因。
文字和多模態條件則由 Qwen3-VL 32B 編碼器處理。最後還要載入影片 VAE 與音訊 VAE。因此，H3 不是只下載一個 safetensors 就能運作，而是一組彼此配合的模型元件。
官方精簡量化工作流的四個主要檔案合計約 39.55GiB。檔案可以在運作時分批卸載，但磁碟與系統記憶體仍要保留足夠空間。 元件 建議量化檔 大小 放置目錄 H3 FL2VA 主模型 pruned INT8 ConvRot 19.53GiB models/diffusion_models Qwen3-VL 編碼器 NVFP4 AWQ 14.61GiB models/text_encoders 影片 VAE FP16 4.85GiB models/vae 音訊 VAE FP32 0.56GiB models/vae
如果要使用多參考素材的 R2V 模式，主模型要改成 ref2va 版本，FL2VA 適合文生影片、圖生影片與首尾幀，Ref2VA 才是用角色、動作、運鏡和聲音參考生成新片段的版本，兩套主模型不能混用。
Arena 成績怎麼看
2026 年 8 月初的 Arena 快照中，MiniMax H3 在圖生影片約為 1476 分，在文生影片約為 1455 分，圖生影片和 Seedance 2.0 的差距只有約 2 分，文生影片也進入前段班，由於 Arena 會持續加入新模型與新投票，排名與分數會變動，這組數字只能當作發表初期的參考。
實際價值不只在單張畫面。武俠對話、角色特寫、太空飛行、動態 MV 與商品廣告等案例，最明顯的提升是鏡頭、口型、音效和場景能放在同一條時間軸裡。這和先產生無聲畫面，再交給另一個模型補音效的流程不同。想比較其他本地影片工具，可以延伸閱讀 OpenMontage 本地 AI 影片工作流 。
用 ComfyUI Desktop 安裝 MiniMax H3
最簡單的方法是安裝最新版 ComfyUI Desktop 。官方要求 ComfyUI 0.30.0 或更新版本，啟動後進入 Template Library，選擇 Video，再搜尋 MiniMax H3。可以先從 T2V 或 I2V 模板開始，缺少的官方模型會顯示下載提示。
更新 ComfyUI 到 0.30.0 或更新版本
開啟 Template Library
進入 Video 類別並選擇 MiniMax H3 T2V、I2V 或 R2V
依模板提示下載模型
先將 duration 設為 4 到 6 秒
將 megapixels 設為 0.2 到 0.4 進行預覽
確認人物、動作和聲音正確後，再提高解析度與長度
完整檔案結構如下。實際安裝根目錄會因 Windows、macOS、Linux 和 Desktop 版本而不同，建議從 ComfyUI 選單開啟模型目錄，不要直接照抄別人的 AppData 絕對路徑。
ComfyUI/
├── models/
│ ├── diffusion_models/
│ │ └── minimax_h3_fl2va_pruned_int8_convrot.safetensors
│ ├── text_encoders/
│ │ └── qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors
│ └── vae/
│ ├── minimax_h3_video_vae_fp16.safetensors
│ └── minimax_h3_audio_vae_fp32.safetensors
└── custom_nodes/如果你已經在使用 ComfyUI，可以參考 Krea2 的 ComfyUI 多圖工作流 理解模型目錄與節點連線，想把工作流放到雲端管理，也可以看 RunningHub 與 ComfyUI 工作流平台 。
8GB 顯存真的能跑嗎
有機會啟動，不代表適合長時間使用，8GB 顯存需要把大量權重卸載到系統記憶體，Windows 可能還會進一步使用虛擬記憶體。這會讓 GPU 在運算與資料搬移之間等待，也會增加 SSD 讀寫。解析度、影片長度、參考素材數量和 VAE 解碼都可能造成記憶體尖峰。
8GB 顯存 ：從 0.2MP、4 秒和單一參考圖開始，準備充足系統記憶體與 NVMe 空間12GB 顯存 ：較適合 480p 附近的短片預覽，仍需模型卸載16GB 顯存 ：可以嘗試 0.2MP 到 0.4MP，再用影片放大工具處理24GB 以上 ：工作流更實用，但完整 768p 與多參考素材仍要監看記憶體
比較務實的做法是先用 864 乘 480 或更低解析度確認運鏡和角色一致性，再進行高解析重繪或 2K 放大，Sage Attention 也能改善速度，ComfyUI 官方文件表示，在相容硬體與正確 CUDA 環境下，速度可能接近兩倍，但部分層仍會回退到標準 attention。
Qwen3-VL Ultra Heretic H3 不是影片主模型
使用者提供的 Qwen3-VL-32B Ultra Heretic H3 ComfyUI 是 H3 的條件編碼器與提示詞 generation tail，不是 MiniMax H3 的影片生成主模型。它建立在經過 Heretic 修改的 Qwen3-VL 32B 上，主要作用是減少拒答，並在 ComfyUI 裡產生或強化 H3 提示詞。
檔案 用途 大小 Heretic BF16 encoder Qwen3-VL 第 0 到 49 層與完整 vision tower 47.97GiB Heretic INT8 ConvRot encoder 較省記憶體的條件編碼器 24.55GiB INT8 generation tail 第 50 到 63 層、final norm 與 LM head 7.09GiB
只想使用官方 H3，不需要下載這套 Heretic 檔案。要使用提示詞增強器，通常下載 INT8 encoder 與相符的 generation tail，兩個檔案都放到下面的目錄。
ComfyUI/models/text_encoders/H3/如果還想把這組 encoder 與 tail 當成獨立的本地 Qwen3-VL 文字或視覺模型，需要額外安裝 TextGen 節點。
cd ComfyUI/custom_nodes
git clone https://github.com/ethanfel/ComfyUI-H3-Qwen3VL-TextGen.git
cd ComfyUI-H3-Qwen3VL-TextGen
pip install -r requirements.txt 重新啟動 ComfyUI 後，使用 H3 Qwen VL Generation Tail Loader 和 H3 Qwen VL Generate Text 節點。如果出現 Missing Node Packs，先確認 ComfyUI 已更新，再確認自訂節點資料夾沒有多包一層 ZIP 目錄，最後使用 ComfyUI 自己的 Python 環境安裝 requirements。
Heretic 與解除限制模型的風險
Heretic 類模型會修改拒答行為，但不保證完全移除安全限制，也不保證品質不受影響，模型卡的測試是在 RTX 5090 32GB、特定 ComfyUI commit、PyTorch 2.8 與 CUDA 12.8 環境完成。不同顯示卡與套件版本可能出現完全不同的結果。
把拒答變少不代表產出的內容合法。人物肖像、聲音複製、品牌素材、成人內容和受版權保護的角色都有額外風險。建立公開或商業服務時，應保留內容審查、權限控制與人工確認，不要把解除限制當成跳過責任的工具。
MiniMax H3 提示詞怎麼寫
H3 的提示詞不是堆疊形容詞，而是建立一條可播放的時間軸，先交代整體風格與初始構圖，再依時間描述鏡頭、動作、對話、環境音與配樂，官方建議至少保留三個欄位。
integrated_multimodal_description:
[Shot 1] 真人電影風格，中景。雨夜的老街上，一名穿深色風衣的女子站在霓虹招牌下。攝影機以緩慢的小幅度向前推進。她抬頭看向街口，雨水沿著臉頰滑下。
[Shot 2] At 00:04.000, the camera cuts to a close-up。女子壓低聲音說：＜d＞[Chinese] 他終於來了。＜/d＞ 遠方車燈穿過雨霧，她握緊手中的信封。
overall_soundscape:
持續的雨聲、遠方車流、鞋底踩過積水的聲音。對話清楚，口型與發聲時間同步。
non_diegetic_music:
低沉的大提琴與稀疏鋼琴，緩慢節奏，在第二個鏡頭逐漸提高張力。 第一個鏡頭不需要時間標記。
第二個鏡頭開始使用明確時間，例如 00:04.000。
運鏡最好同時寫出類型、幅度與速度，例如 slow small-amplitude push in。
對話放在 d 標籤裡，並保留語言標記。
環境中真正存在的聲音放在 overall_soundscape，只有觀眾能聽見的配樂放在 non_diegetic_music。
圖生影片要先固定首幀中的人物、服裝、構圖、色彩和空間關係，再描述後續動作。首尾幀模式則要把中間變化寫清楚，不要只寫「從第一張變成第二張」。多參考模式要為每個素材分工，例如 Picture 1 負責人物外觀，Video 1 負責運鏡，Audio 1 負責音色。這類結構化提示詞也可以搭配 Codex 動態圖表與短影片工作流 自動產生。
授權限制一定要先看
MiniMax H3 主模型不是 Apache 2.0，而是 MiniMax H3 Community License，授權適用範圍排除歐盟、英國、韓國與美國，在這些地區部署需要另外聯絡 MiniMax 取得授權，商業產品年營收超過 2,000 萬美元，也需要事先取得書面授權。
商業產品介面還必須清楚顯示 MiniMax H3。授權也禁止用 H3 或其輸出改善其他非 H3 衍生模型。正式上線前應閱讀最新授權全文並取得法律意見，Qwen3-VL encoder 採 Apache 2.0，不代表整套 H3 工作流會自動變成 Apache 2.0。
我的判斷
MiniMax H3 的真正突破不是某一張畫面更漂亮，而是把角色、場景、鏡頭、對話、音效和音樂放進同一個生成過程，這讓本地 AI 影片從「抽一次卡看看」往可規劃的內容製作靠近。
它仍然是一套非常吃資源的系統。8GB 顯存只是能否啟動的最低挑戰，不是舒適規格，想先體驗的人，應從官方 ComfyUI 模板、4 秒、0.2MP 和單一參考圖開始。確認工作流有價值後，再投資記憶體、儲存空間與高解析度後製，Heretic 版本則只適合明白模型用途、授權與安全風險的人使用。
參考資料
FAQ
MiniMax H3 可以用 8GB 顯存執行嗎？
可以嘗試量化模型與 CPU offload，但要準備足夠的系統記憶體、虛擬記憶體和 NVMe 空間。建議從 0.2MP、4 秒短片開始，8GB 並不是官方保證的舒適規格。
MiniMax H3 本地可以直接產生 2K 嗎？
目前完整的 H3-Regenerate-2K 尚未開放。本地 H3-Base 主要輸出短邊 768px，官方 2K 品質仍需要搭配 API，或使用第三方放大與重繪工具。
Qwen3-VL Ultra Heretic H3 是 MiniMax H3 主模型嗎？
不是。它是 H3 使用的 Qwen3-VL 條件編碼器與 generation tail，負責提示詞理解和生成。真正產生影片的是 FL2VA 或 Ref2VA diffusion model。
MiniMax H3 可以商用嗎？
可以在授權適用地區依社群授權使用，但歐盟、英國、韓國與美國被排除。年營收超過 2,000 萬美元的商業產品需要事先取得書面授權，產品介面也要顯示 MiniMax H3。
ComfyUI 顯示 Missing Node Packs 怎麼辦？
先更新 ComfyUI，再確認自訂節點放在 custom_nodes 的第一層，並用 ComfyUI 自己的 Python 安裝 requirements。重新啟動後仍缺節點，再依節點名稱安裝對應的 node pack。
by Rain Chu 7 月 28, 2026 | Agent , AI
CrewAI 不是一個大語言模型，而是一套用來編排 AI Agent 的 Python 框架，它把一個複雜任務拆成不同角色，再透過 Task、Process 與 Crew 控制合作方式。模型負責思考，工具負責行動，知識庫負責補充事實，而 CrewAI 負責讓這些元件按照可理解的流程運作。
提示詞優化是一個很適合理解 CrewAI 的案例，只要把工作拆成分析、改寫、測試與最終審核，就能看見多 Agent 的價值，也能看見它的代價，Agent 數量增加後，模型呼叫、檢索次數、延遲與費用都會一起增加。真正重要的不是組一支看起來很熱鬧的 AI 團隊，而是讓每個角色都有不可取代的責任。
CrewAI 是什麼
CrewAI 是獨立開發的多 Agent 自動化框架，不依賴 LangChain，官方把主要能力分成 Crews 與 Flows，Crews 適合需要角色分工、探索與協作的任務，Flows 適合需要明確順序、狀態、條件分支與可稽核結果的工作流。
可以把它想成一間小型公司，Crew 是團隊，Agent 是成員，Task 是工作單，Process 是工作順序，Tool 是成員可以使用的工具。Knowledge 則是團隊共同或個別可查閱的資料庫。
元件 負責內容 提示詞優化案例 Agent 角色、目標、模型、工具與行為 分析師、改寫者、測試者 Task 工作描述、輸入、預期輸出與驗收條件 找出缺漏、產生新版、比較品質 Crew 組合 Agent 與 Task 並啟動執行 完整的提示詞優化團隊 Process 決定工作如何安排 依序分析、改寫、測試與定稿 Flow 控制狀態、事件與條件路徑 品質不合格時退回重寫 Knowledge 提供文件、網站或結構化資料 提示詞規範與優秀案例 Tool 讓 Agent 存取外部能力 向量檢索、網頁搜尋與評分器
提示詞優化 Crew 的完整架構
使用者輸入原始需求
↓
RAG 檢索提示詞規範與案例
↓
Prompt Analyzer 找出目標、限制與缺漏
↓
Prompt Optimizer 建立第一版完整提示詞
↓
Prompt Tester 以驗收標準比較品質
↓
Ultimate Optimizer 整合修正並輸出定稿
這種設計的關鍵是讓每個 Agent 產生下一個 Task 能直接使用的結果，分析師不應只給模糊評論，而要輸出結構化問題清單，改寫者要根據問題清單產生完整版本，測試者要使用固定量表，而不是憑感覺說新版比較好，最後的審核者只整合已確認的修正，不再任意改變需求。
若要進一步降低漂移，可以用 Pydantic 或 JSON 結構固定每一階段的輸出。這比單純增加角色背景故事更有效，因為下一個步驟能明確知道要讀取哪些欄位。
四個 Agent 不一定比兩個好
分析、優化、測試與最終優化看起來很完整，但每個角色都使用大型模型，還在每一階段重複查詢向量資料庫時，成本很容易放大。對簡單提示詞而言，分析與改寫可以由同一個 Agent 完成，再保留一個獨立測試 Agent，就已經有清楚的製作與驗收分工。
保留不同 Agent，當兩個角色需要不同工具、不同權限或不同模型時。
合併 Agent，當工作只是同一段文字的連續改寫時。
改用一般函式，當步驟不需要推理，只是格式轉換或資料驗證時。
改用 Flow，當流程需要條件分支、重試、人工確認與狀態保存時。
RAG 在 CrewAI 裡負責什麼
RAG 的用途不是替 Agent 增加想像力，而是讓它在執行任務前找到可靠的參考資料，提示詞優化系統可以把提示詞指南、優秀範例、品牌規範與輸出格式放進知識庫。使用者送出需求後，系統只取回最相關的片段，再讓 Agent 根據這些內容工作。
2024 年的實作組合是 Phidata、pgvector 與 OpenAI Embedding，Phidata 現在已改名為 Agno ，如果要維護舊專案，應先確認套件名稱與匯入路徑，不宜直接照搬舊版命令。
目前 CrewAI 已有內建 Knowledge ，可讀取文字、PDF、CSV、Excel、JSON 與網站內容，官方的 provider-neutral RAG client 預設使用 ChromaDB，也支援 Qdrant，若既有系統已使用 PostgreSQL，仍可把 pgvector 封裝成自訂 Tool，若只是做第一個原型，先用內建 Knowledge 通常更省事。
想理解本地檢索的完整取捨，可以搭配 GraphRAG 使用本地 Ollama ，若知識來源主要是專案文件與程式碼，OpenWiki 建立 Agent 共用知識庫 也很適合一起比較。
先用 RAG，不要急著訓練模型
手上有大量人工撰寫的中英文檢索式或高品質提示詞時，第一步不一定是微調。先把資料清理成「需求、上下文、限制、輸入範例、理想輸出」的成對資料，再用 RAG 找相似案例，通常能更快驗證需求。
先建立測試集，保留一批資料完全不進知識庫。
用 RAG 加單一 Agent 建立基準結果。
加入獨立評分 Agent，比較正確性、完整性與格式。
只有在格式高度穩定、資料量充足且 RAG 已到瓶頸時，再評估微調。
這樣做的好處是資料更新不必重新訓練，錯誤案例也能快速撤換。若資料彼此關聯複雜，還可以參考 Graphify 知識圖譜 ，評估是否需要從純向量檢索進一步加入實體與關係。
CrewAI 2026 最新安裝方式
截至 2026 年 7 月，官方文件要求 Python 3.10 以上且低於 3.14，並建議使用 uv 管理套件。CrewAI 現在預設建立 JSON-first 專案，Agent 放在 agents/*.jsonc，Task 與 Crew 設定放在 crew.jsonc。若需要早期常見的 Python 與 YAML 結構，才使用 --classic。
uv tool install crewai
uv tool update-shell
crewai create crew prompt_optimizer
cd prompt_optimizer
crewai install
crewai run 建立後會看到 crew.jsonc、agents/、knowledge/、skills/ 與 tools/。這個結構已經把多數需求放進設定檔，適合先從角色與任務定義開始，再加入自訂 Python Tool。
需要舊版 Python 與 YAML 專案時
crewai create crew prompt_optimizer --classic 舊版教學常出現 crew.py、agents.yaml 與 tasks.yaml，這些概念仍然有效，但預設腳手架已經不同。遇到匯入錯誤時，先確認 CrewAI 版本，再對照該版本官方文件。
CrewAI 如何連接 Ollama
CrewAI 不限定 OpenAI 或 Anthropic。官方文件提供 Ollama 設定，只要在 Agent 指定 LLM 與 base_url 即可。這能把多數推理留在本地端，避免每個 Agent 都產生雲端 API 費用。
from crewai import Agent, LLM
local_llm = LLM(
model="ollama/qwen3:8b",
base_url="http://localhost:11434"
)
analyzer = Agent(
role="提示詞分析師",
goal="找出需求缺漏並建立清楚的改寫規格",
backstory="你擅長把模糊需求拆成可驗收的條件",
llm=local_llm
) 如果 Ollama 在另一台主機，把網址換成實際內網位置即可。部署前要確認 Ollama 有對區域網路監聽、防火牆已開放，而且 CrewAI 使用的模型名稱與 ollama list 完全一致。選擇模型時可以參考 本地大模型推理框架比較 。
Docker 與硬體需求怎麼看
Docker Desktop 不是 CrewAI 的必要條件。早期範例需要 Docker，是因為它用容器啟動 PostgreSQL 與 pgvector。Linux 伺服器可以直接使用 Docker Engine，也可以把 PostgreSQL 安裝成系統服務。若改用 CrewAI 內建 Knowledge 與本地 ChromaDB，第一版甚至不一定需要 Docker。
一般筆電可以執行 CrewAI，因為框架本身不重。真正決定硬體需求的是模型、Embedding、向量資料庫與同時執行的 Agent 數量。雲端模型加本地向量庫的門檻最低。本地模型則要依參數量、量化格式與上下文長度準備足夠的記憶體或顯示記憶體。
成本最高的地方不是框架
CrewAI 開源框架本身不是主要成本。費用通常來自每個 Agent 的模型呼叫、反覆 RAG 檢索、長上下文、Embedding 建庫與失敗重試。四個 Agent 各自檢索並呼叫一次大型模型，很可能比單一 Agent 加一次驗收多出數倍費用。
讓檢索結果在同一輪工作流中共用，不要每個 Agent 重複搜尋。
分類、格式檢查與簡單摘要改用小模型。
昂貴模型只負責最終改寫或高風險判斷。
為 Task 設定清楚的 expected output、guardrail 與最大重試次數。
保存每次輸入、檢索片段、輸出與評分，才能知道錢花在哪裡。
Crews 與 Flows 應該怎麼選
若任務需要研究、創作、分析與不同專業觀點，使用 Crew。若工作需要固定順序、條件分流、錯誤重試、人工核准與狀態恢復，使用 Flow。正式系統通常會把兩者結合，由 Flow 控制整體流程，只在需要推理的節點呼叫 Crew。
需求 建議方式 研究後寫成報告 Crew 分析、改寫與交叉審核 Crew 依分數決定重寫或通過 Flow 呼叫 API 並等待人工批准 Flow 完整內容生產管線 Flow 控制流程，Crew 處理創作
如果需要從桌面工作台管理 Agent 專案，也可以參考 OpenWork 與 OpenCode Agent 工作台 ，比較框架層與操作介面的差異。
我會怎麼重做這套提示詞優化系統
先用單一 Agent 加 Knowledge 建立基準版本。
定義固定評分表，檢查目標、背景、限制、格式與可驗收性。
加入一個獨立測試 Agent，只負責找問題與打分。
分數未達門檻時，由 Flow 送回改寫，並限制重試次數。
先用 Ollama 小模型跑分析與分類，必要時才把最終改寫交給較強模型。
用保留測試集比較原始提示詞與優化結果，不把自我評價當成唯一證據。
這個版本的 Agent 更少，但責任更清楚，也更容易測試。CrewAI 的價值不是替程式多包幾層，而是讓角色、任務、工具、知識與執行順序都能被明確描述。當每個步驟都能觀察、驗證與替換，多 Agent 才真正從展示走向可維護的系統。
官方資源與案例程式碼
FAQ
CrewAI 是模型還是框架
CrewAI 是多 Agent 編排框架。它負責組織 Agent、Task、Process、Tool、Knowledge 與 Flow，實際推理由 OpenAI、Anthropic、Ollama 或其他模型提供。
CrewAI 可以完全使用本地模型嗎
可以。Agent 的 LLM 可指向 Ollama，也能連接其他 OpenAI 相容端點。若 Embedding 與知識庫也改用本地方案，就能大幅降低雲端 API 成本。
Crew 和 Flow 有什麼差別
Crew 強調角色分工與自主協作。Flow 強調精確的執行路徑、狀態、條件分支與可恢復性。正式系統常用 Flow 管理整體流程，再把需要創作或分析的工作交給 Crew。
建立提示詞優化工具需要微調模型嗎
通常不需要先微調。先用 RAG 提供規範與案例，再建立獨立測試集評估品質。只有資料格式穩定、數量足夠，而且 RAG 已無法改善時，才值得評估微調。
使用 CrewAI 一定要安裝 Docker Desktop 嗎
不一定。Docker Desktop 只是啟動 pgvector 的方便方式。CrewAI 本身不依賴 Docker，Linux 可以使用 Docker Engine，也能改用本機 ChromaDB 或遠端向量資料庫。
by Rain Chu 7 月 28, 2026 | AI , PPT
傳統簡報的限制不只在動畫比較少，而是內容、視覺與互動通常被綁在同一個封閉檔案裡，改用 HTML 後，圖表可以依資料更新，產品可以用 3D 呈現，卡片能拖曳與吸附，按鈕也能真的回應操作。更重要的是，Codex 可以讀懂 HTML、CSS 與 JavaScript，直接修改、測試並反覆改善。
真正有效的方法不是叫 AI 一次做完，而是先把參考案例拆成設計規則，再把內容交給規則處理。這個做法能把「好看」從模糊感覺變成可重複使用的系統，也更適合品牌簡報、產品發表、作品集與資料看板。
HTML 簡報為什麼比 PPT 更適合 AI Agent
內容可程式化 ：文字、圖片與資料都能從檔案或 API 載入互動更完整 ：可加入篩選、拖曳、滾動、吸附、主題切換與即時圖表容易驗證 ：Codex 可搭配瀏覽器測試畫面尺寸、按鈕、動畫與手機版容易複用 ：風格規則可整理成 DESIGN.md，工作流程可封裝成 SKILL.md交付彈性高 ：可直接開啟 HTML，也能再輸出 PDF、圖片、PPTX 或 MP4
如果你已經在使用 Codex，可以把瀏覽器驗證接進製作流程。相關做法可參考站內的 Playwright CLI 是什麼？讓 Codex 用 CLI 操作瀏覽器 。
最穩定的五段式工作流程
蒐集參考 ：挑一到三個真正符合目標的網站、品牌頁或既有簡報拆成規則 ：整理配色、字體、字級、網格、留白、圖片比例、元件與動效帶入內容 ：提供主題、章節、資料表、圖片與必要連結加入能力 ：用 ECharts、Spline 與 GSAP 補上圖表、3D 與動畫驗證與封裝 ：測試桌面與手機版，再把成熟規則做成 Skill
一次直出的頁面常會出現字級、卡片與配色彼此不協調的問題。兩段式做法先產生設計規格，再產生實際頁面，能讓 AI 在每一輪修改時都有共同標準。若你希望更進一步改善 AI 常見的模板感，可以搭配 用 Impeccable 改善 AI 網站設計 。
Open Design 是什麼
Open Design 是開源、local-first 的 AI 設計工作區，原始碼放在 nexu-io/open-design 。它不是另一個封閉模型，而是把 Codex、Claude Code、Cursor、Gemini CLI、OpenCode、Qwen 等既有 Coding Agent 接進一套視覺設計流程。
它能建立原型、Landing Page、Dashboard、簡報、設計系統與 HTML 動態內容，輸出會落在自己的專案資料夾中。核心流程是 Brief、Template、Visual direction、Artifact、Memory，也就是從需求、模板、視覺方向一路走到可執行成品與可重用記憶。
為什麼可視為 Claude Design 的替代方案
比較項目 Claude Design Open Design 使用方式 Anthropic 託管的設計工作區 本機桌面程式、Agent、MCP 或自行部署 Agent 以 Claude 與 Claude Code 為核心 可接 Codex、Claude Code、Cursor、OpenCode、Qwen 等 檔案控制 畫布內建立後可匯出或交接 直接產生專案內可執行檔案 設計系統 可匯入程式庫與設計檔 使用可攜式 DESIGN.md 與 SKILL.md 授權與費用 Beta 功能包含在 Claude Pro、Max、Team、Enterprise Apache-2.0 開源，模型或 Agent 成本依所接服務而定
Claude Design 適合想要託管畫布、直接編輯與快速交接 Claude Code 的使用者，Open Design 則更適合重視本機檔案、可更換 Agent、可自行修改 Skill，以及希望沿用 Codex 工作方式的人。
Open Design 安裝與 Codex 用法
到 Open Design 下載頁 安裝 macOS、Windows 或 Linux 版本
桌面版建議登入後直接開始，官方下載頁標示不必另外設定 API Key
若要接 Codex，先到 Open Design 的 Settings，再進入 MCP server，複製 Codex 專用設定
若終端機的 od 指令確定指向 Open Design，也可以使用下方命令
git clone https://github.com/nexu-io/open-design
cd open-design
pnpm install macOS 內建另一個同名 od 指令，因此桌面版使用者以 Settings 裡提供的完整路徑設定最穩。完成後可以直接對 Codex 說：
請使用 open-design，依照我提供的品牌資料與參考網站，先建立 DESIGN.md，再產生一份 16 比 9 的互動式 HTML 產品簡報。請保留可編輯文字、響應式版面與鍵盤翻頁，完成後用瀏覽器檢查每一頁。可直接使用的繁體中文提示詞
以下內容已把可辨識的簡體中文提示改成繁體中文，並保留原本任務結構。方括號內的文字請換成自己的資料。
提示詞一：直接參考網站製作產品頁
請參考這個網站 [參考網址] 的設計風格，再根據我提供的資料，重製一個 [品牌與產品名稱] 的產品展示頁面。請保留品牌辨識度、響應式版面與可操作的互動效果。提示詞二：把參考素材拆成設計規則
你是一位專業的前端網站設計師。請幫我拆解並整理這個 [網站或圖片] 的設計風格，包括配色、字體、字級、留白、網格、圖片比例、卡片樣式與動畫方式。請提煉成一套明確、可執行的設計規則，並整理成 Markdown 格式的規則文件。提示詞三：使用規則產生 HTML
請根據 [我提供的內容]，套用剛才整理完成的設計規則，製作一個互動性高的 HTML 網頁。請保留一致的配色、字體、網格、留白、圖片比例、卡片與動畫節奏，並確保桌面與手機版都能正常使用。提示詞四：用 ECharts 建立動態 GDP 排名
請載入 ECharts，幫我製作一個中國 2000 至 2025 年各省份年度 GDP 的動態長條圖。資料放在附件試算表中。請把下方範例程式碼換成附件資料，保持原有視覺樣式，最後用 HTML 呈現。畫面要精美、可互動，並提供播放、暫停、速度與年份控制。
[貼上從 ECharts 範例頁取得的程式碼]提示詞五：用 GSAP 改造作品集
這一段是依實際操作需求補全的繁體中文版本，適合直接交給 Codex：
請把我上傳的作品集改造成互動式 HTML 網頁，並使用 GSAP 實作卡片無限循環輪播。需要支援滑鼠與觸控拖曳、平滑吸附、拖曳時的動態回饋，以及上一個與下一個按鈕。請加入一鍵切換主題色功能，保留每張作品卡片的連結，並檢查手機版操作。提示詞六：把成熟版型封裝成 Skill
請根據這套已經驗證過的 HTML 設計風格，幫我封裝成一個可重複使用的 Skill。它需要記錄頁面的整體視覺風格、配色、字體、留白、元件樣式、圖表規範與動效原則，同時整理出封面頁、資料頁、功能拆解頁、案例頁與總結頁等常用頁面模板。
之後我只需要輸入主題、內容大綱、圖片與資料，任何相容的 AI Agent 就能自動套用這套規則，產生風格一致、可編輯、適合簡報展示的 HTML 頁面。
輸出 HTML 前，請自動檢查字體、顏色、間距、圖表樣式與頁面節奏是否統一。第一次建立自訂 Skill，可以先閱讀站內的 用 skill-creator 建立 Skill ，再把設計規則、資產與驗證流程拆成獨立檔案。
提示詞七：加入像 PPT 的可視化編輯功能
請在現有 HTML 中加入一套簡單的可視化編輯功能，支援直接點擊文字修改內容、拖曳元素調整位置、上傳圖片替換素材，並透過側邊欄統一修改字體、顏色、字級與動畫。
同時加入頁面複製、元件刪除、復原、重做與匯出 HTML 功能。編輯時顯示控制框，播放時自動隱藏。整體操作盡量接近傳統 PPT，不要破壞原有設計與動畫。提示詞八：補上主題色切換
請在既有編輯側欄加入主題色設定。提供四組預設色票與一個自訂色彩選擇器。修改後要同步更新頁面背景、卡片、按鈕、圖表與重點文字，同時維持足夠對比。請保留原有內容、互動與動畫。三個能大幅提升 HTML 簡報的前端工具
工具 官方網址 適合用途 建議用法 Apache ECharts echarts.apache.org 長條圖、折線圖、地圖、關係圖與資料看板 先從官方 Examples 找接近的範例，再把程式碼與資料表一起交給 Codex Spline spline.design 產品、空間、3D 模型與互動展示 建立或 Remix 場景，從 Export 取得公開網址或嵌入碼，再放進 HTML GSAP gsap.com 滾動敘事、拖曳、吸附、時間軸、文字與 SVG 動畫 先描述互動狀態與觸發條件，再讓 Codex 用 timeline 組織動畫
ECharts 不只負責把資料畫出來，還能讓篩選條件與簡報節奏同步。Spline 適合讓產品從靜態圖片變成可旋轉的物件。GSAP 則負責讓捲動、拖曳與狀態轉換具有一致節奏。三者一起使用時，先確認內容目標，再決定是否真的需要特效，避免互動比訊息更搶眼。
六個 HTML 與設計 Skill
安裝指令整理
npx skills add https://github.com/alchaincyf/huashu-design
npx skills add https://github.com/op7418/guizang-ppt-skill --skill guizang-ppt-skill
npx skills add https://github.com/lewislulu/html-ppt-skill
npx skills add https://github.com/Leonxlnx/taste-skill --skill design-taste-frontend UIUX Pro Max 目前建議安裝 ui-ux-pro-max-cli，再用 uipro init --ai codex 加入專案。更完整的 WordPress 使用方式可看 UIUX Pro Max 教學 。
npm install -g ui-ux-pro-max-cli
uipro init --ai codex frontend-slides 的 Claude Code Marketplace 指令與一般 Agent 不同。Codex 最簡單的方式是提供 GitHub 網址，要求它讀取 SKILL.md 與必要參考檔，再安裝到自己的 Skill 目錄。每個專案都可能更新，正式安裝前仍應以 GitHub README 為準。
設計靈感網站完整清單
使用靈感網站時，不要只丟首頁網址給 AI。最好指定一個實際案例，說清楚要借用的是資訊層級、網格、留白、字體或動畫，並列出不能照抄的品牌元素。需要從文字或圖片快速建立 UI，也可以延伸閱讀 Google Stitch 教學 。
最後的品質檢查
每頁是否只有一個主要訊息
字體是否已載入，中文與英文是否都有替代字型
圖表標籤、單位與資料來源是否清楚
動畫是否支援停止，是否干擾閱讀
滑鼠、鍵盤與觸控是否都能操作
桌面、平板與手機是否沒有溢出或遮擋
編輯模式與播放模式是否能明確切換
外部程式庫失效時是否有基本內容可看
輸出檔案是否保留來源與授權資訊
HTML 簡報的價值不是把 PPT 換成另一種檔案格式，而是把設計規則、資料、互動與驗證串成一條可重複執行的流程。先讓 Codex 理解規則，再讓它寫頁面，最後用瀏覽器檢查。當這套方法成熟後，再封裝成 Skill，下一份報告就不必重新教一次。
常見問題
Open Design 可以直接配合 Codex 嗎
可以。Open Design 官方列出 Codex 支援，桌面版可在 Settings 的 MCP server 取得 Codex 設定。產出仍會保留在本機專案目錄。
Open Design 完全免費嗎
Open Design 原始碼採 Apache-2.0。桌面下載頁提供登入後使用的官方模型路由，自行部署或 BYOK 模式則可能產生所接模型與 Agent 的費用。
HTML 簡報可以再輸出成 PPTX 嗎
部分 Skill 與 Open Design 提供 PPTX 或相關匯出能力，但複雜互動、3D 與 GSAP 動畫通常無法完整保留。需要保留互動時，建議直接交付 HTML。
最適合先安裝哪一個 Skill
要做一般網頁簡報可先看 frontend-slides。要快速選主題、版型與動畫可用 html-ppt-skill。要建立品牌化設計流程可研究 huashu-design。畫面總有模板感時，再加入 taste-skill 或 UIUX Pro Max。
參考資料
by Rain Chu 7 月 28, 2026 | AI , 語音合成
VibeVoice 現在不能只理解成一個文字轉語音模型，它已經變成 Microsoft 的開源語音模型家族，包含長音訊語音辨識、即時串流 TTS、長篇多人 TTS，以及最新的 CPU 量化辨識版本，值得注意的地方，不只是能把文字念出來，而是它開始把「聽懂一小時內容」與「收到文字後立刻開口」做成兩條可以獨立部署的路線。
先講我的結論。如果要做會議轉錄、訪談整理或字幕，先看 VibeVoice-ASR。如果只有一般電腦，優先測試 VibeVoice-ASR-BitNet。如果要讓 Agent 邊產生答案邊說話，選 VibeVoice-Realtime-0.5B，至於能合成 90 分鐘、最多四人對話的 VibeVoice-TTS-1.5B，目前官方快速體驗仍標示為停用，不能把社群整合包的功能直接當成官方現況。
VibeVoice 四個版本怎麼選
模型 主要工作 適合場景 部署重點 VibeVoice-ASR-7B 長音訊轉文字 會議、訪談、字幕、多人對話 可一次處理最長 60 分鐘，完整模型需要較多 GPU 記憶體 VibeVoice-ASR-BitNet CPU 語音辨識 桌機、Mac、邊緣設備、離線轉錄 模型約 1.58 GB，不需要 GPU VibeVoice-Realtime-0.5B 即時文字轉語音 語音 Agent、即時旁白、串流回應 單一說話人，英文為主要目標，其他語言仍屬實驗 VibeVoice-TTS-1.5B 長篇多人語音合成 Podcast、有聲內容、多人對話 原始能力可達 90 分鐘與四位說話人，但官方程式與快速體驗目前停用
VibeVoice 的核心不是單純縮小模型
VibeVoice 使用聲學與語意連續語音 tokenizer，運作頻率只有 7.5 Hz，這代表模型不需要把長音訊展開成極密集的離散 token，處理長序列時比較節省，生成端再用 next-token diffusion，把語言模型負責的文字脈絡與對話流程，交給 diffusion head 補上聲學細節。
這個架構帶來兩個很實際的能力。ASR 可以在 64K token 長度內一次接收最長 60 分鐘音訊，輸出誰在什麼時間說了什麼。
Realtime TTS 則採用交錯的視窗設計，一邊接收新增文字，一邊延續前文產生聲音，讓 LLM 不必等完整答案寫完才開始說話。
如果正在組本地語音 Agent，可以把它放進 speech-to-speech 的 VAD、STT、LLM、TTS 管線 。VibeVoice-ASR 負責聽，Realtime 負責說，中間的 LLM 可以換成本地模型。這比把整套功能綁死在單一 App 裡更容易維護。
ASR 不只是逐字稿，還會分辨說話人
一般 Whisper 工作流常要再接一套 speaker diarization，才能把不同說話人分開。VibeVoice-ASR 把語音辨識、說話人分離與時間戳放進同一個輸出，直接得到 Who、When、What 的結構。對會議記錄、Podcast 整理、客服通話和長篇訪談，這比單純吐出一整段文字更有用。
它也支援自訂 hotwords，可以先提供人名、產品名、技術術語與背景資料，減少專有名詞被聽錯的機率。官方 Transformers 版本支援超過 50 種語言，也能處理語句內與語句間的語言切換。這讓 Python 整合不必依賴特定 WebUI。
VibeVoice 真的比 Whisper 快又準嗎
答案不是單純的「是」，Microsoft 公布的 CPU BitNet 測試中，在 AMD EPYC 7V13 上使用三條 CPU 執行緒時，RTF 為 0.77，已經快於即時播放速度，四條執行緒降到 0.63。Apple M4 使用四條執行緒的 RTF 為 0.43。這些結果證明 CPU 即時辨識成立，但不同處理器、音訊長度與編譯方式都會影響速度。
官方 WER 測試顯示兩個模型各有優勢，數值越低越好 準確率也要分資料集看。BitNet 在 MLC-EN、AMI-ihm、AMI-sdm 與 VoxPopuli 的 WER 低於 Whisper，但在 Fleurs-en、Libri-clean 與 Libri-other 則是 Whisper 較低。所以比較正確的說法是，VibeVoice-ASR-BitNet 在多說話人與部分長音訊測試很有競爭力，不能直接延伸成所有語言、所有錄音條件都勝過 Whisper。
如果目前的工作流已經大量使用 Whisper，可以先看我整理的 Whisper 本地語音辨識 ，再拿自己的中文會議、多人訪談與背景噪音資料做同一套測試。真正有意義的是自己的素材，不是只看單一排行榜。
最省硬體的做法，用 VibeASR.cpp 跑 BitNet
只想在 CPU 上完成轉錄，官方的 VibeASR.cpp 是目前最直接的路線。需要 Python 3.9 以上、CMake 3.14 以上，以及 GCC 或 Clang。Windows 需要 MinGW-w64，MSVC 目前不支援。
git clone --recursive https://github.com/microsoft/VibeASR.cpp.git
cd VibeASR.cpp
pip install -r requirements.txt
python setup_env.py 準備一個 WAV 音檔後，用四條 CPU 執行緒開始轉錄。
./build/bin/asr_infer \
--vae-model models/vibeasr/vibeasr-vae-encoder-i8_s.gguf \
--lm-model models/vibeasr/vibeasr-lm-i2_s-embed-q6_k.gguf \
--audio input.wav -t 4 模型頁也提供 Ollama 的啟動方式。這條命令適合先快速取得模型，若要穩定處理音訊檔與調整執行緒，VibeASR.cpp 的 CLI 參數會更清楚。
ollama run hf.co/microsoft/VibeVoice-ASR-BitNet:Q6_K 用 Transformers 在 Python 呼叫 ASR
需要接進自己的 Python 程式時，使用 Transformers 5.3.0 以上的官方模型最乾淨。完整 ASR 權重較大，先確認顯卡記憶體與磁碟空間，不要把 Realtime 0.5B 的硬體需求套過來。
python -m venv .venv
source .venv/bin/activate
pip install transformers==5.3.0 accelerate soundfile from transformers import AutoProcessor, VibeVoiceAsrForConditionalGeneration
model_id = "microsoft/VibeVoice-ASR-HF"
processor = AutoProcessor.from_pretrained(model_id)
model = VibeVoiceAsrForConditionalGeneration.from_pretrained(
model_id,
device_map="auto"
)
inputs = processor.apply_transcription_request(
audio="input.wav"
).to(model.device, model.dtype)
output_ids = model.generate(**inputs)
generated_ids = output_ids[:, inputs["input_ids"].shape[1]:]
result = processor.decode(generated_ids, return_format="parsed")[0]
for item in result:
print(item)
如果要讓多人共用，官方還提供 vLLM 外掛，對外開出 OpenAI 相容的 /v1/chat/completions 端點，並支援串流、長音訊、hotwords、資料平行與張量平行。這條路比較適合公司內部的集中式轉錄服務。
啟動 Realtime 0.5B 即時 TTS
Realtime 版本的價值是讓 LLM 還在產生文字時就開始發聲。官方資料寫的是約 200 毫秒產生第一段聲音，但實際聽到的時間還會加上網路與播放緩衝。官方測試中 NVIDIA T4 與 Mac M4 Pro 可以達到即時速度，這不代表每一台 Mac 或每張 6GB 顯卡都一定相同。
git clone https://github.com/microsoft/VibeVoice.git
cd VibeVoice
python -m venv .venv
source .venv/bin/activate
pip install -e ".[streamingtts]"
python demo/vibevoice_realtime_demo.py \
--model_path microsoft/VibeVoice-Realtime-0.5B Realtime 0.5B 目前只支援單一說話人，英文仍是主要目標。德文、法文、義大利文、日文、韓文、荷蘭文、波蘭文、葡萄牙文與西班牙文屬於實驗音色。中文長篇多人合成若來自社群分支或整合包，應分開標示版本與來源。想比較更偏聲音克隆的方案，可以延伸看 dots.tts 的 3 秒聲音復刻架構 ，若重點是音色設計，則可以看 Qwen3-TTS 的音色控制 。
文字正規化是長篇 TTS 的必做前處理
長篇語音最常見的問題不是音色，而是日期、金額、百分比、網址與特殊符號被念錯。輸入「2026/7/28」與輸入「二零二六年七月二十八日」，模型收到的任務並不相同。正式生成前應先清理 Markdown、程式碼、罕見符號與過度複雜的標點，再把數字轉成預期的口語形式。
from wetext import Normalizer
normalizer = Normalizer(lang="zh", operator="tn")
text = normalizer.normalize("2026年7月28日，版本 1.0")
print(text) WeText 可以做中文、英文與日文的 TN 和 ITN。它不是萬能修正器，品牌名、縮寫與人名仍要自行建立字典。這一步也適合放在 Voicebox 本地 AI 語音工作室 這類批次工作流前面，避免同一個錯誤被大量生成。
安裝時最容易卡住的地方
PyTorch 裝成 CPU 版 ：先用 python -c "print(__import__('torch').cuda.is_available())" 檢查，再依自己的 CUDA 版本重裝官方 PyTorch 套件。把所有版本當成同一套需求 ：ASR-7B、Realtime-0.5B 與 BitNet 的模型大小和執行後端完全不同。把社群功能當成官方保證 ：自訂音色、中文多人 TTS 與一鍵整合包要確認來源、commit 與安全性。忽略 FFmpeg ：Gradio 與長音訊服務通常需要 FFmpeg 解碼，先確認 ffmpeg -version 能正常執行。直接丟進正式產品 ：Microsoft 明確把目前版本定位在研究與開發用途，正式商用前要自行測試準確率、延遲、授權與風險。
我會怎麼選
VibeVoice 最有價值的不是某一個模型贏過所有對手，而是它把語音工作拆成幾個明確層級。只有 CPU 就用 BitNet。需要長音訊、說話人與時間戳，就用完整 ASR。需要 Agent 邊想邊說，就用 Realtime。需要中文音色克隆與更強的角色控制，則把 dots.tts、Qwen3-TTS 或其他本地 TTS 放進比較名單。
我特別喜歡 BitNet 這次的方向。它不是叫使用者為了語音辨識再買一張顯卡，而是透過量化與專用 CPU runtime，把模型帶回一般電腦。這種改進比單純把參數做大更接近真正能落地的本地 AI。
官方資源
FAQ
VibeVoice 可以完全離線使用嗎
可以。模型與依賴下載完成後，VibeASR.cpp、Transformers ASR 與 Realtime TTS 都可以在本地執行。第一次安裝與下載權重仍需要網路。
6GB 顯存可以跑所有 VibeVoice 模型嗎
不可以。6GB 是特定 TTS 或 Realtime 組合的實測條件，完整 ASR 權重需要更多資源。只有一般電腦時，CPU 版 BitNet 是更合理的起點。
VibeVoice-Realtime 支援中文嗎
官方目前仍把英文列為主要目標，另提供九種實驗語言，名單不含中文。社群版本可能加入中文或自訂音色，但要分開看待。
近期留言