AI 短剧工程实践：从视频生成到角色引擎

一、把镜头生成变成可维护的生产过程

让林晓在三个镜头里保持身份，比单次生成一段视频多出了一组工程问题：哪版角色资产被使用，接电话前穿什么，某段声音重做后哪些镜头需要重新对口型，以及失败任务会不会覆盖已经审核的成片。

模型决定生成能力的边界，应用层则负责把资产、状态、任务和验收组织起来。两者共同影响结果，没有一个可以通用于不同产品的“模型占三成、工程占七成”比例。

本文提出面向预制短剧的架构方案，以林晓接到录用电话为贯穿案例。JSON 均为说明性模型，不代表已经部署的服务。交互分支可以复用状态版本设计；持续实时生成另见《AI 实时交互式视频》。

二、角色注册表保存资产，不替镜头决定一切

角色不能只有一个 LoRA 文件名。外观、声音和适用的底模分别演进，项目需要知道每次生成究竟使用了什么。

下面将角色资产版本与模型适配配置分开。模型名称和文件路径为示例占位，实际生产应替换为经过验证的具体产物：

{
  "character_id": "CH_001",
  "name": "林晓",
  "asset_version": 3,
  "visual": {
    "reference_images": ["front-v3.png", "side-v3.png"],
    "adapter_profile": "visual-profile-v2",
    "default_hair": "short"
  },
  "audio": {
    "zh": {
      "voice_asset_id": "voice-CH001-zh-v2",
      "adapter_profile": "tts-profile-zh-v1",
      "reference_audio": "voice-zh-v2.wav"
    }
  },
  "wardrobe": ["business_casual", "pajamas_pink"],
  "validation_set_version": "character-tests-v4",
  "status": "approved"
}

角色 ID 维持业务身份，资产版本固定外观与声音资源，适配配置记录底模、节点版本和参数。制作中的一集引用明确版本，不能每次执行都自动取“最新”，否则同一项目会在不知情时混用角色。

验证集覆盖正脸、侧脸、表情、换装和预期画风。身份相似度帮助筛出可疑结果，最终还要看镜头意图和时序。指标下降时先定位底模、适配器、检测器或参考资产的变化，不能一律触发重新训练。

多角色镜头中，区域条件能否隔离身份要按具体实现检查。分角色生成再合成也不是自动保真：角色间遮挡、接触、视线和光照都需要检查。注册表应保存经过验证的组合配置，而不只保存每个角色单独生成时的最佳参数。

三、将剧情状态与生成结果分开保存

林晓在前一场面试后回到家，换上睡衣，坐在沙发上等待电话。世界状态保存这些剧情事实；生成任务读取状态，却不能凭“任务完成”就证明画面已经满足要求。

{
  "branch_id": "main",
  "scene_id": "S03_E01",
  "state_version": 12,
  "characters": {
    "CH_001": {
      "asset_version": 3,
      "clothes": "pajamas_pink",
      "hair": "short",
      "emotion": "anxious",
      "location_id": "home_living_room",
      "pose": "sitting_on_sofa"
    }
  },
  "environment": {"time": "evening", "lighting": "warm_indoor"},
  "previous_state_version": 11
}

“短发”沿用角色设定，衣服与情绪是当前场景状态。一次镜头请求可以进一步规定“听到消息后由惊讶转为高兴”，但镜头输出、审核结果和剧情状态变更应分别记录。未通过审核的画面不能直接进入成片或成为下一镜头的已确认参考。

状态适配层负责把业务意图转换为模型实际支持的输入：

剧情字段	可用的生成条件	需要检查
睡衣与短发	提示词、参考图或兼容的角色适配器	不把换装误当作身份变化
坐在沙发上	姿态、深度或构图参考	模型是否支持对应条件
焦虑语气	TTS 支持的指令、参考音频或参数	不把内部情绪枚举直接当成通用 API
客厅与暖光	场景资产、背景参考及光照描述	遮挡、透视和跨镜头位置关系

业务状态稳定，模型接口可以替换；但适配器需要明确能力检查。不支持某种情绪指令时，应选择参考表演或人工调整，而不是静默丢弃要求。

分支恢复的是状态版本

预制分支剧中，观众可在同一个决策点选择不同剧情。每个分支引用独立状态版本，回溯时从分叉前的快照重新创建分支：

快照可保存完整状态，也可通过事件增量恢复。前者读取简单，后者需要维护事件顺序、模式版本和恢复检查。无论选择哪一种，恢复状态都不等于撤销已完成的外部操作或删除已有媒体；这些对象保留各自的版本和引用关系。

数据库保存可恢复的状态与任务记录，对象存储保存媒体产物。缓存用于加速读取，不能成为唯一的剧情和任务事实来源。并发修改使用预期版本检查，避免旧分支的晚到结果覆盖新状态。

四、结构化剧本给生成任务提供契约

自然语言剧本适合创作，但不足以安排依赖和检查资源。剧本中间件把“接电话后惊喜地站起来”拆成镜头，并为每个镜头指定角色、输入状态、台词与目标时长。

以下镜头仍使用前述角色和状态：

{
  "schema_version": 1,
  "episode_id": "EP03",
  "shot_id": "EP03_S01_SH02",
  "branch_id": "main",
  "input_state_version": 12,
  "character_id": "CH_001",
  "character_asset_version": 3,
  "shot_type": "close_up",
  "camera_movement": "static",
  "target_duration_sec": 4,
  "action": "answering_phone",
  "emotion": "anxious",
  "dialogue": {
    "language": "zh",
    "text": "喂？是的，我是林晓。",
    "voice_asset_id": "voice-CH001-zh-v2"
  },
  "acceptance": ["identity", "speech_content", "lip_sync", "continuity"]
}

目标时长用于规划，真实 TTS 音频时长用于排镜和对口型。台词说不完时，需要修改文本、节奏或镜头时长；不能只截断音频来满足最初的四秒配置。

LLM 可以生成候选分镜，但结构正确不代表镜头可实现。进入队列前至少检查：

Schema：字段、类型、枚举和时长范围符合当前版本。
引用：角色、声音、状态与模型适配配置存在且版本匹配。
连续性：服装、地点和道具变化有剧情依据。
可执行性：选定模型支持需要的输入、时长和动作。
创作审核：镜头是否表达剧本意图，人物台词是否自然。

提示词、Schema、界面选项和适配器必须使用同一份词表。不能在示例中写 close_up，提示词却只允许 close-up；情绪也不能一边只允许 happy，另一边输出 ecstatic。

剧本编辑器应保留人工修改并展示变更，不让下一次自动拆解覆盖已经确认的镜头。对于已有模板的重复场景，规则和模板也可以直接完成转换，无需每次调用 LLM。

五、按依赖调度，按输入版本接收结果

一个镜头可拆为视觉生成、语音合成、对口型、后处理与审核。视觉和音频是否能并行，取决于镜头：音频驱动模型要先拿到音频，独立视觉生成则可与 TTS 并行。

纯旁白镜头可以复用背景或已有视觉素材，但仍需要画面和时间线；TTS 使用 CPU 还是 GPU 由模型与部署决定，不能按“有没有人物动作”直接分配。

每个任务记录输入资产版本、模型与工作流版本、参数、种子、上游产物哈希和尝试编号。远程提交成功但本地没收到响应时，先用供应商任务 ID 查询状态；盲目重交既可能重复计费，也可能产生两个互相覆盖的输出。

工作节点先上传不可变产物，再以任务版本与当前尝试编号为条件提交结果。超时旧任务的晚到输出可以保留为候选，但不能覆盖已经选中的新结果。上游产物变化后，将引用旧产物的下游标记为失效，按需要重建；未受影响的镜头继续复用。

区分重试、重新生成和人工修复

问题	下一步	停止条件
临时网络错误或限流	按服务契约退避、查询已有任务	达到截止时间或调用预算
不合法参数、缺少资产	修正输入，不重复发送原请求	输入校验通过后再运行
显存不足	降低并发，或更换已验证的执行配置	不以降质结果自动替代原验收标准
面部或动作不合格	选择新种子、修改条件或局部修复	达到镜头预算后进入人工处理
发音或口型不合格	先定位文本、音频、对齐或画面问题	对应检查和试听通过

确定性配置错误与可复现的质量问题，不会因为同参数重试三次就消失。身份分数、口型分数和语音质量预测也不是通用通过线；MOS 原本来自主观评分，自动预测值应标明评价器与标定方式。

成本以入选镜头为单位

单集成本应累加所有尝试、修复、声音、后处理、存储传输和人工成本，再除以最终入选时长或镜头数。不能只用服务商的单次生成价格乘以计划镜头数。

例如，仅作算例：150 个镜头，共提交 300 次视频生成，每次成本 0.8 元，则视频尝试成本是 240 元。若还有音频、对口型和人工剪辑，需要继续计入；这不是任何服务商的报价，也不是实际生产预算。

缓存键同样需要完整：同一句台词在不同语言、声音版本、情绪、语速和上下文下可能生成不同表演；同一个客厅也可能有不同机位、光照和陈设。只有输入条件满足复用契约时，才复用产物。

六、版本与审核贯穿最终交付

底模、角色资产、工作流和评价器都可能变化。每集确认制作配置后固定版本，升级时先跑留出的回归镜头，再决定替换哪些资源。保存参数和种子有助于追踪，但不同运行环境未必能逐像素复现，因此还要保留入选产物本身。

自动审核覆盖适用的内容、身份和品牌要求，可疑结果进入复核。审核错误率应从本项目样本计算；敏感词列表或单一图像检测器不能替代对上下文和最终成片的检查。

多语种发行也沿用版本设计。角色可以拥有多套目标语言声音配置，但必须核对模型具体版本的语言支持与使用条件。GPT-SoVITS 与 CosyVoice 提供不同的训练、零样本和跨语言能力，不能将所有语言写成同一套“声纹接口”。

翻译会改变台词长度、停顿和情绪节奏，因此多语种版本需要重新检查剪辑时长、字幕和口型；视觉资产可以复用，最终镜头仍需验收。

七、借鉴游戏引擎的状态组织，保留生成系统的特点

角色、场景、剧情与资源管理，可以借鉴游戏引擎的对象组织方式。但生成模型的输出不是确定性的场景渲染，离线制作还要处理候选选择、质量退回与人工修复。两类系统可以共享设计思路，不能因此视为同一套执行机制。

小团队可以从版本化文件、镜头清单和人工审核开始。只有多角色复用、并发任务和迭代频率实际增长时，再引入独立注册表、调度服务与状态管理。扩展的依据是重复工作和协作成本，而不是为了完整复制一套“角色引擎”。

最终，应用层应能回答四个问题：这个镜头用了什么，为什么得到这个结果，修改后哪些产物需要重做，以及哪一版已经可以交付。回答清楚这些问题，视频生成才成为可持续维护的生产过程。