快速摘要
Fun-CineForge 是由通义实验室语音团队联合中国科学技术大学发布的开源多模态电影配音模型，基于 MLLM（多模态大语言模型）架构，能够在零样本条件下完成影视场景的智能配音。 它的核心优势在于：不仅能"听"和"说"，还能"看"视频画面，精准识别谁在说话、什么时候说话，并实现口型同步、音色自然切换和情感表达。项目同时开源了首个大规模中文电视剧配音数据集 CineDub-CN（超过 4700 小时），以及完整的端到端数据集制作流水线。无论你是影视从业者、AI 研究者还是视频创作爱好者，这篇文章都会帮你把 Fun-CineForge 的技术原理和实际操作流程彻底搞明白。往下看有更详细的拆解。
一、为什么我们需要 AI 电影配音？
莫潇羽@无忆研习社 最近在研究 AI 语音相关的开源项目时，发现了一个很有意思的现象：现在的短视频平台上，有大量的外语影视作品被翻译成中文配音，但质量参差不齐。有些配音声音和画面完全对不上，角色张嘴的时候配音还没开始，说完话了嘴还在动；有些虽然时间对上了，但所有角色的音色都像同一个人在说话，完全没有辨识度；还有些在多人对话场景下简直是一团糟，根本分不清谁在说什么。
回想以前看港剧的国语配音版本，那些专业配音演员能做到一个人分饰多角，声音切换非常自然，而且口型精准得惊人。这种高水准的配音体验，在 AI 技术时代，到底能不能被复现？
答案是：正在变成现实，而且速度比很多人想象的要快。
传统的 AI 配音方案——也就是所谓的"电影配音"（Movie Dubbing）技术——面临两个根本性的瓶颈。第一个瓶颈是数据层面的：现有的高质量多模态配音数据集规模很小，标注信息不够丰富，而且大多仅限于独白场景，很难覆盖真实的影视剧中那些复杂的多人对话。比如学术界常用的 V2C-Animation 数据集，总共只有一万多条片段、不到 7 小时的数据量。用这么小的数据集训练出来的模型，效果自然有限。第二个瓶颈是模型层面的：现有的配音模型大多只依赖嘴唇区域的视觉信息来做音视频对齐，这种方法在简单的正面特写镜头下还勉强能用，但一旦遇到侧脸、遮挡、多人同框、快速切换镜头等复杂场景，就会严重失准。
Fun-CineForge 正是为了解决这两个瓶颈而生的。
在深入了解 Fun-CineForge 之前，有必要先简单梳理一下"电影配音"（Movie Dubbing）这个 AI 任务的定义和技术背景。从学术角度来说，电影配音任务是在视频场景的条件约束下，根据给定的文字台词来合成语音。这个任务看起来和普通的文本转语音（TTS）很类似，但实际上要复杂得多，因为它需要同时满足多个约束条件：合成的语音必须和视频中角色的嘴唇运动精确对齐（唇语同步），必须使用正确的角色音色（音色迁移），必须符合场景的情感氛围（情感表达），还必须在时间上精确匹配视频的节奏（时间对齐）。
早期的电影配音方法主要依赖传统的信号处理技术，后来随着深度学习的发展，出现了基于编码器-解码器架构的方案（如 V2C 系列）。但这些方法大多只关注降低发音错误率这一个维度，对口型同步和声学质量的重视不够。近两年，随着大语言模型（LLM）和多模态学习技术的飞速发展，研究者们开始将 LLM 引入配音系统的设计中，催生了 FlowDubber、DeepDubber、InstructDubber 等一系列新方法。Fun-CineForge 正是这一技术浪潮中最新、也是最完整的代表之一。
二、Fun-CineForge 到底是什么？
Fun-CineForge 是一个端到端的电影配音解决方案，由两个核心部分组成：一套完整的数据集生产流水线，以及一个基于多模态大语言模型（MLLM）架构的配音模型。
用更直白的话来说，它能做到这些事情：
给你一段无声的视频片段，加上配音台词文本、角色线索描述（比如"一位中年男性，语气沉稳有力"）、场景类别（独白、旁白、对话等），以及参考音频，Fun-CineForge 就能自动合成出与视频场景高度匹配的语音。合成的语音不仅口型对得上，音色能准确迁移，情感表达也自然贴切。
项目来自 FunAudioLLM 团队，这个团队隶属于通义实验室，此前已经发布过多个有影响力的语音 AI 开源项目，包括用于语音识别的 SenseVoice、用于语音生成的 CosyVoice，以及端到端语音识别大模型 Fun-ASR。Fun-CineForge 可以看作是这个生态体系中面向影视配音场景的新成员。
需要特别说明的是，Fun-CineForge 目前是学术研究性质的开源项目，并非商业产品。根据项目仓库的声明，它采用 Apache-2.0 开源协议发布，代码和推理脚本均可自由使用，但 CineDub 数据集的使用受到特定许可条款的约束。
三、技术原理深度解析
这一部分是整篇文章的重头戏，莫潇羽@无忆研习社 会尽量用通俗的语言把 Fun-CineForge 的技术架构讲清楚。
3.1 整体架构概览
Fun-CineForge 的配音模型由两个紧密协作的模块组成：
第一个模块是 MLLM 多模态对齐模块，负责理解和对齐多种模态的信息。它接收视频帧序列（包括全局画面和局部嘴唇区域）、文本台词、角色线索描述、场景类别等输入，然后通过一种创新的多模态对齐机制，同时建模三个关键问题——"哪里可以有语音"（时间定位）、"说的是什么"（文本对齐）、"嘴唇和语音是否对齐"（精细的唇语同步）。
第二个模块是流匹配（Flow Matching）语音合成模块，负责根据第一个模块输出的对齐信息和参考音频，生成最终的语音波形。这个模块特别设计了说话人切换机制，能够在多角色场景中自然地在不同音色之间转换。
这种两阶段的设计思路在最新的影视配音研究中是一个重要趋势——先让一个视觉-语言理解模型搞清楚场景中发生了什么，再让一个专门的语音生成器去合成对应的声音。相比于那些只盯着嘴唇区域做端到端生成的老方法，这种架构能够利用更丰富的上下文信息，因此在复杂场景下的表现要好得多。
3.2 多模态对齐机制：不只是"看嘴"
传统的配音模型在做音视频对齐时，通常只会从视频中提取嘴唇区域的图像序列，然后尝试让生成的语音和嘴唇运动匹配。这种方法有一个明显的短板：真实的电影场景中，说话人的嘴唇经常被遮挡，或者摄影机在不同角色之间快速切换，单纯依赖嘴唇信息远远不够。
Fun-CineForge 的 MLLM 模块采用了一种更全面的方式。它不仅关注嘴唇，还整合了以下几类信息：
全局视频帧：理解画面中正在发生什么，比如场景是室内还是室外、画面中有几个人、当前的情感氛围是什么样的。这些全局信息对于确定合适的语调和情感表达非常重要。
局部嘴唇序列：提取说话人面部和嘴唇区域的逐帧图像，用于实现精细的唇语同步。数据集流水线中的说话人识别模块会预先把每一帧中每个说话人的面部和嘴唇区域裁剪出来，作为训练和推理的输入。
文本台词与线索描述：文本台词告诉模型"说什么"，而线索描述（Clue）则以自然语言的方式告诉模型"怎么说"。比如一条典型的线索描述可能是"一位青年男性，语气中充满对已逝亲人的深切怀念与对过去美好生活的向往，语调柔和，略带感伤"。这种自然语言形式的指令让模型能够细腻地控制语音的情感和韵律。
时间信息：包括每段对话的精确起止时间戳，以及说话人的活动时间区间。这些时间信息让模型能够精准地知道在视频的哪个时间点开始和结束说话，解决了时间对齐的问题。
通过联合建模这些多维度的信息，Fun-CineForge 实现了一种比传统方法更加鲁棒的对齐策略。即使在嘴唇被遮挡、说话人偏头、多人交叉说话等复杂情况下，模型依然能够给出合理的语音输出。
3.3 流匹配语音合成：高质量声音的秘密
流匹配（Flow Matching）是近几年在生成式模型领域崛起的一种方法，它可以看作是扩散模型（Diffusion Model）的一种高效变体。相比于传统的扩散模型需要上百步的迭代去噪，流匹配通常只需要 5 到 10 步迭代就能生成高质量的输出，推理效率大幅提升。
Fun-CineForge 的语音合成模块正是基于流匹配框架构建的。它的工作方式大致如下：
首先，MLLM 模块输出的对齐信息被编码为一组条件向量。这些条件向量包含了语音的时长、韵律节奏、情感色彩等关键控制信号。
然后，参考音频通过一个编码器被转换为说话人音色的表征向量。这就是所谓的"零样本音色迁移"——只需要一小段参考音频，模型就能"学会"这个说话人的声音特征，并在后续的合成中使用这个音色。
最后，流匹配模块以这些条件向量和音色表征为输入，从一个噪声分布出发，通过若干步迭代，逐步"流向"目标语音的梅尔频谱。生成的梅尔频谱再经过声码器（Vocoder）转换为最终的音频波形。
值得注意的是，Fun-CineForge 在流匹配模块中特别引入了说话人切换机制。在多人对话场景中，不同角色的台词是交替出现的，模型需要在不同的音色之间快速切换。传统的方法通常是为每段台词单独生成语音再拼接，容易出现不连贯的问题。而 Fun-CineForge 的设计让模型能够在一次推理过程中就完成多个说话人的语音生成，过渡更加自然流畅。
为了让大家更直观地理解流匹配的工作方式，我们可以做一个类比：想象你面前有一张纯噪点的图片（就像电视没信号时的雪花屏），流匹配的过程就像是有一个看不见的"引力场"在慢慢把这些随机噪点拉向正确的位置，经过几步迭代之后，噪点逐渐排列成了一张清晰的图片——在 Fun-CineForge 的场景中，这张"图片"就是语音的梅尔频谱图。而条件信息（文本内容、口型对齐、情感线索、音色参考等）就像是这个引力场的"塑形模具"，决定了噪点最终会"流向"什么样的目标形状。
流匹配相比传统扩散模型的核心优势在于"路径更直"——它学习的是从噪声到目标的最优传输路径（Optimal Transport），而不像扩散模型那样需要经过复杂的曲折路径来回去噪。这种更高效的路径规划让流匹配只需 5-10 步就能完成高质量的生成，大幅降低了推理延迟。
3.4 场景覆盖能力
Fun-CineForge 能够处理四种主要的影视配音场景：
独白（Monologue）：单个角色面对镜头说话，这是最基础也最常见的配音场景。模型需要精确对齐口型，并保持一致的音色和情感。
旁白（Narration）：画外音叙述，说话人不在画面中出现。这种场景不需要口型同步，但对语音的自然度和情感表达有较高要求。
对话（Dialogue）：两个角色之间的交流，需要模型在两种音色之间切换，并正确处理对话的节奏和情感互动。
多人说话（Multi-speaker）：三个或更多角色同时出现在场景中，说话人频繁切换，甚至可能出现多人同时说话的情况。这是最具挑战性的场景，也是 Fun-CineForge 相比同类方法优势最明显的地方。
根据论文中报告的实验数据，在上述所有场景类型下，Fun-CineForge 在多个评估维度上都超过了当前最先进的方法。这里有必要解释一下这些评估指标的含义，方便不太了解语音领域的读者理解：
MOS（Mean Opinion Score，平均主观评分）：这是评估语音质量最经典的指标，通常由人类评估者打出 1-5 分的评分，分数越高表示语音越自然、越接近真人说话。Fun-CineForge 在各个场景下的 MOS 评分都表现优秀，尤其是在多人说话场景下的优势最为明显。
LSE-D（Lip Sync Error - Distance）：衡量生成语音和视频中嘴唇运动之间的同步程度。数值越低表示同步越精准。论文报告 Fun-CineForge 在独白场景下的 LSE-D 达到了 3.82，这意味着语音和口型之间的偏差非常小，肉眼几乎察觉不到不同步的感觉。
SPK-SIM（Speaker Similarity，说话人相似度）：衡量生成语音的音色和参考音频的音色之间的相似程度。数值越高表示音色迁移越成功。Fun-CineForge 的 SPK-SIM 达到了 76.5%，也就是说，生成的声音和参考音色之间有很高的匹配度。
CER（Character Error Rate，字符错误率）：衡量生成语音中发音错误的比例。这个指标直接反映了"模型有没有说对台词"这个基本问题。经过多模态 CoT 修正后的训练数据，CER 仅为 0.94%，远低于未修正版本的 4.53%。
ES-MOS（Emotional Style MOS）：专门评估语音情感表达的自然度和准确度。Fun-CineForge 报告的 ES-MOS 达到 3.80，说明模型不仅能说对字、对上口型，还能较好地传达角色的情感状态。
一个特别值得关注的对比实验是：用之前的小规模数据集（V2C-Animation、Chem、GRID）训练出的模型，在口型同步和发音质量上都明显逊色于用 CineDub-CN 训练的模型。更进一步，用经过 CoT 修正的 CineDub-CN 数据训练的模型，又比用未修正版本训练的模型有显著提升。这充分证明了高质量大规模数据集对于配音模型性能的决定性作用。
四、CineDub-CN：首个大规模中文电视剧配音数据集
除了配音模型本身，Fun-CineForge 的另一个重大贡献是 CineDub-CN 数据集。这是目前首个专门为影视配音任务构建的大规模中文数据集，莫潇羽@无忆研习社 认为这对整个中文语音生成研究领域都是一件大事。
4.1 数据集规模与特点
CineDub-CN 包含超过 4700 小时的中文电视剧配音数据，由超过 150 万条精细分割的视频-音频-文本片段组成。相比此前学术界常用的几个配音数据集（如 V2C-Animation 的 6.8 小时、GRID 的有限规模），CineDub-CN 在数据量上实现了数量级的飞跃。
数据集的标注信息非常丰富，每一条数据都包含以下内容：
精确的文本转录：包括标准化的语音转录文本，字符错误率（CER）经过多模态 CoT 修正后降低到了 0.94%，已经接近甚至优于人工转录的质量。
时间戳标注：帧级别的精确时间标注，记录了每段语音的起止时间和每个说话人的活动时间区间。
说话人属性标注：包括说话人的年龄段、性别，以及音色描述关键词（如"沉稳有力""清脆活泼"等）。
场景类别标注：将每个片段划分为独白、旁白、对话或多人说话四种场景类型。
面部和嘴唇序列：为每个说话人提取了逐帧的面部和嘴唇区域图像。
情感和线索描述：以自然语言形式描述每段语音的情感特征和说话风格。这种自然语言形式的标注方式非常灵活，比传统的离散情感标签（如"开心""愤怒""悲伤"）能表达更加细腻和丰富的情感层次。
音频轨道：包括分离后的纯人声音频和背景音频。纯人声用于模型训练，背景音频在最终合成时可以重新混合回去，恢复场景的环境氛围感。
4.2 数据集的构建方法
CineDub-CN 的构建完全依赖 Fun-CineForge 提供的自动化数据集流水线，整个过程不需要人工标注。这一点非常重要，因为传统的配音数据集通常需要大量人力来做转录和标注，成本极高且难以规模化。
Fun-CineForge 的数据集流水线通过将多种专业模型的自动处理与多模态大语言模型的智能修正相结合，实现了接近人工质量的自动标注。具体的流水线步骤我们在下一节会详细讲解。
此外，项目最近的更新还增加了对英文视频的支持，并发布了 CineDub-EN 英文数据集样本。这意味着这套流水线工具不仅适用于中文，还可以用于英文乃至更多语言的配音数据集生产。
五、完整操作指南：从环境搭建到数据集生产
接下来，莫潇羽@无忆研习社 会手把手带你走一遍 Fun-CineForge 数据集流水线的完整操作流程。即使你是刚接触这个领域的小白，只要按照下面的步骤操作，也能跑通整个流程。
5.1 前置准备
硬件要求：数据集流水线中的部分步骤（如语音分离、说话人识别）建议使用 GPU 加速。如果你有 NVIDIA 显卡（建议至少 8GB 显存），整体处理速度会快很多。如果只有 CPU 也能跑，只是速度会慢不少。模型推理部分则需要消费级 GPU。
软件要求：Python 3.10 及以上版本，需要安装 Conda 环境管理工具和 FFmpeg 视频处理工具。
素材要求：如果你想自己制作配音数据集，建议准备的视频素材需要满足以下条件——来源是电视剧或电影（非纪录片），有较多的独白或对话场景，角色面部清晰且无遮挡（比如不要有面具、面纱等）；语音要求发音标准、吐字清晰、人声突出，尽量避免方言过重或背景噪音过大的素材；画面要求分辨率高、面部细节清晰、光线充足，避免极暗或强逆光场景。
5.2 环境安装
在正式开始操作之前，我们先来整体看一下数据集流水线的完整流程图，方便你对后续每一步的作用有一个全局性的认知：
原始视频素材
│
▼
[步骤1] 标准化 & 裁剪 ──→ 统一格式，去掉片头片尾，提取音频
│
▼
[步骤2] 语音分离 ──→ 人声和背景音乐/音效分开
│
▼
[步骤3] 视频智能剪辑 ──→ ASR 识别字幕 → 按句切割成短片段 → 清理异常片段
│
▼
[步骤4] 多模态说话人识别 ──→ 生成 RTTM → 人脸检测追踪 → 活跃说话人判断 → 裁剪面部/嘴唇
│
▼
[步骤5] 多模态 CoT 修正 ──→ 大语言模型思维链推理纠错 + 标注角色属性
│
▼
[可选] 语音 Token 提取 ──→ CosyVoice3 Tokenizer 转为离散 Token
│
▼
最终数据集（可直接用于模型训练）每一步的输出都是下一步的输入，形成了一个严格的串行流水线。如果某一步出了问题，直接影响后续所有环节的质量，所以莫潇羽建议你在每一步完成后都做一次快速的质量抽检。
现在我们进入具体的操作环节。首先克隆项目代码并创建 Python 环境：
# 克隆代码仓库
git clone git@github.com:FunAudioLLM/FunCineForge.git
# 创建并激活 Conda 环境
conda create -n FunCineForge python=3.10 -y && conda activate FunCineForge
# 安装 FFmpeg（如果系统还没装的话）
sudo apt-get install ffmpeg
# 运行初始化设置脚本
python setup.pysetup.py 脚本会自动下载和配置各个子模块所需的依赖项。如果在国内网络环境下遇到下载速度慢的问题，可以考虑配置国内的 pip 镜像源（如阿里云镜像 https://mirrors.aliyun.com/pypi/simple/）来加速依赖安装。
安装完成后，将你准备好的视频素材放到 datasets/raw_zh 目录下（如果是英文素材则放到 datasets/raw_en）。
5.3 第一步：视频标准化与裁剪
这一步的目的是统一视频的格式和命名规范，并裁剪掉长视频开头和结尾的片头片尾部分（这些部分通常包含标题、字幕、制作人信息等，不适合用于配音数据集）。
python normalize_trim.py --root datasets/raw_zh --intro 10 --outro 10这条命令会处理 datasets/raw_zh 目录下的所有视频文件，默认裁掉开头和结尾各 10 秒。如果你的视频片头片尾比较长，可以把 --intro 和 --outro 的值调大。处理完成后，脚本还会自动从裁剪后的视频中提取纯音频文件，方便后续步骤使用。
莫潇羽的实操建议：如果你处理的是完整的电视剧集，片头片尾可能有 60-90 秒，这时候把裁剪值设大一些效果更好。如果是已经剪辑好的短片段，可以把值设为 0。
5.4 第二步：语音分离
这一步是把视频音频中的人声和背景音乐、环境音效分离开来。这是整个流水线中非常关键的一步，因为如果人声中混杂了大量背景音，后续的语音识别和说话人识别都会受到严重影响。
cd speech_separation
python run.py --root datasets/clean/zh --gpus 0 1 2 3--gpus 参数指定使用哪些 GPU 来并行处理。如果你只有一张 GPU，就写 --gpus 0；如果有多张就按编号列出，处理速度会按比例提升。分离后的纯人声音频会保存在 datasets/clean/zh 目录下对应的位置。
Fun-CineForge 在语音分离这个环节使用的是 ClearerVoice-Studio 的技术方案，它同样来自 FunAudioLLM 生态体系，在语音增强和分离任务上表现非常出色。
5.5 第三步：视频智能剪辑
长视频需要被切割成一个个短片段，每个片段对应一句或一段完整的台词。这一步使用了 VideoClipper 工具，它会先对视频进行语音识别获取句子级别的字幕文件（SRT 格式），然后根据时间戳把长视频剪辑成对应的短片段。
cd video_clip
bash run.sh --stage 1 --stop_stage 2 --input datasets/raw_zh --output datasets/clean/zh --lang zh --device cpu几个关键参数说明：--lang zh 表示处理中文视频（如果是英文则改为 --lang en）；--device cpu 表示使用 CPU 运行，中文语音识别用 CPU 就够了，但英文建议改成 --device cuda 用 GPU 加速。
剪辑完成后，还需要运行两个清理脚本，确保生成的片段质量合格：
# 检查视频时长是否在合理范围内
python clean_video.py --root datasets/clean/zh
# 检查字幕文件的格式和内容是否正确
python clean_srt.py --root datasets/clean/zh --lang zh这两个脚本默认只会打印出需要删除的问题文件列表，让你先检查确认。确认无误后，加上 --execute 参数才会真正执行删除操作。这种"预览+确认"的设计很贴心，避免误删。
5.6 第四步：多模态说话人识别
这是流水线中技术含量很高的一步。它要完成三个任务：通过多模态活跃说话人识别（Active Speaker Detection）生成 RTTM 格式的说话人标注文件；识别每一帧画面中说话人的面部位置；提取帧级别的面部和嘴唇区域图像。
cd speaker_diarization
bash run.sh --stage 1 --stop_stage 4 --hf_access_token hf_xxx --root datasets/clean/zh --gpus "0 1 2 3"注意 --hf_access_token 需要填入你自己的 Hugging Face 访问令牌，因为部分预训练模型需要通过 Hugging Face 下载。如果你还没有 Hugging Face 账号，需要先注册一个并创建 Access Token。
说话人识别流程的内部工作原理大致是这样的：首先通过语音活动检测（VAD）找到音频中有人说话的时间段；然后用人脸检测和追踪模型在视频帧中定位所有出现的人脸；接着结合音频信号和视频中人脸嘴唇运动的信息，判断每个时间段是哪个人在说话；最后为每个被识别出的说话人裁剪出对应的面部和嘴唇图像序列。
这里补充一些技术细节：说话人识别（Speaker Diarization）是语音处理领域中的一个经典问题，它的目标是回答"谁在什么时候说话"这个问题。传统的纯音频说话人识别方法通常采用特征提取加无监督聚类的流程——先用 VAD 过滤掉非语音片段，再用滑窗方式提取说话人嵌入向量（Speaker Embedding），最后通过聚类算法将属于同一说话人的片段归为一组。但这种纯音频方法在多人同时说话或声音相似的场景下容易出错。
Fun-CineForge 采用的是多模态活跃说话人识别（Audio-Visual Active Speaker Detection）方法，同时利用音频和视频两个维度的信息。视频提供了"嘴唇在动的是谁"这一关键线索，音频提供了"声音来自谁"的信息。两者结合可以更准确地判断活跃说话人的身份，尤其在多人同框的场景中效果提升明显。
整个说话人识别模块分为四个子阶段（对应脚本中的 stage 1 到 stage 4）：子阶段一是生成 RTTM 标注文件，记录每个说话人的活动时间区间；子阶段二是面部检测和追踪，定位视频中每一帧的人脸位置；子阶段三是活跃说话人检测，判断哪个人脸对应当前正在说话的人；子阶段四是面部和嘴唇区域的裁剪和导出，为后续的配音模型训练提供精细的视觉输入数据。
RTTM（Rich Transcription Time Marked）文件是一种记录说话人时间信息的标准格式，每一行记录了某个说话人在什么时间开始说话、说了多长时间。
5.7 第五步：多模态 CoT 智能修正（重点）
这一步是整个数据集流水线中最有创意、也最值得深入理解的环节。
前面几步使用了各种专业模型来处理视频和音频，但这些模型各自都有一定的错误率——语音识别可能认错字，说话人识别可能搞混身份，时间戳可能有偏差。如果直接使用这些有瑕疵的结果来训练配音模型，模型的上限就会被数据质量拖累。
Fun-CineForge 的解决方案是引入通用的多模态大语言模型（比如 Gemini）作为"质量审核员"。具体来说，系统会把音频、语音识别文本、说话人标注文件（RTTM）等多种信息一起送给大语言模型，利用思维链（Chain-of-Thought，简称 CoT）推理来逐步分析和修正前面步骤的结果。
所谓思维链推理，就是让模型像人类一样一步步思考：先听音频判断大致内容，再对照 ASR 文本找出可能的错误，然后结合视频画面中谁在张嘴来验证说话人标注是否正确，最后给出修正后的结果。
除了修正错误，这个步骤还会为每段对话标注角色的年龄段、性别和音色描述关键词。这些标注信息对于后续训练配音模型非常有价值，因为它们提供了丰富的角色声音特征描述。
# 处理中文数据
python cot.py --root_dir datasets/clean/zh --lang zh --provider google --model gemini-3-pro-preview --api_key xxx --resume
# 处理英文数据（如果有的话）
python cot.py --root_dir datasets/clean/en --lang en --provider google --model gemini-3-pro-preview --api_key xxx --resume
# 构建最终的数据集文件
python build_datasets.py --root_zh datasets/clean/zh --root_en datasets/clean/en --out_dir datasets/clean --save几点说明：--provider google 和 --model gemini-3-pro-preview 指定使用 Google 的 Gemini 模型作为 CoT 修正的底座模型，你需要配置对应的 API 密钥。理论上你也可以尝试替换为其他支持多模态输入的大语言模型。--resume 参数非常实用，它启用了断点续传功能——如果处理过程中因为网络问题或 API 调用限额而中断，重新运行时不会从头开始，而是从上次中断的位置继续，避免重复推理浪费资源和费用。
根据论文中的实验数据，经过这一步修正后的效果非常显著：字符错误率（CER）从 4.53% 降低到了 0.94%，说话人识别错误率（DER）从 8.38% 降低到了 1.20%。这个质量已经达到甚至超过了人工转录的水平，可以说是整个流水线中画龙点睛的一笔。
5.8 可选步骤：语音 Token 提取
如果你计划用生成的数据集来训练自己的配音模型（而不只是使用预训练好的 Fun-CineForge 模型），还可以用 CosyVoice3 的 Tokenizer 来提取语音 Token：
python speech_tokenizer.py --root datasets/clean/zh这一步会把原始语音波形转换为离散的语音 Token 序列，方便后续作为大语言模型训练的输入。CosyVoice3 是 FunAudioLLM 团队的语音生成模型，其 Tokenizer 能够高效地将连续的语音信号压缩为离散的 Token 表示，同时保留语音的韵律和音色信息。
六、模型推理：怎么用 Fun-CineForge 给视频配音
了解完数据集流水线之后，我们来看看怎么直接使用 Fun-CineForge 的预训练模型来给视频配音。
6.1 推理环境
Fun-CineForge 的推理代码和模型权重已经在 2026 年 3 月 16 日正式开源。根据 GitHub 仓库的说明，推理只需要消费级 GPU 即可运行。项目在 exps 目录下提供了推理脚本和测试用例。
6.2 基本推理流程
cd exps
bash infer.sh运行 infer.sh 脚本后，模型会读取 data 文件夹中的测试用例（包含视频片段、配音台词、角色线索、参考音频等），然后自动完成配音生成。
为了帮助大家更好地理解推理过程中到底发生了什么，这里用一个具体的例子来说明。假设我们要给一段电视剧中的双人对话场景配音，输入数据包
