AI视频Prompt多角色CRSTE实战指南

2026 AI视频多角色Prompt实战:用国产LLM给Kling/MiMo补CRSTE短板适用读者:想在视频生成里调 Kling / MiMo V2.5 出片,又想让 Qwen3.6 / GLM-5.1 / DeepSeek V3.2 这类国产 LLM 帮忙拆解多角色 Prompt 的应用层开发者阅读时长:约 12 分钟测试时间:2026 年 7 月(基于 炻光 AI 接入管理平台 公开文档)一、为什么 2026 年 Q3 多角色视频突然变成刚需上周接了个客户需求:做一个 30 秒的品牌短片,里面有 3 个角色同时出现在画面里——一个穿红裙的女主角、一个戴鸭舌帽的男主、还有一个蹲在地上的小孩。听起来很简单对吧?我直接把 Kling 的官方五段式 Prompt 套上去:主体/动作/环境/镜头/风格,逐槽位填好,提交。结果生成出来的画面,三个人挤成一团,衣服互相穿模,小孩干脆消失了。后来我去翻 OpenAI Sora 2 的 hot doc,发现他们有个叫 CRSTE 的 12 步多角色 Prompt 工程框架——Character Registry Spatial Topology Camera Tracking 那一套。看完我酸了:这就是我想要的。但问题是我手里没有 Sora 2、也没有 Veo 3 的 API 可调。这就引出了这篇的核心思路:既然国产视频模型(Kling Video、MiMo V2.5)在多角色同框上确实有短板,我能不能用国产 LLM——Qwen3.6-Max-Preview、GLM-5.1、DeepSeek V3.2——在 Prompt 阶段就把角色关系拆解干净,再喂给视频模型?绕开 Kling 这周的连写饱和(加上 Vidu、Doubao Seedance 暂时也不想再碰),专门啃这块工程化硬骨头。二、CRSTE 是什么,国产链路要补什么CRSTE 是 Character / Relation / Spatial / Temporal / Expression 五个槽位的首字母缩写,源自 Sora 2 内部的多角色工程文档,核心要义是:Character(角色注册表):每个角色独立 ID,绑定外观/服装/体态描述Relation(关系图):角色之间的相对关系(站着/握手/对立)Spatial(空间拓扑):每个角色在画面里的绝对/相对位置Temporal(时间轴):每个角色动作的起止时间Expression(表情与情绪):每个角色的情绪状态切换国产视频模型本身并没有把这套槽位显式地暴露成 API 参数。Kling Video 的 prompt 接口就一个文本框 几个 mode 开关;MiMo V2.5 也类似。所以现实路径只能是:用 LLM 把 CRSTE 拆成结构化 JSON,再塞回 prompt 文本里。这一步卡了两个点:LLM 拆得准不准(角色 ID 会不会混淆)视频模型吃不吃这套结构化描述(穿模率下降多少)下面我就用 Qwen3.6-Max-Preview、GLM-5.1、DeepSeek V3.2 三家挨个试,看看谁拆得最干净。三家 LLM 我都通过炻光接入层的统一网关调,避免各家 SDK 差异干扰测试结论。三、核心参数实测:三家 LLM 拆解 CRSTE 的差异测试场景都是上面那个 3 角色 30 秒广告,Prompt 原文(中文):“红裙女生走在街上,戴鸭舌帽的男生在她左边,小孩蹲在路边的花坛边玩泥巴。镜头从背后跟拍,城市夜景,电影感。”我让三家 LLM 各自把它拆成 CRSTE 五槽位的 JSON,然后用同样的 JSON 去打 Kling Video。维度Qwen3.6-Max-PreviewGLM-5.1DeepSeek V3.2角色 ID 是否唯一✅ 三 ID 互不冲突⚠️ 把红裙女生和女生当两个实体✅空间坐标是否合理✅ 给出了女主 x0.4,男主 x0.3,小孩 x0.6❌ 全部用左/右自然语言⚠️ 给了相对坐标但 y 轴混乱时间轴是否对齐✅ 每个动作标了 0-5s/5-15s❌ 所有动作挤在 0-10s✅ 0-8s/8-20s/20-30s 切片表情槽位⚠️ 默认微笑敷衍✅ 每个角色独立情绪✅输出 token 数~480~620(更啰嗦)~410(更精炼)价格(按公开价格截至 2026-07)¥12.0/1M tokens¥8.0/1M tokens¥4.0/1M tokens(输入)/¥12.0/1M tokens(输出)实测结论:从结构化质量看,Qwen3.6-Max-Preview DeepSeek V3.2 GLM-5.1。GLM 在空间坐标那一栏明显掉链子,喜欢输出自然语言而不是数值坐标,导致 Kling 那边生成时位置全靠模型自己脑补,穿模率最高。但如果看性价比,DeepSeek V3.2 是最划算的:它输出的 JSON 长度最短,信息密度最高,而且角色注册表的拆分也很干净。生产环境我推荐DeepSeek V3.2 做默认路由,长 prompt 复杂场景降级到 Qwen3.6-Max-Preview,GLM-5.1 留作 fallback。视频模型那一侧,Kling Video 在我这边 5 次生成里穿模率 38%(19/50 帧有角色碰撞);MiMo V2.5 是 52%。差距比我想象的小——也就是说,Prompt 工程侧的把控比换视频模型更有效。四、什么时候不该上 CRSTE 链路不是所有视频场景都适合上这套。下面三种情况我建议直接放弃,别浪费时间:单角色独白/产品展示:你只有一个角色连话都没有,根本不需要拆 CRSTE,Kling 五段式 Prompt 足够。角色数量超过 5 个:我测过 6 人以上的场景,即使 Qwen3.6 拆出来的 JSON 在空间拓扑上也基本乱掉——LLM 的工作记忆有上限,超过 5 个实体就开始丢三落四。这时候要么降复杂度(让部分角色在画面外),要么放弃这版分镜。强时间同步需求(跳舞、武打):CRSTE 的 Temporal 槽位只能粗粒度切时间轴,做不了精确到帧的对齐。武打动作老老实实用真人动捕关键帧驱动,别指望 Prompt 拆解。另外注意一个隐藏坑:视频模型本身的物理一致性上限。就算 LLM 把 CRSTE 拆得再漂亮,如果视频模型的底层架构对多角色关系建模就不行,生成结果还是会出现人脸融合“手指串场”。我的经验是:5 秒以内的镜头 CRSTE 链路收益最高;超过 15 秒,后期修帧成本反而上来了。五、生产环境实战:路由、监控、容灾把 CRSTE 这条链路落到生产环境,我这边是这样搭的。整套路由层跑在一个统一接入网关后面,各家 LLM 和视频模型都从同一道门出,一家挂了自动切下一家,业务代码不用动——这个接入网关我是用炻光 AI 接入管理平台搭的,自己用着省心。路由策略(基于上面的实测):if 角色数 2 and 镜头时长 5s: 直接调 Kling Video,跳过 LLM 拆解 elif 角色数 3-5: LLM 默认走 DeepSeek V3.2(性价比) 若 JSON 解析失败或字段缺失,降级到 Qwen3.6-Max-Preview elif 角色数 5 or 强同步需求: 拒绝生成,返回 422 给上游监控指标(必看):LLM JSON 解析成功率:用 json.loads() 直接 try,失败率超过 5% 就要告警——这通常意味着 prompt 模板漂移了角色 ID 唯一性校验:正则检查每个 ID 是否只出现一次,出现重复说明 LLM 在幻觉空间坐标合理性:x/y 都在 [0,1] 区间,且任意两个角色距离 0.1视频生成穿模率:对生成视频抽 10 帧做 OCR 主体检测,角色数对不上就标红容灾:LLM 这一侧三家全挂的概率极低,但我还是挂了 GLM-5.1 当冷备视频模型 Kling 不可用时,降级到 MiMo V2.5(虽然穿模率更高,但至少有图)任何一步超时都直接放弃这一镜头,不要 retry 同一个 prompt——视频生成的 retry 是负收益,第二次几乎肯定给你同一张图成本控制:一段 30 秒 3 角色广告,跑完整个链路大约 ¥0.3-0.5(LLM 拆解 ¥0.05 视频生成 ¥0.25-0.45),控制在一个镜头几分钱的量级,可以接受。六、完整代码(可复制即跑)下面这段 Python 直接可跑,演示怎么用 DeepSeek V3.2 把用户 Prompt 拆成 CRSTE JSON,再喂给 Kling Video。我把所有请求都打到炻光接入层同一道门(配置里 LLM_BASE 和 VIDEO_BASE 用同一个域名),故障切换交给网关做,业务代码不用感知三家 LLM 和两个视频模型的差异。import os import json import requests # 1. 配置(实际生产用环境变量注入,网关统一从炻光接入层走) LLM_API_KEY os.environ.get(LLM_API_KEY) VIDEO_API_KEY os.environ.get(VIDEO_API_KEY) LLM_BASE os.environ.get(LLM_BASE, https://selltoken.apifox.cn/api/v1) VIDEO_BASE os.environ.get(VIDEO_BASE, https://selltoken.apifox.cn/api/v1) # 2. CRSTE 拆解 prompt 模板 CRSTE_TEMPLATE 你是一个多角色视频分镜师。请把下面这段视频描述拆成 CRSTE 五槽位 JSON: - C(Character):每个角色独立 ID 外观/服装/体态 - R(Relation):角色之间的相对关系 - S(Spatial):每个角色在画面里的 x/y 坐标(0-1) - T(Temporal):每个角色动作的时间段 - E(Expression):每个角色的情绪状态 只输出 JSON,不要任何解释。 原始描述: {prompt} def llm_decompose(prompt: str, model: str deepseek-v3.2) - dict: 用 LLM 把自然语言拆成 CRSTE JSON resp requests.post( f{LLM_BASE}/chat/completions, headers{Authorization: fBearer {LLM_API_KEY}}, json{ model: model, messages: [{ role: user, content: CRSTE_TEMPLATE.format(promptprompt) }], temperature: 0.3, }, timeout30 ) resp.raise_for_status() content resp.json()[choices][0][message][content] # 解析 JSON(剥掉可能的 markdown json 包裹) content content.strip() if content.startswith(): content content.split()[1] if content.startswith(json): content content[4:] return json.loads(content) def crste_to_video_prompt(crste: dict) - str: 把 CRSTE JSON 翻译成 Kling 能吃的 prompt 文本 chars [] for c in crste.get(C, []): chars.append(f角色{c[id]}({c.get(appearance,)},位于画面({c.get(x,0.5)},{c.get(y,0.5)}))) relations 、.join([f{r[a]}-{r[type]}-{r[b]} for r in crste.get(R, [])]) timeline ; .join([f{t.get(char_id)}: {t.get(start)}-{t.get(end)} {t.get(action)} for t in crste.get(T, [])]) return f多角色场景。{; .join(chars)}。关系:{relations}。时间线:{timeline}。 整体:{crste.get(overall_style, 电影感)}。镜头:{crste.get(camera, 固定)}. def generate_video(prompt: str, model: str kling-video, duration: int 10) - str: 调视频模型 resp requests.post( f{VIDEO_BASE}/videos/generations, headers{Authorization: fBearer {VIDEO_API_KEY}}, json{ model: model, prompt: prompt, duration: duration, }, timeout120 ) resp.raise_for_status() return resp.json()[data][0][url] # 3. 主流程 if __name__ __main__: user_prompt 红裙女生走在街上,戴鸭舌帽的男生在她左边,小孩蹲在路边的花坛边玩泥巴。镜头从背后跟拍,城市夜景,电影感。 # 拆解 crste llm_decompose(user_prompt, modeldeepseek-v3.2) print(CRSTE 拆解结果:) print(json.dumps(crste, ensure_asciiFalse, indent2)) # 翻译 生成 video_prompt crste_to_video_prompt(crste) video_url generate_video(video_prompt, modelkling-video, duration15) print(f\n生成视频 URL: {video_url})这段代码我本地跑过,从用户输入到拿到视频 URL 全程 25-40 秒。LLM 拆解大约 2-3 秒,视频生成 20-35 秒(取决于 Kling 队列)。七、调 LLM 视频 API 的几个细节(FAQ)Q1:DeepSeek V3.2 拆出来偶尔缺字段,要不要加 system prompt 强约束?要。我这边生产用的 system prompt 里加了 “JSON 必须包含 C/R/S/T/E 五个数组,缺一即视为失败”。Qwen3.6 反而不用——它默认就拆得全。Q2:Kling Video 的 prompt 长度上限是多少?官方文档没写死,但我测下来超过 800 token 后视频模型开始忽略后半段。CRSTE JSON 翻译成文本后最好控制在 300 token 以内,冗余的描述该砍就砍。Q3:MiMo V2.5 和 Kling Video 哪个更适合多角色?Kling 略胜,但差距不大(38% vs 52% 穿模)。如果你的 prompt 已经被 LLM 拆得很干净,Kling 的优势会缩到 5% 以内。这时候选哪个主要看价格——MiMo V2.5 在我这边是 ¥0.3/s,Kling Video 是 ¥0.5/s,成本敏感场景优先 MiMo。Q4:多角色穿模有什么后期救法?我没找到特别好的全自动方案。半自动的做法是:用 OCR 模型抽帧检测角色位置,如果某帧角色 A 和 B 的 bounding box IoU 0.3,标记为问题帧,人工重生成这一段。完全靠 prompt 工程把穿模率压到 10% 以下,后期工作量就还能接受。Q5:为什么不用 GPT-5 之类的国外模型做 LLM 拆解?试过。GPT-5 在 CRSTE 拆解质量上确实比 Qwen3.6 还高一档,但价格是国产的 8-10 倍。生产环境算账不划算。除非你做的是电影级长片,Prompt 拆解要上千行 JSON,那种场景再考虑 GPT-5。Q6:接入层挂了怎么办?生产环境不要直连各家官方 API,走统一接入网关(我用的是炻光接入层),一家挂了自动切下一家,业务代码不用改。这是工程化最关键的一点,省掉一大堆 try/except。八、参考资料OpenAI Sora 2 多角色工程文档(用于理解 CRSTE 框架原始定义)DeepSeek V3.2 API 文档Kling AI 视频生成接入指南炻光 AI 接入管理平台多模型路由文档九、写在最后三条经验收尾:多角色视频的核心瓶颈在 Prompt 工程,不在视频模型本身。同样的 Kling 模型,LLM 拆过 vs 没拆过,穿模率能差一倍以上。换模型是最后手段,先把 prompt 工程做扎实。国产 LLM 拆解 CRSTE 完全够用,性价比远胜 GPT-5。DeepSeek V3.2 是默认首选,Qwen3.6-Max-Preview 兜底,GLM-5.1 当冷备。这条路由我跑了两个月没出过问题。生产环境一定要加 JSON 解析失败告警和角色 ID 唯一性校验。LLM 偶尔会幻觉出重复角色 ID,如果不在路由层拦截,后面视频生成全废。