你做过 AI 视频吗？不是那种生成一段风景然后配个音乐就发朋友圈的。是正经剧本，几十个镜头，角色不能走着走着就换了张脸。
如果有，你一定懂那该死的”抽卡”。写好提示词，点生成，结果跟你脑子里想的差了十万八千里。重来，重来，再重来。一集 3 分钟的 AI 漫剧，手气差了能烧掉一天的算力和半年的耐心。行业里管这叫概率游戏，真实做内容的人管这叫”这破玩意没法量产”。
DramaClaw 就是冲着这个痛点来的。不是”又一个 AI 视频工具”，是从剧本解析到成片导出，整条线给你铺平。新飞 AI 实验室（Neo Flying AI Lab）把 AI 短剧制作里最难啃的三块骨头：角色身份一致性、空间场景稳定性、批量化生产效率，用一套工业流水线框架串了起来，然后全部源码可用、本地可部署地放到了 GitHub 上。
说到底这篇文章想讲明白一件事：这条”工业级”流水线到底靠不靠谱？什么样的人能从它身上薅到最多的羊毛？以及一个更重要的问题：当底层模型还在快速迭代，赌一套固定流水线框架是不是聪明。
DramaClaw 的架构思路上手就能摸到：它是一套模块化的微服务风格流水线，前端 React 管交互，后端 FastAPI 管调度，任务进程内执行（没有 Redis、Celery、Postgres 这些外部依赖）。整条链路不需要 GPU，推理走远程 OpenAI 兼容网关，一台普通笔记本就能跑起来。这种”轻部署”的策略很聪明，把复杂的模型部署问题外包给网关，自己专心做编排。
资产库先锁身份，线稿先兜底算力
DramaClaw 最核心的设计思路不是去卷模型精度，而是把 AI 视频最不稳定的环节，身份的跨镜头一致性，从概率问题变成工程问题。
怎么做？角色、场景、道具、声线各自建一份”档案”，就叫资产库。角色图生成后锁住，三视图出完锁住，后续所有镜头里的这个角色都从同一份引用源出图。做过连载的人都懂这意味着什么。画风飘、人物走形、场景穿帮，不是模型的问题，是模型没有记忆。资产生成之后锁住，这层”锁”比任何 Prompt 技巧都管用。
线稿先行是另一个让我觉得”对嘛，早该这么设计”的地方。正常 AI 视频工作流是你改需求后一遍遍跑全尺寸精渲染，算力烧到手软。DramaClaw 反过来：先出线稿草图，构图、角色位置、镜头意图确认了，再从线稿跑精细化渲染。多了一道工序，但把返工成本卡在了最便宜的阶段。很朴素的工程思路，但很多 AI 产品就是不肯拐这个弯，因为线稿环节对用户来说”多了一步”，产品经理不喜欢。
世界模型（Director World / 3GS）补了空间一致性的另一块缺口。你框出一个虚拟场景，摄像机可以在里面转，但桌椅板凳不会跟着变。上一镜女主在餐桌左边，下一镜她特写时，背景里的餐桌还在原地。不是什么黑科技，但它是 AI 长视频从”能看”到”能追”的那道分水岭。目前只有可选扩展 world 支持 GPU + CUDA 跑这层，标准流程用不上，有点可惜。
双轨工作流的设计也值得一句肯定。主流水线走标准流程：剧本进来，分镜生成，配音合成，成片输出，适合日更量产。无限画布（Freezone）是你憋大招的地方，节点式操作，某个镜头想精雕细琢，拖进去慢慢调。关键是调完能推回主线，两套系统不割裂。大部分 AI 创作工具的坑就在这：量产是一套系统，精修是另一套，搞到最后前后不搭，合成环节还得人肉对齐。DramaClaw 把这两条线收进了一个项目里，这件事本身比它当前能做到的精度更重要。
一条 docker compose up，从零到跑起来的坑都在这里
Docker 一把梭，不需要 GPU（标准流程走远程网关）：
git clone https://github.com/dramaclaw/dramaclaw.git
cd dramaclaw
cp .env.example .env
# 编辑 .env，设置 PROMPT_EXPORT_PASSWORD 为任意密码
docker compose up -d --build
想跳过编译直接用预构建镜像：
curl -LO https://raw.githubusercontent.com/dramaclaw/dramaclaw/main/docker-compose.release.yml
docker compose -f docker-compose.release.yml up -d
启动后访问 http://localhost:8080 进 Web UI。上传剧本（支持文件上传和直接粘贴文字），系统自动检测章节、提取角色，然后按流水线步骤推下去。
要留意的坑，我替你踩过了：
-
模型推理默认走远程网关，不跑本地模型。你必须配置 API Key 或使用自带网关，纯离线不可用 -
可选的 world扩展（体素/全景到 3D）需要 GPU + CUDA，标准流程不需要，别装错了白浪费时间 -
Docker 镜像首次 build 比较慢，直接拉 docker-compose.release.yml的预构建镜像更省事 -
.env里的PROMPT_EXPORT_PASSWORD必须设，否则 API 服务启动直接挂。值随便填，但不能空
支持的模型供应商覆盖了主流链：文本走 OpenAI 兼容网关（官方 Key 或自建），图像用 gpt-image 和 nano-banana，视频走 Seedance 1.0/1.5/2.0 和 happyhorse，配音是 IndexTTS2，故事图谱用 Cognee。这几个模型选型反映出团队的一个务实选择：不绑死任何供应商，但也不会为了”全开源”而牺牲质量。
什么场景值得装，什么场景趁早绕路
| 场景 | 典型用户 | 优势 | 局限 |
|---|---|---|---|
| AI 漫剧/短剧连载 | 小型动画团队、MCN | 资产库锁身份，线稿降返工成本 | 50 集以上资产膨胀，需自行管理存储 |
| 产品广告视频 | 电商运营、品牌方 | 风格模板一键套用 | 复杂产品细节（logo、特定包装）需手工修图 |
| 乙游/视觉小说 | 独立游戏开发者 | 分镜到配音全链覆盖 | 交互逻辑需外挂，仅出视频不出游戏 |
| 快速原型/Pitch Deck | 制片人、导演 | 线稿机制控成本 | 成片精度受底层模型制约，非 DramaClaw 可控 |
但以下三类场景建议直接绕路，别折腾：
-
你只是想生成一段 5 秒的 AI 视频发社交媒体。用 Runway 或 Pika 更省事，这条管线对你来说是对牛刀杀鸡 -
你的作品不需要角色身份一致性（比如抽象风格 MV）。DramaClaw 的资产库反而增加操作成本，起步就重了 -
你的团队没有技术背景配置 Docker 和 API Key。DramaClaw 不是 SaaS，它是一套需要自己拉下来部署的流水线系统
关于 3.2K Stars 和那个绕不开的 Bus Factor
| 指标 | 数据 | 说明 |
|---|---|---|
| Stars | 3,249（截至 2026-08-05） | 约 4 个月冲到 3.2k，AIGC 赛道中上水平 |
| 核心维护者 | 11 人 | Bus Factor 评估：中风险（commit 集中于 1-2 人） |
| Open Issues | 32 个 | Issue 平均关闭 0.9 天，处理速度极快 |
| 协议 | Elastic License 2.0 | 源码可用，自托管/二次开发均可。禁止打包成 SaaS 倒卖，企业需评估合规 |
这个仓库的社区健康度在 AIGC 赛道里属于中上。11 人维护团队对于一个 4 个月的项目来说阵容不小，但大部分 commit 集中在少数核心成员。0.9 天的 Issue 关闭速度很养眼，说明有人在认真盯反馈，不是那种丢个 README 就消失的”开源 KPI 项目”。
掘金社区有篇文章标题很直白：“开源漫剧流水线 DramaClaw：穿帮和量产这两件事，终于有人一起啃了”。评论区最多的声音是”终于有人把工业化这条路走了”。但也有人提到，Elastic License 2.0 的 SaaS 禁令让一部分想做托管服务的团队犹豫。这个协议选型本质上是在保护核心团队的商业化路径，对使用方来说不是好协议，但能理解。
DramaClaw 官网放了团队用自家管线制作的 6 部真实短剧，从《归灵司》到《乌龙仙途》，风格覆盖写实古装到国风奇幻。”吃自家狗粮”的展示方式比任何 benchmark 都有说服力。
不看模型看产线，DramaClaw 赌的是一个不一样的未来
DramaClaw 的底层逻辑不是”更好的 AI 视频生成器”，而是”AI 视频的工厂流水线”。这个区别比看上去大得多。
看一下当前的 AIGC 视频赛道。大头全在卷模型：Seedance 2.0 的画质提升了多少，Veo 的运镜比 Sora 自然了多少。这些很重要，但对一个要做连载的团队来说，模型精度的边际收益远不如流程稳定性。DramaClaw 看明白了这一点：不去卷模型，去卷产线。
但这个选择也决定了 DramaClaw 的天花板不在自己手上。它做的是编排，不是生成。成片的最终质量取决于接入的模型：文本靠 LLM，图像靠 SD/Seedance，配音靠 IndexTTS2。底层模型拉胯了，DramaClaw 只能把拉胯的过程变快、变稳，变不出魔术。
对比同类项目能更清楚地看到它的位置。waooAI（13.4k Stars）是商业 SaaS，功能多但不可自托管。inkos（8.3k Stars）偏小说生成和 IP 内容，视频是附加项。wind-comic 也是剧本到短剧管线，但依赖多云供应商集成。DramaClaw 的独特性在三点上：全本地可部署、资产库驱动的身份一致性、双轨工作流不割裂。
有一个风险没办法绕开：Bus Factor。11 人团队看着还行，但从 commit 分布来看，核心架构决策集中在 1 到 2 人手中。如果这些核心开发者的精力被其他项目牵走，DramaClaw 的迭代速度会直线下降。这不是推测，是开源项目的经典死法。做原创连载的团队如果把自己的管线押在一套依赖少数核心维护者的框架上，得先想好 Plan B。好消息是目前新飞 AI 实验室的公开信息显示团队处于扩张期，短期内核心维护者离场的概率不高，但这一点必须持续关注。
趋势上，我的判断是”谨慎看好”。赛道选对了（AI 视频工业化），切入点准（角色一致性和产线效率），开源策略聪明（Elastic License 2.0 既允许自由使用又防 SaaS 套壳）。但它面临一个快速变动的底层模型格局。如果明年 Seedance 3.0 或 Veo 2 能原生解决身份一致性问题，DramaClaw 的资产库设计就被釜底抽薪了。不用怕，但要心里有数。
资源地址
| 资源 | 地址 |
|---|---|
| GitHub | https://github.com/dramaclaw/dramaclaw |
| 官方主页 | https://dramaclaw.ai |
别等模型替你解决流程问题
如果你已经在跑 AI 短剧项目，被人物走形、场景穿帮、工具链碎片折磨到想摔键盘，DramaClaw 值得你花一个下午搭起来试试。从导入剧本开始，让它自动帮你拆角色、建资产库、出分镜草图。那条”抽卡”的痛苦循环，它至少能替你砍掉一半。
如果你还在观望，盯紧两个指标：一是核心维护者的近 30 天活跃度（别只看 commit 总数），二是 Elastic License 2.0 条款是否有调整迹象。前者决定项目会不会烂尾，后者决定你能不能放心用它做商业项目。
一个做了 4 个月的 AI 视频管线，在模型还在军备竞赛的时候，默默把工业化走到了这种程度，然后全部开源到 GitHub 上让所有人自建。这份判断力，比它的 Star 数更值得关注。