前面一篇我们分析了 Pixelle-Video 的 AI 文案生成流程。
在 generate 模式下,用户只需要输入一个主题,系统会调用 LLM 自动生成多段解说词,然后继续生成图片提示词、语音、画面和最终视频。
但在真实使用中,并不是所有人都希望 AI 帮自己写文案。
很多时候,我们已经有现成脚本,只想让 Pixelle-Video 帮我们完成后面的自动化步骤:
已有文案
↓
自动拆分成多段旁白
↓
生成配图提示词
↓
生成语音
↓
渲染模板
↓
合成视频
这就是 Pixelle-Video 的 fixed 模式。
fixed 模式可以理解为“固定文案模式”:
用户提供完整脚本,系统不再根据主题重新写稿,而是按规则把脚本拆成多个 narration,再继续走后面的视频生成流程。
这一篇我们就专门分析 fixed 模式。
一、为什么需要固定文案模式?
AI 自动写稿很方便,但它也有几个问题。
第一,内容不一定完全符合用户想法。
比如你想做一条健康类短视频,文案必须谨慎、准确、不能夸大。如果完全让 AI 写,可能会出现表达过度、逻辑不严谨、甚至事实错误。
第二,风格不一定稳定。
同一个主题,不同模型、不同参数、不同时间生成的文案可能不一样。对于长期运营一个账号来说,风格稳定很重要。
第三,商业项目往往需要审核过的文案。
比如产品介绍、课程宣传、企业短视频,文案通常需要提前确认,不能让 AI 每次临场发挥。
第四,有些用户本身就擅长写文案。
这类用户不需要 AI 帮忙写内容,只需要 AI 帮忙生成素材、配音和合成视频。
所以 fixed 模式解决的是一个很实际的问题:
把“文案创作权”交还给用户,把“视频制作流程”交给 Pixelle-Video。
二、fixed 模式在源码中的位置
Pixelle-Video 的标准生成流程在 StandardPipeline 中实现。源码注释写得很明确:这个 pipeline 支持两种模式,generate 表示由 LLM 根据主题生成 narration,fixed 表示使用用户提供的脚本。标准流程会生成或确定标题、生成 narration 或拆分 fixed script、生成每段 narration 的图片提示词,再逐帧生成音频、图片、合成画面和视频片段,最后拼接并添加 BGM。
也就是说,fixed 模式不是一个完全独立的新流程,而是 StandardPipeline 里的一个分支。
核心差异发生在 generate_content() 这一步:
generate 模式:
text 被当成主题
调用 generate_narrations_from_topic()
由 LLM 生成多段旁白
fixed 模式:
text 被当成完整脚本
调用 split_narration_script()
按规则拆成多段旁白
源码里 generate_content() 会先读取 mode,默认是 "generate"。如果是 generate,就调用 generate_narrations_from_topic();否则就进入 fixed 分支,读取 split_mode,默认是 "paragraph",然后调用 split_narration_script()。同时源码还记录了一条日志:fixed 模式下 n_scenes 会被忽略。
这点非常关键。
在 generate 模式中,n_scenes 决定 AI 要生成几段 narration。
在 fixed 模式中,分段数量由你的脚本内容和拆分规则决定,而不是由 n_scenes 决定。
三、fixed 模式不是“不用 AI”,而是“不用 AI 写稿”
这里要先澄清一个容易误解的点:
fixed 模式并不等于整个流程完全不调用 AI。
它准确的含义是:
跳过 AI 根据主题生成解说词这一步。
也就是说,用户已经提供了完整文案,Pixelle-Video 不再调用 LLM 去扩写主题。
但是后续流程可能仍然会使用 AI。
例如,如果你选择的是 image 或 video 类型模板,plan_visuals() 阶段仍然会根据每段 narration 生成图片提示词。源码中会根据模板类型判断是否需要媒体生成:image 模板需要图片,video 模板需要视频,static 模板则跳过媒体生成;只有需要媒体时才会调用 generate_image_prompts()。
另外,如果用户没有手动指定标题,fixed 模式下 determine_title() 仍然会调用 generate_title(),并使用 strategy="llm" 从脚本中生成标题。
所以 fixed 模式可以分成三种情况理解:
固定文案 + static 模板 + 手动标题:
基本可以跳过 LLM 写稿和图片提示词生成
固定文案 + image/video 模板 + 手动标题:
跳过 LLM 写稿,但仍可能用 LLM 生成图片提示词
固定文案 + image/video 模板 + 自动标题:
跳过 LLM 写稿,但仍可能用 LLM 生成标题和图片提示词
因此,fixed 模式更准确的名字应该是:
固定解说词模式,而不是完全离线模式。
四、split_narration_script:固定文案的核心函数
fixed 模式的核心函数是 split_narration_script()。
这个函数位于 pixelle_video/utils/content_generators.py,用于把用户提供的完整脚本拆分成 narration 列表。它支持三种拆分方式:paragraph、line、sentence。源码注释中也明确说明,paragraph 按双换行拆分,line 按单换行拆分,sentence 按句末标点拆分,支持中文句号、问号、感叹号以及英文 . ! ?。
三种模式可以这样理解:
paragraph:
按段落拆分,适合已经按分镜写好的脚本
line:
按每一行拆分,适合一行一句旁白的脚本
sentence:
按句子拆分,适合普通连续文章
fixed 模式最终返回的是:
[
"第一段旁白",
"第二段旁白",
"第三段旁白"
]
后面 Pixelle-Video 会把这个列表继续传给 storyboard 和 frame_processor。
五、paragraph:最推荐的固定文案拆分方式
paragraph 是 fixed 模式的默认拆分方式。
源码中 split_narration_script() 在 paragraph 模式下会用正则按双换行拆分,也就是类似 \n\n 的段落间隔;同时它会保留段落内部的单换行,只去除前后空白。
这意味着,你可以这样写脚本:
很多人以为学习效率低,是因为自己不够努力。
但真正的问题,往往是没有把目标拆小。
如果每天只盯着一个很大的目标,大脑会天然产生压力。
更好的方法,是把目标拆成今天能完成的一小步。
当你每天都有一点正反馈,学习效率自然会慢慢提升。
如果使用 paragraph 模式,每个空行之间的内容就会变成一个 narration。
这种方式最适合短视频制作,因为你可以提前控制每一个分镜的旁白。
比如:
第 1 段:提出痛点
第 2 段:解释原因
第 3 段:给出反常识观点
第 4 段:提出方法
第 5 段:总结收尾
每段就是一个镜头,每段就是一段配音,每段就是一个视频片段。
所以,如果你追求可控性,我最建议用 paragraph。
六、line:适合“一行一个镜头”的脚本
line 模式更简单。
源码中 line 模式直接按 \n 拆分,并过滤空行。
例如:
很多人学习效率低,不是因为不努力。
真正的问题,是目标太大。
目标越大,越容易拖延。
把目标拆成今天能完成的一步。
每天有正反馈,效率自然会提升。
拆分后就是:
1. 很多人学习效率低,不是因为不努力。
2. 真正的问题,是目标太大。
3. 目标越大,越容易拖延。
4. 把目标拆成今天能完成的一步。
5. 每天有正反馈,效率自然会提升。
这种方式适合已经写成“短句列表”的脚本。
它的优点是节奏快、分镜清楚。
缺点是每一行可能太短,生成出来的视频节奏会比较碎。
如果你的目标是做 15 秒到 30 秒的短视频,line 模式很好用。
如果你的目标是做 1 分钟以上的讲解视频,line 模式可能会让片段过多,合成和配图成本也会增加。
七、sentence:适合普通文章转视频
第三种是 sentence 模式。
源码中 sentence 会先把脚本中的连续空白压成一个空格,然后按句末标点拆分;支持中文 。!? 和英文 . ! ?。
例如:
很多人学习效率低,并不是因为不努力,而是方法错了。真正高效的学习,第一步是明确目标。第二步是拆分任务,把大目标变成每天能执行的小动作。第三步是及时复盘,知道哪里有效,哪里需要调整。
会被拆成:
1. 很多人学习效率低,并不是因为不努力,而是方法错了。
2. 真正高效的学习,第一步是明确目标。
3. 第二步是拆分任务,把大目标变成每天能执行的小动作。
4. 第三步是及时复盘,知道哪里有效,哪里需要调整。
这种模式适合把普通文章、口播稿、小红书笔记、公众号段落快速转成短视频。
但它也有明显限制:
如果原文句子太长,每个镜头就会太长。
如果原文句子太短,每个镜头就会太碎。
如果原文没有明显标点,拆分效果会很差。
如果一句话里有多个视觉场景,系统不会自动进一步拆镜头。
所以 sentence 模式适合“快速转视频”,但不一定适合“精细控制”。
八、fixed 模式的完整流程
fixed 模式的完整流程可以画成这样:
用户输入完整脚本
↓
StandardPipeline.generate_content()
↓
mode != "generate"
↓
读取 split_mode,默认 paragraph
↓
split_narration_script()
↓
得到 ctx.narrations
↓
determine_title()
↓
如果用户没给标题,则 LLM 生成标题
↓
plan_visuals()
↓
根据模板类型决定是否生成 image_prompts
↓
initialize_storyboard()
↓
每段 narration 变成一个 StoryboardFrame
↓
produce_assets()
↓
FrameProcessor 逐帧生成音频、媒体、画面和 segment
↓
post_production()
↓
拼接视频片段,添加 BGM
↓
finalize()
↓
保存结果和任务元数据
也就是说,fixed 模式只替换了最前面的内容生成部分。
从 ctx.narrations 之后,它和 generate 模式基本汇合。
这也是 Pixelle-Video 设计得比较好的地方:
generate 模式输出 narrations
fixed 模式也输出 narrations
只要变成 narrations,后面的流程就可以复用
这种设计让系统扩展很自然。
未来你还可以增加其他内容来源,比如:
从网页文章提取 narration
从 PDF 文档提取 narration
从字幕文件 SRT 提取 narration
从 Markdown 大纲生成 narration
从 Excel 表格批量生成 narration
只要最后输出 narration 列表,就能接入后面的生成链路。
九、从 narration 到 StoryboardFrame
fixed 模式拆分完成后,initialize_storyboard() 会把每一段 narration 转成 StoryboardFrame。
源码中创建 StoryboardConfig 后,会创建 Storyboard 对象,然后遍历 zip(ctx.narrations, ctx.image_prompts),为每一组 narration 和 image_prompt 创建一个 StoryboardFrame,并设置 index、narration、image_prompt、created_at。
可以理解为:
脚本文案第 1 段 → frame 0
脚本文案第 2 段 → frame 1
脚本文案第 3 段 → frame 2
每个 frame 后面都会进入 FrameProcessor。
FrameProcessor 的注释说明,它负责单个 frame 的完整处理流程,包括 TTS、图片生成、画面合成、视频片段生成,并且以 TTS 音频时长驱动视频时长,保证音频和画面同步。
所以 fixed 模式里,每一段文案都不是简单的文本,而是后续整个视频片段的起点:
narration
↓
TTS 音频
↓
图片/视频素材
↓
模板画面
↓
视频片段
这就是为什么 fixed 模式要求用户提前把脚本分好段。
分段质量会直接影响视频质量。
十、fixed 模式和 generate 模式的核心区别
我们可以把两种模式放在一起对比。
generate 模式:
输入:主题
文案来源:LLM 自动生成
分镜数量:由 n_scenes 控制
可控性:较低
自动化程度:较高
适合:快速生成、测试选题、批量创作
fixed 模式:
输入:完整脚本
文案来源:用户提供
分镜数量:由 split_mode 和脚本结构决定
可控性:较高
自动化程度:中等
适合:已审核文案、商业视频、口播稿转视频、账号风格固定
一句话总结:
generate 模式适合从 0 到 1,fixed 模式适合从文案到视频。
如果你没有文案,只想快速生成一条视频,可以用 generate。
如果你已经有文案,或者对内容准确性要求很高,应该用 fixed。
十一、fixed 模式下 n_scenes 为什么被忽略?
源码中特别记录了一句日志:
Note: n_scenes is ignored in fixed mode
这不是小细节,而是 fixed 模式的核心特征。
在 generate 模式中,n_scenes 的作用是告诉 LLM:
请生成 5 段旁白
但在 fixed 模式中,旁白段落已经由用户脚本决定。
如果用户写了 3 段,系统就拆成 3 段。
如果用户写了 10 行,系统就拆成 10 段。
如果用户写了一篇有 20 个句子的文章,sentence 模式可能拆成 20 段。
这时再用 n_scenes 强行控制数量,反而会破坏用户原文。
所以 fixed 模式选择忽略 n_scenes 是合理的。
但这也提醒我们:
在 fixed 模式下,用户必须自己控制脚本结构。
如果想要 5 个镜头,就写 5 段。
如果想要 8 个镜头,就写 8 行或 8 个段落。
十二、三种拆分模式怎么选?
实际使用时,可以按下面原则选择。
1. 做高质量短视频,选 paragraph
如果你已经认真写好脚本,并且希望每个镜头都有明确节奏,优先用段落拆分。
推荐格式:
第一段:开头钩子
第二段:提出问题
第三段:解释原因
第四段:给出方法
第五段:总结或反转
每段之间空一行。
这样最容易控制画面、配音和节奏。
2. 做短平快内容,选 line
如果你做的是 15 秒、30 秒的短视频,一行一句就够了。
推荐格式:
一句痛点
一句反常识
一句解释
一句方法
一句总结
这种方式节奏快,适合短视频平台。
3. 从文章快速转视频,选 sentence
如果你有一篇现成文章,不想手动分段,可以用 sentence。
但最好先检查一下原文标点,把特别长的句子拆短,把太抽象的句子改得更有画面感。
否则生成出来的视频可能节奏不稳。
十三、fixed 模式的一个实际示例
假设我们要做一条关于“学习效率”的短视频。
用户输入 fixed script:
很多人学习效率低,并不是因为不努力,而是方法错了。
真正高效的学习,第一步是明确目标。你要知道今天到底要完成什么。
第二步是拆分任务。不要一上来就想着学完整本书,而是先完成一小节。
第三步是及时复盘。每天花五分钟看看哪里有效,哪里浪费了时间。
当你能持续优化方法,学习效率自然会慢慢提升。
选择:
mode = fixed
split_mode = paragraph
template = image_default.html
tts_voice = zh-CN-YunjianNeural
bgm_mode = loop
系统内部会变成:
ctx.narrations = [
"很多人学习效率低,并不是因为不努力,而是方法错了。",
"真正高效的学习,第一步是明确目标。你要知道今天到底要完成什么。",
"第二步是拆分任务。不要一上来就想着学完整本书,而是先完成一小节。",
"第三步是及时复盘。每天花五分钟看看哪里有效,哪里浪费了时间。",
"当你能持续优化方法,学习效率自然会慢慢提升。"
]
然后继续生成:
5 段 TTS 音频
5 个图片提示词
5 张图片或 5 段视频素材
5 个视频片段
1 个最终 MP4
这就是 fixed 模式的核心价值:
你控制内容,Pixelle-Video 控制生产流程。
十四、固定文案模式特别适合哪些场景?
fixed 模式适合这些场景。
1. 健康、财经、法律等高风险内容
这类内容不能完全依赖 AI 即兴生成。
你可以先人工写稿或审核,再让 Pixelle-Video 做配音和合成。
2. 产品介绍视频
产品卖点、功能描述、价格信息、使用步骤都应该准确。
fixed 模式可以保证文案不乱改。
3. 课程和知识付费内容
课程脚本通常需要结构严谨。
fixed 模式可以把已经打磨好的讲稿转成视频。
4. 批量口播稿转视频
如果你已经有大量口播稿,可以按段落整理,然后批量生成视频。
5. 账号风格固定的短视频
比如你有固定的开头、固定的结尾、固定的话术,fixed 模式更容易保持一致。
十五、fixed 模式的优点
fixed 模式最大的优点是可控。
具体来说,有几个方面。
第一,文案可控。
系统不会重新改写你的核心表达。
第二,结构可控。
你写几段,基本就对应几个分镜。
第三,风格可控。
你可以保持自己的表达习惯,不受 LLM 风格影响。
第四,审核可控。
文案可以先人工审核,再生成视频。
第五,成本可控。
如果搭配 static 模板和手动标题,可以减少 LLM 和媒体生成调用。
第六,适合批量生产。
一批脚本按统一格式整理后,就可以进入同一套视频生成流程。
十六、fixed 模式也有不足
fixed 模式虽然可控,但也不是万能的。
1. 不会自动优化文案
如果你的脚本节奏很差,fixed 模式不会主动帮你改。
比如:
这个方法非常重要,因为它在很多情况下都能够帮助我们更好地提升整体效率,并且在实际操作过程中也会带来很多不一样的体验。
这句话太长,TTS 会拖,画面也不好配。
fixed 模式会照着读,不会自动压缩。
2. 分段质量完全取决于用户
如果你一整篇文章没有空行,又选择 paragraph 模式,那可能只会拆出一个 narration。
如果你每行只有两三个字,又选择 line 模式,视频会碎成很多短片段。
3. 画面提示词仍可能不稳定
如果使用 image/video 模板,后续的 image prompts 仍可能由 LLM 生成。
文案越抽象,生成画面越难。
4. 标题可能仍被 AI 生成
如果你不传标题,fixed 模式下系统仍可能调用 LLM 生成标题。
如果你希望完全控制结果,最好手动填写标题。
十七、使用 fixed 模式的脚本写法建议
如果你真的要用 fixed 模式生成短视频,建议脚本这样写。
第一,每段只表达一个意思。
不要一段里又讲痛点,又讲原因,又讲解决方案。
最好一个段落对应一个镜头。
第二,每段长度控制在 1 到 3 句话。
太短,视频碎。
太长,配音拖。
第三,尽量写具体画面。
比如不要只写:
很多人都很焦虑。
可以改成:
深夜十一点,很多人还在刷手机,一边焦虑明天的工作,一边停不下来。
后者更容易生成画面。
第四,开头要有钩子。
短视频前 3 秒很重要。
第一段最好直接提出痛点、反常识或强问题。
第五,结尾要有收束。
最后一段最好总结观点,或者给用户一个明确动作。
第六,如果要完全控制内容,手动填写标题。
这样可以避免系统调用 LLM 重新生成标题。
十八、二次开发可以怎么优化 fixed 模式?
如果你想基于 Pixelle-Video 做二次开发,fixed 模式有不少可优化点。
1. 增加“预览拆分结果”
现在 fixed 模式的拆分逻辑很清楚,但用户最好能在生成前看到:
系统拆出了几段?
每段是什么?
每段预计配音多长?
是否有段落太长?
是否有段落太短?
这样可以减少生成失败或效果不佳的情况。
2. 增加“智能拆分但不改写”
可以增加一个新模式:
smart_split
它不改写用户文案,只让 LLM 帮忙把文案拆成更适合短视频的片段。
这样兼顾 fixed 的可控性和 AI 的辅助能力。
3. 增加“长度检查”
在 split_narration_script() 后,可以检查每段长度。
例如:
少于 8 个字:提示太短
超过 80 个字:提示太长
超过 150 个字:建议拆分
这样能提升视频节奏。
4. 增加“镜头可视化检查”
如果某段 narration 太抽象,可以提示用户改写。
比如:
人生的本质是不断寻找秩序。
可以提示:
这句话比较抽象,建议改成具体场景,方便生成画面。
5. 增加 SRT 字幕导入
很多用户已经有字幕文件。
如果支持 SRT,就可以直接把字幕片段转成 narration,并保留时间轴。
6. 增加 Markdown 分镜格式
可以让用户这样写:
## 镜头 1
旁白:很多人学习效率低,并不是因为不努力。
画面:深夜书桌,年轻人疲惫学习。
## 镜头 2
旁白:真正的问题,是目标太大。
画面:白板上写着巨大目标,被拆成几个小任务。
这样可以同时控制 narration 和 image_prompt。
这个方向很适合把 Pixelle-Video 改造成专业的短视频脚本工具。
十九、源码阅读建议
如果你要读 fixed 模式相关源码,可以按这个顺序:
1. pixelle_video/pipelines/standard.py
看 generate_content() 如何根据 mode 分支进入 fixed 模式
2. pixelle_video/utils/content_generators.py
看 split_narration_script() 的 paragraph / line / sentence 拆分逻辑
3. pixelle_video/pipelines/standard.py
继续看 determine_title(),注意 fixed 模式下无标题时会调用 LLM
4. pixelle_video/pipelines/standard.py
看 plan_visuals(),理解 fixed 文案如何继续生成图片提示词
5. pixelle_video/models/storyboard.py
看 narration 如何变成 StoryboardFrame
6. pixelle_video/services/frame_processor.py
看每个 frame 如何继续生成音频、画面和视频片段
这个阅读顺序能把 fixed 模式从入口到最终视频片段串起来。
二十、总结
这一篇我们分析了 Pixelle-Video 的固定文案模式。
fixed 模式的核心链路是:
用户输入完整脚本
↓
mode = fixed
↓
split_narration_script()
↓
paragraph / line / sentence 拆分
↓
ctx.narrations
↓
生成标题或使用用户标题
↓
根据模板决定是否生成图片提示词
↓
创建 StoryboardFrame
↓
TTS 配音
↓
生成图片/视频素材
↓
模板渲染
↓
生成视频片段
↓
拼接最终视频
它和 generate 模式最大的区别是:
generate 模式:
AI 根据主题写文案
fixed 模式:
用户提供文案,系统只负责拆分和视频化
fixed 模式特别适合那些对内容准确性、风格一致性、审核流程有要求的场景。
如果一句话总结:
Pixelle-Video 的 fixed 模式,本质上是把用户写好的脚本转换成 narration 列表,然后复用后续的配图、配音、模板渲染和视频合成流程。
651

被折叠的 条评论
为什么被折叠?



