Jellyfish：開源 AI 短劇工作流（Apache-2.0），把劇本到影片串成一條流程，但開發停在 2026 年 4 月

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

Jellyfish 想把 AI 短劇製作串成一條流程：劇本進去、分鏡出來、角色與風格跨鏡頭盡量一致、最後交給影片模型生成。它是 Forget-C 維護的開源專案，5138 顆星、Apache-2.0 授權，看起來相當亮眼，但有兩件事得先講清楚：它本身不做模型，劇本與畫面最終都送往你自備的雲端 API；而且它的最後一次更新停在 2026 年 4 月，使用者的問題已經堆到 6、7 月還沒人回。

TL;DR：Jellyfish（GitHub：Forget-C/Jellyfish，5138★，Apache-2.0）是 AI 短劇的端到端製作工作區，把劇本、分鏡、角色資產、影片生成與匯出串成一條流程，靠全局風格鎖定與資產複用緩解人物漂移。它本身不生成畫面，只把流程串起來，文字與影片都走你自備的 API（OpenAI、Claude 加上 Kling、Runway、Luma）。最後一次更新停在 2026 年 4 月的 v0.3.2，現階段更適合技術團隊摸索架構，而不是直接上線。

它是編排層，不是模型：劇本與畫面都送往雲端 API

先把它放對位置：Jellyfish 是一套工作流與資產管理工具，本身不會生成任何畫面或台詞。你把劇本餵進去，它幫你拆分鏡、管理角色與道具、把任務派給外部模型，最後把結果收回來整理。真正產出文字與影片的，是你自己接的 API，文字端常見的是 OpenAI、Claude，影片端則涵蓋 Kling、Runway、Luma 這類服務。

Pin

這個定位很重要，因為它決定了你的劇本與角色設定最後去了哪裡。劇本交給語言模型、角色定妝圖與分鏡交給影片模型，等於你的內容會經過這些雲端服務，計費也照它們的定價走。換句話說，Jellyfish 省下的是你手動在多個工具之間複製貼上的力氣，而不是算力成本；它本身免費、開源，但你跑它背後那串 API 時，帳單照樣會累積。這種「編排層疊在雲端模型之上」的做法，和 TripStar 那種建構在他人框架之上的自架工具 是同一類思路，差別在 Jellyfish 串的是商業模型 API。

把生成任務交給雲端模型，計費就是跑不掉的成本。一個分鏡多試幾次、角色反覆重生成，費用累積得比想像中快，而 Jellyfish 真正能幫上忙的地方，是它把文字、圖片、影片這些長時間的生成全收進同一套非同步任務系統，每個任務有狀態、能取消、出錯能恢復。這代表你不必盯著瀏覽器等一個鏡頭跑完，事後還能回頭查哪個任務花了多少、為什麼失敗、哪一次的重生成最燒錢。把這些紀錄留下來，才有辦法壓低廢片率與重複呼叫，對量產短劇控制成本有實際幫助。這也是它作為編排層最實在的價值所在。

人物漂移靠「資產複用」緩解，而不是被解決

做 AI 短劇最讓人崩潰的，是同一個主角切個鏡頭就變了臉，這就是所謂的人物漂移。Jellyfish 面對這個問題的切入點很具體：它要你在開工前先把全局風格與種子定下來，讓後續分鏡有個共同基準，而不是每個鏡頭各自隨機；角色、場景、道具、服裝這些素材建成可重複引用的資產卡，每張卡帶標籤與參考圖，分鏡用到某個角色時直接引用那張卡，對應的提示詞與參考條件就一起帶上，省去每次重打；分鏡的粒度也做得更細，頭尾關鍵幀能各自下獨立提示詞。

但這套做法的成效要有合理的期待。Jellyfish 把「一致性」當成一等公民來設計，確實能降低漂移發生的頻率，可它改變不了一個事實：當前的 AI 影片模型在角色一致性上，本質上還是個沒有完美解的問題。同一個角色在不同鏡頭、不同模型之間能維持多像，最終取決於你接的模型能力與你下的提示詞功夫，工具能做的是把這些素材管理好、讓你少重複勞動，而不是保證零漂移。把它當成「大幅減少手動縫合」的助手，會比期待它「根治漂移」來得實際。同樣在拆解 AI 影片製作流程的，可以對照 Violin 把 AI 影片翻譯拆成四段、逐段挑模型 的做法。

再深入一點看它的資產庫設計。Jellyfish 把角色、場景、道具、服裝分開管理，每個資產可以帶上標籤與參考圖，分鏡要用某個角色時直接引用那筆資產，系統就會把對應的提示詞與參考條件一起帶上，不讓你每次從空白打起。這套設計對角色多、場景切換頻繁的長篇短劇特別有感，因為真正讓人頭痛的從來不是生成一張好看的圖，而是連續幾十個鏡頭都要讓觀眾認得出這是同一個人、同一個場景。把素材顆粒化、可複用、可追蹤，就是它面對一致性這個老大難問題時務實的工程回答，它沒有發明新演算法，發明的是一套讓你少做苦工的資料結構。

5138 顆星很亮眼，但開發停在 2026 年 4 月

這是最需要誠實講的一點。Jellyfish 在 GitHub 上有超過五千顆星，看起來是個熱門專案，但它的主分支最後一次更新停在 2026 年 4 月 20 日，最新一個發布版本是 4 月 17 日的 v0.3.2，距離現在已經超過三個月沒有新動靜。與此同時，issue 列表上還有 6、7 月才提的新問題，例如有人反映資產管理的圖片生成會失敗、有人想要模型配置教學，這些都還掛著沒有回應。

這不代表專案一定被棄坑，畢竟很多開源作者會週期性批次處理；但對要把工作流架在自己產品裡的團隊來說，一個三個月沒更新、問題堆著沒回的專案，風險要算進去。AI 影片模型這一兩年迭代極快，Kling、Runway、Luma 的 API 規格常常變動，一個停滯的編排層很快就會跟最新模型對不上。要用的話，把它當成「可以 fork 來改的起點」會比當成「持續維護的現成方案」穩當，並且務必先翻一下 issue 區，感受一下維護者的回應節奏。

具體可以做的檢查不複雜：翻一下最近半年的提交紀錄看節奏、看 issue 區有沒有人掛了兩三個月沒回、再看 fork 數與衍生專案是否還有人在維護。這幾個訊號合起來，大概就能判斷它是「作者在忙、遲早回來」，還是「已經實質停滯」。對 Apache-2.0 這種寬鬆授權的專案來說，真要長期用，最穩的做法往往是 fork 一份自己維護，把模型對接與分鏡流程改成自己的版本，把上游當成靈感來源，而不是依賴對象。

Pin

Apache-2.0、FastAPI 加 Docker，技術棧與部署門檻

授權與技術棧這一面相對正面。Jellyfish 採 Apache-2.0，是相當寬鬆、商業友善的條款，比 AGPL 那類強 copyleft 自由得多，企業拿來改作、嵌入產品的顧慮較低。它的後端是 FastAPI、前端是 React 加 Vite，並且提供了 Docker 映像檔。順帶澄清一個常見誤解：有些介紹文章會說它沒有一鍵部署包，但倉庫其實有打包 Docker 映像檔，容器化部署是做得到的，沒那麼克難。

不過自己拉起來跑仍要懂一點前後端工程，部署時有一些容易踩的小坑。例如它的前端型別是跟著後端的介面規範同步產生的，所以後端要先正常啟動，再去前端跑一次同步，否則前端會連續報錯；這類細節對有技術背景的人只是個關卡，對純創作者就是一道門檻。同樣是 Apache-2.0、可自己架的開發工具，可以對照 Data-Analysis-Agent 用自然語言查資料庫 的定位。

順帶一提，社群還有人基於它拉出一個給 Ubuntu 用的 headless 命令列版本，讓不想開瀏覽器、想在伺服器上跑批次的人多一個選擇。不過那屬於第三方衍生，更新節奏跟不上主專案，拿來當無人值守的批次腳本可以，當主力部署來源就不太牢靠。

適合誰，以及先想清楚再投入

Jellyfish 真正順手的對象，是有技術背景、想摸索 AI 短劇量產流程的小團隊或獨立創作者。他們的痛點不是不會用 AI 模型，而是受夠了在劇本工具、繪圖工具、影片模型之間手動縫合，需要一個地方把劇本、分鏡、角色資產、生成任務統一管起來。對這群人，Jellyfish 提供了一個值得參考、甚至 fork 來改的架構起點，尤其是它把長時間的生成任務做成可追蹤、可取消、可恢復的非同步任務系統，這個工程細節對量產場景很實用。

把上面這些條件合起來看，Jellyfish 現階段更像一個給你參考、甚至 fork 來改的架構起點：它的分鏡渲染成熟度、模型相容性與維護活躍度，都要由你自己承擔，還沒到能直接扛起生產線的程度。如果你期待的是裝好就一鍵產出完整短劇，或需要官方持續維護的保證，它目前還給不了。把 AI 影片處理收進單一流程的同類思路，也可以看 deep-printfilm 把劇本、角色定妝、關鍵幀收進同一個專案，以及 MioSub 把 AI 字幕的轉錄、翻譯、壓制做成一條龍。

常見問題

Jellyfish 免費嗎？

本身開源免費（Apache-2.0）。但它背後的文字與影片模型都要走你自備的 API，跑越多、帳單越貴，那些費用是付給 OpenAI、Kling、Runway 這些服務，不是付給 Jellyfish。

它會自己生成劇本和畫面嗎？

不會。它負責的是把流程串起來、管理角色與分鏡資產、把任務派給外部模型再收回結果。實際產出文字與畫面的是你接的那些 API。

專案還在維護嗎？

截至 2026 年 7 月，主分支最後更新停在 2026 年 4 月，最新版本是 v0.3.2，之後三個月沒有新動靜，但 issue 仍有人在提。算是熱門但有停滯跡象，要用的話建議當成可 fork 改的起點，並先觀察維護者的回應節奏。

它能解決人物漂移嗎？

只能降低發生率，根治不了。工具這端靠的是風格鎖定加資產複用，但跨鏡頭像不像，最後還是看你接的模型檔次和下提示詞的熟練度。

非技術背景能用嗎？

目前不太適合。它需要自己準備 API Key、用 Docker 或本機跑前後端、還要懂一點 OpenAPI 同步的小手續，對純創作者是一道門檻，現階段更適合有技術背景、且有能力自己接 API 與排解部署問題的人。

如果你是有技術背景的創作者或小團隊，受夠了在多個 AI 工具之間手動縫合短劇，Jellyfish 提供了一個值得參考、也能 fork 來改的流程架構。但要帶著兩個認知裝它：你的劇本與畫面最終都送往雲端模型 API，費用自負；而且它的開發目前停在 2026 年 4 月，把它當實驗與借鏡很合適，當成有穩定維護的現成方案、尤其是要放進商業產品之前，就要三思。