VideoCaptioner AI 字幕：从素材到成片的自动化实践

VideoCaptioner 是近两年开源圈比较活跃的一个 AI 字幕工具，核心思路是把 Whisper 转录、字幕断句、校对三件事用一条流水线串起来。我自己用了大半年，从最初的卡顿到现在的稳定批量跑，趟了不少坑，整理成这篇笔记。

整体架构

VideoCaptioner 的核心模块有三个：

• 转录引擎：默认调用 OpenAI Whisper，本地跑 small 或 medium 模型，云端可接 faster-whisper、WhisperX、WhisperLargeV3
• 断句后处理：基于时间戳合并相邻短语，把 Whisper 那种每几个字一断的原始输出重新整理成可读字幕
• 字幕校对：可选调用 LLM 修正错字、补全专有名词、统一标点

整条流水线不是必须全开。纯本地用户可以只跑转录 + 断句，把校对环节留给人工。我自己的工作流是：素材先用 yt-dlp 拉下来（如果是流媒体素材），VideoCaptioner 跑转录断句，导出 ASS，扔进 Aegisub 手动校对。比纯人工快四到五倍。

模型选型

Whisper 的模型梯度从 tiny 到 large-v3，大小差几十倍。实测：

• tiny：中文识别错误率 18% 左右，只能当草稿用，不推荐
• base：错误率 10% 左右，短句够用，长对话断句一塌糊涂
• small：错误率 6%，速度比 base 慢一倍，普通视频能直接出片
• medium：错误率 3%，速度再慢一倍，长视频吃显存
• large-v3：错误率 1.5%，但 10 分钟视频在我 4060Ti 上要跑 25 分钟

我个人常用 small 做初稿，medium 做最终稿，large-v3 只在纪录片这种对识别精度要求极高的场景下用。

显存不够的朋友可以考虑 faster-whisper，它是 Whisper 的 C++ 重写版，相同精度下显存占用降低 40%，速度提升 30%。VideoCaptioner 在 0.8 版本后原生支持 faster-whisper，配置文件里把 engine 字段切过去就行。

断句策略

Whisper 原始输出有个老大难问题：它倾向于按词的边界做硬切，每 1-2 秒就断一行，导致字幕像电报。VideoCaptioner 的断句后处理做了几件事：

• 合并相邻短片段，按语义边界（句号、问号、感叹号）切分
• 单条字幕长度控制在 18-42 字符之间（中文字符数）
• 单条字幕最短显示 1.2 秒，最长不超过 7 秒
• 段间留 100-200 毫秒空隙，避免画面跳切

这套规则借鉴了 BBC 的字幕规范，对中文也基本适用。但有个例外：日漫里大量出现"——"作语气停顿，VideoCaptioner 默认会把它当成段落分隔，导致对白被错切。配置文件里加 sentence_delimiters: ["。", "！", "？"]，把破折号从分隔符列表里剔掉就行。

LLM 校对环节

VideoCaptioner 从 0.7 版本开始接 LLM 校对。原理是把转录文本分段送进 LLM，让模型修正错字、补全专有名词、统一标点。常用的模型有：

• GPT-4o-mini：性价比最高，10 分钟视频校对成本 0.02 美元左右
• Claude 3.5 Haiku：速度更快，中文错字修正能力略弱于 GPT-4o-mini
• DeepSeek-V3：国产模型里中文表现最好的一个，开源可自部署
• Qwen2.5-72B：阿里开源，自部署首选

校对 prompt 是关键。我试过很多版本，目前稳定用这个：

你是一名字幕校对员。下面是一段视频字幕的原始转录，可能包含错字、漏字、专有名词错误。
请按以下规则修正：
1. 仅修改错字，不改变原意，不补写未出现的内容
2. 专有名词按上下文修正（如人名、地名、术语）
3. 标点统一为中文全角
4. 数字用阿拉伯数字
5. 输出纯文本，每行一条字幕，不附加任何解释

原始转录：
{transcript}

关键是不让 LLM 改写句子结构，否则会偏离原台词。我吃过亏，让 GPT-4o 帮我"润色"，结果把一段口语台词改成了书面语，配音和字幕对不上，整个工程重做。

批量任务编排

VideoCaptioner 支持命令行批量模式，写个脚本就能跑整个目录：

for f in ./input/*.mp4; do
  videocaptioner \
    --input "$f" \
    --output "./output/$(basename "$f" .mp4).ass" \
    --engine faster-whisper \
    --model medium \
    --language ja \
    --llm gpt-4o-mini \
    --llm-key "$OPENAI_API_KEY"
done

我一般晚上挂机跑 30-50 个视频，第二天早上起来全部校对完。失败的任务会写日志，第二天人工重跑就行。这套流程让我一个人能维持一个月 60-80 部短片的字幕产能，纯人工根本不可能。

失败重试与异常处理

VideoCaptioner 不太稳定的地方是 LLM 调用。OpenAI 偶尔会限流、超时、返回空内容。我加了几个兜底：

• 单条字幕校对失败 3 次重试，间隔 2/4/8 秒退避
• LLM 返回为空时保留原始转录，标记 <needs-review> 字段
• 全局失败率超过 30% 时暂停整个流水线，避免无效消耗

这些机制 VideoCaptioner 本身不带，需要在外层包一层 Python 脚本实现。我放在 GitHub gist 里了，搜 "videocaptioner-batch-wrapper" 能找到。

翻译理论札记

写到这里想插入一段翻译理论的思考。奈达的功能对等强调译文读者读到译文时的反应，应当与原文读者读到原文时的反应基本一致，这意味着翻译不是字面替换，而是要在目标语里重新构造等值效果。我们做字幕，观众在屏幕前只有几秒钟读完一行字，反应时间被严重压缩，所以功能对等在字幕里被推到了极端——可读性优先于忠实度。

纽马克的区分更实用：交际翻译关注译文效果，语义翻译关注原文意义。字幕绝大多数时候走交际翻译路线，但遇到关键术语、专有名词、文化负载词时又要切回语义翻译，避免观众被误导。这两条路线在字幕里不停切换，做久了会形成直觉。

韦努蒂的归化异化是另一条轴线。归化是让译文流畅得像目标语原创，异化是保留原文的陌生感。日漫字幕里大量保留"前辈""学园""王道"等词就是异化，因为这些词在中文语境里已经形成了稳定的亚文化共识，强行归化反而失味。但纪录片、欧美剧的台词又需要强归化，否则观众跳戏。题材决定策略，没有一招通吃的方案。

—— 这些理论看起来抽象，但实际做字幕时每天都在用，只是未必意识到。把直觉变成方法论，是新人到熟手的分水岭。