Select Page
Qwen3-TTS 是什麼？音色設計補上開源 TTS 最大短板

Qwen3-TTS 是什麼？音色設計補上開源 TTS 最大短板

by | 7 月 9, 2026 | AI, TTS

Qwen3-TTS 這次真正補上的，不只是「又一個開源 TTS 模型」，而是把 AI 語音從單純文字轉語音，往「可以設計聲音」推了一步。對創作者來說，這個差異很大：以前多半是找一段參考音頻去克隆，現在可以先用文字描述你想要的音色，再生成符合角色感的聲音。

我會把 Qwen3-TTS 放在本地 TTS 工具鏈的一個重要位置：它不是完全取代 Index TTS2，也不是只適合做 demo，而是補上了「音色捏臉」這個創作端很需要的能力。尤其當它被包進 ComfyUI 節點後，對做短片、角色對白、旁白、多角色音頻工作流的人會更順手。

如果你之前已經看過 VoxelCPM 本地 TTS 或 本地即時語音 Agent，Qwen3-TTS 可以理解成另一條更偏「創作型語音生成」的路線。

先講結論：Qwen3-TTS 最值得看的是音色設計

Qwen3-TTS 的幾個核心能力可以拆成三塊：音色設計、音色克隆、自訂聲音與情緒控制，音色克隆大家比較熟，給一段參考音頻，再讓模型生成相似聲音；真正新鮮的是音色設計，你可以用提示詞描述聲音，例如年齡、性別、顆粒感、情緒、語氣、角色氣質。

這件事對內容創作很實用。做科幻短片時，你可以要一個「低沉、沙啞、有壓迫感的中年男聲」；做兒童故事時，可以要「明亮、溫柔、帶笑意的年輕女聲」；做遊戲角色時，可以先把聲音當成角色設定的一部分，而不是等拿到參考音頻後才開始克隆。

這也是 Qwen3-TTS 和 Index TTS2 的關鍵差異，Index TTS2 在參考音頻和情緒控制上仍然很靈活，但 Qwen3-TTS 把「從文字描述生成音色」這件事做成主能力，兩者不是誰完全取代誰，而是切入點不同。

Qwen3-TTS 的三種用法

從 ComfyUI 節點 README 來看，HAIGC 的 Comfyui-HAIGC-QwenTTS 把 Qwen3-TTS 包成幾個常用節點，最核心的是模型載入、聲音設計、聲音克隆、自訂聲音、角色預設保存與多角色對話合成。

用法需要的模型適合場景限制
聲音設計VoiceDesign用文字描述角色聲線，先捏出音色需要會寫清楚聲音提示詞
聲音克隆Base用參考音頻生成相似聲音需要參考音頻與對應文本
自訂聲音CustomVoice使用預設說話人或提示詞控制聲音情緒與音色控制受模型能力限制
多角色對話搭配角色預設短劇、廣播劇、遊戲 NPC 對話要管理角色名與預設檔

這裡有一個實作上很重要的細節：模型要放在 `ComfyUI/models/qwen-tts/` 下面，節點不會幫你自動下載模型。也就是說，這不是裝好節點就直接能跑，還要自己把 Qwen3-TTS 的對應模型資料夾放到正確位置。

ComfyUI 節點讓它更像創作工作流

如果只看 TTS CLI，Qwen3-TTS 會比較像模型測試。但進到 ComfyUI 節點後，它就開始有工作流價值。你可以把文案、角色聲音、參考音頻、角色預設、多角色對話接成流程，最後輸出可用音頻。

這對影片創作者尤其實用。前面整理 OpenMontage 本地 AI 影片工作流時也提過，影片生成不是只有畫面，旁白、角色語音、字幕和音效都是完整作品的一部分。Qwen3-TTS 這類工具的價值，就是把聲音也放進可控流程裡。

站上之前也整理過 ComfyUI 本機部署工作流。圖像生成和 TTS 看起來是不同領域，但 ComfyUI 的優勢都是一樣的：把模型變成節點，讓創作者能用流程管理。

音色設計：最像「聲音捏臉」的功能

音色設計最適合用在你還沒有參考音頻，但已經知道角色感的情境。比方說，你想要一個「沙啞、低沉、帶警告意味的戰士聲音」，傳統聲音克隆會問你：參考音頻在哪裡？Qwen3-TTS 的 VoiceDesign 則是讓你先用文字描述聲音。

這對角色型內容很關鍵。短劇、遊戲、動畫、解說頻道，都常常不是缺一個真實人聲，而是缺一個「符合角色設定」的聲音。音色設計讓 TTS 從工具變成創作材料，這是我覺得 Qwen3-TTS 最值得測的地方。

但提示詞也會變成新門檻。你不能只寫「好聽的聲音」，最好描述清楚年齡、性別、音域、情緒、語速、質感、場景。例如：

A deep, raspy middle-aged male voice, slow pace, serious and threatening tone, cinematic fantasy character.

中文也可以寫，但英文描述通常比較容易控制細節。之後如果要大量產角色聲音，我會建議把常用聲音提示詞整理成自己的 prompt library。

聲音克隆：自然度不錯，但仍要看參考音頻品質

Qwen3-TTS 的聲音克隆需要參考音頻，也最好提供參考音頻對應的文本，這點和很多 zero-shot voice cloning 工具一樣：參考音頻越乾淨，語速和情緒越穩，克隆結果越容易自然。

這裡我會提醒兩件事。第一，不要拿太吵、太短、音量忽大忽小的音頻當參考；第二，克隆聲音牽涉聲紋與授權問題，不要拿真人聲音去做未經同意的商業使用，工具越方便，這條線越要自己守住。

如果你主要目標是語音克隆，可以把 Qwen3-TTS 和 VoxCPM 語音克隆一起測，不要只看單句 demo，要測長句、情緒、停頓、重複生成穩定性。

情緒控制：Qwen3-TTS 和 Index TTS2 的取捨

Qwen3-TTS 可以透過自訂聲音與預設說話人做某種程度的情緒與語氣控制，但這裡要小心期待值，它的自訂情緒方式更偏「用預設或提示詞控制」，而 Index TTS2 在某些情境下則可以直接用參考音頻帶出情緒，操作上會更直覺。

所以我不會說 Qwen3-TTS 全面打掉 Index TTS2。更準確的說法是：

  • 你想從文字描述直接設計聲音，Qwen3-TTS 更值得測。
  • 你有很好的參考音頻，想保留聲音和情緒，Index TTS2 仍然有優勢。
  • 你要做 ComfyUI 影音工作流，Qwen3-TTS 節點會更容易串進流程。
  • 你要穩定量產，兩者都要測長文本、批次生成和錯誤率。

安裝與使用時先注意這幾點

  1. 模型要自己下載：節點預設讀 `ComfyUI/models/qwen-tts/`，資料夾命名要和模型後綴一致。
  2. 先確認模型類型：VoiceDesign、Base、CustomVoice 對應的功能不同，載錯模型就會覺得節點怪怪的。
  3. FP16 / FP32 和 CUDA 要看環境：GPU 跑得快，但顯存、驅動、torch 版本都會影響穩定性。
  4. 角色預設要管理好：如果要做多角色對話，角色名、.pt 預設檔和對白格式最好固定。
  5. 節點早期可能有 bug：遇到預設節點跑不起來，先看 GitHub issue 和最新 commit，不要急著判定模型不可用。

如果你只是想快速試用，也可以先用 ModelScope 的 Qwen3-TTS demo 或 RunningHub 工作流感受效果。真正要放進自己的內容生產流程，再回頭做本地 ComfyUI 部署。

適合誰？

我覺得 Qwen3-TTS 特別適合四種人。

  • 短片創作者。需要快速做旁白、角色音、警告音、廣播音，不想每次找真人錄音。
  • 遊戲與互動敘事作者。多角色對話、NPC 聲音、角色預設會很有用。
  • ComfyUI 工作流玩家。想把聲音生成接進圖像、影片、字幕和後製流程。
  • 本地 AI 研究者。想比較 Qwen3-TTS、Index TTS2、VoxCPM、ChatTTS 等不同開源 TTS 路線。

如果你只需要最簡單的文字轉語音，反而不一定要上這套。Qwen3-TTS 的價值在於音色設計、角色聲音與工作流整合，而不是單純把一段文字念出來。

資源整理

Qwen3-TTS 補上的是創作者最想要的控制感

Qwen3-TTS 最讓我在意的，不是它又多會念文字，而是它讓聲音開始可以被設計。對內容創作來說，聲音不是最後補上的配件，而是角色、情緒和敘事的一部分。

它目前還不是無腦安裝、無腦量產的工具。模型要自己放、節點要確認版本、不同功能要對應不同模型，ComfyUI 工作流也需要一點整理。但方向很明確：TTS 正在從「文字轉語音」進化成「聲音設計工具」。

一句話總結：Index TTS2 仍然香，但 Qwen3-TTS 把音色捏臉這塊補起來了。之後做角色語音、短劇旁白、多角色對話，我會把它列入優先測試清單。

Grill Me 是什麼？讓 AI Agent 開工前先問清楚需求

Grill Me 是什麼？讓 AI Agent 開工前先問清楚需求

by | 7 月 9, 2026 | AI, skills

很多 AI Agent 做不好，不是因為模型太弱，而是任務在一開始就太模糊，使用者一句「幫我做一個工具」、「幫我寫一個遊戲」、「幫我規劃一個工作流」，Agent 會很認真地往前衝，但它其實是在替你補完一堆你沒有講清楚的決策。

Grill Me 這類 skill 的價值，就在於把「開工前的需求訪談」變成固定流程，它不急著執行，而是先反過來問你：目標是什麼？使用者是誰？限制在哪裡？哪些選項還沒決定？什麼事情一定不能做？這一步看起來慢，實際上是在幫你省掉後面反覆重做的時間。

如果你已經在用 Codex、Claude Code、Cursor、Windsurf 或 OpenCode 這類工具，這篇可以當成一個提醒：真正拉開成果差距的，不只是模型版本，而是你有沒有一套讓 Agent 開始前先釐清需求的工作流。站上之前整理過 OpenWork / OpenCode 桌面工作台，那偏向執行環境，這篇談的是執行前的需求對齊。

先講結論：不要太快叫 Agent 開始做事

AI Agent 最常見的失控點，是使用者以為自己已經講清楚，但其實只講了一個方向，人類同事遇到模糊需求，可能會回頭問你，Agent 則常常直接開做，做出一個看起來完整、但不是你真正想要的東西。

Grill Me 的做法很簡單：在實作前先訪談。它會針對任務目標、使用場景、輸出格式、限制條件、技術選擇、驗收標準一路追問，直到這個任務足夠明確，Agent 才開始真正執行。

這不是把 prompt 寫長而已，而是把「需求還沒完成」這件事明確暴露出來，對我來說，這是使用 AI Agent 很重要的一個分水嶺：你不是把一段模糊想法丟給模型猜，而是先和模型一起把決策樹走完。

Grill Me 是什麼？

Grill Me 來自 Matt Pocock 的 skills 倉庫，這個倉庫不是單一工具，而是一組可安裝到 AI coding agent 裡的工作流程 skill，包含需求訪談、文件對齊、規格整理、TDD、debugging、code review 等。

我在 2026 年 7 月 9 日查看 GitHub API 時，這個倉庫已經超過 16 萬顆星，授權是 MIT，README 裡的定位也很明確：這些 skill 是小型、可調整、可組合的流程，而不是把整個開發過程交給一套巨大框架接管。

Grill Me 本身很短，核心是啟動一段 grilling session，也就是讓 Agent 對你的計畫或設計進行密集訪談。它不是替你做決策，而是逼你把原本藏在腦袋裡的決策說出來。

為什麼「需求訪談」會讓結果差很多？

用「做一個側邊欄貪食蛇遊戲」這種需求來看，沒有訪談時，Agent 也能做出一個可玩的版本。它可能有開始按鈕、分數、速度調整，也能用鍵盤操作。表面上看起來不差。

但只要開始追問，需求會變得完全不一樣：這個側邊欄是 Codex 裡的小工具，還是瀏覽器側邊欄？它是一次性 demo，還是要固定留下來？等待 Agent 工作時能不能玩？鍵盤焦點可能不在遊戲上，是否需要畫面按鈕保底？撞牆要不要死亡？分數要不要保存？記錄要不要能清除？

這些問題不是細枝末節，而是產品體驗的骨架。當它們沒有被問出來，Agent 只能照自己的預設做，當它們被問出來，Agent 才能把設計、互動、資料保存、通知機制都接到同一個使用情境上。

一個好用的 Grill Me 流程，應該問哪些問題？

我會把這類訪談問題分成七組。你不一定要每次問滿，但至少要讓 Agent 在開工前碰過這些維度。

  • 目標：這次任務真正要改善什麼？成功之後看起來是什麼樣子？
  • 受眾：誰會使用這個成果？是自己用、團隊用、客戶用，還是公開產品？
  • 場景：使用者會在什麼時間、什麼裝置、什麼流程裡使用它？
  • 限制：不能用哪些技術？不能改哪些檔案？不能花太多時間在哪裡？
  • 輸出：最後要交付文章、程式、規格、PRD、測試、圖片，還是一組可執行步驟？
  • 驗收：怎樣才算完成？要不要測試？要不要截圖？要不要能回滾？
  • 禁區：哪些事情不要做？哪些語氣、設計、依賴、資料來源要避開？

站上之前寫過 CO-STAR prompt 框架，那套方法適合把指令寫得更完整；Grill Me 則更像互動式版本，讓 Agent 透過追問幫你補齊缺口。

Matt skills 倉庫才是核心資源

Matt Pocock 的 skills 倉庫。這個連結比一般工具推薦更重要，因為 Grill Me 不是孤立存在，它其實是整套工作流的一個入口。

這套 skill 大致分成 engineering 和 productivity，Grill Me 屬於 productivity，適合非程式任務或早期想法釐清；Grill with Docs 則偏 engineering，會把訪談結果延伸到專案文件、domain model、ADR 等長期維護資料。

這也呼應我之前整理的 Matt Pocock Skills 工作流：真正有價值的不是某個單點技巧，而是把訪談、規格、測試、程式碼審查變成一套固定節奏。

Grill Me 不是讓 AI 變聰明，而是讓任務變清楚

用了 Grill Me，不代表模型突然變成更高階版本，也不代表結果一定完美，它真正改善的是「任務定義品質」。

模糊任務的問題在於，Agent 會把大量隱性選擇變成自己的預設，比方說你說「做一個工具」，它要猜是網頁、CLI、桌面 app 還是瀏覽器插件；你說「幫我寫文章」，它要猜讀者是新手、工程師、主管還是 SEO 流量；你說「做得好看」，它要猜品牌、風格、資訊密度、互動狀態。

Grill Me 把這些猜測改成問題。當問題被回答，Agent 的輸出就不再只是「通用答案」，而會更貼近你的真實情境。

我會怎麼把 Grill Me 放進自己的 Codex 流程？

如果是新專案，我會把流程拆成四步。

  • 第一步，用 Grill Me 釐清需求。先不要寫程式，先讓 Agent 問到目標、限制、驗收方式都清楚。
  • 第二步，把訪談整理成規格。可以轉成 PRD、spec 或 issue，避免後面上下文掉失。
  • 第三步，用 TDD 或驗收清單鎖住品質。讓 Agent 先知道什麼叫完成，而不是做完才補救。
  • 第四步，讓 code review / debug 流程收尾。不要把「看起來能跑」當成完成。

這條路線和 用 Superpowers 建立 AI 開發紀律的方向很接近：不要把 Agent 當一次性神諭，而是把它放進一套有檢查點、有回饋、有驗收的流程。

安裝 skill 前，先想清楚你要它解決什麼問題

很多人看到 skill 倉庫，第一反應會是全部安裝。這可以，但我更建議先從自己的痛點倒推。

如果你常常覺得 Agent 做出來的東西方向不對，先試 Grill Me。若你已經有專案文件，但 Agent 老是誤解術語和架構，可以研究 Grill with Docs。若你遇到的是改一處壞三處，TDD 和 debugging 類 skill 會更有幫助。

如果你想自己建立類似流程，也可以回頭看 用 skill-creator 建立自訂技能。真正好用的 skill，通常不是把所有規則塞滿，而是把一個高頻問題變成可重複執行的流程。

可以直接拿去用的 Grill Me 提示詞

如果你還沒安裝 skill，也可以先用下面這段作為替代版，它不如正式 skill 可維護，但已經能改善很多「太快開工」的問題。

在開始執行前，請先訪談我。
你要把我的需求問清楚，而不是直接開始做。

請一次只問 1 到 3 個最關鍵的問題。
每個問題請附上你的推薦答案，以及為什麼你推薦這樣選。
當你認為需求、限制、輸出格式、驗收標準都足夠清楚後，
請先整理一份任務規格給我確認。
等我明確說「開始執行」之後，你才可以動手。

這段的重點有三個：一次不要問太多、問題要附推薦答案、最後要整理成規格再等確認，這樣做可以避免 AI 把訪談變成問卷疲勞，也能讓使用者比較快做決策。

AI Agent 的品質，常常卡在開工前

Grill Me 給我的最大提醒是：不要把所有問題都歸咎於模型。很多時候，Agent 不是不會做，而是它根本不知道你真正要的是哪一種成果。

需求訪談不是形式，它是把模糊想法變成可執行任務的過程。當目標、場景、限制、輸出和驗收都被問清楚，Agent 才有機會交出真正能用的結果。

我會把 Grill Me 放在 AI Agent 工作流的第一關。不是因為它很華麗，而是因為它解決了一個最基本、也最常被忽略的問題：開始之前，先確定大家要做的是同一件事。

延伸資源

Hugging Face speech-to-speech：本地即時語音 Agent 怎麼跑？

Hugging Face speech-to-speech：本地即時語音 Agent 怎麼跑？

by | 7 月 8, 2026 | Agent, AI, 語音合成, 語音辨識

Hugging Face 的 speech-to-speech 真正有趣的地方，不只是「本地 AI 語音聊天」這句話，而是它把即時語音 Agent 拆成一條清楚的工程管線：VAD 偵測你什麼時候開始和結束說話，STT 把語音轉成文字，LLM 產生回應，TTS 再把文字變回聲音。

這條路線的價值很直覺：如果你不想把麥克風聲音、私人對話、公司資料一路送到雲端，那就把語音 Agent 搬回自己的機器。代價也很明顯：你要處理 Python、FFmpeg、CUDA、模型下載、本地 LLM server、TTS 後端、瀏覽器端 WebSocket。這不是「安裝一個 App 就結束」的工具。

如果你之前看過 VoxelCPM 本地 TTS，這篇可以當成下一步：TTS 只是讓 AI 開口，speech-to-speech 則是把「聽、想、說」接成一個即時循環。

先講結論：它不是語音模型，而是一條可替換的語音 Agent 管線

huggingface/speech-to-speech 的 README 把架構講得很清楚：這是一條低延遲、模組化的 voice-agent pipeline，順序是 VAD → STT → LLM → TTS，並且透過 OpenAI Realtime-compatible WebSocket API 對外提供服務。

也就是說，你可以把支援 OpenAI Realtime 協議的 client 指到本機 server。

這個設計比單純做一個 demo 更有意思，因為每一段都能換。

STT 可以用 Parakeet、Whisper、Faster Whisper、MLX Whisper 或 Paraformer；LLM 可以接 OpenAI-compatible provider，也可以接 vLLM、llama.cpp、llama-server；TTS 可以用 Qwen3-TTS、Kokoro、Pocket TTS、ChatTTS 或 MMS TTS。

換句話說，它的重點不是某個模型最強，而是把語音 Agent 做成可插拔架構。

這和 OpenWork / OpenCode 工作台的方向有點像：真正可長期使用的 AI 工具，不應該只綁死在單一供應商或單一模型。

Speech-to-speech 和傳統語音翻譯有什麼差別？

Hugging Face Audio Course 裡對 speech-to-speech translation 的說明很適合拿來釐清概念。

傳統機器翻譯是文字到文字，speech-to-speech 則是語音到語音。最常見的做法是串接：先把語音轉成文字，再做翻譯或生成，最後合成語音。

它也提醒一個很重要的問題：管線越長，錯誤越會累積，延遲也越高。

ASR 認錯一個字，後面的 LLM 可能照著錯字理解；LLM 回答太長，TTS 就要等更久；TTS 聲音不自然，最後體驗還是會掉下來。

所以本地即時語音 Agent 的關鍵不是只看「能不能講話」，而是看四件事：

  • 語音辨識是不是準，尤其是中文、口音、背景噪音。
  • LLM 回應是不是夠快，不要讓人等到出戲。
  • TTS 聲音是不是自然，長時間聽會不會疲勞。
  • 整條管線的延遲是不是穩定，而不是偶爾順、偶爾卡。

官方預設路線：先跑起 realtime server

官方 quickstart 很短：

pip install speech-to-speech
export OPENAI_API_KEY=...
speech-to-speech


跑起來之後，server 會在本機開一個 OpenAI Realtime 相容端點，常見位置是：
ws://localhost:8765/v1/realtime

預設路線會用本地 STT、本地 TTS，再把 LLM 接到 OpenAI-compatible API。你如果想讓 LLM 也留在本機，可以用 llama.cpp 啟動本地模型 server，再把 `responses_api_base_url` 指到本機。

speech-to-speech \
  --model_name "ggml-org/gemma-4-E4B-it-GGUF" \
  --responses_api_base_url "http://127.0.0.1:8080/v1" \
  --responses_api_api_key ""


這裡的重點是 OpenAI-compatible。只要你的本地 LLM server 能提供類似 OpenAI API 的介面，它就有機會接進來。這也是為什麼 Ollama 遠端連線和本地 OpenAI-compatible server 的設定很重要：語音只是入口，真正回答問題的是後面的 LLM。

Windows 實作路線：不是難，是零件很多

核心流程可以簡化成這樣：

  1. 裝 Python 3.11、Git、FFmpeg。
  2. 建立 `C:\s2s` 之類的資料夾，開 venv。
  3. 安裝 `speech-to-speech`。
  4. 用 llama.cpp 跑本地 Qwen 模型，開在 `http://127.0.0.1:8080/v1`。
  5. 啟動 speech-to-speech，把 STT 指到 Whisper、LLM 指到本地 server、TTS 指到 Qwen3-TTS。
  6. 開網頁 client，WebSocket 指到 `localhost:8765`。

這裡最容易踩坑的是 FFmpeg 和 winget。留言裡有人遇到 `winget` 找不到，這通常代表 Windows App Installer / winget 沒裝好，或 PowerShell 環境找不到它。這時候不要卡在同一條命令，可以改成手動下載 FFmpeg，或先修好 winget，再重新開 PowerShell。

架構表：每一段都可以替換，但每一段也都會出事

階段作用常見選擇容易卡住的地方
VAD判斷使用者何時開始/停止說話Silero VAD背景噪音、切句太早或太晚
STT語音轉文字Parakeet、Whisper、Faster Whisper中文辨識、口音、GPU/CPU 速度
LLM理解問題並產生回應OpenAI-compatible API、llama.cpp、vLLM、Ollama 類服務延遲、上下文長度、模型能力
TTS文字轉語音Qwen3-TTS、Kokoro、Pocket TTS、ChatTTS聲音自然度、CUDA wheel、中文品質
Client麥克風輸入與播放Realtime WebSocket client、網頁呼吸球介面瀏覽器權限、WebSocket 位置、服務啟動順序

這張表就是我對本地語音 Agent 的看法：模組化很香，但你不能只看成功 demo 任一段延遲太高、模型太大、依賴裝錯、WebSocket 指錯，都會讓整體體驗掉下來。

4GB 顯存、4090、CPU：期待值要分開看

如果你只是想體驗，本地小模型加 CPU/GPU 混跑可以試；如果你想每天使用，就要認真看顯卡、VRAM、記憶體、模型大小與量化格式。這部分可以搭配 AI 工作站顯卡選購那篇看，因為語音 Agent 不是只吃一個模型，而是一整條 pipeline。

本地部署值不值得？

安裝太複雜、Python 依賴一直重裝、免費雲端語音也能用、中文場景不一定比微信等現成工具舒服。

我會這樣判斷：

  • 如果你只想偶爾語音聊天，雲端 App 更省事。
  • 如果你在意隱私、離線、可控模型，本地 speech-to-speech 才有意義。
  • 如果你要接自己的 Agent 或自動化流程，OpenAI Realtime 相容 API 很有價值。
  • 如果你不想處理依賴，等整合包或 Docker / 一鍵腳本會比較舒服。

有留言建議做整合包，把 Python、虛擬環境、依賴、模型檔都打包好。這個方向很務實。語音 Agent 要走向一般使用者，最重要的可能不是模型再強一點，而是安裝流程少掉一半。

接進 Hermes、OpenWork 或自己的 Agent：語音只是入口

有人問如果部署在 Hermes 裡，是不是就不用打字了。方向是對的，但要分清楚：speech-to-speech 解決的是語音輸入與語音輸出，Agent 真正能不能工作，還要看後面的工具調用、上下文、記憶、權限與任務執行。

也就是說，語音不是 Agent 的全部，只是更自然的控制入口。你可以想像之後用語音叫本地 Agent 幫你查資料、改檔案、跑腳本、操作工作流，但這需要像 OpenWork 或 Hermes Agent 這類工作台或 runtime 來承接任務。

真正有用的組合會是：speech-to-speech 負責「聽和說」，Agent runtime 負責「做事」，本地 LLM / 工具 / MCP 負責「連到你的資料和系統」。語音只是讓人更容易下指令，不能替代完整的任務架構。

資源整理

本地即時語音 Agent 很香，但現在還偏工程師玩具

speech-to-speech 讓本地語音 Agent 的架構變得很清楚：你可以把 VAD、STT、LLM、TTS 串起來，對外提供 OpenAI Realtime 相容 API，再用網頁或其他 client 連進來。這條路很有想像空間，尤其適合隱私敏感、離線使用、機器人、客服、語言練習、自建 AI 助手。

但我不會把它包裝成人人都該裝。現階段它還需要處理太多環境問題，Windows 下尤其明顯。真正適合的人，是願意花時間把本地模型、音訊依賴、GPU、WebSocket 和 Agent runtime 串起來的人。

一句話總結：本地即時語音不是為了取代手機上的語音助手，而是為了把「能聽、能想、能說」這個入口，接到你自己的模型、資料和工作流上。這件事如果跑順，會比單純聊天更有價值。

FAQ

speech-to-speech 是什麼？

speech-to-speech 是 Hugging Face 的開源語音 Agent 管線，透過 VAD、STT、LLM、TTS 四個階段，把使用者語音轉成模型回應，再合成語音輸出。

它可以完全本地運行嗎？

可以，但需要把 STT、LLM、TTS 都換成本地後端，例如 Whisper、llama.cpp 或其他 OpenAI-compatible 本地 LLM server，以及 Qwen3-TTS 等本地語音合成模型。

為什麼不用雲端語音助手就好？

如果只是日常聊天，雲端語音助手更省事。本地方案的價值在於隱私、離線、可控模型、可接自有資料與 Agent 工作流。

OpenWork 是什麼？OpenCode 桌面工作台與本地 Agent 入門

OpenWork 是什麼？OpenCode 桌面工作台與本地 Agent 入門

by | 7 月 8, 2026 | Agent, AI

OpenCode 和 OpenWork 這組工具，真正值得看的地方不是「又一個 Claude Code 替代品」而已，而是它把 AI Agent 從純命令列往桌面工作台推了一步, OpenCode 負責 agentic coding 的核心能力，OpenWork 則把工作目錄、Session、Skill、Plugin、MCP、權限確認和遠端 worker 包成比較容易操作的圖形介面。

這條路線剛好踩在很多人的痛點上：Claude Code 好用，但成本、封閉性和模型選擇會卡住；Codex 很適合開發工作，但一般辦公流程、跨工具流程、團隊共享設定，還需要另一層產品化介面, OpenWork 的企圖就是把 opencode 這套底層能力包成「可以給團隊重複使用的 Agent 工作流」。

如果你之前已經在看 OpenCode 如何使用本地端模型，這篇可以當成下一步：不只讓模型接進來，而是把 skills、plugins、MCP 和權限流程一起整理成可操作的工作台。

OpenWork 是 opencode 的桌面層，不是另一個單純聊天 App

OpenWork 官方把自己定位成 Claude Cowork 和 Codex 的開源替代方案，它是一個 local-first 的桌面 app，背後 powered by opencode 你可以在本機跑 host mode，也可以用 client mode 連到既有 OpenCode server, 之後透過 UI 管理 session、看 streaming event、處理 permission request、管理 templates、安裝 skills 和 plugins。

這個定位很重要。OpenWork 不是要取代 OpenCode，而是把 OpenCode 原本比較偏開發者的 CLI 體驗，變成更像工作台的產品。OpenCode 擅長讀檔、改檔、跑工具、處理任務；OpenWork 則負責讓這些能力變得可視化、可審核、可分享。

這也是我覺得它和 用 AI 組一家公司那篇可以放在一起看：真正有價值的不是單一模型多會回答，而是能不能把一套工作流程產品化，讓人、Agent、工具和權限一起運作。

OpenCode 和 OpenWork 的分工

這兩者的分工：

項目OpenCodeOpenWork
核心角色AI coding agent 與 CLI/Server 核心桌面工作台與協作介面
使用者體驗偏工程師、命令列、設定檔偏圖形介面、session、權限與模板
擴充方式plugins、agents、SDK、生態資源skills manager、plugins、MCP、templates
適合場景開發、專案自動化、終端機工作流把 Agent 流程包成團隊可重複使用的工作台

OpenWork README 裡有一句很關鍵：它是 ejectable 意思是就算 UI 還沒包到某個能力，只要底層 OpenCode 能做，理論上還是可以回到底層去做。這是開源工具很重要的特性，因為你不會被單一 UI 的產品進度完全卡死。

安裝與模式：先分清楚桌面 App、Host mode、Client mode

OpenWork 有幾種使用方式。最直覺的是下載桌面 app；如果你想自己 build，就要準備 Node.js、pnpm、Bun、Rust/Tauri、OpenCode CLI 官方 source build 流程大致是：

git clone https://github.com/different-ai/openwork
cd openwork
git checkout dev
pnpm install --frozen-lockfile
pnpm dev
如果只想跑 CLI host，也可以用 OpenWork Orchestrator：

npm install -g openwork-orchestrator
openwork start --workspace /path/to/workspace --approval auto

這裡要注意一件事：OpenWork 的 Host mode 會在本機跑 host stack，預設綁在 127.0.0.1 Client mode 則是連到既有的 OpenCode server，如果你看到 ready 是灰色、New task 不能按，第一個方向不是懷疑模型，而是檢查工作目錄、host stack、OpenCode server、provider key 或本地模型連線是否真的準備好。

Skills、Plugins、MCP：OpenWork 真正有用的地方

OpenWork 的 Skills manager 可以列出 `.opencode/skills`，也能把本地 skill folder 匯入到 `.opencode/skills/<skill-name>` 這個方向很像 Claude Code / Codex 的 skills 概念：把常用工作流程寫成可重複使用的操作說明，讓 Agent 每次做事不用從零開始猜。

如果你站上看過 用 skill-creator 建立 Skill，OpenWork 這裡的邏輯也很接近：與其每次都寫一長串 prompt，不如把工作流程變成可安裝、可分享、可版本化的能力。

Plugin 則是 OpenCode 的原生擴充方式。OpenWork 會讀寫 `opencode.json`，Project scope 在工作目錄的 `opencode.json`，Global scope 通常在 `~/.config/opencode/opencode.json`。

awesome-opencode 這個 repo 則像是生態目錄，整理了 plugins、themes、agents、projects 和 resources 它不是核心工具，但很適合用來觀察 opencode 生態正在長出哪些周邊能力。

Build Mode 和 Plan Mode：不要一開始就讓 Agent 放手改

OpenCode 這類 agentic tool 最容易出問題的地方，是使用者還沒搞清楚任務邊界，就直接讓 Agent 進入執行狀態。比較穩的做法是先用 Plan Mode 讓它讀資料、拆任務、確認工具與風險，再進 Build Mode 讓它動手。

我會把它想成兩層：

  • Plan Mode：先觀察、讀檔、列步驟、找不確定性、提出執行順序。
  • Build Mode：開始改檔、跑命令、安裝依賴、呼叫工具、產出結果。

這和 Claude Code Workflow 裡的做法一致：先讓 Agent 把路線講清楚，再授權它動手。

AI Agent 的效率不是靠更衝，而是靠每一步都能回頭檢查。

本地模型與 Ollama：重點在 provider 設定，不是只裝好模型

很多人以為「Ollama 已經能跑模型」就等於 OpenWork 會自動看到它，但中間還差 provider 設定、base URL、模型名稱，以及 OpenCode / OpenWork 讀取設定檔的位置。

原則上，你要確認三件事：

  1. Ollama server 已經在跑，常見位置是 `http://localhost:11434`，遠端機器則要確定防火牆與 bind address。
  2. OpenCode 的 provider 設定有指到 Ollama 或 OpenAI-compatible endpoint。
  3. OpenWork 使用的 workspace / dev-mode / global config，和你實際編輯的設定檔是同一份。

這部分可以搭配 Ollama 遠端連線教學 和 LM Studio 與 Ollama 的零 API 成本環境一起看 OpenWork 不是魔法入口，它還是要靠底層 provider 設定把模型接起來。

Token 成本：免費模型不等於無限使用

免費通常代表某段時間、某個額度、某個服務條款下不用付費，不代表可以無限燒，也不代表 latency、rate limit、上下文長度和品質都沒有代價。

OpenCode / OpenWork 這種工具特別容易消耗 token，因為 Agent 會讀檔、反覆規劃、呼叫工具、看輸出、再修正你讓它處理一個大型 workspace，成本不是只有最後回答那幾百字，而是整個工作循環。

所以比較實際的策略是：

  • 簡單查詢與短任務用便宜或本地模型。
  • 高風險修改、跨檔案重構、複雜判斷再用強模型。
  • 能寫成 skill / template 的流程就固化，減少每次重新解釋。
  • 先 Plan 後 Build，避免 Agent 一路試錯燒成本。

Windows 使用者要先注意的幾個坑

Windows 問題不少，這也很符合這類 Tauri / Node / CLI 混合工具的現況。

OpenWork README 也有提到，Windows access 有一部分是透過 paid support plan；source build 則會牽涉 Node、pnpm、Bun、Rust、Tauri 和 OpenCode CLI。這不是一般雙擊安裝就結束的輕工具。

  • Ready 灰色：先檢查 host stack 是否啟動、workspace 是否選對、provider 是否可用。
  • New task 灰色：通常表示前置狀態未完成，例如沒有有效 session、工作目錄或 worker 尚未 ready。
  • nul 檔案問題：Windows 下 `nul` 是特殊裝置名，如果工具誤產生同名檔，刪除會很麻煩。這種問題要優先回報 issue，並避免在重要目錄直接測不穩定版本。
  • `.config` 目錄看起來不對：要確認你看的到底是 OpenCode global config、workspace config，還是 dev-mode 隔離狀態。

這裡我會建議用比較保守的方式測：先開一個乾淨測試資料夾，不要直接指到重要專案；先確認 session、provider、permission、簡單讀寫任務都正常，再把 OpenWork 放進真正的工作流程。

OpenWork 適合誰？

OpenWork 現階段比較適合三種人。

  • 第一種是想把 OpenCode 圖形化的人。你已經接受 agentic coding，但希望有 session、permission、skills、plugins 的視覺工作台。
  • 第二種是想把 Agent 工作流交給團隊的人。Templates、skills、remote sharing 這些能力，重點都是讓流程可以重複與分享。
  • 第三種是正在比較 Claude Code、Codex、OpenCode 生態的人。OpenWork 讓 opencode 不只停留在 CLI，而是開始往產品化入口走。

但如果你現在只想要一個穩定、少設定、打開就能工作的辦公 AI，OpenWork 可能還會讓你覺得太工程化。它的價值在於可控與可擴充，不在於完全隱藏複雜度。

資源整理

截至我整理資料時，OpenWork GitHub repo 約 1.6 萬 stars，awesome-opencode 約 8 千多 stars 這代表生態正在被快速關注，但也代表文件、Windows 體驗、plugin 相容性和錯誤處理還會持續變動。用它之前要有「早期開源工具」的心理預期。

OpenWork 把 OpenCode 從工具變成工作台

OpenCode 已經回答了「AI Agent 能不能在 terminal 裡幫我做事」；OpenWork 想回答的是下一題：「這套能力能不能被包成一個可視化、可分享、可審核的工作台？」

現階段最好的用法，是先用 OpenCode 跑穩本地模型、provider、skills 和 plugins，再用 OpenWork 管理 session、權限、template 與團隊共享流程。

OpenWork 的重點不是多一個聊天視窗，而是讓 opencode 的 Agent 能力開始變成「可交付的工作流程」。這會是 2026 年 AI 工具很重要的一條線。

FAQ

OpenWork 是什麼？

OpenWork 是 powered by opencode 的開源桌面工作台，讓使用者在本機或遠端 server 上管理 AI Agent session、skills、plugins、MCP、templates 與權限確認。

OpenWork 和 OpenCode 有什麼差別？

OpenCode 是底層 AI coding agent 與 CLI/Server 核心；OpenWork 是圖形化桌面層，負責把 session、權限、skills、plugins、templates 與工作目錄變得更容易操作。

OpenMontage 本地部署實測：開源 AI 影片工作流怎麼跑？

OpenMontage 本地部署實測：開源 AI 影片工作流怎麼跑？

by | 7 月 8, 2026 | AI, 影片製作

OpenMontage 最吸引我的地方，不是「一句話自動做完 AI 影片」這種口號，而是它把 AI 影片製作拆成一套比較像真實片廠的工程流程：研究、提案、腳本、分鏡、素材、剪輯、合成、檢查，全部交給 coding agent 去編排。

這件事有意思，因為現在很多 AI 影片工具其實只是在「生成幾段畫面」或「把幾張圖做動」, OpenMontage 的方向不太一樣，它把影片看成一個專案，而不是單一模型輸出, 你可以用生成式素材，也可以走免費素材檢索，也可以讓 Remotion、HyperFrames、FFmpeg、TTS、字幕工具一起工作。

如果你之前看過我寫的 HyperFrames 用 HTML 寫影片，OpenMontage 可以理解成更上層的總控：HyperFrames 或 Remotion 是渲染舞台，OpenMontage 則負責決定要演哪一齣、需要哪些素材、哪個管線比較適合。

先講結論：它不是單一工具，而是一套 agentic video workflow

OpenMontage 官方把它定位成 open-source agentic video production system。

這句話翻成白話就是：你不是打開一個剪輯軟體慢慢拉時間軸，而是把需求丟給 AI coding assistant，讓它在專案裡呼叫一串工具，最後產出可渲染的影片專案。

它目前主打 12 條 production pipelines、52 個 production tools、數百個 agent skills。這些數字先不用神化，真正重要的是架構：OpenMontage 把「做影片」拆成管線選擇問題。要做動畫解說、紀錄片蒙太奇、動態文字、產品廣告、Podcast repurpose、字幕翻譯，走的流程不應該一樣。

這也很符合我對 AI Agent 的看法。真正能落地的 Agent，不是一直聊天，而是能選工具、讀檔、跑命令、檢查輸出、失敗後改路線。這點跟我前面整理過的 Ornith 35B 與 Hermes 工作流是同一個方向：模型不是主角，流程控制才是主角。

本地部署的基本盤：Python、Node、FFmpeg，再加一個 AI coding assistant

OpenMontage 的安裝門檻不算低，但也沒有到很誇張。官方 README 的 Quick Start 是：

git clone https://github.com/calesthio/OpenMontage.git
cd OpenMontage
make setup
如果是在 Windows 環境，配套筆記把步驟拆得更實際：先裝 Git、Python 3.11、Node.js；建立 venv；安裝 Python requirements；進 remotion-composer 跑 npm install；再預熱 HyperFrames。簡化後大概是這樣：
git clone https://github.com/calesthio/OpenMontage
cd OpenMontage
python -m venv venv
venv\Scripts\activate
python -m pip install -r requirements.txt
cd remotion-composer
npm install
cd ..
npx --yes hyperframes --version

OpenMontage 不是只有 Python 腳本，它會用 Remotion 做 React 影片渲染，也會用 HyperFrames 做 HTML/GSAP 類型的動態文字與 motion graphics，也就是說，它本質上是一個跨 Python、Node、前端渲染、影音處理的混合專案。

如果你本來就在研究 AI 影片生成模型，可以延伸看 Wan 2.1 的整理，OpenMontage 不是要取代這些模型，而是把模型、素材庫、TTS、剪輯和渲染器放進同一條可控流程。

零 API Key 可以玩，但不要把零成本理解錯

OpenMontage 官方 README 有一段很重要：沒有付費 API key 也能做東西。它可以用 Piper TTS、本地字幕、FFmpeg、Remotion、HyperFrames，以及 Archive.org、NASA、Wikimedia Commons 這類開放素材來源，配套筆記則建議本地中文配音可以接 dots.tts，走 OpenAI 相容的本地 API 服務。

但我會把這件事講精準一點：零 API Key 不等於零成本。你省下的是雲端生成 API 的帳單，但仍然有時間成本、硬碟成本、顯卡成本、網路下載成本，以及 Agent 跑錯路線後的重跑成本。

比較正確的理解是：OpenMontage 讓你有機會把成本從「每次生成都付費」改成「本地工具與免費素材優先，必要時才接付費 provider」。這也是我喜歡本地 AI 工作流的原因，重點不是假裝不用花錢，而是你可以決定錢花在哪裡。

如果你對本地 TTS 有興趣，可以接著看 VoxelCPM 本地 TTS 與離線部署。OpenMontage 這類工具能不能舒服使用，中文配音品質其實會大幅影響成品觀感。

三條路線：生成類、檢索類、動態文字類

真正開始用 OpenMontage 時，我覺得要先把題目分成三種，不要一律丟給同一條管線。

  • 生成類：適合知識動畫、概念解釋、抽象主題。重點是腳本、旁白、視覺生成與字幕。
  • 檢索類：適合森林、海浪、城市、科技感、自然景觀這種通用氛圍題。重點是免費素材庫與剪輯節奏。
  • 動態文字類：適合頻道預告、產品短片、宣傳片、資訊卡。重點是排版、節奏、字卡與音樂。

這裡最大的坑是「題目和管線不匹配」。例如你想做歷史事件、特定人物、某次火箭發射、某個實驗室場景，免費素材庫不一定找得到精準畫面。這種題目硬走檢索管線，很容易找到一堆氣氛接近但內容對不上的 B-roll。

相反地，如果題目是「地球的呼吸」「雨夜城市」「森林甦醒」這類氛圍型主題，檢索管線就很適合。因為它不需要某個唯一正確鏡頭，只要找到情緒與節奏對的真實素材，就能剪成一支完整作品。

這點也可以和 OiiOii 動畫分鏡工作流放在一起看。AI 影片的關鍵不只是模型，而是你能不能在生成前就把「題目、鏡頭、節奏、素材來源」講清楚。

OpenMontage 最值得記下來的 6 個坑

這次配套筆記最有價值的地方，是把幾個踩坑點寫得很直接。我整理成實作時應該先記在旁邊的清單。

  1. 不要亂加逐詞字幕。動畫解說如果要求逐字、逐詞字幕，切詞可能會很碎。普通字幕反而比較乾淨。
  2. 檢索管線要避開大規模 corpus builder。直接把 NASA、Archive.org 整段抓下來建語料庫，很容易下載失控。快速路線是 direct_clip_search，只用 Pexels / Pixabay，720p，限制槽位。
  3. 不要讓 Agent 自己亂翻中文搜尋詞。檢索素材時，最好把每個鏡頭先翻成 5 個字以內的英文短語，例如 misty forest valley、ocean waves、city rain night。
  4. 提示詞會影響管線選擇。如果你寫「科普、旁白、TTS、中文字幕」，系統很可能走 animated-explainer；如果你要真實素材蒙太奇，就要明確寫 documentary montage、real footage only、direct_clip_search、no narration。
  5. 8GB 顯卡不適合硬衝本地影片生成。能塞進去的模型選擇有限，還要 CPU offload，最後可能等很久只得到短短幾秒低解析片段。
  6. 免費素材路線適合通用題，不適合特定命名物。森林、城市、海浪很好找；某個具名歷史場景或特定設備就不要硬搜。

OpenMontage 現階段最合理的期待值：可以跑通，可以做出東西，但要用對題目、用對管線、不要期待它第一次就像成熟商業剪輯工具。

我會怎麼下 prompt：先鎖管線，再鎖素材來源

OpenMontage 不是越自由越好用。你如果只寫「幫我做一支很酷的 AI 影片」，Agent 會需要猜太多東西：要不要旁白？要不要真實素材？要不要生成圖片？要不要字幕？要用 Remotion 還是 HyperFrames？

比較穩的 prompt 應該長這樣：

製作一支 60 秒紀錄片蒙太奇，主題是「地球的呼吸」。
管線：documentary-montage。
素材：只用真實素材，只從 Pexels / Pixabay 搜尋，走 direct_clip_search，不要 Archive.org，不要 NASA，不要 corpus_builder。
音訊：不要旁白，只放背景音樂。
畫面：720p，10 個素材槽位。
搜尋詞：每個槽位用我給的英文短語，不要自行改寫。
輸出：Remotion 渲染，三段中文畫面文字卡，淡入淡出。

如果要做動態文字宣傳片，就要反過來鎖死：不要檢索、不要生成圖片、全部用程序化排版文字、渲染引擎用 HyperFrames/GSAP。這樣 Agent 才不會跑去找素材，或突然把簡單字卡做成一堆不必要的生成圖。

這也是我覺得 OpenMontage 適合搭配 Codex 這類 coding interface 的原因。它需要的是能讀專案、跑命令、改檔案、看錯誤、重新執行的環境，不只是單純聊天介面。

8GB 顯卡可以玩嗎？可以，但不要從本地影片生成開始

本地影片生成性價比偏低，Wan2.1-1.3B 這類模型可以勉強塞，但要開 CPU offload；輸出通常短、解析度不高，等待時間也不短。圖生影片若不小心切到更大的 14B 模型，8GB 顯卡直接爆掉也不奇怪。

所以如果你的硬體只有 8GB VRAM，我會建議先走三條比較務實的路：

  • 用免費素材庫做真實素材蒙太奇。
  • 用 Remotion / HyperFrames 做程序化動畫與動態文字。
  • 把本地 TTS、字幕、剪輯、自動化流程先跑順。

等流程穩了，再評估要不要加付費 API 或升級硬體，如果你正在考慮 AI 工作站，RTX PRO 6000 Blackwell 顯卡選購那篇可以搭配看，OpenMontage 這種工作流很吃「整體系統」，不只是顯卡型號而已。

適合願意把影片當工程專案的人

OpenMontage 現在比較適合三種人。

  • 第一種是技術型創作者：你願意看 log、改 prompt、裝依賴、調管線，OpenMontage 會給你很大的控制權。
  • 第二種是想把內容流程自動化的人：例如固定產出知識動畫、短片、宣傳片、字幕版本，這套管線可以慢慢沉澱成自己的模板。
  • 第三種是正在研究 AI Agent 的人：OpenMontage 很適合觀察 Agent 如何做工具選擇、階段驗證、失敗重試與輸出檢查。

但如果你期待的是「打一句話、三分鐘後給我商業級成片」，它目前不會是最好的選擇，它更像一個正在快速演化的開源片廠骨架，需要你願意進去調教。

資源與安全連結整理

OpenMontage 的價值在「可編排」，不是魔法

我會把 OpenMontage 看成 AI 影片製作的 agentic framework，而不是一個單純的 AI 影片生成器。它真正有價值的地方，是把影片製作拆成可選管線、可替換工具、可檢查輸出的流程。

它現在最適合的打法，是先從零 API Key 或低成本路線開始：本地 TTS、免費素材庫、Remotion、HyperFrames、FFmpeg，等流程跑通，再依照題目決定要不要加 Veo、Kling、FLUX、OpenAI TTS 或其他 provider。

一句話總結：OpenMontage 不是把創作變成不用思考，而是把創作變成可以被 Agent 執行、被人類審核、被工程流程反覆改進的系統。這條路如果走通，AI 影片工具會從「生成一段畫面」進化成「管理一個製作流程」。

FAQ

OpenMontage 是什麼？

OpenMontage 是一套開源的 agentic video production system，讓 AI coding assistant 透過管線方式處理研究、腳本、素材、剪輯、渲染與檢查，不只是單一影片生成模型。

OpenMontage 可以不用付費 API Key 嗎？

可以。它可以使用本地 TTS、免費素材庫、Remotion、HyperFrames、FFmpeg 等工具先跑出作品。不過零 API Key 不等於零成本，仍然有硬體、時間、下載與維護成本。

OpenMontage 適合用在哪些題目？

通用氛圍類題目適合走真實素材檢索，知識解釋適合走動畫解說，產品或頻道宣傳適合走動態文字。特定歷史事件、具名人物或稀有場景，不適合硬走免費素材檢索。