告別「人工縫合」：開源AI 短劇工作流程Jellyfish 深度解析
在AI 影片創作領域，產生單一片段並不難，真正的挑戰在於如何維持故事的連貫性。目前的短劇創作模式大多依賴「手動抽卡」：在文字模型中撰寫劇本，在Midjourney 中透過墊圖嘗試，最後將素材丟進影片模型等待結果。
創作痛點： 角色在不同鏡頭間頻繁「變臉」（人物漂移），導致創作者不得不維護龐大的提示詞表格，在各個工具間反覆複製粘貼，將高效的AI 創作變成了低效的「賽博打螺絲」。
Jellyfish 旨在打破這種割裂感。作為一個開源項目，它不開發底層模型，而是建立一套整合工作流程，嘗試將劇本創作、分鏡設計、角色資產管理、視訊生成與後期剪輯串聯在同一套邏輯之下。
核心邏輯：如何解決人物漂移與流程割裂？
Jellyfish 的核心想法是將影片創作“積木化”，透過強化資產重複使用邏輯來降低隨機性：
- 全域風格錨定： 在專案創建階段鎖定統一的風格與種子值，最大限度減少分鏡間的視覺偏差。
- 雙層資產庫管理： 將預設的角色形象、關鍵裝備存入資產庫並標示。後續呼叫時直接檢索標籤，無需重複編寫冗長的Prompt。
- 精細化分鏡控制： 提供更直覺的分鏡編輯能力，例如支援為首尾關鍵影格獨立設定提示詞，提升畫面轉場的精準度。
適用環境與模型接取：
Jellyfish 不提供算力支持，使用者需自備API Key。其設計支援文字端對接 OpenAI、Claude 等模型，視訊端則相容 Kling、Runway、Luma 等主流服務。
Jellyfish 不提供算力支持，使用者需自備API Key。其設計支援文字端對接 OpenAI、Claude 等模型，視訊端則相容 Kling、Runway、Luma 等主流服務。
技術部署與避坑指南
對於希望透過原始碼部署的開發者，Jellyfish 的介面框架和模型管理模組已可運行，但在前後端聯調階段需注意以下細節：
關鍵步驟：同步前端介面
由於前端請求基於後端的OpenAPI 規範自動生成，若啟動後出現介面報錯，請先確認後端在
由於前端請求基於後端的OpenAPI 規範自動生成，若啟動後出現介面報錯，請先確認後端在
8000 連接埠正常運行，隨後在前端目錄下執行 pnpm run openapi:update 以更新類型文件。 注意事項： 根據官方Roadmap，核心的分鏡渲染鏈路仍處於開發中，且目前沒有提供一鍵部署套件。此專案現階段較適合技術團隊研究架構方向，尚未達到商業生產環境的成熟度。
商業觀點：流程優化的經濟價值
在高階視訊模型計費昂貴的今天，依賴「盲試」的創作方式會導致極高的廢片率，直接推高生產成本。
價值核心：成本控制
這類工作流程工具的真正意義在於透過「編排」來減少無效呼叫。如果參考圖復用和分鏡管理能順利落地，將大幅降低大量生產團隊的試誤成本。
這類工作流程工具的真正意義在於透過「編排」來減少無效呼叫。如果參考圖復用和分鏡管理能順利落地，將大幅降低大量生產團隊的試誤成本。
🚀 資源獲取通道
免責聲明： 本文介紹的Jellyfish 專案僅供技術研究與架構探討。該專案處於早期開發階段，非成熟商業工具。使用時請遵守原作者開源協議，並確保調用的第三方API（如Kling、OpenAI 等）符合當地法律法規及服務條款。
正文完
