Jellyfish

图1：Jellyfish 项目 Logo

一款正在悄悄改变短剧生产方式的 AI 工具

想象这样一个场景：你手头有一个 30 集微短剧的剧本大纲，传统制作方式意味着——找编剧拆解分镜、请美术设计角色和场景、带演员反复拍摄、后期剪辑合成，每集成本轻易破万，周期以月计。而 Jellyfish 试图把这整套流程压缩到一台电脑上完成。

由开发者 Forget-C 开源的 Jellyfish，是一个端到端的 AI 短剧创作工作流平台。它不只是一个「AI 生成图片」的工具，而是一套完整的内容生产线：剧本分析、分镜规划、角色/场景一致性管理、画面生成、视频合成、任务追踪，全部在一个界面里闭环。

图2：Jellyfish 项目概览界面

背景：微短剧赛道的爆发与生产瓶颈

2024 年以来，微短剧（竖屏短剧）成为内容消费的新风口。平台数据显示，精品短剧的付费转化率远超传统长视频，但产能瓶颈始终存在——专业团队制作一集 2 分钟的短剧，周期仍需 3-5 天。

AI 视频生成技术的快速成熟（Runway Gen-3、Kling、即梦等）给了行业一个答案，但生成能力的提升不等于生产效率的提升。真正的痛点在于：AI 生成的画面在多镜头之间容易失去一致性（同一角色在不同镜头里看起来像不同的人）、生成过程不可追踪（不知道任务跑到哪了）、以及生成结果难以复用（这组合好的提示词下次怎么调用）。

Jellyfish 正是为解决这三个问题而生：它把 AI 生成能力当作「基础设施」，在上层构建了一套完整的生产管理逻辑。

核心功能：五层能力覆盖短剧全流程

1. AI 剧本解析与分镜生成

用户输入章节剧本后，Jellyfish 的脚本处理 Agent 会自动完成以下工作：

• 将剧本拆解为独立的镜头（Shot）
• 提取每个镜头的角色（Character）、场景（Scene）、道具（Prop）、服装（Costume）和对白（Dialogue）
• 运行脚本优化和一致性检查，确保描述清晰无歧义

这一层的核心价值是结构化：把一段自然语言剧本变成机器可理解、可编辑的资产卡片，为后续的 AI 生成提供干净的输入。

2. 资产一致性管理系统

这是 Jellyfish 最有区分度的功能。系统维护了一套跨镜头的实体模型：

• 角色/演员：每个角色可上传参考图、设定描述，后续所有镜头共用同一角色
• 场景：场景图可复用，避免同一「古代宫殿」在不同镜头里风格突变
• 道具与服装：道具图和服装图同样纳入统一管理

图3：角色与资产统一管理界面，支持跨镜头复用

当 AI 生成镜头时，系统会优先使用已有的角色/场景图作为参考，确保风格一致。这直接解决了 AI 视频生成最大的体验痛点——「每次生成的画面风格都在飘」。

3. 分镜准备与确认工作流

镜头不是直接生成，而是走一个「提取 → 确认 → 就绪」的流水线：

剧本拆解 → 分镜候选提取 → 资产/对白候选确认 → 镜头就绪 → 生成工作区

每一张候选资产、每一句候选对白，都需要创作者明确接受或忽略。这不是「全自动化」，而是人机协同：AI 快速生成候选，人类做最终决策。

4. 统一异步任务中心

图像生成、视频生成都是长耗时任务，Jellyfish 接入 Celery + Redis 实现统一的任务调度：

• 任务状态实时追踪（等待中/执行中/完成/失败）
• 支持任务取消
• 从任务中心可直接跳转回对应的项目/章节/镜头上下文

每个生成任务完成后，结果自动写回资产库，不需要手动整理文件。

5. 模型与提示词基础设施

Jellyfish 内置了完整的多模型管理能力：

• 支持多 Provider（OpenAI、Anthropic 等）和多模型动态切换
• 提示词模板管理（图像、视频、镜头各有模板）
• 默认模型按类别预设，开箱即用
• 前后端通过 OpenAPI 契约通信，前端代码从 OpenAPI spec 自动生成

技术架构：LangGraph Agent + FastAPI + React

Jellyfish 的技术选型非常务实，没有过度设计：

后端：FastAPI 提供 RESTful API，Celery 处理异步任务，SQLAlchemy 管理数据模型。剧本解析逻辑基于 LangGraph（LangChain 的工作流框架）实现，将多个 Agent（脚本解析、资产提取、一致性检查等）串联成有向无环图，每个 Agent 专注单一任务，通过图结构协作。

前端：React 18 + TypeScript + Vite 构建，UI 库选用 Ant Design，样式用 Tailwind CSS。前后端完全解耦，前端通过 OpenAPI spec 自动生成类型安全的 API 调用代码。

存储：MySQL 9.0 存储结构化数据，RustFS（兼容 S3 API 的对象存储）管理媒体文件，Redis 做缓存和 Celery Broker。

部署：提供完整的多阶段 Dockerfile 和 docker-compose，一行命令启动全部服务。

部署体验：一条命令跑起来

cp deploy/compose/.env.example deploy/compose/.env
# 编辑 .env，填入 OPENAI_API_KEY 和存储配置
docker compose --env-file deploy/compose/.env -f deploy/compose/docker-compose.yml up --build

完成后：

• 前端：http://localhost:7788
• 后端：http://localhost:8000/docs（Swagger 文档）
• RustFS（文件存储）：http://localhost:9000

门槛：需要 NVIDIA GPU（CUDA 支持），显存建议 8GB 以上，因为图像/视频生成依赖本地 GPU 推理或远程 GPU API。没有 GPU 的用户也可以使用云端 API（OpenAI、Runway 等）。

局限与挑战

必须坦诚地说，Jellyfish 目前并非开箱即用的「一键成片」工具：

1. 视频生成依赖外部 API：Jellyfish 本身不实现视频生成模型，它通过统一的任务接口调用外部服务（如 Runway、Kling），因此需要额外的 API 费用。
2. 本地 GPU 不是免费的：如果想跑开源视频模型（如 CogVideoX），需要一台高配 GPU 机器，不是普通开发者的标配。
3. 上手需要一定学习成本：平台功能丰富，但文档目前只有英文和日文，中文社区资料较少。
4. 项目仍处于活跃开发阶段：末次提交为 2026-04-20，部分功能可能仍有 bug。

行业意义：从工具到平台的价值跃迁

Jellyfish 最有意思的地方，不在于它用了什么模型，而在于它的设计思路：把 AI 生成能力当作一种可编排的基础设施，而不是一个独立的工具。

当行业还在讨论「哪个 AI 视频模型最强」的时候，Jellyfish 的作者已经在思考：有了生成能力之后，怎么管理生成结果的一致性？怎么追踪生成任务的生命周期？怎么让创作者不是面对一堆散落的图片文件，而是面对一个结构化的内容资产库？

这种「生产管理」的思路，可能比任何单一模型更有长期价值。随着 AI 生成能力越来越强、越来越便宜，谁能把生成后的管理流程做好，谁就掌握了短剧工业化的下一张船票。

GitHub Stars 3714、Fork 685 的数据说明，有一批认真的创作者正在关注这个方向。Jellyfish 可能还不是最终答案，但它提出了正确的问题。