Posts

前幾天在 r/comfyui 上看到一則貼文，標題平平無奇——「LTX 2.3 Video Builder UI for ComfyUI - High Level Beta Overview」，點進去看完整個 Demo 影片後，我第一個念頭是：AI 影片生成工具終於要從「極客的玩具」變成「創作者的武器」了。 這篇文章不只是想介紹這個工具，我想帶你從 LTX 2.3 模型本身聊到 ComfyUI 上的 Video Builder 工作流程，再聊聊它對整個 AI 影片生態的意義。如果你曾經用過 Runway、Pika 或 Sora，但苦於不夠靈活；或者你已經在用 ComfyUI 做影像生成，卻覺得影片流程太零散——這篇文章應該會讓你眼睛一亮。 LTX 2.3 是什麼？為什麼它值得關注？ LTX 2.3 是以色列公司 Lightricks 推出的開源影片生成模型，架構上採用 Diffusion Transformer（DiT），是目前高階生成式影片的主流架構。它的最大賣點可以用一句話概括：「一個模型，搞定影片＋同步音訊。」 核心規格亮點 能力 說明 最高解析度 4K（4096×2160） 最高幀率 50 FPS 影片長度 最長 20 秒 畫幅比例 16:9、9:16（原生支援）、1:1 音訊 原生同步生成 授權 年營收低於 1000 萬美元的企業可免費商用 這裡有幾個關鍵升級值得注意： 1. 重新設計的潛在空間（Latent Space） LTX 2.3 訓練了一個更高品質的 Video VAE，意味著細部表現（髮絲、文字、邊緣）比前代 LTX-2 更銳利。簡單來說，生成的畫面不會再有一層「AI 糊感」。 ...

前言 前陣子看到一篇來自 Quesma 的文章，作者在他的 MacBook Max M5（128GB RAM）上跑了 Qwen 3.6 系列模型後，得出一個頗具爭議的結論：27B 稠密模型在本地開發中才是最佳選擇，而不是 35B MoE 版本。 這個說法在 Reddit 的 LocalLLaMA 社群引發了熱烈討論——有人認同、有人反對。作為一個長期關注開源模型本地部署的人，我覺得這正是個好機會，把 Qwen 3.6 整個系列徹底盤點一遍，讓大家在實際部署前有個清晰的認知。 Qwen 3.6 家族全覽 Qwen 3.6 是阿里通義千問團隊在 2026 年 4 月推出的新一代模型家族，主要分為三大版本： 1. Qwen 3.6-Plus（旗艦閉源版） 透過阿里雲百煉 / DashScope API 提供 預設 100 萬 token 上下文視窗 採用混合線性注意力（Linear Attention）+ MoE 架構 估計活躍參數超過 4000 億 定價約 $0.29/100 萬輸入 token、$1.65/100 萬輸出 token，比 Claude Opus 4.6 便宜約 12 倍、GPT-5.4 便宜約 6 倍 2. Qwen 3.6-35B-A3B（開源 MoE 版） ...

前言 如果你曾經用過 VideoScribe 或 Doodly 做過白板動畫，你就知道這套視覺語言有多麼強大——手繪線條在白色背景上一筆一筆出現，搭配旁白，能把複雜概念講得連阿公阿嬤都聽得懂。但問題也很明顯：手動選素材、排時間軸、錄旁白，一支兩分鐘的影片花個半天是常有的事。 現在，一位開發者 Yogendra Yatnalkar 推出了一個開源專案 Storyboard AI ，主打「輸入一段文字，自動產出一支完整的白板動畫影片」，從腳本、分鏡、插圖生成、動畫到配音字幕，全流程 AI 驅動。這個專案在 Reddit 的 r/SideProject 上引發了不少討論，目前已經獲得超過 59 個讚。 這篇文章帶你深入認識這個工具，看看它到底能做到什麼程度，以及跟市面上其他方案相比，有什麼優勢和限制。 Storyboard AI 到底是什麼？ 簡單來說，Storyboard AI 是一套 Agentic Pipeline（智能代理管線），它的核心概念是用一個「導演代理（Director Agent）」來統籌整個影片製作流程。你只需要提供一個主題或一段文字描述，它就會自動完成以下步驟： 研究與腳本撰寫：根據你給的主題，自動生成一段有吸引力的敘事腳本。 分鏡規劃：把腳本拆解成多個場景，規劃每個場景的視覺呈現方式。 素材生成：為每個場景生成白畫風格的插圖。 動畫製作：模擬手繪過程，讓畫面以「邊畫邊出現」的效果呈現。 配音與字幕：合成語音旁白，並精準對齊字幕。 整個過程你幾乎不需要插手，這就是它被稱為「E2E（End-to-End）」的原因。 技術架構：它怎麼做到的？ Storyboard AI 的技術堆疊相當紮實，我們來拆解它的核心組件： 1. Director Agent 與子代理架構 Director Agent 是整個管線的大腦。它會將你輸入的高階主題拆解成多個場景，然後將每個場景的任務委派給專門的子代理： 腳本代理：負責根據主題生成敘事腳本。 分鏡代理：規劃每個場景的視覺結構。 素材代理：生成白畫風格的插圖。 動畫代理：處理繪畫動畫效果。 音訊代理：合成旁白語音並對齊字幕。 這種「一個大代理帶一群小代理」的架構，在當前 AI Agent 應用中是非常主流且有效的设计模式。 2. 關鍵模型配置 專案的 config.py 中定義了幾個核心模型，目前使用的是 Google 的 Gemini 系列： MODEL_NAME = "gemini-2.5-pro" IMAGE_GEN_MODEL = "gemini-3-pro-image" VEO_MODEL = "veo-3.1-generate-preview" gemini-2.5-pro：負責腳本生成、分鏡規劃等文字與邏輯任務。 gemini-3-pro-image：生成白畫風格的插圖素材。 veo-3.1-generate-preview：處理影片動畫生成。 3. SAM 3 分割引擎 Storyboard AI 用到了 Segment Anything Model 3（SAM 3） 來做實例分割（instance segmentation）。這讓它能精確地從生成的插圖中提取出需要動畫化的元素，確保繪畫效果準確到位。 ...

前言 如果你曾經用過 Stable Diffusion 的 Booru 訓練模型（比如各種 Nijijourney、Animagine checkpoint），你一定有過這種痛苦：明明腦海中有個很生動的畫面——「一個穿著牛仔短褲的黑髮吸血鬼少女，在深夜的教室裡抱臂微笑」——但打到提示詞框裡的卻是一串像亂碼的 tag： 1 d g a i r r k l , c l v a a s m s p r i o r o e m , , f n a i n g g h s t , , d m e a n s i t m e r s p h i o e r c t e s , , b b e l s a t c k q u h a a l i i r t , y a r m s c r o s s e d , s m i r k , 寫過一次還好，寫了十次之後手會酸、腦會霧。更別說你根本不知道哪些 tag 是模型真正看得懂的、哪些只是多餘的噪音。 ...

前言 如果你跟我一樣，大部分時間都泡在終端機裡——裝套件、寫程式、管理伺服器——那麼每次要下種子檔時，非得切到瀏覽器或打開一個臃腫的 GUI 客戶端，總覺得有點斷了「流」。 前陣子在 Reddit 上看到一個 Side Project 分享，作者 build 了一個叫 Torrra 的終端機種子工具，短短時間就拿到了 178 顆星。我點進去看了看，發現它不僅功能完整，而且設計理念非常貼合終端機使用者的習慣。這篇文章就來好好介紹一下這個工具。 什麼是 Torrra？ Torrra 是一個用 Python 寫的命令行工具，核心定位很明確：「不用離開 CLI 就能搜尋、下載、管理種子檔」。 它整合了三個關鍵組件： Jackett / Prowlarr 作為索引器（Indexer），幫你從各大種子站搜尋資源 Libtorrent 作為底層下載引擎，負責實際的 P2P 傳輸 Textual 框架打造的 TUI（文字使用者介面），提供漂亮的終端機畫面 簡單來說，Torrra 把「搜尋種子 → 選擇檔案 → 開始下載 → 管理進度」這整個流程，全部收斂在一個終端機視窗裡完成。 核心功能 一鍵搜尋多站資源 一般用種子，最麻煩的就是要一個一個站去搜——YTS 有這部嗎？EZTV 有嗎？FitGirl 重製版在哪？Torrra 透過 Jackett 或 Prowlarr 串接所有已設定的索引器，一次搜尋、全部回報。你只需要輸入關鍵字，剩下的它幫你搞定。 直觀的 TUI 介面 Torrra 不是那種滿是參數的古老 CLI，它用 Textual 框架打造了一個響應式的文字使用者介面。搜尋結果以列表形式呈現，你可以用方向鍵或 vi 風格的 j / k 來瀏覽，按 Enter 直接下載選中的項目。 ...

前陣子在 r/comfyui 上看到一則讓社群瞬間沸騰的貼文——VNCCS 3.0 正式發布了。這個由開發者 V-chan（AHEKOT）打造的視覺小說角色創建套件，從去年 9 月推出 V1.0 以來，短短不到一年就跳到了 3.0，迭代速度之快令人咋舌。 這篇文章來好好聊聊 VNCCS 3.0 到底更新了什麼、為什麼它能在眾多角色一致性工具中脫穎而出，以及對一般 AI 繪圖玩家來說，VNCCS 3.0 有什麼值得關注的地方。 什麼是 VNCCS？先搞懂角色一致性這個痛點 在深入 VNCCS 3.0 之前，先來理解它要解決的核心問題：角色一致性（Character Consistency）。 你用 AI 繪圖工具（Midjourney、Stable Diffusion、Flux 等等）生成角色時，最頭痛的是什麼？同一個角色，換個提示詞、換個姿勢、換個服裝，長得就不像了。眼睛顏色不對、髮型走樣、連臉型都變了。這對單張插畫來說還好，但如果你要做視覺小說（Visual Novel）、遊戲角色、或是需要同一角色出現在多個場景的系列作品，一致性就是生死關鍵。 VNCCS 的全名是 Visual Novel Character Creation Suite，直譯就是「視覺小說角色創建套件」。它的核心思路很直接：先建立一個「角色基準表（Character Sheet）」，然後基於這個基準表，在所有後續的生成中保持角色外觀一致。 可以想成先畫一張角色設定圖（正臉、側臉、全身），然後所有後續的表情、動作、服裝都參考這張設定圖來生成。這聽起來不難，但要做到「自動化」且「高品質」，背後需要一套完整的 pipeline。 VNCCS 3.0 的重大更新 V-chan 在 GitHub 上宣布 3.0 時用了這樣一句話： “We got a BIIIIIIG update, and now everything is completely new.” 確實，3.0 幾乎是把整個架構重寫了一遍。以下是幾個最重要的更新： 1. 全面整合 Qwen 模型 3.0 最大的改變之一是全面採用 Qwen 模型作為核心引擎。之前的版本主要依賴 SDXL 系列模型，而 3.0 引入了基於 Qwen 的角色編碼器（VNCCS_QWEN_Encoder），這讓角色特徵的提取和保持更加精準。 ...

前陣子我發現一個現象：Hermes Agent 第一次發話時的初始上下文，從之前的 1.6K tokens 左右，悄悄爬升到了 2.8K tokens，增幅接近 75%。 起初以為只是個人設定差異，結果去 Reddit 的 r/hermesagent 一看——好家伙，幾乎 everybody 都在抱怨同樣的事。 這篇就來好好聊聊這個問題：從發現、原因分析、社群反饋到實戰解法，一次講清楚。 什麼叫「初始上下文」？為什麼它很重要？ 在深入之前，先釐清一個概念：Hermes Agent 每次發話（無論你只打一個「hi」），都會把完整的 system prompt 送給模型。這包含： 核心行為規則與 persona 所有已載入工具的 schema 定義 Skill 清單（名稱 + 描述） AGENTS.md（開發者指南） Memory、User Profile、SOUL.md 等個人設定 這些全部打包在一起，就是所謂的「初始上下文」或「system overhead」。 為什麼重要？ 因為這塊 overhead 是固定成本。你發一句「今天天氣如何」和發一段 5000 字的程式碼需求，初始上下文幾乎是一樣的。對 token 計費的模型來說，這意味著你在為「沒用到的東西」付費。 更糟的是，如果這個 overhead 持續膨脹，長期下來就是一筆可觀的開銷。 1.6K → 2.8K：增長從何而來？ 根據 Reddit 社群的深度 audit，Hermes 每次發話的 token 組成大致如下： 組成部分 Token 佔比 說明 工具定義 (Tool Schemas) ~38% 50 個工具的 schema，預設全部載入 AGENTS.md ~22% 開發者指南，在 repo 內會自動載入 MCP 工具 ~9% 如 Shopify 等第三方整合 Skill List ~7% 279 個 skills 的名稱+描述 Memory / Profile / Persona ~12% 個人設定與記憶 System Prompt ~12% 行為規則、格式規範 以一個預設安裝來說，初始上下文大約落在 14K–16K tokens。但如果你把 AGENTS.md、MCP 工具、以及大量不用的 skills 排除，可以壓到 4K–6K。 ...

前言 2026 年 6 月 26 日，OpenAI 正式對外公布了 GPT-5.6 系列的預覽版本，其中最受矚目的旗艦模型 GPT-5.6 Sol 一登場就引爆了整個 AI 社群的討論。這次不僅帶來了性能的大幅躍升，更引入了全新的「天體命名法」與多層式安全防護機制。 這篇文章將帶你完整認識 GPT-5.6 Sol 的核心能力、三大模型差異、實測 benchmark 數據，以及 METR 獨立評估報告中的關鍵發現。 為什麼要改名？全新「天體命名法」解讀 這次 GPT-5.6 最引人注目的變化之一，是 OpenAI 放棄了過去「Instant」系列的命名方式，改以 Sol（太陽）、Terra（地球）、Luna（月亮） 這三個天體來代表不同的能力階層。 OpenAI 的官方解釋是：數字代表模型的世代（generation），而天體名稱代表「持久化的能力階層」（durable capability tiers），這些階層可以各自獨立演進，不受世代更新的限制。 簡單來說，未來的 GPT-6 系列可能會有 Sol v2、Terra v2，它們的性能會隨著時間自然成長，而不需要等到下一個世代號更新。這個策略讓產品線更具彈性，也讓開發者能更精準地選擇適合的模型。 模型 定位 適用場景 Sol 旗艦級 高難度編程、Agentic 工作、進階推理、網路安全與生物研究 Terra 均衡型 日常任務，性能與 GPT-5.5 競爭，價格低一半 Luna 高效型 高吞吐量任務、分類/摘要、延遲敏感型應用 定價策略：每百萬 token 的帳單 先來看大家最關心的價格（以每百萬 token 計價）： 模型 輸入價格 輸出價格 Sol $5.00 $30.00 Terra $2.50 $15.00 Luna $1.00 $6.00 幾個值得注意的定價細節： ...

前言 最近 AI 工具圈有一個新東西竄出來，讓不少用 Obsidian 和 Notion 的人開始動搖了——OpenKnowledge。 簡單說，這是一個開源的、本地優先（Local-First）的 Markdown 編輯器，但它不只是「又一個筆記軟體」。它的核心定位是：讓 AI 代理（Agent）和人類共同維護一個知識庫。 你沒聽錯，AI 不只是「幫你寫筆記」，而是可以直接在你的筆記裡讀寫、搜索、管理知識。 這篇文章我會把 OpenKnowledge 的來龍去脈、核心功能、安裝方式和使用方法整理得明明白白，讓你想深入了解或上手試試的時候，不用再去翻一堆零散的文件。 它到底是什麼？ OpenKnowledge 是由 Inkeep 團隊開發的開源專案，採用 GPL-3.0 授權。它的官網是 openknowledge.ai ，原始碼在 github.com/inkeep/open-knowledge 。 團隊自己的說法是： 「我們想打造一個像 Google Docs 一樣的編輯體驗，但底層全是乾淨的 Markdown 檔案。」 換句話說，它解決了一個長期存在的痛點：Markdown 編輯器的「寫的時候」和「看的時候」總是兩張臉。Obsidian 寫的時候是一堆符號，切換到預覽模式又是另一副模樣，那種割裂感就像戴著游泳鏡吃飯。 OpenKnowledge 用 WYSIWYG（所见即所得）的方式，讓你在編輯時就能看到最終效果，同時底層仍然是標準的 Markdown 檔案。 核心功能大解構 1. WYSIWYG Markdown 編輯器 這是最直觀的功能。OpenKnowledge 的編輯器基於 Tiptap / ProseMirror 這個強大的編輯引擎，搭配 CodeMirror 處理程式碼區塊，提供類似 Google Docs 的編輯體驗。 支援的進階 Markdown 元素包括： Callouts & Tips：內嵌的警告或提示框 Accordions：可摺疊的段落 Tabs：內嵌的內容切換標籤 Mermaid：原生渲染流程圖和圖表 Media：拖放圖片（支援縮放）和嵌入影片 Embeddable HTML：支援互動式應用程式和數據視覺化 2. AI 原生整合（這才是重頭戲） OpenKnowledge 不是一個「加了 AI 外掛」的筆記軟體，它是從設計之初就為 AI 打造的。 ...

近期開源 AI 圈迎來了一項引人注目的發布——由 DeepReinforce 推出的 Ornith-1.0 模型系列。這組專為 Agentic Coding（智慧體編碼）設計的開源模型，在發布後迅速成為社群討論的焦點。本文將從模型架構、基準測試表現、核心技術創新與部署可行性等面向，客觀分析 Ornith-1.0 的亮點與潛在價值。 模型背景與版本架構 Ornith-1.0 系列建立在 Gemma 4 與 Qwen 3.5 的預訓練模型之上，共推出四個參數量版本： 模型版本 架構類型 適用場景 Ornith-1.0-9B Dense（稠密） 邊緣裝置、IDE 整合 Ornith-1.0-31B Dense（稠密） 均衡效能與資源 Ornith-1.0-35B MoE MoE（混合專家） 本地部署首選 Ornith-1.0-397B MoE MoE（混合專家） 旗艦級雲端部署 其中，397B MoE 是本次發布的旗艦模型，僅有 17B 的活躍參數（active parameters）。而 35B MoE 版本則被視為「甜蜜點」——參數量遠低於旗艦版，但在多項編碼基準測試中卻能逼近甚至超越 397B 大模型的表現。 所有模型均採用 MIT 授權協議，允許商業與研究用途，無任何額外限制。 基準測試表現 根據官方公布的數據，Ornith-1.0 在多個主流編碼智慧體基準測試中取得了亮眼的成績。以下整理主要結果： 旗艦版（397B MoE） 測試項目 Ornith-1.0-397B Claude Opus 4.7 Claude Opus 4.8 Terminal-Bench 2.1 77.5 70.3 85.0 SWE-Bench Verified 82.4 80.8 87.6 SWE-Bench Pro 62.2 — 69.2 SWE-Bench Multilingual 78.9 — — NL2Repo 48.2 — — ClawEval 77.1 — — 在 Terminal-Bench 2.1 與 SWE-Bench Verified 兩項測試中，397B 版本超越了 Claude Opus 4.7，展現了開源模型在編碼智慧體任務上的競爭力。 ...