第 3 镜和第 30 镜，主角换了一张脸：讲透 AI 短剧的一致性难题，和我做开源短剧工作台的经过

charlieww
1 阅读25分钟

做过 AI 短剧的人，大概都见过这样两个镜头。

第 3 镜，男主左眉有一道疤，白衣，黑发。第 30 镜，疤没了，衣服变成米色，脸也像换了个人。提示词一个字没改。

后来我想明白一件事：AI 短剧的一致性，根本不是提示词问题，是依赖管理问题。

这是一篇长文，分三部分：

  1. 它是怎么一步步长出来的。 一套成熟的短剧制作流程怎么变成软件，时间线全部来自 Git 提交记录。
  2. 一次讲透 AI 短剧是怎么做出来的，又为什么难。 竖屏短剧的结构、出海的行业数据、生成链路、一致性为什么会崩、业内常见的几种解法，以及视频生成接口在成本、延迟和失败上的真实状况。不懂扩散模型也能看懂。
  3. 我的解法：7 个阶段、资产优先的架构，三条命令部署，外加一节诚实的“还做不好的地方”。

赶时间的话，直接跳到第三部分。

第一部分：一个工作台是怎么长出来的

起点：生成一个镜头，和做完一集短剧

直觉上，这件事好像不难：模型已经能生成像样的 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 它，并且锁住版本。

短剧也一样。在每个镜头的提示词里反复写“黑发、白衣、左眉有疤”，相当于把同一段代码复制粘贴三十次，然后祈祷每次编译结果一致。

我的做法是反过来：

  1. 角色、场景、道具先单独做成资产。 每个资产生成一张参考图，人工确认一次，保留版本历史。
  2. 镜头只引用资产。 生成镜头时，把资产库里的参考图和镜头提示词一起交给视频模型。
  3. 改资产就是升版本。 下游镜头知道自己引用的是哪一版，回退、重跑都有依据。

规则只有一条：下游只读上游的产物，不读上游的提示词。

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 会定好题材、集数、画幅，并检查哪些模型已经配好。也可以直接上传自己写的剧本。

创作 Agent转存失败，建议直接上传图片文件

2. 剧本定稿。 先定底稿，再按集、按镜头分条写。定稿后还能续写或重写，锁定的部分不会被误改。

剧本转存失败，建议直接上传图片文件

3. 做资产。 每个角色一张定妆参考图，每个场景一张空镜参考图。提示词随时能看、能改，改完就是新版本。

角色定妆转存失败，建议直接上传图片文件

4. 分镜工作台。 这是“依赖”真正起作用的地方。资产库里的角色、场景、道具直接引用进镜头，景别、运镜、台词一镜一镜写清楚，再交给 Seedance 生成。

分镜工作台转存失败，建议直接上传图片文件

5. 配音和剪辑。 在时间轴上点一下切换片段，点播放直接预览配好音的片段，最后导出整集。

6. 从上往下看全局。 七个阶段也能放到无限画布上用节点图看，节点颜色就是进度。

无限画布转存失败，建议直接上传图片文件

不想一步步点的话，可以让 Agent 在后台把整条线跑完，你再回头挑某一步重跑。因为每一步都有产物，重跑的成本只落在那一步上。

一个假设的场景：海外短剧小团队怎么用

以下是假设的使用流程，用来说明 7 个阶段怎么串起来，不是真实案例，也不代表任何效果承诺。

假设你是一个想做海外短剧的小团队：一个人写剧本，一个人管画面，目标是面向北美观众的一部英文竖屏短剧。一集会这样走过 7 个阶段：

  1. 剧本。 在创作 Agent 里用中文把想法说清楚，比如“霸总甜宠，9:16，女主是咖啡店店员，第一集结尾揭穿男主身份”。Agent 定好题材、集数和画幅。你可以要求文本模型把分集剧本和台词写成英文，团队再逐集审稿、改稿，确认后锁定。
  2. 角色。 为男女主各出一张定妆参考图，按目标观众调整长相、服装和妆容，满意了就确认这一版。之后每个镜头都引用它。
  3. 场景。 咖啡店、写字楼大堂、夜景街道，各出一张空镜参考图，定好光线。
  4. 道具。 第一集的关键道具，比如一张写着名字的工牌，单独做成资产。台词里提到工牌，生成前的检查就会要求镜头提示词里写到它。
  5. 分镜/镜头。 在工作台里一镜一镜排：景别、运镜、英文台词。资产库里的角色、场景、道具引用进来，再交给 Seedance 生成。某个镜头失败或不满意，只重跑那一个。
  6. 配音。 这一步要提前说清楚：默认的 edge-tts 配置里，角色音色目前是中文音色，旁白音色可以通过 EDGE_TTS_VOICE 换掉。做英文剧，更稳妥的做法是接一个 OpenAI 兼容的语音接口来出英文配音。
  7. 剪辑。 在时间轴上排好片段，预览，导出整集。

整个过程里，团队里习惯中文的人可以用中文界面，合作的海外同事可以在界面上切到英文。界面语言和剧的语言是两件事：界面切换管的是按钮和菜单，剧本、台词这些内容是你自己写进去的。

想再出一个西班牙语版本？角色、场景、道具这些资产已经在库里了，主要是重做台词、配音和需要重生成的镜头。这正是资产优先的设计想省下的那部分工作。至于具体能省多少，取决于你的剧本和镜头，我不想给你一个编出来的数字。

三条命令跑起来

git clone https://github.com/charliewwdev/OpenMontage.git && cd OpenMontage
cp studio/.env.example .env        # 填上你的模型 Key，其他用默认值
docker compose -f docker-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，踩到的坑和想要的功能我都会看。

参考资料（数据均为第三方估算，访问于 2026 年 11 月）

  1. Sensor Tower，《State of Short Drama Apps 2025 Report》，2025 年：sensortower.com/blog/state-…
  2. Sensor Tower，《State of Short Drama Apps Overseas 2025 Report》（PDF），2025 年：downloads.ctfassets.net/vfkpgemp7ek…
  3. Marketing Dive，《Microdrama apps stand out on mobile: Here's what the numbers say》，2026 年 2 月 20 日，引用 Sensor Tower《State of Mobile 2026》：www.marketingdive.com/news/microd…
  4. 电影界，《2025短剧出海：头部吃肉，腰部喝汤，还是全员内卷？》，2025 年 9 月 18 日：www.dianyingjie.com.cn/2025/0918/3…
avatar
文章
阅读
粉丝