三十个镜头不崩人物：把角色当资产依赖的短剧流程

一集三十个镜头已经不是演示，而是生产，而生产会把一次成功生成所掩盖的问题全部暴露出来：第三场戏里左眉上方的那道疤，到第十四场就没了；外套在咖啡馆和街边换了颜色；台词里反复提到的那封信，画面里始终没出现。可用的解法是：不要再在每一次请求里用文字描述主角，而是把他变成可版本化的资产依赖——人物、场景和道具先各生成一张参考图，由人确认一次，再带上版本号，每个镜头只引用某个具体版本。同时在每次付费的视频调用之前跑一遍便宜的确定性检查，完全不额外调用模型：台词里写了疤而镜头描述里没有，这一场就在扣钱之前被拦下。下面用七个阶段把这个流程拆开讲，包括架构和它的真实边界。

依据是开源工作室 OpenMontage 的作者 2026 年 11 月 5 日发在 dev.to 上的实践复盘：Keeping AI characters consistent across a 30-shot short drama。以下是我的转述，加上来自我们站点统计的数字。

为什么同一个女主角会变成三个不同的人

原因正好五个，而且都是技术原因，不是「模型不行」。

• 每次调用都没有记忆：视频模型不记得上一个镜头，凡是没有重新传入的东西，全都交给随机。
• 文字描述脸太弱：「二十出头、黑色长发、左眉上方有疤」能对上几百万人。
• 描述会漂移：让语言模型连写三十条镜头描述，细节会被改写、缩写、漏掉。
• 随机种子：同样的描述换个种子就是另一个人。
• 单个镜头内的一致，不等于跨镜头的一致。前者模型已经做得不错，后者是你自己的活。

由此得出一个不太舒服的结论：集数越长，越不值得死磕单个画面。更划算的做法是一次性把「同一个主角」定义清楚，并且把它当数据存起来，而不是当成一段文字。

常见方案，以及它们卡在哪里

• 参考图。先定一张肖像，之后每个镜头都带上。简单、到处都支持，但角度、表情或光线变化大时细节还是会滑。
• 给角色训练适配器。约束更强，但要训练时间、数据，还得能控制模型本身。
• 基于参考图的适配器。把参考图编码后注入注意力层，不必为每个角色单独训练。
• 首尾帧控制。把镜头的开头和结尾钉住，有助于把相邻镜头接上。

这四种做的是同一件事：给模型一个比文字更稳的东西。但它们都回答不了「这是不是我们上次定下来的那一版主角」，也挡不住在生成之前就能看出来的错误。

七个阶段，每个阶段都留下产物

1. 剧本。题材、画幅、风格、梗概、各集正文；一集可以续写、重写或锁定。
2. 人物。参考肖像，带版本：发型变了，版本号就往上加。
3. 场景。空间与光线，一张场地概念图。
4. 道具。关键物件与材质，也就是台词里提到、画面上必须看得见的东西。
5. 分镜。语言模型把一集拆成镜头，视频模型带着资产参考逐镜生成。
6. 配音。对白与旁白。
7. 剪辑。时间线与导出。

关键在于引用关系：镜头不是「描述」女主角，而是引用一个资产和它的版本。换了肖像就能看到哪些镜头还建立在旧版本上、哪些必须重做；回滚和重跑也有依据，这是文字描述给不了的。我们自己站点的视频生成也是类似的思路：同一个镜头可以重新拼一次，这属于正常工作，而不是事故。

零成本、却保住一次昂贵生成的检查

在任何视频请求之前，工作室会跑 prompt_consistency.py：一组确定性规则，不额外调用任何模型，所以便宜。

• 台词里说话的每个角色，都必须出现在镜头描述里；
• 台词提到看得见的证据——疤、戒指、信——就必须出现在画面里；
• 台词没说到的物件，不该抢走这个镜头；
• 每个按名字引用的人物、场景、道具，必须真的在资产库里。

台词里有疤、描述里没写，这一场就在付费之前被拦住。第二层是排队顺序：静态图片任务（包括参考肖像）排在视频任务之前，先修好糟糕的参考图，而不是让它去烧视频生成额度。

架构：四个部分，没有魔法

• 关系型数据库。剧本、资产、镜头和版本都是结构化数据，所以任何阶段都能回滚或重跑，而不必重做整集。
• 任务队列。媒体任务排队，由独立的工作进程执行，界面只通过 WebSocket 看状态。一个镜头失败，只重试这一个。
• 对象存储。参考图、片段和成片放在这里，数据库里只存指针。
• 一个 YAML 文件描述整条流程：阶段、工具、界面文案。改一个阶段名只需改一处，不必在前端里到处找字符串。

怎么跑起来

三条命令：克隆仓库、复制配置示例、用 compose 起服务。之后打开本地地址，用 GET /api/health 做健康检查。

git clone https://github.com/charliewwdev/OpenMontage.git && cd OpenMontage
cp studio/.env.example .env
docker compose -f docker-compose.studio.yml up --build

compose 里已经有界面、服务端、媒体工作进程、数据库、队列和对象存储。没有的：语言模型密钥、付费的图片与视频生成密钥（图片也可以换成你自己的部署）。语音合成默认不需要密钥。作者提醒，对外公开之前务必改掉对象存储的默认凭据并关闭演示登录。许可证是 AGPL-3.0：如果把修改版作为网络服务提供，需要向用户提供源码。

错一次要多少钱：我们的数字

预检的价值只在钱上看得清楚。按我们站点的生成成本表，2026 年 10 月 6 日到 11 月 5 日，2146 次视频生成平均每次 0.442 美元，14344 次图片生成平均每次 0.035 美元。差了十二倍以上，所以「先出图、再出视频」不是审美偏好，而是省钱。

视频模型之间的差距更大：同一窗口里，229 次 Seedance 2.5 生成平均每次 2.137 美元，而 148 次 Seedance 1.5 Pro 生成平均 0.074 美元。三十倍。如果分镜有三十个镜头，草稿阶段选错一次模型，比整条链路其他环节都贵。

废片也要算。按 7 月 27 日到 10 月 25 日 299 次已结束的 Kling 3.0 生成，成功率 91%；另一个图片模型 2991 次为 93.3%，1395 次为 91.2%（benchmark 聚合，按终态直接从生产库算出）。也就是说，每十个镜头里有一个要重做，而失败那次的钱已经扣了。模型本身怎么选，可以看我们的博客栏目。

这套方案解决不了什么

• 参考图不是银弹：角度、表情、光线剧烈变化时细节仍会漂。资产确认加预检能抓到很多，但不是全部。
• 失效判断很粗：改了剧本之后，系统按阶段状态知道要重做哪些，但「这句台词影响这两个镜头」这种行级追踪还没做。
• 质检提示很吵：有时会把可用的片段标成问题。
• 界面目前主要是中文，内置配音声音也是中文，其他语言要接外部语音合成。
• 需要自己的服务器和密钥，而且版本还是 0.1.0——期待值要准。

这周就要出片，从哪里开始

不要从整集开始。先做三到五个镜头，定下主角肖像和一个关键道具，跑一遍预检，再放开剩下的。如果到第五个镜头主角还是同一个人，说明流程能用；如果不是，问题在资产而不在模型，拖得越久越贵。

还有一点：跨镜头的一致性，观众只有在它缺失时才会注意到。没人会因为你第十四场戏里那道疤和第三场一致而夸你，但它决定了这集会不会被看完。