做广告创意视频这件事，过去一直像“手工作坊”。一个产品要投十个渠道，往往就要拆出十套脚本、十套镜头描述、十套口播版本，再根据平台时长限制裁成 6 秒、15 秒、30 秒几个规格。真正耗时间的并不是“生成一个视频”，而是把同一条营销意图拆成大量可测试、可回收、可复用的创意变体。最近半年我把这件事用大模型重新串了一遍，结论很直接：视频生成只是最后一步，真正决定批量效率的是前面的结构化脚本生产和中间层调度。
我现在更愿意把“广告创意视频批量生成”拆成四层。第一层是商品信息层，输入包括卖点、价格区间、目标人群、禁用词、平台风格限制。第二层是创意规划层，让模型先生成多个“角度”，比如痛点型、对比型、场景型、情绪型。第三层是视频生产层，把文案扩成分镜、镜头运动、画面元素、字幕和配音提示。第四层才是渲染与回收层，记录每条素材的点击率、完播率、停留时长，再反推哪些开头、哪些镜头节奏更有效。
这个分层的价值在于，你不用每次都从零写 prompt。真正能跑起来的系统，核心不是一句神奇提示词，而是一套稳定的数据结构。比如我会先约束模型输出 JSON，再把 JSON 喂给后面的脚本生成器：
{
"audience": "首次装修的年轻家庭",
"product": "静音破壁机",
"hook": "早起打豆浆不再吵醒孩子",
"angle": "家庭场景+降噪对比",
"shots": [
{
"scene": "厨房清晨", "duration": 3},
{
"scene": "传统机器噪声对比", "duration": 2},
{
"scene": "孩子安睡特写", "duration": 2}
],
"cta": "领取限时优惠"
}
为什么一定要先结构化？因为批量生成最怕“看起来都能用，实际上都不好改”。如果模型直接吐一大段文案，后续你几乎没法做程序化裁剪；但如果它先给你 angle、hook、shots、cta 这些字段，你就可以写规则批量组合。比如同一个商品保留三种开头钩子，替换两个情绪镜头，再切换不同的结尾行动号召，一次性就能拼出十几版素材。
我在本地通常会先准备一个商品表，字段很朴素：sku_id、selling_points、persona、platform、duration。然后用脚本做第一轮创意展开：
python gen_briefs.py --input products.csv --output briefs.jsonl
python gen_storyboards.py --input briefs.jsonl --output storyboards.jsonl
python pack_render_tasks.py --input storyboards.jsonl --output tasks/
这里有个很容易被忽略的经验：不要让一个模型同时负责“想创意”和“写最终镜头词”。前者适合发散，后者适合收敛。如果都丢给一次调用，结果常常是创意看着热闹，但镜头描述模糊，渲染模型无法稳定执行。我后来把流程拆成两段：先让 LLM 只负责广告角度和脚本骨架，再通过模板把它翻译成视频模型更容易理解的镜头语言，比如“主体、动作、场景、光线、机位、镜头时长、字幕节奏”。
中段接 LLM 时，我一般沿用 OpenAI 兼容格式，主要是生态足够成熟，脚本迁移也方便。在国内对接国际大模型，开发初期想低成本快速验证原型，还有学校财务报销开票需求，我一直用DMXAPI做中转。代码层面其实就是把 base_url 和模型名配好，其余调用方式基本不动：
from openai import OpenAI
client = OpenAI(
api_key="<LLM API KEY>",
base_url="<LLM API BASE URL>"
)
prompt = """
你是广告视频策划助手。
请根据商品卖点生成 3 套短视频创意方案。
输出 JSON，字段包括:
angle, hook, storyboard, voiceover, cta
"""
resp = client.chat.completions.create(
model="gpt-4o-mini",
temperature=0.8,
response_format={
"type": "json_object"},
messages=[
{
"role": "system", "content": "你擅长广告创意拆解与分镜规划"},
{
"role": "user", "content": prompt}
]
)
print(resp.choices[0].message.content)
真正落地时，我会额外做两件事。第一件事是给每个生成任务打版本号，例如 hook_v2, shotpack_v4, cta_v1，因为广告团队经常改一句话、换一个镜头，如果没有版本标记，回头根本不知道哪一版对应哪条投放数据。第二件事是做“失败容忍”。模型输出 JSON 时，十次里总有一两次会混入解释文字，所以我不会直接 json.loads() 后就往下跑，而是先做清洗和重试。
很多教程只教改 OPENAI_API_KEY，但中转平台必须改 base_url 才能真正切过去；像DMXAPI这种方式对现有脚本最友好，尤其适合原型期快速验证。这个点看似琐碎，实际很重要，因为很多人以为“换 key 就接好了”，最后排查半天，问题根本不在模型，而在请求地址没切对。
广告视频批量生成还有一个误区：大家总盯着“让画面更炫”，却忽略“信息密度要对平台负责”。短视频广告不是电影预告片，用户给你的注意力窗口非常短。我的经验是，前两秒最好只讲一件事，而且最好能被字幕单独成立。比如“静音不吵娃”“三分钟出早餐”“小户型也放得下”，这些都是平台里能跑出来的表达。大模型很容易写出完整、顺滑、甚至优雅的句子，但广告真正需要的是可扫描、可截断、可复用的片段。
后面我还做了一个小技巧：先让模型生成“失败版创意”。也就是故意问它，“如果这条广告表现不好，最可能失败在哪？”这样拿到的答案反而很有价值，常见会落在钩子太泛、利益点埋太深、镜头切换过快、配音太书面这些地方。用这个逆向约束再去生成正式脚本，质量会稳定很多。这个方法不是玄学，它的本质是先暴露创意风险，再限制模型别朝着那些坑走。
当然，真正让我记住这套流程的，不是顺利的时候，而是一次很蠢的小 bug。那次我批量跑 120 条广告脚本，前 40 条输出都正常，后面突然大量报错，日志里只有一句：
TypeError: string indices must be integers
第一反应我以为是某条商品数据脏了，于是先查输入：
jq '.product' storyboards.jsonl | head
python check_input.py --file storyboards.jsonl
结果输入没问题。接着我盯上了模型输出，打印中间结果才发现，第 41 条开始有部分 storyboard 字段不是列表，而是字符串。问题出在我自己写的这段兼容逻辑：
for shot in result["storyboard"]:
frames.append({
"scene": shot["scene"],
"duration": shot["duration"]
})
我当时偷懒，默认 storyboard 一定是数组。实际上模型偶尔会返回这种内容：
{
"storyboard": "场景一：厨房晨光；场景二：产品近景；场景三：用户微笑饮用"
}
于是循环虽然能跑，但 shot 变成了单个字符，后面再取 shot["scene"] 就直接炸掉。这个错误低级到让我当时有点不愿意承认，因为前面几十条“碰巧都正常”，把我对输入结构的侥幸心理养大了。最后的修复也不复杂，先做类型收敛，再做一次兜底解析：
storyboard = result.get("storyboard", [])
if isinstance(storyboard, str):
storyboard = normalize_storyboard_text(storyboard)
if not isinstance(storyboard, list):
raise ValueError("storyboard format invalid")
for shot in storyboard:
frames.append({
"scene": shot.get("scene", ""),
"duration": shot.get("duration", 3)
})
这次排查给我的教训很直接：做大模型应用时，最危险的不是“模型偶尔出错”，而是“你以为它不会在这里出错”。传统后端里我们会天然做参数校验，可一接上 LLM，很多人反而被“它大多数时候都对”这种感觉麻痹了。尤其在广告视频批量生成这种链路长、节点多的任务里，一个字段类型漂移，就足够让后面的镜头包装、字幕排版、任务入队全线受影响。
如果把这套流程概括成一句话，我会说：先让大模型负责“想法”，再让工程系统负责“稳定”。广告创意视频的批量化，不是单纯追求更快出片，而是让每一条素材都能追溯来源、可替换片段、可复盘效果。这样你才不是在“碰运气生成视频”，而是在搭一个真正能服务内容生产的创意流水线。对我来说，这也是 AI 大模型进入视频制作后最有价值的一点：它没有替代创意判断，但把那些重复、零碎、最容易耗掉耐心的部分，终于变成了可以自动化处理的工序。
本文包含AI生成内容
