NarratoAI 0.8 系列深度解析：AI 解说剪辑如何从"自动化脚本"进化为"创作者工作台"

本文由 莫潇羽@源码七号站（www.fuyuan7.com）撰写，转载请注明出处。

快速摘要： NarratoAI 0.8 系列（截至2026年7月已迭代到 0.8.4）并不是一次普通的"加几个按钮"式更新。它把短剧解说、影视解说、字幕转录、多视频剪辑、AI 配音、字幕遮罩、生成进度可视化和剪映草稿导出串成了一条完整链路。核心变化在于：以前的 AI 剪辑工具偏向"一键出片"，而 0.8 系列把创作流程拆成了可审核、可修改、可干预的多个步骤——AI 负责粗活和初稿，创作者保留判断权和审美。本文从项目演进、技术架构、解说流程、字幕系统、配音引擎、部署实践到国内合规使用，全面拆解这个工具的里里外外。想看完整拆解，往下翻。

开篇：AI 解说视频创作，到底卡在哪？

我做内容这些年，见过太多人兴致勃勃地想入局影视解说或者短剧解说，最后卡住的往往不是"写文案"这个环节。文案可以憋一憋、改一改，总能出来。真正让人崩溃的，是那些看似不重要、实则极其耗时的杂活。

举个例子。你手头有五集短剧素材，每集自带硬字幕。你要做的事情包括：把字幕转录出来（或者手动敲）、看懂每集讲了什么、理清人物关系、写一段有节奏的解说文案、把文案里的每一句话对应到具体的画面时间戳、给视频配音、加上新字幕、遮掉原片的硬字幕避免重叠、最后合成输出。如果你还想精修——比如调换某个镜头、调整配音节奏、加点转场音效——还得把粗剪结果丢进剪映或者其他剪辑软件再加工。

这些步骤如果全靠人工，一条十分钟的解说视频从素材到成片，熟练工也要四到六个小时。新手可能要花一整天。

市面上当然有不少 AI 剪辑工具。但它们大部分的设计思路是"输入素材 → 自动生成 → 输出成片"，中间的过程是个黑盒。你拿到成品之后，能改的空间非常有限。文案不对？重来。画面匹配不准？重来。配音不喜欢？重来。每次"重来"都意味着大量时间沉没。

我折腾过好几个方案之后，开始理解一件事：创作者真正需要的不是"一键出片"的魔法按钮，而是一个能把重复劳动自动化、同时保留人工干预入口的工作台。

NarratoAI 的 0.8 系列，恰好踩在了这个点上。

这个工具本身是一个开源项目，基于大语言模型来理解视频内容、生成解说文案，再配合语音合成和视频处理引擎完成剪辑、配音、字幕等一系列动作。0.8 版本之前，它已经能跑通基本的"自动生成视频"流程。但 0.8 系列做了一个关键的方向调整：不再追求"一键到底"，而是把整个解说创作过程拆成了几个可以独立审核和修改的步骤——先理解剧情，再生成文案让你改，改完再匹配画面，匹配完再配音加字幕，最后还能导出剪映草稿做精修。

这个思路变化，比功能列表里多出来的任何一个按钮都重要。它意味着 AI 的角色从"替代创作者"变成了"辅助创作者"。

接下来的内容，我会把这个工具的方方面面拆开来讲：从项目演进到技术骨架，从解说流程到字幕系统，从配音引擎到部署实践，再到国内的合规使用。中间会穿插表格、代码块和流程图，争取让原理和操作都能一目了然。我自己在部署和使用过程中踩过的坑，也会在对应的章节里如实交代。

如果你正在做或者打算做影视/短剧解说类内容，希望这篇文章能帮你省掉一些摸索的时间。

NarratoAI 项目全景：从 0.7 到 0.8.4 的进化图谱

先把这个项目的底细交代清楚。

NarratoAI 是一个托管在 GitHub 上的开源项目，核心功能一句话概括：利用 AI 大模型自动理解视频内容、生成解说文案，然后自动完成剪辑、配音和字幕合成。它不是一个 SaaS 服务（虽然也有云端托管版），主力形态是本地部署的 Python 应用，前端用 Streamlit 搭建 WebUI，背后串联了 LLM、ASR、TTS、FFmpeg 等一堆组件。

项目从 2024 年开始活跃，到 2026 年 7 月已经迭代了超过 400 个 commit，版本号从早期的 0.3.x 一路飙到现在的 0.8.4。节奏相当快——2025 年下半年到 2026 年上半年尤其密集，几乎每个月都有新版本。

光看版本号可能没感觉，我把最近几个关键版本的变化整理成了一张表，这样你能直观地看到这个工具的能力是怎么一层一层叠加上去的：

从这张表里能读出几条信息。

第一，0.7.x 系列的主线是"把基础设施搭稳"——统一 API 请求链路、优化缓存和并发、补齐 ASR 转录能力。这个阶段的 NarratoAI 更像一个"能跑起来的 AI 剪辑脚本"，功能有，但各个环节之间的衔接还不够顺滑。

第二，0.8.0 是一个分水岭。这次更新不是加功能，而是改架构——把原先偏线性的"输入→生成→输出"流程拆成了多步骤、可干预的工作流。短剧解说和影视解说被分成两条独立的处理链路，字幕从"上传一个 SRT 文件"升级为一套完整的转录-校准-遮罩系统，多视频素材管理、剪映草稿导出这些真正贴近创作实际的诉求也被正式纳入。

第三，0.8.1 和 0.8.4 说明项目在 0.8.0 的大框架下持续做精细化打磨。0.8.1 优化了剪映导出后的字幕匹配，0.8.4 升级了豆包 TTS 的配置方式——都不是惊天动地的改动，但都指向同一个方向：让工作流更顺，让使用者更少折腾。

我个人在 0.7.9 版本开始尝试这个工具，当时字幕转录刚变成一键操作，确实比手动敲字幕省了太多时间。但真正让我觉得"这东西可以纳入日常工具箱"的，是 0.8.0 的解说流程重构。后面章节会详细拆这个流程，这里先不展开。

还有一个值得提的背景：NarratoAI 在 2026 年的 AI 视频工具赛道上，并不是唯一的玩家。Recapo.ai 走的是全流程自动化路线，OpusClip 主打长视频高光提取，KrillinAI 偏向轻量化和 CLI 工作流。NarratoAI 的差异化在于——它选择了"开源本地部署 + 可干预工作流"这条路，既不像纯云端工具那样受限于服务可用性，也不像纯脚本工具那样需要使用者自己写大量代码。这个定位在后面讲部署和对比的时候会再细说。

总体来说，如果你把 0.7.x 看作"做好每一块积木"，那 0.8 系列就是"把这些积木拼成一个能灵活调整的工作台"。这个比喻不一定精准，但大致能概括我的感受。

技术骨架：四根柱子撑起 AI 解说工作台

每次聊到 AI 工具，我都倾向于先把技术骨架理清楚。不是因为我喜欢写技术文档——恰恰相反，是因为搞懂了骨架之后，后面遇到各种报错和奇怪现象，你至少知道该往哪个方向排查。NarratoAI 的技术骨架可以概括为四根柱子：LLM、ASR、TTS 和 CV（计算机视觉），外加一根横梁 FFmpeg 把一切串起来。

下面这张图是我梳理的技术流程，从左到右就是一次完整的解说视频生成过程：

flowchart LR
    A[视频素材 + 字幕文件] --> B[ASR 语音转录]
    B --> C[LLM 剧情分析]
    C --> D[LLM 文案生成]
    D --> E{人工审核修改}
    E -->|通过| F[LLM 画面匹配/时间戳]
    E -->|修改| D
    F --> G[TTS 配音生成]
    G --> H[CV 字幕遮罩]
    H --> I[FFmpeg 视频合成]
    I --> J[输出 MP4 / 剪映草稿]

这张图简化了不少细节，但主干是对的。下面逐个拆开讲。

LLM：不只是"写文案"

很多人对 LLM 在视频工具里的角色的理解止步于"自动写解说词"。但 NarratoAI 里 LLM 参与了三件不同的事。

第一件，剧情分析。视频素材导进来之后，系统会把字幕文本（不管是上传的还是转录的）喂给 LLM，让它理解剧情结构、人物关系、关键冲突和转折点。这一步的输出不是文案，而是一个结构化的剧情摘要。对于短剧这种人物多、节奏快、反转密集的内容，跳过这一步直接写文案，十次有八次会翻车——人物关系张冠李戴、时间线混乱、关键情节遗漏。

第二件，文案生成。基于剧情分析的结果，LLM 再按照你选的内容类型（短剧解说、影视解说、混剪等）和风格偏好来写解说文案。这里有一个很重要的设计：文案生成完之后，不会立刻进入下一步，而是停下来让你审核修改。你可以直接在 WebUI 的表格视图里编辑每一句文案，删掉不喜欢的表达，调整节奏，甚至改写整段。

第三件，画面匹配。这一步很多人容易忽略。文案有了之后，AI 需要把每一句解说词对应到视频素材的具体时间段上——"这句话配第 3 个视频的第 45 秒到第 58 秒"。如果时间戳匹配不准，就会出现"画面还在跑，解说已经说完了"或者"解说说的是人物 A，画面放的却是人物 B"的尴尬。LLM 在这里根据文案内容和字幕时间信息来做匹配推理。

我用一段伪代码来描述这个三阶段流程，比纯文字更直观：

# 伪代码：NarratoAI 的 LLM 三阶段调用
def narrato_llm_pipeline(video_subtitles, content_type):
    # 阶段 1：剧情理解
    plot_analysis = llm.analyze(
        input=video_subtitles,
        task="理解剧情结构、人物关系、关键转折",
        content_type=content_type  # "short_drama" or "movie"
    )

    # 阶段 2：文案生成（可审核修改）
    script_draft = llm.generate(
        context=plot_analysis,
        task="生成解说文案，控制节奏和悬念",
        style="口语化、有钩子"
    )
    # 用户在这里审核修改 script_draft
    script_final = user_review(script_draft)

    # 阶段 3：画面时间戳匹配
    timeline = llm.match(
        script=script_final,
        subtitles_with_timestamps=video_subtitles,
        task="将每句文案匹配到对应画面时间段"
    )

    return timeline

ASR：把语音变成可分析的文字

ASR（自动语音识别）在这套系统里的角色是把视频里的对白和旁白转成文字。没有这一步，LLM 就"看不懂"视频——它本质上只能读文本。

NarratoAI 0.8 系列支持了多种 ASR 引擎，这个设计挺聪明的。云端 ASR（比如阿里百炼 Fun-ASR）省事但依赖网络，本地 ASR（比如 FunASR-Pack、FireRedASR2）需要自己部署但不受网络限制。

对创作者来说，ASR 的准确率直接影响后续所有步骤的质量。如果转录出来的字幕里人名、地名、关键台词全是错的，LLM 的剧情分析再强也没用。所以这个环节没有太多花活，拼的就是底层引擎的识别精度。

TTS：解说声音的"最后一公里"

配音是解说视频的灵魂。一段好文案配上机械感十足的声音，观众的跳出感会非常强。NarratoAI 在 0.8 系列里把 TTS 引擎扩展到了八个以上——从云端的 Edge TTS、Azure、腾讯云、豆包，到本地的 IndexTTS、IndexTTS2、OmniVoice。

为什么要搞这么多选择？因为不同创作者的需求差异很大。做短剧解说的可能想要一个声音有戏剧张力、有情绪起伏，做纪录片风格的则需要平稳、克制的声线。如果只给一两个选项，很难覆盖这些需求。在后面的配音章节我会更详细地对比这些引擎的实际表现。

CV + FFmpeg：处理画面和合成视频

计算机视觉在 NarratoAI 里的主要应用是字幕遮罩——自动检测原视频中的硬字幕区域，生成一个模糊或纯色遮罩盖住它，然后再把新的解说字幕叠加上去。这个功能对经常处理"带硬字幕素材"的创作者来说，简直是救命级的存在。以前遇到这种情况只能手动裁剪画面或者忍受两层字幕打架，现在自动化了。

FFmpeg 则是最终把所有东西"组装"起来的胶水：裁剪视频片段、合并音轨、烧录字幕、合成输出。0.8 版本还专门加了 FFmpeg 引擎检测功能，能在 WebUI 里直接看到 FFmpeg 是否可用、支不支持硬件加速、能不能烧录字幕——对排查"为什么合成失败"这类问题帮助极大。

四根柱子加一根横梁，整体来看技术架构不算复杂，但把每个环节都打磨到"创作者能顺畅用起来"的程度，确实需要不少迭代。对使用者来说，理解这个骨架的最大好处是——出了问题你知道该去看哪根柱子。

解说流程深度拆解：从素材到成片的六道工序

前面说了技术骨架，这一章把它落到具体的操作步骤上。我会按一次完整的解说视频创作过程，从头到尾走一遍。如果你正准备上手，这一章可以当作"认知地图"来读，知道每一步在干什么、为什么要这么设计、有哪些地方需要注意。

先给一张六道工序的总览图：

flowchart TD
    A[① 导入素材] --> B[② 剧情分析]
    B --> C[③ 文案生成]
    C --> D[④ 画面匹配]
    D --> E[⑤ 配音与字幕]
    E --> F[⑥ 合成与导出]

    B1[LLM 理解剧情结构] -.-> B
    C1[用户审核修改] -.-> C
    E1[TTS 引擎选择] -.-> E
    E2[字幕遮罩处理] -.-> E
    F1[MP4 直接输出] -.-> F
    F2[剪映草稿导出] -.-> F

下面逐道工序拆开讲。

第一道：导入素材

打开 NarratoAI 的 WebUI 之后，第一步是把你的视频素材和字幕文件导进去。0.8 系列支持单个视频也支持多个视频——多集素材可以一次性导入，系统会给每个视频分配一个 video_id 并在后续处理中全程追踪来源。

字幕方面，你有三个选择：直接上传现成的 SRT 字幕文件、使用云端 ASR 在线转录、或者使用本地 ASR 引擎离线转录。如果你手头的素材本身带字幕文件，上传 SRT 是最省事的路。但很多短剧和影视素材并不会附带字幕文件，这时候 ASR 转录就派上了用场。

我自己常用的做法是：先用 Fun-ASR 一键转录，然后花几分钟在字幕预览界面里快速扫一遍，把明显的识别错误手动改掉。这一步花的时间不多，但对后续剧情分析的准确性影响很大。

第二道：剧情分析

素材导进去、字幕也有了之后，下一步是让 LLM 做剧情分析。你需要告诉系统这部内容的基本信息——名称、类型（短剧/影视/纪录片等），还可以选择是否开启联网搜索来辅助识别公开的剧情信息和人物关系。

这一步的输出不是文案，而是一个结构化的剧情摘要。它会梳理出：故事的主线是什么、有哪些关键人物、人物之间的关系是什么样的、核心冲突和转折点在哪里。对于短剧来说，还会额外标记爽点、反转和悬念设置的位置。

为什么要把剧情分析单独拎出来，而不是直接让 LLM 看着字幕写文案？我实际对比过。同样的短剧素材，跳过剧情分析直接生成文案，人物关系出错的概率大概是三到四成——尤其是在人物多、名字相似、关系复杂的情况下。先做剧情分析再写文案，出错率能降到一成以下。这个差距在批量处理内容的时候会被放大很多倍。

第三道：文案生成

这是整个流程里最"创作"的环节。基于剧情分析的结果，LLM 按照你选择的内容类型和风格偏好，生成一段完整的解说文案。

关键设计在于——文案生成完之后，流程不会自动往下走。系统会停下来，把文案展示在一个可编辑的表格视图里，让你逐条审核、修改、删减或者重写。你可以调整某一句话的表达、修改某个段落的节奏、删掉你觉得多余的铺垫。确认无误之后，再手动推进到下一步。

这个"停下来"的设计，是我觉得 0.8 系列最聪明的地方。它承认了一个事实：AI 写出来的文案，在信息准确性上可能没问题，但在"好不好听""有没有节奏感""钩子够不够强"这些层面，目前还做不到让有经验的创作者完全满意。与其让 AI 假装自己能一步到位，不如老老实实把判断权交还给创作者。

第四道：画面匹配

文案定稿之后，LLM 会把每一句解说词对应到具体的视频片段和时间戳上。这一步叫"画面匹配"或者"时间轴对齐"。

举个例子。假设你的文案里有一句"女主角推开门，发现房间里空无一人"，系统需要在你的视频素材里找到女主角推门的那个镜头，然后把这句话的时间戳匹配上去。

0.8 系列在这步做了两个重要的改进。第一个是多视频场景下的来源追踪——每段字幕都知道自己来自哪个视频，匹配的时候不会"串台"。第二个是原声保留比例的控制——你可以设定多大比例的视频片段保留原声（比如保留关键台词和情绪爆发点），其余部分用解说配音覆盖。这个参数对短剧解说尤其重要，因为有些"名场面"如果不保留原声，冲击力会大打折扣。

第五道：配音与字幕

文案和画面时间轴都就绪之后，进入配音和字幕处理。

配音环节，你需要从 TTS 引擎列表里选一个引擎和对应的音色。不同的引擎和音色处理速度差别很大——Edge TTS 几乎即时出结果，但音色选择有限；IndexTTS2 等本地引擎音色更多、可定制性更强，但需要本地有相应的模型文件。

字幕环节，0.8 系列做了两件很实用的事。一是字幕遮罩——自动检测原视频中的硬字幕区域并生成遮罩覆盖，避免新字幕和旧字幕叠在一起。二是在横屏和竖屏模式下可以分别设置字幕位置和遮罩区域——同一个项目既能出横屏长视频也能出竖屏短视频，不用手动改两套参数。

第六道：合成与导出

最后一步是合成。FFmpeg 把所有东西——裁剪好的视频片段、生成的配音音频、字幕文件——组装成一个完整的 MP4 文件。0.8 系列增强了合成过程的进度展示，把整个合成过程拆成"读取脚本→裁剪视频→生成配音→合并音频→处理字幕→合成最终视频"几个阶段，让你知道当前在哪个环节、大概还要多久。

如果你不满足于 AI 的粗剪结果，还可以选择导出剪映草稿。这会把完整的时间线、音频轨道和字幕信息导出为剪映能识别的草稿格式，你可以在剪映里打开继续精修——换镜头、调节奏、加音效、贴表情包，想怎么改就怎么改。

这个六道工序走下来，我的感受是：NarratoAI 0.8 系列不是在试图替代创作者，而是在给创作者配一个"不会累的助理"——助理负责搬砖（转录、粗剪、打时间轴），创作者负责把关和润色。如果你能接受这个定位，用起来会非常顺手；如果你期待的是"丢素材进去、完美成片出来"，那目前任何 AI 工具都还做不到。

短剧与影视：两种内容，两套 AI 策略

如果你同时做过短剧解说和影视解说，肯定有一个体会：这两种内容的"解法"完全不一样。把给短剧写的那套逻辑生搬硬套到一部两小时的电影上，出来的东西会很奇怪——要么节奏全乱，要么关键信息全丢。反过来也一样。

NarratoAI 0.8 系列在这一点上做了明确的区分：短剧解说和影视解说是两条独立的处理链路。它们共享同一套底层技术（LLM、ASR、TTS、FFmpeg），但在提示词策略、分析重点和输出风格上做了差异化处理。

我用一张表来对比两种模式的核心差异：

这个表不是绝对的——有些短剧拍得像微电影，有些电影节奏快得像短剧。但作为"默认策略"，这个区分是合理的。

短剧解说的特殊挑战

短剧解说有一个让 AI 很容易翻车的点：人物识别。短剧的角色名字经常很相似——"林雪"和"林雨"、"顾北辰"和"顾北城"——加上单集时间短、出场人物多、关系变化快，LLM 如果没有足够的上下文，很容易把人物搞混。

NarratoAI 0.8 系列应对这个问题的方式是三重保障。第一，在剧情分析阶段专门做人物关系图谱的梳理，把每个人的身份、关系和关键台词标注清楚。第二，支持联网搜索辅助识别——如果这部剧在公开平台上有剧情简介或者人物介绍，AI 可以抓取这些信息作为参考。第三，文案生成完之后停下来给你审核——人物搞混这种错误，AI 可能察觉不到，但人一眼就能看出来。

另外一个短剧特有的需求是"原声保留"。短剧的高级感很多时候来自演员的原声表演——哭腔、怒吼、冷笑——这些情绪细节是 TTS 配音很难复制的。0.8 系列的解决方案是给你一个"原片占比"参数，比如设为 30%，系统会在生成时间轴时保留 30% 的原声片段用于关键情绪节点，其余部分用解说配音填充。

影视解说的空间更大，但取舍更难

影视解说（电影、电视剧、纪录片）的情况正好相反。素材很长，信息密度没那么高，你不需要每一分钟都塞满信息。但难在取舍——一部两小时的电影，你要在十分钟的解说视频里讲清楚，哪些留、哪些删、哪些一笔带过、哪些重点展开，这个判断目前 AI 还做不好。

NarratoAI 的处理策略是"先全量分析，再按需生成"。LLM 会先把整部电影（或电视剧集）的剧情吃透，生成一份完整的剧情分析报告，然后根据你设定的视频时长和风格偏好，从中提取最重要的情节线来生成文案。你如果觉得 AI 选的重点不对，可以在文案审核环节手动调整——加一段你觉得重要的情节分析，删掉 AI 认为重要但你觉得无聊的部分。

这个"全量分析→按需生成→人工调整"的思路，比"直接让 AI 从字幕里挑重点写文案"靠谱得多。因为 AI 只有先看完全部剧情，才知道哪些是真正的关键节点；如果只看局部就做判断，很容易把次要情节当成主线。

我用两种模式的真实感受

我自己拿同一套短剧素材分别跑过"短剧解说"和"影视解说"两种模式，出来的文案差异非常大。短剧模式下的文案节奏快、钩子密、每三四句话就有一个悬念或者反转提示；影视模式下的文案更沉稳，有明显的"引入→展开→高潮→收尾"结构。这说明底层的提示词策略确实不一样，不是换个名字糊弄人的。

不过话说回来，AI 生成的文案再怎么差异化，还是需要创作者把关。尤其是涉及到主观判断的地方——"这段该用什么样的语气""这个反转该铺垫多少""结尾要不要留悬念"——这些目前还没有哪个 AI 能替你做决定。0.8 系列的"生成完停下来给你改"这个设计，本质上就是在承认这个现实。

另外需要提醒一点：如果你做的是影视解说类内容，素材的版权问题需要自己注意。AI 工具只负责技术处理，不负责版权合规。使用受版权保护的影视素材进行解说创作时，建议了解相关的合理使用边界，以及国内各平台对影视二创内容的具体规则。这不是工具能帮你解决的问题——这是创作者自己的功课。

（关于 AI 生成内容的合规标注，后面有专门的章节展开，这里先提一嘴。）

字幕系统全解析：转录、校准、遮罩一条龙

字幕这件事，没做过视频的人可能觉得就是"加一行字"。真做过的都知道，字幕是一个完整的子系统——从获取字幕文本、校准时间轴、到遮罩处理、最终烧录到视频上，每一步都可能出问题。

NarratoAI 0.8 系列把字幕从原来"上传一个 SRT 文件"的简陋状态，升级成了一套完整的工作流。这个变化非常实用，值得单独开一章来讲。

ASR 引擎选择：云端 vs 本地，各有各的适用场景

首先面临的选择是：用什么引擎来转录字幕？0.8 系列支持了多个 ASR 引擎，我把它整理成了一张对比表：

新手我一般建议先用阿里百炼 Fun-ASR。配置简单，识别精度在同级别里表现不错，关键是省去了本地部署模型的时间。如果你是处理自己录制的素材或者对数据隐私有要求，那就走本地 FunASR-Pack 的路——部署稍微复杂一点，但一次配好之后可以无限用。

有一点要说明：ASR 引擎的价格和 API 配额政策变动非常快。上面这张表里没有标价格，是因为到你在看这篇文章的时候，实际费用可能已经变了。建议以各引擎官方定价页面的实时数据为准。

字幕预览与校准：花五分钟能省一小时

ASR 转录完的字幕，不是直接拿去用的。识别准确率再高的引擎，在遇到口音重、背景嘈杂、多人同时说话的场景时，也难免出错。如果这些错误没被发现就直接喂给 LLM 做剧情分析，后续文案就会带着错误一路跑偏。

NarratoAI 的字幕预览界面让你可以在转录完成后快速扫一遍字幕内容，发现错误直接在线修改。我自己的习惯是重点关注这几类内容：人名（最容易识别错）、专有名词（地名、机构名、作品名）、数字（时间、金额、数量）。普通对话里偶尔错一两个字问题不大，但关键信息错了一定要改。

校准完成后，字幕会带着修正后的内容和时间戳信息进入下一个环节。这一步花的五分钟，往往能在后面省掉一两个小时返工。

字幕遮罩：解决"两层字幕打架"的刚需

这个是 0.8 系列里我个人评价最高的功能之一。

很多影视和短剧素材都自带硬字幕——画面底部压着一行白色或黄色的字，去不掉。如果你直接在这个基础上再加一层解说字幕，结果就是两行字叠在一起，谁也看不清。

传统的解决方式很粗暴：手动裁剪画面底部，把原字幕裁掉。但这样画面比例就变了，而且如果原字幕位置偏高，裁剪之后构图会很奇怪。

NarratoAI 的字幕遮罩采用了更智能的方式：利用计算机视觉检测原字幕区域，在那个区域上生成一个模糊遮罩（或者纯色条），把原字幕"盖住"，然后在遮罩上方或指定位置添加新的解说字幕。效果类似电视台处理外来素材时用的"字幕条"。

更贴心的是，横屏和竖屏可以分别设置遮罩区域和字幕位置。这意味着你同一个项目，做横屏版的时候字幕放在画面底部偏上一点的位置，做竖屏版（比如抖音短视频）的时候字幕放在画面中下部——两套参数互不干扰。

实际操作中容易踩的两个坑

第一个坑：字幕时间轴偏移。ASR 转录出来的时间戳，偶尔会跟实际画面对不上——尤其是视频开头有几秒静音或者片头的情况下。如果发现生成的字幕整体偏早或偏晚，在字幕校准界面里可以整体偏移时间轴，不需要逐条手动调整。

第二个坑：字幕遮罩位置不准。CV 检测原字幕区域的时候，如果原字幕颜色和背景太接近，或者字幕不是标准的底部居中位置（比如某些短剧把字幕放在左下角），检测可能会有偏差。遇到这种情况，可以在设置里手动调整遮罩的坐标和尺寸，覆盖自动检测的结果。

字幕系统的这些功能，单独拎出来看都不是什么惊天动地的技术突破。但把它们整合进同一个工作流里、让创作者在一个界面里就能完成"转录→校对→遮罩→定位"的全过程，确实省掉了大量在不同工具之间切来切去的时间。

多视频素材管理与配音引擎矩阵

这一章聊两件事：素材管理和声音选择。它们看起来不相关，但在实际创作中经常同时出现——你的素材是一堆零散视频，你需要一个清晰的管理机制把它们组织起来，然后选一个合适的配音方案把它们串成一条完整的故事线。

多视频素材：不止是"一次上传多个文件"

NarratoAI 0.8 系列对多视频的支持，不是因为"能传多个文件"就叫多视频支持了。真正的难点在于——系统要知道每段字幕来自哪个视频，每句文案匹配到哪个视频的哪一秒，最终合成的时候从哪个视频的哪个位置裁剪画面。

举个例子。你手头有三个视频文件：第一集的上半部分、第一集的下半部分、第二集完整版。这三个文件里都有字幕，字幕的时间戳都是从 00:00 开始的。如果系统不区分"视频来源"，它就没法判断"00:30 到 00:45"这段字幕到底对应哪个视频的画面——三个视频的 00:30 内容完全不一样。

0.8 系列的解决方案是在底层数据结构里为每段内容打上来源标记：

# 多视频场景下的数据结构示意
{
    "script_segment": {
        "text": "女主角推开门，发现房间里空无一人",
        "start_time": "00:00:45",
        "end_time": "00:00:58",
        "video_id": 2,
        "video_name": "第一集_下.mp4",
        "keep_original_audio": false
    }
}

这个 video_id 和 video_name 字段贯穿整个流程——从字幕导入、剧情分析、文案匹配到最终合成，每一步都知道"这段内容属于哪个视频"。在多集短剧、连续剧合集这种场景下，这个机制是"可靠"的基础。

实际操作中，你可以在 WebUI 里上传多个视频文件，同时上传对应的字幕文件（或用 ASR 分别转录）。系统会自动分配视