做了一款 AI 短剧创作工作台：流程拆解、功能对接与多场景一致性实战复盘

最近把一款 AI 短剧创作工具「拾梦」从原型推到了生产环境（shimeng.okra.xin）。期间踩过的坑和验证过的方法，比任何一份 PRD 都更适合记下来。这篇不复述功能列表，只挑三件事讲清楚：流程是怎么拆的、功能和工序如何一一对齐、为什么"换场景不出错"是真正的工程难题。

一、先拆流程：把"做一部短剧"拆到最小可对齐的节点

短剧创作直觉上很顺：写剧本 → 选角 → 搭场景 → 拍视频 → 配音 → 字幕 → 导出。但在工程上必须再拆一层——不是按"角色"拆，而是按"一次 LLM 调用能稳定产出一个独立产物"拆。拆分粒度的判定标准有三条：

  1. 产物自包含：这一节点的产出能独立落盘、独立回显、不依赖后续节点立刻被消费。
  2. 可失败回滚：节点失败不污染上游，失败后用户重做不会产生脏数据。
  3. 可中断恢复：用户关掉浏览器，下次回来能继续——这一点直接决定了要不要走异步任务模型。

拾梦最终拆出了 11 个生产节点 + 6 个资辅助节点。每个节点都是一次独立的 LLM/T2I/TTS/视频生成调用：

工序 节点 产物 模型
写剧本 LLM-01 备选剧本 6 条 logline+结构 文本 LLM
写剧本 LLM-02 剧本变体 单剧本扩写 文本 LLM
写剧本 LLM-03 换一套 同主题新版本 文本 LLM
选角 LLM-04 系统推荐角色 角色卡 ×N 文本 LLM
选角 LLM-04F 角色面容锚点 角色脸部特征句 文本 LLM
搭场景 LLM-08 系统推荐场景 场景卡 ×N 文本 LLM
大纲 LLM-09 分集大纲 分集剧情骨架 文本 LLM
大纲 LLM-10 逐集剧情+对白时间表 完整剧本文本+时间锚点 文本 LLM
拆镜 LLM-13 镜头拆解 镜头列表 文本 LLM
拍图 image-01 角色/场景参考图 图像模型
配音 speech-2.8-hd TTS mp3 语音模型
拍视频 H3 成片 mp4 视频模型
导出 pyJianYingDraft 剪映草稿 zip 工具库

拆完回头看，有一个反共识：角色图片不应该在"选角"里一口气生成完。原方案是"LLM-04 角色卡 → 批量 image-01"，实际跑下来发现角色图片必须逐个生成且允许中途调整 prompt，否则失败一次就要重做全部。最终落成"角色卡 → 用户逐张点生图"的形态。

二、功能与工序一一对齐：不是"一个 tab 对应一个工序"，是"一个 tab 对应一组可独立失败/回滚的工序"

PRD 上常见的误区是"Tab 1 剧本 / Tab 2 角色 / Tab 3 场景 / Tab 4 大纲 / Tab 5 拆镜"。照这个做出来用户会在 Tab 1 写 30 分钟、Tab 2 写 5 分钟、Tab 3 卡住整个工作流回不去。错在哪？错在工序之间的依赖被拍扁成页面切换——用户在 Tab 3 看到缺角色时，没有"回去补 Tab 2"的明确入口。

拾梦的对齐原则是：

  • 每个 Tab 顶部固定一个"工序入口"按钮（"生成备选剧本"、"系统推荐角色"），点进去是单独的 modal；
  • 生成过程是后台异步（submit 立即返回，后台轮询），用户可以自由切换其他 Tab做其他事，不需要等；
  • 失败定位到节点：任务中心能清楚看到"哪一个节点失败 / 用了多少次重试"，而不是"导出失败了"这种含糊反馈；
  • 数据落地：节点的产物（剧本、角色卡、场景卡）只要 LLM 返回成功，立刻写回项目 content——不依赖前端一次性完整操作。

落到代码层面，每个节点都对应 routers/gen.py 里一个独立的 task kind（text / image / tts / video / export_jianying / char_pipeline），共用一个 /api/gen/tasks 列表端点。这样做的副产品是配额计费可以按节点类型区分（视频贵、文本便宜），账单比"按项目计费"清晰得多。

三、多场景一致性：把"会变的东西"和"不变的东西"在架构上分开

这是上线后踩坑最深的点。一致性在 AI 应用里指的不是"风格统一"这种软指标，而是：

换场景后，结果应当可预测、可复现、不需要用户重新理解一遍产品。

拾梦面对的"会变的轴"有四条：

  1. 真人 vs 漫剧（visual type）—— 影响所有图片和视频生成 prompt；
  2. 移动端 vs PC（video orientation 9:16 vs 16:9）—— 影响画布尺寸、首尾帧比例、视频平台档位；
  3. 单人创作 vs 多账号协作（数据隔离）—— 影响权限、并发、配额；
  4. 本地 dev vs 生产容器（部署形态）—— 影响异步并发模型、文件路径、跨机兼容。

3.1 视觉一致性：所有视觉 prompt 都过一个"一致性守门员"

核心做法是把视觉相关配置提到 project.background.visualType，在每一处图片/视频 prompt 模板里强制注入。规则只有一条：哪个节点忘了注入这个守门员，那里就一定会出现"该出真人的出了动漫图"或者反过来。

// 摘自 prompt 装配层
function getVisualTypePrompt(visualType) {
  return visualType === 'realistic' 
    ? '真人风格：写实摄影质感、自然光线、真实人物比例' 
    : '日漫风格：动漫赛璐璐作画、清晰线条、动漫人物比例';
}

真人/漫剧各自有完整的样例 prompt 库 + 反例 prompt 库。生成失败里有相当比例其实是 prompt 漂移——LLM 没忽略守门员，但样例 prompt 没跟上。

3.2 平台一致性：尺寸不写死，跟着 orientation 走

早期版本曾因尺寸写死踩过坑——用户反馈"移动端和 PC 是不同的"。这条铁律贯穿整个项目：

  • 画布：9:16 → 1080×1920；16:9 → 1920×1080。判断依据是 background.videoOrientation，不写死。
  • 首尾帧图比例：跟着视频平台档位走（480P 横/竖），不写死。
  • 生成素材最低合规像素：image-01 边长 ∈ [512, 2048] 且 8 倍数，写死的是合规约束，不是尺寸偏好。

3.3 多账号一致性：所有数据按 user 归属，鉴权从入口处守住

后端每张表都有 user_id，每一份资源都走"查属主 → 验证 → 操作"三步。media 表存 assetMap，项目 content 只存 *AssetId 引用，不存 dataURL——保证素材上云、按用户隔离、上传即配额扣减。

跨账号测试是用 tester 账号做的：tester 登录 OK、项目列表空、直接访问 admin 项目 ID 返回 404、下载 admin 素材返回 404。三层隔离全过。

3.4 部署一致性：跨机兼容是真正的硬骨头

这是上线首日暴露的最大坑。剪映草稿导出后，"素材无法播放"——字幕能导入、视频不行。本地 dev 一切正常。

排查路径：

  1. 版本对齐：先确认生产前端 = 本地最新。排除"线上跑老版本"。
  2. 导出链路对比：dev 导出的 zip 视频能播、生产导出的不能。导出代码本身没区别，差异在容器内文件系统路径。
  3. 铁证对照：本地某个早期真机成功的备份里，素材 path 是 ./assets/xxx 相对路径；后续媒体改造回归为绝对路径（导出时本机路径）——dev 能播是因为该绝对路径恰好指向本地还活着的源文件；生产 Linux 导出 + Windows 剪映打开 = 路径失效。
  4. 实验验证：把 draft_content.json 里相对素材路径手动改成你机器上剪映草稿根的绝对路径后再打开剪映 → 视频正常播放。铁证：剪映只认绝对路径，不解析相对路径。

修复方案不是"想办法让第三方工具认相对路径"（那要 hack 工具链），而是承认它的产品约束——给用户一个"剪映草稿根目录"输入框，导出时拼成 {root}/{项目名}.draft/assets/xxx。用户解压到对应目录即可。这是用产品妥协换工程兼容，比让 AI 理解"为什么这么设计"便宜得多。

3.5 部署加固：把"上线即裸奔"挡在生产之前

上线前审计发现多个 web 应用通用风险。举几条和 AI 应用相关性最高的：

  • 依赖不锁版本：开发环境用 >= 装包很舒服，但生产 docker build 每次拉到最新版——上游一旦发包失误，自己也是受害者。生产一律 == 锁实测版本 + 升级走 PR 流程。
  • 弱默认密钥：.env.example 里的示例值如果被原样抄到生产，加密链路整体失效。生产 fail-fast：连生产数据库时若仍用默认值/弱密钥/默认口令 → 直接拒启动。
  • 端口暴露：反向代理/容器编排里最容易踩的形态之一——后端服务既被网关反代、又被自身端口裸暴露在 0.0.0.0。标准做法是：后端服务只监听本机回环，公网只走网关/反代。这是 web 通用准则，不是 AI 应用的特殊问题。
  • 生成费用无闸：用户连点 20 次"生成视频" → 20 次真扣费。后台并发闸 + 每用户每分钟限频。

这些不是"AI 应用的特殊问题"，是任何把模型调用接到生产环境的应用都会遇到的问题——只是 AI 应用因为扣费链路更深，问题更容易被放大。

四、几个值得记下来的工程判断

  1. 别追求"端到端全自动"。全自动做出来用户不敢用、不敢改；纯手工做出来用户嫌累。中间态是"AI 给候选 + 用户挑"，拾梦的 6 个备选剧本、6 个备选角色、6 个备选场景就是这个中间态。
  2. 限流设计要"打平峰值"而不是"压住上限"。后台任务并发闸设计为 task_concurrency=2：高峰时被排队、正常用户无感知、恶意点不动。比"无限制 + 灭火""硬限 1 次""拆账号绕"都好。
  3. 异步任务必须有钥匙 + adopt 接管。任何"submit 后后台跑、不轮询"的链路都要：① 提交即记任务 id 到 localStorage；② 按钮 disable 持久化；③ 刷新后 init 阶段 adopt 自动接管 + 回填 + 解锁。少任何一项，要么按钮能重复点烧钱、要么数据丢失。
  4. 跨机一致性测试是上线必做项。dev 能跑 ≠ 生产能跑。Docker、Linux/Windows、绝对/相对路径——生产部署首日必须把核心链路在生产端端跑通。
  5. 产品功能妥协比技术兼容便宜。第三方工具的"我行我素"约束很难 hack；让用户填一个适配它的参数，比维护一个跨平台路径映射库便宜得多。

五、未尽事项

写到这里更想说的是未尽事项——做产品最诚实的部分：

  • 导出端本地 mock 模式还有残留。生产部署下已锁死，但 dev 体验仍有"路径空 →"误以为"项目丢了"的死角。
  • API Key 轮换没自动化。一旦某个 Key 过期，用户得手动改 + 重新验证。应该加自动轮换。
  • 生成成本看板只是"显示用了多少"，没到"预测要花多少"。下次大版本会加预估。
  • 多模态输出的一致性还没做到位。同一角色在不同场景下"穿着一样"这件事，目前靠 prompt 而非真正的 reference image。引入 IP-Adapter 之类的技术栈会显著改善，但成本涨 3-5 倍。

最后一句：AI 应用的产品经理不能只懂 prompt，还要懂上游模型的成本结构、下游工具链的工程约束、以及中间这条异步任务链路的可靠性。三者缺一，做出来的产品就只能在自己电脑上玩——这正是把 AI 应用推到生产时学到的最贵一课。

如果你也在做类似的 AI 创作工具，欢迎对线。我在 shimeng.okra.xin 上持续迭代拾梦，也欢迎围观。