声明：本人是作者。
做过 AI 短剧的人，大概都见过这样两个镜头。
第 3 镜，男主左眉有一道疤，白衣，黑发。第 30 镜，疤没了，衣服变成米色，脸也像换了个人。提示词一个字没改。
后来我想明白一件事：AI 短剧的一致性，根本不是提示词问题，是依赖管理问题。
这是一篇长文，分三部分：
- 它是怎么一步步长出来的。一套成熟的短剧制作流程怎么变成软件，时间线全部来自 Git 提交记录。
- 一次讲透 AI 短剧是怎么做出来的，又为什么难。竖屏短剧的结构、出海的行业数据、生成链路、一致性为什么会崩、业内常见的几种解法，以及视频生成接口在成本、延迟和失败上的真实状况。不懂扩散模型也能看懂。
- 我的解法：7 个阶段、资产优先的架构，三条命令部署，外加一节诚实的“还做不好的地方”。
赶时间的话，直接跳到第三部分。
- 仓库：https://github.com/charliewwdev/OpenMontage
- 演示站：https://openmontage.dtok.io
第一部分：一个工作台是怎么长出来的
起点：生成一个镜头，和做完一集短剧
直觉上，这件事好像不难：模型已经能生成像样的 5 秒视频了，把剧本拆成镜头，一个个生成，再拼起来，不就是一部短剧吗？
可一旦动手就会发现，生成一个镜头和做完一集短剧，中间隔着一整个制片流程。
流程不用发明，短剧行业早就有了
这个制片流程，短剧行业早就有了，而且很成熟：先有剧本，再选角、定妆，然后定场景、备道具，接着画分镜、拍镜头，最后配音、剪辑。每一步交给下一步的都是确定的东西：定好的妆、搭好的景、备好的道具。没有哪个剧组会在每场戏开拍前重新描述一遍主角长什么样。
所以我做的事，说穿了不是发明一套新流程，而是把一套已经被短剧行业验证过的制作流程，原样搬进软件里，让 AI 去承担其中能承担的那部分活。Drama Studio 的 7 个阶段，剧本、角色、场景、道具、分镜/镜头、配音、剪辑，就是这条流程的一一对应。
反过来看，如果把每个镜头当成一次独立的请求，就很难做好短剧，问题往往不在模型够不够好。剧组靠定妆照和道具单记住“主角是谁、东西长什么样”，软件也得有同样的记忆：角色长什么样、场景在哪、哪个道具出现过，都得被记住，并且被每一个后续镜头引用。
23 天的提交记录
Drama Studio 的代码主要在仓库的studio/目录下。我翻了一遍这个目录的 Git 历史，把关键节点列在这里，日期取自提交记录和 GitHub Release（按 UTC 计）：
| 日期（2026） | 发生了什么 |
|---|---|
| 10 月 12 日 | studio/目录的第一批提交：短剧管线、工作台雏形，当天就做成了能部署的版本 |
| 10 月 13 日 | API 从 Python 标准库的 HTTP 服务迁到 FastAPI；把产品配置集中到一处，提交信息里写的是 “ban hardcoding”；加上一键进入的 Demo 用户 |
| 10 月 16 日 | 媒体队列改成持久化的；出视频之前先检查镜头提示词和台词、资产对不对得上；让定妆图任务排在视频任务前面，参考图失败就不再白白消耗视频生成 |
| 10 月 17 日 | 加了任务队列页面，用 WebSocket 实时刷新进度 |
| 10 月 26 日 | 发布 v0.1.0，第一个公开版本 |
| 11 月 1 日 | Docker Compose 一键部署，自带 MinIO，本地默认开演示登录 |
| 11 月 4 日 | 英文界面合并进主分支，界面可以中英文切换 |
截至 11 月 4 日，studio/目录一共有 103 次提交。
这张表里藏着踩过的坑。光看 10 月 16 日那几条提交信息就知道当时在解决什么：任务丢了要能接着跑，提示词写错了要在出片前发现，参考图不行就别急着生成视频。这些都不是模型层面的问题，而是一条生产线要能稳定运转必须补上的工程活。
为什么开源，为什么是 AGPL-3.0
Drama Studio 以 AGPL-3.0 协议开源。这个协议的意思很直接：你可以用、可以改、可以自己部署；但如果你把改过的版本做成网络服务给别人用，就得把源码也给到用户。
对一个需要自己部署、自己接模型 Key 的工具来说，代码公开也意味着你能看清楚每一步在做什么：提示词怎么拼、参考图怎么传、任务怎么排队。这些在下面的科普和架构部分我都会讲到。
好，故事先讲到这。下面进入正题：AI 短剧到底难在哪。
第二部分：科普，AI 短剧是怎么做出来的，又为什么这么难
1. 先认识竖屏短剧
竖屏短剧是为手机屏幕设计的剧集形态，画幅 9:16，单集很短，一部剧有很多集。它和传统影视最大的不同在于节奏是按“划走”来设计的：观众的拇指就悬在屏幕上，随时准备划到下一个视频。
所以竖屏短剧有几条几乎写进行规的结构：
- 前 3 秒钩子。开场就要抛出冲突、反转或者悬念，不铺垫。打脸、身份揭穿、一句狠话，都是常见的开法。
- 分集卡点。每一集结尾停在一个“接下来会怎样”的地方，让人点开下一集。
- 强情绪、快节奏。镜头切得快，台词短，人物关系一眼能看懂。
- 人物高度固定。观众记住的是“那个左眉有疤的男主”。一部剧几十上百个镜头，主角要始终是同一个人。
最后一条，正是 AI 生成最容易出问题的地方。
2. 短剧出海：数据怎么说
竖屏短剧不只是国内的生意。过去两年，一批中国公司做的短剧 App 在海外跑了出来，ReelShort（中文在线旗下[4]）和 DramaBox 是其中最常被提到的两个。下面的数字全部来自 Sensor Tower 的公开报告，注意它们的统计口径：只算 App Store 和 Google Play 的应用内购买估算，不含广告收入、第三方安卓商店和官网等其他渠道的付费[1]。
- 2025 年第一季度，全球短剧 App 的应用内购收入约 7 亿美元，2024 年第一季度是 1.78 亿美元[1]。
- 同一季度，ReelShort 和 DramaBox 的应用内购收入分别约 1.3 亿和 1.2 亿美元，在海外短剧 App 收入榜上排第一、第二；截至 2025 年 3 月，两者的全球累计应用内购收入分别约 4.9 亿和 4.5 亿美元[1]。
- 美国是收入最高的单一市场，2025 年第一季度约 3.5 亿美元，接近全球短剧 App 总收入的一半[2]。
- 2025 全年，Sensor Tower 在《State of Mobile 2026》里给出的数字是：短剧类 App 应用内购收入 29.8 亿美元，同比增长 115%[3]。
还有一个细节值得开发者注意。同一份 2025 年报告分析一款新秀 App 的增长时，提到的因素包括本地化、多语言字幕和高频更新[2]。换句话说，出海短剧拼的不只是剧本，还有把同一部剧快速做成多种语言版本的能力。
我要说清楚一点：这些数字描述的是整个行业，和 Drama Studio 没有任何关系。没有哪部爆款是用它做的，它也不能保证你的剧能火。我放这一节，是因为它解释了为什么“低成本、可重复地生产短剧”这件事值得用工程的方式认真对待。
3. 一条典型的 AI 短剧生成链路
把一部 AI 短剧拆开看，大致是这样一条链：
一句话想法 → LLM 写剧本（梗概、分集、每集的镜头和台词） → 文生图：生成角色定妆图、场景图、道具图（参考图） → 图生视频：带着参考图生成每一个镜头 → TTS：生成旁白和对白 → 剪辑：把镜头和声音排到时间轴上，导出成片每一环用的模型不同，擅长的事也不同：
- 大语言模型（LLM）擅长结构化写作。它能按要求把一个故事拆成集、把一集拆成镜头，给每个镜头写好景别、运镜、台词。它不碰像素。
- 文生图模型根据文字生成静态图。在短剧里，它最重要的产物不是成片画面，而是参考图：角色长什么样、场景什么光线、道具什么材质。
- 图生视频模型以一张或几张图作为条件，生成一段几秒钟的动态画面。参考图在这里决定了“画面里是谁”。
- TTS（文本转语音）把台词变成声音。
- 剪辑是最“传统”的一环，通常用 FFmpeg 这样的工具，把片段、配音、字幕合成一个文件。
看上去是一条流水线，但每一环的输出都会影响下一环，而且越往后越贵。
4. 一致性为什么会崩
这是全文最重要的一节。理解了它，你就理解了为什么“输入提示词、输出视频”的工具做不好短剧。
原因一：每次调用都是一次失忆
现在主流的图像和视频生成模型，大多是扩散模型。粗略地说，它从一团随机噪声出发，在文字（和图像）条件的引导下，一步步把噪声“去”成画面。
关键在于：模型本身不记得上一次生成了什么。第 3 镜和第 30 镜是两次独立的调用，模型并不知道它们属于同一部剧。你在第 3 镜里得到的那张脸，只是那一次随机过程的结果，没有任何东西保证第 30 镜会再得到它。
原因二：文字描述一张脸，本来就不够
“黑发、白衣、左眉有疤、二十多岁、眼神冷”，这段描述能对上的脸有无数张。文字是一种很“宽”的约束：它能限定类别，却很难精确限定身份。
而且模型对属性的理解并不总是精确的。属性多了以后，有的会被忽略，有的会张冠李戴，比如疤跑到了另一个人脸上，或者白衣变成了白发。
原因三：提示词漂移
真实的制作里，提示词不会一字不改。每个镜头要描述不同的动作、表情、景别和环境，为了写清楚这些，角色描述往往被压缩、改写或者省略。镜头越多，这种漂移越大。第 30 镜的提示词，可能早就不是第 3 镜那个版本了。
原因四：随机种子
扩散模型的初始噪声由随机种子决定。种子不同，同样的提示词也会得到不同的结果。固定种子能让“同样的输入得到同样的输出”，但短剧里每个镜头的输入本来就不同，固定种子并不能锁住一个角色的身份。
原因五：镜头内一致，不等于镜头间一致
视频模型在一段几秒的片段内部，通常能让人物保持稳定，这是模型本身在时间维度上做的事。但短剧需要的是跨片段一致：几十个独立生成的片段之间，人物、服装、场景、道具都对得上。这超出了单次调用的能力范围，必须由调用之外的系统来保证。
5. 业内常见的几种解法
既然单次调用管不了，大家就在调用之外想办法。常见的路子有这么几类，各有取舍。
参考图（图像条件）
最直接的办法：先为角色生成或挑出一张满意的定妆图，之后生成每个镜头时，把这张图作为条件一起交给模型。很多图生视频接口都支持传入参考图。
- 好处：不需要训练，接入成本低，换角色就是换一张图。
- 局限：参考图能拉住大方向，但不保证每个细节都完全一致；角色换了角度、表情、光线，仍然可能有偏差。
LoRA 微调
LoRA 是一种轻量的微调方法：用同一个角色的若干张图，训练一个很小的附加权重，让模型“学会”这个角色。之后生成时加载这个 LoRA，角色就更容易稳定。
- 好处：对单个角色的约束通常比单张参考图更强。
- 局限：要准备训练图、要训练时间和算力，每个角色都要单独训；一般需要你能控制模型权重，所以多用在自己部署的开源模型上，很多闭源的云端接口并不开放这个能力。
IP-Adapter 一类的图像提示适配器
这类方法不训练角色本身，而是给模型加一个适配器：把参考图编码成特征，通过注意力机制注入到生成过程里，相当于让模型“看着这张图画”。IP-Adapter 是其中比较有代表性的一个，社区里也有专门针对人脸身份的变体。
- 好处：不用为每个角色训练，即插即用。
- 局限：和底模、版本强相关，通常用在自己能改工作流的环境里，比如 ComfyUI。
首尾帧控制
一些视频模型允许你指定片段的第一帧，有的还能指定最后一帧。做法是：先生成（或挑出）关键帧，再让模型在帧与帧之间补出运动。相邻镜头之间，还可以拿上一个镜头的末帧去做下一个镜头的首帧，让衔接更顺。
- 好处：对画面的控制更直接，适合需要精确衔接的镜头。
- 局限：要先准备好关键帧，流程变长；对长距离（比如第 3 镜和第 30 镜）的一致性，仍然要靠关键帧本身是一致的。
这些方法的共同点
仔细看会发现，所有办法本质上都在做同一件事：把“角色是谁”从易变的文字里拿出来，变成一个稳定的、可以被反复引用的东西。可能是一张图，可能是一份权重，可能是一组关键帧。
这就是我前面说的“依赖管理”。
6. 视频生成的现实：贵、慢、会失败
除了一致性，做过的人还会撞上另外三堵墙。这里只讲定性的情况，具体价格和速度各家差别很大，也在不停变化，请以各厂商的官方说明为准。
贵。主流的高质量视频生成接口基本是按调用、按时长或按分辨率计费的。一集短剧要几十个镜头，再算上不满意要重来的次数，成本很快就上去了。所以“哪一步可以少重跑”直接等于省钱。
慢。生成一段几秒的视频，等待时间通常比生成一张图长得多，而且高峰期还要排队。如果前端一直挂着一个请求等结果，体验会非常糟糕。
会失败。失败的原因五花八门：内容审核拦截、超时、限流、参考图不合格、返回的画面明显不对。在批量生成几十个镜头时，偶发失败几乎是必然的。
这三点合起来，意味着一个短剧工具必须做到：异步执行、单点重试、尽量在花大钱之前发现问题。
7. 把问题对上解法
把上面的问题整理成一张表，就是我设计 Drama Studio 时的需求清单：
| 问题 | 根因 | 系统层面要做的事 |
|---|---|---|
| 角色换脸 | 每次调用独立，文字约束太宽 | 角色先做成资产，用参考图约束每个镜头 |
| 场景、道具对不上 | 同上，且常被提示词省略 | 场景、道具也做成独立资产，镜头显式引用 |
| 提示词漂移 | 每个镜头的描述各写各的 | 镜头只引用资产，生成前检查提示词有没有写错写丢 |
| 改一处要整集重来 | 没有状态，没有版本 | 每一步的产物入库，带版本，可回退可重跑 |
| 贵、慢、会失败 | 视频接口的天然属性 | 异步队列、单镜头重试、便宜的步骤排在贵的步骤前面 |
第三部分：我的解法
核心思路：把角色当成依赖，而不是描述
写代码的人都懂这个道理：你不会在每个文件里把一个函数复制一遍，你会 import 它，并且锁住版本。
短剧也一样。在每个镜头的提示词里反复写“黑发、白衣、左眉有疤”，相当于把同一段代码复制粘贴三十次，然后祈祷每次编译结果一致。
我的做法是反过来：
- 角色、场景、道具先单独做成资产。每个资产生成一张参考图，人工确认一次，保留版本历史。
- 镜头只引用资产。生成镜头时，把资产库里的参考图和镜头提示词一起交给视频模型。
- 改资产就是升版本。下游镜头知道自己引用的是哪一版，回退、重跑都有依据。
规则只有一条：下游只读上游的产物，不读上游的提示词。
7 个阶段，每一步都有产物
这 7 个阶段对应的就是短剧实际的制作顺序：剧本 → 选角定妆 → 场景 → 道具 → 分镜 → 配音 → 剪辑。区别只在于，每一步的产物都被存成了可以引用、可以回退的数据。
| # | 阶段 | 产物 |
|---|---|---|
| 1 | 剧本 | 题材、画幅、视觉风格、梗概，分集剧本（可续写、重写、锁定） |
| 2 | 角色 | 定妆参考图（Seedream，或你自己的 ComfyUI），保留版本历史 |
| 3 | 场景 | 空间、光线设定和场景概念图 |
| 4 | 道具 | 关键道具和材质细节 |
| 5 | 分镜/镜头 | LLM 拆镜头，Seedance 结合角色、场景、道具参考图生成每个镜头 |
| 6 | 配音 | 旁白和对白 TTS（默认 edge-tts，也能换成 OpenAI 兼容的语音接口） |
| 7 | 剪辑 | 在时间轴上排片段，FFmpeg 导出整集 |
界面上，1 到 4 各占一个标签页，5 到 7 合在“工作台”里按片段一起做，所以你在顶栏会看到 8 项。
一个小细节：花钱之前先查一遍
第二部分说过，视频生成贵且会失败。所以在真正调用视频模型之前，Drama Studio 会先过一道检查，代码在studio/server/prompt_consistency.py。它不额外调用模型，只做确定性的规则检查：
- 台词里说话的角色，必须出现在镜头提示词里；
- 台词提到了一个看得见的证据，比如伤疤、戒指、信，提示词里就必须让它出现在画面上；
- 台词没提到的道具，比如手机、屏幕，不能抢了镜头；
- 提示词里用
@名字引用的角色、场景、道具，必须在资产库里真实存在。
还记得开头那道疤吗？如果台词里说到了疤，而提示词把它写丢了，这一步就会拦下来，而不是等视频生成完再发现。
同样的思路也用在任务排序上：队列会让定妆图这类静态图任务先跑，参考图不合格，就先回头出图，不急着出片。studio/server/job_queue.py里有一句注释说得很直白：参考图失败，片子就过不了质检。
架构：每个组件对应一个痛点
React UI (studio/src) │ ▼ FastAPI (studio/server) ──▶ PostgreSQL (projects · studio_kv · meta) │ └──────▶ Redis (media job queue) └──▶ MinIO / S3 (inspire · media blobs)PostgreSQL 管状态，对付“改一处要整集重来”。剧本、资产、镜头、版本都是结构化数据。任何一步都能回退、重跑、切换版本，改一个角色不用整集重来。
Redis 队列管媒体任务，对付“贵、慢、会失败”。图像和视频请求丢进队列，由单独的 media worker 执行，前端只看任务状态，任务队列页面会实时刷新进度。一个镜头失败，只重试那一个。
MinIO / S3 管文件。参考图、镜头视频、成片都放对象存储，数据库只存引用。
一个 YAML 管流程。导航、工作台阶段、工具和文案集中在studio/config/platform.yaml。想加一个阶段或改名字，不用满前端找字符串。界面的中英文文案也走配置。
模型可插拔。文本模型走 OpenAI 兼容接口，DeepSeek、OpenAI、Claude、Gemini、通义、豆包、Kimi、GLM、MiniMax、OpenRouter 都能接，在“模型配置”里按账号设置，支持连接测试和热加载。图像也可以接你自己的 ComfyUI，如果你习惯在 ComfyUI 里用 LoRA 或 IP-Adapter，那是你自己工作流的事，Drama Studio 只负责调用和管理产物。
| 路径 | 内容 |
|---|---|
studio/ | 前端和 API |
studio/config/platform.yaml | 导航、阶段、工具、文案 |
pipeline_defs/·skills/ | Agent 管线和导演技能 |
lib/·tools/ | 工具注册 |
跟着一个项目走一遍
下面用演示站里的项目《天帝归位》，把流程走一遍。
1. 一句话起项目。在创作 Agent 里输入“10 集复仇爽剧，9:16，前 3 秒要有钩子”。Agent 会定好题材、集数、画幅，并检查哪些模型已经配好。也可以直接上传自己写的剧本。
2. 剧本定稿。先定底稿，再按集、按镜头分条写。定稿后还能续写或重写，锁定的部分不会被误改。
3. 做资产。每个角色一张定妆参考图，每个场景一张空镜参考图。提示词随时能看、能改，改完就是新版本。
4. 分镜工作台。这是“依赖”真正起作用的地方。资产库里的角色、场景、道具直接引用进镜头，景别、运镜、台词一镜一镜写清楚，再交给 Seedance 生成。
5. 配音和剪辑。在时间轴上点一下切换片段，点播放直接预览配好音的片段，最后导出整集。
6. 从上往下看全局。七个阶段也能放到无限画布上用节点图看，节点颜色就是进度。
不想一步步点的话，可以让 Agent 在后台把整条线跑完，你再回头挑某一步重跑。因为每一步都有产物，重跑的成本只落在那一步上。
一个假设的场景：海外短剧小团队怎么用
以下是假设的使用流程，用来说明 7 个阶段怎么串起来，不是真实案例，也不代表任何效果承诺。
假设你是一个想做海外短剧的小团队：一个人写剧本，一个人管画面，目标是面向北美观众的一部英文竖屏短剧。一集会这样走过 7 个阶段：
- 剧本。在创作 Agent 里用中文把想法说清楚，比如“霸总甜宠，9:16，女主是咖啡店店员，第一集结尾揭穿男主身份”。Agent 定好题材、集数和画幅。你可以要求文本模型把分集剧本和台词写成英文，团队再逐集审稿、改稿，确认后锁定。
- 角色。为男女主各出一张定妆参考图，按目标观众调整长相、服装和妆容，满意了就确认这一版。之后每个镜头都引用它。
- 场景。咖啡店、写字楼大堂、夜景街道，各出一张空镜参考图，定好光线。
- 道具。第一集的关键道具，比如一张写着名字的工牌，单独做成资产。台词里提到工牌，生成前的检查就会要求镜头提示词里写到它。
- 分镜/镜头。在工作台里一镜一镜排：景别、运镜、英文台词。资产库里的角色、场景、道具引用进来，再交给 Seedance 生成。某个镜头失败或不满意，只重跑那一个。
- 配音。这一步要提前说清楚：默认的 edge-tts 配置里，角色音色目前是中文音色，旁白音色可以通过
EDGE_TTS_VOICE换掉。做英文剧，更稳妥的做法是接一个 OpenAI 兼容的语音接口来出英文配音。 - 剪辑。在时间轴上排好片段，预览，导出整集。
整个过程里，团队里习惯中文的人可以用中文界面，合作的海外同事可以在界面上切到英文。界面语言和剧的语言是两件事：界面切换管的是按钮和菜单，剧本、台词这些内容是你自己写进去的。
想再出一个西班牙语版本？角色、场景、道具这些资产已经在库里了，主要是重做台词、配音和需要重生成的镜头。这正是资产优先的设计想省下的那部分工作。至于具体能省多少，取决于你的剧本和镜头，我不想给你一个编出来的数字。
三条命令跑起来
gitclone https://github.com/charliewwdev/OpenMontage.git&&cdOpenMontagecpstudio/.env.example .env# 填上你的模型 Key，其他用默认值dockercompose-fdocker-compose.studio.yml up--build打开 http://localhost:8787，本地默认开着演示登录，点 Demo 就能进。健康检查是GET /api/health。
开跑之前，先看清楚 Compose 帮你带了什么、没带什么：
docker-compose.studio.yml里有吗？ | |
|---|---|
| Studio（UI + API）和 media worker | ✅ 从仓库构建 |
| PostgreSQL 16 | ✅ |
| Redis 7 | ✅ |
| MinIO 对象存储 | ✅（也可以换成自己的 S3） |
| 文本大模型 Key | ❌ 自己提供 |
| 图像 + 视频生成 | ❌ 自己提供火山方舟 Key（Seedream / Seedance，付费 API）；图像也可以接自己的 ComfyUI |
| TTS | 默认 edge-tts，不需要 Key |
两句提醒：MinIO 默认账号是 minioadmin，演示登录默认开启，放到公网前一定改密码，按需关掉演示登录（STUDIO_DEMO_ENABLED）。部署到服务器时，STUDIO_PUBLIC_URL、API_BASE_URL、MINIO_*换成你自己的。模型费用直接付给模型厂商。
它现在还做不好的地方
这一节我写得比别的都认真，因为你迟早会自己发现。
- 成本不低。视频和图像依赖付费的 Seedance / Seedream，一集的花费取决于镜头数和时长。建议先拿三五个镜头试水，再决定要不要整集跑。
- 参考图不是银弹。第二部分讲过，参考图能拉住大方向，但角度、表情、光线变化大的时候，细节仍然可能偏。现在的做法是靠资产确认和生成前检查把问题尽量拦在前面，不能保证每个镜头都完美。
- 失效传播还比较粗。改了剧本以后，下游哪些镜头要重做，现在主要靠阶段状态和版本来管。真正细到“这一句台词只影响这两个镜头”的依赖追踪，还没做。
- 多语言还不完整。界面能中英文切换，但内置的 edge-tts 角色音色目前是中文的，做外语剧的配音最好接外部语音接口；系统内部的部分提示词和文档也还是中文。
- 质检提示有点吵。会标出一些其实能用的片段，正在调。
- 部署门槛不算低。要自己准备服务器和模型 Key。如果你只是想看看，先去演示站逛一圈更省事。
这是 v0.1.0。我更愿意让你带着准确的预期来试，而不是带着失望走。
协议和下一步
项目以AGPL-3.0协议开源。如果你把修改后的版本作为网络服务提供给别人用，AGPL-3.0 第 13 条要求你向用户提供源码。
如果你在做 AI 短剧、出海短剧，或者只是对视频生成的工程问题感兴趣，欢迎来试试。
我也很想听听你是怎么解决一致性的。参考图、LoRA、IP-Adapter、首尾帧，还是别的路子？评论区聊，或者直接开 issue，踩到的坑和想要的功能我都会看。
- 仓库：https://github.com/charliewwdev/OpenMontage
- 演示站：https://openmontage.dtok.io
参考资料（数据均为第三方估算，访问于 2026 年 11 月）
- Sensor Tower，《State of Short Drama Apps 2025 Report》，2025 年：https://sensortower.com/blog/state-of-short-drama-apps-2025
- Sensor Tower，《State of Short Drama Apps Overseas 2025 Report》（PDF），2025 年：https://downloads.ctfassets.net/vfkpgemp7ek3/6cNlWw8314o8FX2cNa1OlE/14111704149f364f862ad9650f395bc5/State_of_Short_Drama_Apps_Overseas_2025_Report.pdf
- Marketing Dive，《Microdrama apps stand out on mobile: Here’s what the numbers say》，2026 年 2 月 20 日，引用 Sensor Tower《State of Mobile 2026》：https://www.marketingdive.com/news/microdrama-apps-stand-out-on-mobile-heres-what-the-numbers-say/812610/
- 电影界，《2025短剧出海：头部吃肉，腰部喝汤，还是全员内卷？》，2025 年 9 月 18 日：https://www.dianyingjie.com.cn/2025/0918/396942.shtml
