作者：莫潇羽@无忆研习社(www.wuyi.wiki)｜转载请注明出处
🎯 快速摘要
如果你只想知道结论，记住这几条就够了：AutoSubs 是一款完全开源、完全本地运行的 AI 字幕生成工具，由开发者 Tom Moroney 主导维护，GitHub 上的 Star 数已经突破 4.3K。它把 Whisper、Parakeet、Moonshine 这三大主流语音识别模型直接跑在你自己的电脑上，不走云端、不需要订阅、不限时长，音视频文件丢进去就能一键产出带时间轴的字幕。更关键的是，它内置了 Pyannote 说话人分离能力，能自动识别对话中有几个人在讲话，并且给每个人打上独立标签和颜色；同时支持 独立运行 和 深度对接 DaVinci Resolve（达芬奇） 两种工作流，支持 Windows、macOS（M 系列与 Intel 双架构）、Linux 三大平台。一句话总结：它解决的是视频创作者最头疼的那件事——字幕从识别到对齐到分角色，不用再手动做。 下文会从技术原理、架构拆解、模型区别、逐步安装到实战使用，把这个工具讲透，想深入了解的朋友往下看。
一、做视频的人，都卡在过同一个环节
写这篇文章之前我（莫潇羽）特地翻了一下自己这几年剪过的项目，发现一个规律：一条视频从开机到发布，真正花在"剪辑本身"上的时间其实没那么多，真正耗时间的是字幕这一关。
剪完一条十分钟的片子，粗剪可能一小时就搞定，但字幕的打轴、核对、断句、调色、找错别字，往往要再花两到三个小时。如果是访谈、播客、双人对谈这种多说话人场景，还要再叠加一个工作量——分辨谁在说话、给不同人的字幕设不同颜色、拉不同轨道。很多人用剪映、Arctime、Pr 自带的识别去做，要么精度达不到，要么免费额度不够用，要么对多人对话束手无策，尤其是使用敏感素材的时候，还要担心上传云端是否安全。
这也是为什么这几年 Whisper 一出来，开源社区立刻涌现出几十个包装它的 GUI 工具。但大多数工具要么只解决"识别"，不解决"分角色"；要么解决了"分角色"，但没法无缝接到剪辑软件里；要么界面做得很工程师，没有考虑普通用户怎么用。
今天要讲的 AutoSubs，是我最近一段时间在无忆研习社（www.wuyi.wiki）的选题库里反复试用之后，真心觉得值得写一篇详细拆解的项目。它的目标非常明确：让本地设备上的 AI 一口气搞定识别、打轴、分说话人、送回剪辑软件这整条链路。
二、AutoSubs 到底是什么
AutoSubs 是一款 开源免费 的桌面端字幕生成工具，项目托管在 GitHub 上（仓库地址 https://github.com/tmoroney/auto-subs ），发布主站是 https://tom-moroney.com/auto-subs/ 。它的设计目标只有一句话——"一键产出高质量字幕"，而且要做到三件事：快、准、可离线。
和市面上常见的字幕工具相比，它最核心的差异点可以用一张对照表来理解：
|
维度 |
云端订阅型工具 |
本地脚本型工具 |
AutoSubs |
|
运行环境 |
服务器 |
命令行 / Python 环境 |
本地 GUI 桌面应用 |
|
隐私 |
文件需上传云端 |
本地 |
完全本地 |
|
使用门槛 |
注册、订阅 |
会装 Python |
下载 .exe 或 .pkg 即用 |
|
说话人识别 |
部分支持 |
需要自行拼接 Pyannote |
内置 |
|
剪辑软件集成 |
几乎没有 |
需要自行开发脚本 |
原生对接 DaVinci Resolve |
|
语言支持 |
大多按次数计费 |
视模型而定 |
50+ 语言 |
|
成本 |
按时长/按次 |
有硬件门槛 |
完全免费 |
AutoSubs 属于第三种路径：把底层的模型链路、音频预处理链路、剪辑软件对接链路全部封装进一个桌面应用里，给用户看到的只有"选文件、点按钮、看结果"三步。
它目前已经支持以下系统：
- Windows 10/11（x86_64）
- macOS（Apple Silicon 与 Intel 分别打了不同安装包）
- Linux（提供 .deb 安装包，Debian / Ubuntu 系可直接装）
三、本地运行意味着什么：不只是"不用上传"这么简单
很多人对"本地运行"的理解还停留在"不用联网就能用"，但这个特性背后带来的改变其实是系统性的，值得展开讲一下。
第一，敏感素材可以放心丢进去了。 企业内训视频、未公开的采访、商业谈判录音、学术访谈、播客原带——这些素材一旦经手云端服务，就涉及版权、保密协议、甚至合规风险。AutoSubs 把模型直接放在用户机器上跑，所有处理都在本地硬盘里完成，不会产生任何网络请求（首次下载模型除外），这件事对 B 端用户来说尤其重要。
第二，处理速度不再受网络影响。 云端方案必然要走"上传→排队→处理→下载"的链路，文件一大就要等很久。本地方案只受制于你的 CPU / GPU 性能，一条十几分钟的视频，在一台 M1 的 MacBook Pro 上，用 Parakeet 跑完全文识别可能只要几十秒。
第三，没有调用次数限制。 云端服务必然要对每次调用计价，而本地跑模型只消耗电费。你可以一晚上处理掉几十个小时的素材而不用看额度。
第四，不受服务端策略影响。 云服务关停、调价、改 API 的事在这几年反复上演，本地工具的好处就是"下载下来就永远能用"，哪怕原项目不再维护，老版本也还在本地能跑。
这里莫潇羽多啰嗦一句：选开源工具的时候，一个很重要的判断标准就是——它是不是真的可以脱离原作者持续运行。AutoSubs 满足这一条，因为它依赖的所有组件（Whisper、Parakeet、Moonshine、Pyannote、FFmpeg、Tauri）都是社区维护的开源资产，不存在单点风险。
四、架构拆解：一个 Tauri 桌面应用是怎么搭起来的
这部分是整篇文章的"硬核区"，打算把工具讲明白的话，绕不开它的技术选型和架构。看不懂代码细节没关系，只要知道每一层在做什么就够了。
4.1 整体架构：前端 + Tauri 桥 + Rust 后端 + 引擎 + 外部依赖
AutoSubs 的整体结构可以用这样一张流程图来描述：
graph TB
subgraph 前端层
UI[React + TypeScript 界面]
CTX[状态管理：字幕/模型/进度/设置]
UI <--> CTX
end
subgraph Tauri 桥接层
IPC[IPC 命令与事件总线]
end
subgraph Rust 后端
API[命令处理器]
AP[音频预处理]
API --> AP
end
subgraph 转录引擎
EM[引擎管理器]
EM --> W[Whisper]
EM --> P[Parakeet / Moonshine]
EM --> D[Pyannote 说话人分离]
EM --> TR[翻译器]
end
subgraph 外部依赖
FF[FFmpeg 音频解码]
HF[HuggingFace 模型托管]
end
subgraph DaVinci Resolve（可选）
LUA[AutoSubs.lua 脚本]
end
UI <--> IPC
IPC <--> API
API --> EM
AP --> FF
EM --> HF
LUA <-.IPC.-> IPC这张图里藏着几个关键信息点。
前端用的是 React + TypeScript。这意味着它的界面是标准的现代 Web 技术栈，熟悉 React 的开发者可以直接读代码、改 UI 主题甚至做二次开发。
中间层用的是 Tauri。Tauri 是近几年取代 Electron 的新一代桌面应用框架，核心区别在于：它不像 Electron 那样把整个 Chromium 打包进安装包，而是复用操作系统原生的 WebView（Windows 上的 Edge WebView2，macOS 上的 WebKit，Linux 上的 WebKitGTK），再搭配 Rust 写的后端。带来的直接好处是：
- 安装包体积小：Electron 应用经常 80–150MB 起步，Tauri 应用能压到 10MB 以下
- 内存占用低：Electron 空载 150–300MB，Tauri 通常只需 30–50MB
- 启动速度快：冷启动可以做到秒开
- 安全性更高：Rust 的内存安全特性 + Tauri 的默认沙箱机制
后端是 Rust。Rust 语言以零成本抽象、内存安全、无 GC 为人所知，特别适合做"计算密集型+需要稳定跑很久"的任务。字幕识别这个场景恰好非常吃计算性能，用 Rust 写音频预处理、流程调度、模型管理这一层是一个非常合理的选型。
AI 引擎层支持三种模型：Whisper、Parakeet、Moonshine，再加上负责说话人分离的 Pyannote、做字幕翻译的模块。这是 AutoSubs 最核心的价值所在，下面会单独展开。
外部依赖里有两个重要角色：FFmpeg 负责处理任意格式的音视频文件（MP4、MOV、MKV、WebM、MP3、WAV 等等都能直接喂进去）；HuggingFace Hub 负责模型的分发，用户第一次选择某个模型时，应用会从 HuggingFace 上下载对应的模型权重到本地。
最后，DaVinci Resolve 的集成通过一个 Lua 脚本实现，这个 AutoSubs.lua 脚本放在 Resolve 的脚本目录里，通过 IPC 机制和 Tauri 主应用通信，把识别好的字幕直接写入剪辑时间线。
4.2 完整处理流程：从"选择文件"到"字幕落在时间线上"
整个链路的数据流大概是这样的：
[用户操作]
│
▼
① 选择音视频文件 ──────▶ 前端把路径发给 Rust 后端
│
▼
② Rust 后端通过 FFmpeg 解码音频
- 归一化采样率到 16kHz
- 立体声降为单声道
- 转成模型需要的格式
│
▼
③ 引擎管理器根据用户选择调用对应模型
- Whisper / Parakeet / Moonshine 做语音识别
- 输出带时间戳的文本片段 [{start, end, text}, ...]
│
▼
④（可选）Pyannote 进行说话人分离
- 语音活动检测（VAD）
- 提取说话人嵌入向量
- 聚类，输出 [{start, end, speaker_id}, ...]
│
▼
⑤（可选）翻译模块把结果翻译成目标语言
│
▼
⑥ 格式化器处理换行、每行字数限制、语言特定规则
│
▼
⑦ 结果通过 Tauri IPC 实时流式推回前端
│
▼
⑧ 用户在编辑器里微调，导出 SRT / TXT / 或发送到 Resolve 时间线这条链路有几个值得注意的设计：
识别和说话人分离是解耦的。识别模型只管"说了什么"，说话人分离只管"谁在说"。两个结果最后在时间轴上做对齐融合，哪条文本属于哪个人，是靠比对两者的时间区间重叠度来决定的。这个设计的好处是灵活——你可以只要识别不要分角色，也可以两个都要，互不干扰。
处理是流式的。Rust 后端会在处理过程中不断地通过 IPC 事件把进度推给前端，所以用户能实时看到百分比、看到已经识别好的字幕一条一条往下滚。这个细节对用户体验非常重要。
预处理统一用 FFmpeg。这是一个非常务实的决定。因为音视频格式的碎片化问题 FFmpeg 已经解决了二十多年，AutoSubs 没必要自己造轮子。
4.3 为什么音频预处理这么关键
很多人对"音频预处理"这一步没什么概念，但它在整条链路里其实占了不小的比重，决定了最终识别的准确率。AutoSubs 在这一步做的事情大致有：
- 解码：把 MP4、MOV、MKV、WebM 等等容器格式里的音轨抽出来
- 重采样：几乎所有语音识别模型都要求 16kHz 的采样率（这是语音识别领域的默契，人声的主要信息集中在 8kHz 以下，16kHz 的采样率已经足够还原清晰度），原始音频经常是 44.1kHz 或 48kHz，需要降采样
- 混音为单声道：语音识别模型只关心"说话内容"，不关心"空间感"，双声道反而增加计算量，所以要把立体声合并成单声道
- 电平归一化：不同设备录出来的音频音量差异很大，如果不做归一化，小声录的内容模型可能直接当成静音忽略掉
- 格式转换：最终输出成模型喜欢的 16-bit PCM 或者 Float32 格式
这一整套操作用 FFmpeg 一条命令就能搞定，AutoSubs 的 Rust 后端把 FFmpeg 作为 sidecar（附属程序）打包，不需要用户单独安装。
# 类似这样的命令在后台被执行
ffmpeg -i input.mp4 \
-ar 16000 \ # 采样率降到 16kHz
-ac 1 \ # 合并为单声道
-af "loudnorm" \ # 电平归一化
-f wav \ # 输出为 WAV 格式
output.wav这些细节用户完全不用关心，但正是这些细节决定了识别效果能不能稳定。莫潇羽早年自己折腾过 Whisper 命令行版本，最大的坑就是有时候直接喂原始 MP3 文件识别效果很差，后来才发现是采样率和电平的问题。AutoSubs 把这些坑全部填了，用户只需要关心"内容"本身。
4.4 模型的下载与管理
模型是整个应用的"大脑"，但又不能打包进安装包（因为太大，Whisper Large 就 1.6GB，打包进去安装包就 2GB 起步了，这对下载和分发极其不友好）。AutoSubs 的做法是：
- 安装包本身只有几十 MB（这是 Tauri 架构带来的优势之一）
- 用户第一次选择某个模型时，从 HuggingFace Hub 按需下载
- 下载好的模型缓存到本地，后续调用直接从本地加载
- 支持预下载：用户可以在设置里提前把几个常用模型都下载好，后续切换零等待
这个"按需下载"的设计非常聪明：只用 Whisper base 的用户不用被迫下载 1.6GB 的 Large 模型；英文内容多的用户可以选择只下 Parakeet；实际上绝大多数用户最终会稳定在某两三个模型上。
模型文件的存储结构也值得一提：AutoSubs 沿用了 HuggingFace 的标准缓存目录，这意味着如果你原来就在用 Transformers 库，已经下好的模型不需要重复下载，AutoSubs 可以直接复用。
五、三大识别模型怎么选：Whisper、Parakeet、Moonshine 的差异
AutoSubs 最有意思的地方，就是它不是绑死一个模型，而是让用户根据场景自由切换。但切换的前提是你得知道这三个模型的差别是什么。这一节莫潇羽来帮你把这三家捋清楚。
5.1 Whisper：全能选手
Whisper 由 OpenAI 在 2022 年开源，至今仍然是语音识别领域的标杆作品。它的最大特点是：
- 多语言覆盖极广，原版支持 99 种语言，中文、日文、粤语甚至闽南语都能识别
- 有翻译能力，可以把非英语音频直接翻译成英文输出
- 模型尺寸从 tiny 到 large-v3 多档可选，可以根据硬件取舍
Whisper 的底层是标准的 Transformer 编码器-解码器结构，编码器做全局自注意力，解码器自回归地生成 token。它把音频切成 30 秒一块的固定窗口处理，短音频要 padding 到 30 秒才能喂进去。
Whisper 的缺点也很明显：速度不快，尤其是 large 系列模型，在 CPU 上跑十分钟的音频可能要等几分钟；GPU 上会快很多但需要至少 6–10GB 的显存。后来社区出了 Whisper Large V3 Turbo、faster-whisper（基于 CTranslate2 加速）、MLX-Whisper（针对 Apple Silicon 优化）等一系列衍生项目来解决速度问题。
什么场景选 Whisper：识别非英语内容（尤其是中文）、需要翻译成英文、对精度要求高、时间不敏感。
5.2 Parakeet：英文速度王
Parakeet 是 NVIDIA 出品的模型家族，其中最广为人知的是 Parakeet-TDT 0.6B 和 V3 两个版本。它的架构基于 NVIDIA 自研的 FastConformer 编码器加 TDT（Token-and-Duration Transducer）解码器。
Parakeet 和 Whisper 最大的区别在"看音频的方式"：Whisper 是逐帧地顺序读完所有音频，哪怕是静音段也不跳过；Parakeet 会把音频信号先做 8 倍压缩，然后模型一次预测"说了哪个词 + 这个词持续了多久"，遇到静音或者长元音可以一次性跳过去。这个设计带来了惊人的速度提升。
在公开的基准测试里，Parakeet V3 以 6 亿参数的体量在 Hugging Face Open ASR Leaderboard 上取得了领先成绩，速度比 Whisper Large V3 Turbo 快约 10 倍，英文识别精度还更好。
但 Parakeet 有个硬伤：英文专精，对非英语支持有限。另一个小问题是输出数字的格式——它倾向于输出 "one, two, three" 而不是 "1, 2, 3"，后处理时要注意。
什么场景选 Parakeet：英文内容、追求极致速度、设备性能一般、做英文 Podcast 或 YouTube 素材。
5.3 Moonshine：边缘设备小钢炮
Moonshine 来自 Moonshine AI（前身是 Useful Sensors），定位非常明确：面向边缘设备、面向实时场景。
它的技术路线比较特别：使用编码器-解码器 Transformer 架构，但通过 ONNX Runtime 推理，同时取消了 Whisper 那种"必须 padding 到 30 秒"的限制，你输入多长它就处理多长。这让短音频（1–10 秒）的延迟非常低。
Moonshine Base 模型只有 61M 参数，磁盘占用约 237MB，在一颗消费级桌面 CPU 上处理 4 秒音频只需约 0.09 秒。作为对比，Whisper Large V3 Turbo 在同样的 CPU 上处理同样的 4 秒音频要 17.7 秒——这是两个量级的差距。
Moonshine 也支持多种语言（日文、普通话、韩文、阿拉伯语等），不过多语言版本的成熟度和覆盖度不如 Whisper 全面。默认输出是小写且无标点，需要后处理加标点。
什么场景选 Moonshine：低配设备（老笔记本、一些嵌入式场景）、实时字幕、大量短音频批处理。
5.4 模型选择速查表
┌──────────────────────────────────────────────────────┐
│ 场景 │ 推荐模型 │
├──────────────────────────────────────────────────────┤
│ 中文 / 多语种视频 │ Whisper │
│ 英文 Podcast / YouTube │ Parakeet │
│ 翻译成英文输出 │ Whisper │
│ 老笔记本 / 集成显卡 │ Moonshine │
│ 实时字幕 / 短句批量识别 │ Moonshine │
│ 会议录音 / 多说话人对话 │ Whisper + Pyannote │
│ 追求最高精度 │ Whisper Large │
│ 追求最快速度（英文） │ Parakeet │
└──────────────────────────────────────────────────────┘六、说话人识别：Pyannote 是怎么"听出谁在说话"的
这一节来聊 AutoSubs 的另一半魔法——说话人分离（Speaker Diarization）。这个技术要解决的问题叫 "who spoke when"，翻译过来就是"谁在什么时候说话"。
6.1 说话人分离的典型流程
Pyannote.audio 是法国 INRIA 实验室的开源项目，目前是 speaker diarization 领域最成熟的方案之一，底层基于 PyTorch。它的处理流程通常是这样的：
- 语音活动检测（VAD）：先从音频里把"有人说话"的段落挑出来，去掉静音、噪声、背景音乐
- 说话人嵌入提取：把每一段语音送进一个神经网络（常见的是基于 ResNet 或 ECAPA 结构的模型），输出一个高维向量（embedding），这个向量可以理解为"这个人声音的指纹"
- 聚类：把所有片段的 embedding 拿去做聚类（常用的算法是谱聚类、层次聚类、AHC 等），同一个聚类里的片段就判定为同一个说话人
- 重叠语音检测（可选）：识别有哪些时段是两个人在同时说话
- 输出结构化结果：
[{start, end, speaker_id}, ...]
然后在和识别结果做对齐时，按时间重叠度把每条文本分配给最可能的 speaker。
6.2 为什么说它是"魔法"
AutoSubs 最让人惊艳的是它把这套复杂的流程完全封装了，用户在界面上只需要勾选"启用说话人识别"，剩下的全部自动化完成。识别结果会自动给 SPEAKER_00、SPEAKER_01 这样的匿名标签，你可以在编辑器里把它们改成真实人名（比如"主持人"、"嘉宾A"），然后每个说话人可以设不同颜色、不同字体、不同轨道。
这意味着什么？对谈类、访谈类、播客类、会议纪要类的视频，过去需要你手动听辨、手动切分、手动染色的工作，现在一键完成。这是剪辑工作流上的一个质变。
6.3 对中文效果的诚实提醒
莫潇羽必须提醒一下：Pyannote 的预训练模型是基于英文数据集为主训练的，对中文普通话的分离效果虽然能用，但 EER（等错误率）比英文场景要高一些。实测下来，两人对谈的场景准确率通常不错，三人以上 + 口音重 + 背景嘈杂的情况下容易出现同一个人被识别成两个说话人，或者两个人被合并的问题。
遇到这种情况，一般的补救办法是：
- 尽可能选择清晰、单声道的录音
- 在设置里手动指定"预计说话人数量"（AutoSubs 支持这个参数）
- 识别完后在编辑器里做人工合并 / 拆分
6.4 说话人嵌入向量：声音的"指纹"
聊到这里稍微再深入一点说。说话人识别背后的数学直觉其实很美妙：每个人的声音经过神经网络压缩后，可以得到一个高维向量（通常是 192 维、256 维或 512 维），这个向量就像是这个人声音的"指纹"。
判断两段语音是不是同一个人，就是判断这两段语音的向量在高维空间里的距离。距离近就是同一个人，距离远就是不同的人。具体用余弦相似度、欧氏距离还是其他度量方式，是不同模型的技术选择。
这套方法的牛逼之处在于：它不需要事先知道有哪些人。你只要给它一段音频，它就能自己发现这段音频里有几个不同的声纹、每个声纹对应哪些时段。在聚类算法的帮助下，这个过程是完全无监督的。
这也是为什么我们看到 Pyannote 输出的标签是 SPEAKER_00、SPEAKER_01 而不是真名——模型只能告诉你"这里有几个不同的人"，至于这些人是谁，需要用户自己去打标签。AutoSubs 把这个打标签的交互做成了"编辑器里一键改名，所有同一人的字幕一起更新"的形式，是一个非常顺手的设计。
七、DaVinci Resolve 深度集成：和达芬奇的原生联动
DaVinci Resolve（简称 Resolve 或达芬奇）是目前独立创作者圈子里最受欢迎的专业剪辑软件，它有免费版，功能强大到足以做院线级调色。AutoSubs 对 Resolve 的集成是很多人选它的决定性原因。
7.1 集成方式
集成方式是通过一个 Lua 脚本。在 Resolve 里，你可以通过 Workspace → Scripts → AutoSubs 启动集成。背后的原理是：
- AutoSubs 主程序暴露一个本地 IPC 服务
AutoSubs.lua脚本驻留在 Resolve 的脚本目录，能调用 Resolve 的 Fusion/Timeline API- 用户在 AutoSubs 里点击"发送到 Resolve"时，Lua 脚本接收字幕数据，然后在当前时间线上按时间码自动插入字幕轨道
7.2 支持的能力
- 直接生成到时间线：不用导出再导入，字幕以 Text+ 模板的形式出现在字幕轨道上
- 每个说话人独立样式：可以给 SPEAKER_00 设红色描边白色填充，给 SPEAKER_01 设蓝色描边白色填充，字幕会按说话人自动套用对应样式
- 每个说话人独立轨道：也可以把不同人的字幕放到不同的视频轨道上，方便后期调整
- 填充颜色 / 描边颜色 / 边框颜色分别可调，并且有实时预览
- 可选每条字幕显示的行数（1 行或 2 行）
7.3 一个小提醒
官方文档里明确指出：AutoSubs 不支持从 Mac App Store 下载的 DaVinci Resolve 版本。因为 Mac App Store 版本的沙箱限制导致外部脚本无法正常注入。如果你用的是 App Store 版，需要到 Blackmagic Design 官网 https://www.blackmagicdesign.com/products/davinciresolve/ 重新下载安装包版本才能正常使用。
7.4 集成工作流的实际体感
莫潇羽这里多说一句实际体感。在没有 AutoSubs 之前，Resolve 里做中文字幕是一件相当痛苦的事情。Resolve 自带的语音识别从 18 版开始加了进来，但对中文支持不算理想，而且要用它的识别必须先把项目做成最新版的 Studio 才能跑得动部分功能。
接入 AutoSubs 之后的工作流是这样的：
- 在 Resolve 里把粗剪做完，敲定时间线
- 切到 Edit 面板 → Workspace → Scripts → AutoSubs，一键启动
- AutoSubs 自动读取当前时间线的音频，转录完毕后字幕直接落在时间线上
- 回到 Resolve 里做调色、做包装、做最终导出
字幕和剪辑是两个并行的工作，互不干扰。对专业创作者来说，这种"字幕完全不用出工程"的体验，效率提升比任何单点优化都明显。
八、独立模式：不用达芬奇也能用
除了和 Resolve 对接，AutoSubs 还有一个 独立运行模式（Standalone Mode）。这个模式下它就是一个纯字幕生成工具，把文件拖进去、选参数、点转录，得到结果后在内置编辑器里微调，然后导出成 SRT、纯文本或者复制到剪贴板，拿到任何剪辑软件里都能用。
这个模式特别适合以下场景：
- 用 Premiere Pro、Final Cut Pro、剪映专业版的用户
- 只需要字幕文件，不需要直接上时间线
- 做字幕翻译、做课程转写稿、做播客 Show Notes
- 处理一批采访录音，只要文字稿
独立模式下的编辑器界面也做了很多优化：
- 响应式布局，窗口大小变化时字幕预览区会跟着自适应
- 桌面端有可拉伸的分栏，左边是字幕列表，右边是视频预览，可以一边听一边改
- 每条字幕可以批量修改样式
- 快捷键支持：上下箭头跳条目，空格播放/暂停，Enter 换行
8.1 字幕格式的那些门道
顺便讲讲字幕格式这个坑。做视频字幕的朋友多少都会接触到各种格式，它们之间的差异其实不小：
- SRT（SubRip Subtitle）：最通用的格式，几乎所有播放器和剪辑软件都支持。纯文本，一条字幕由编号、时间码、文本三部分组成。缺点是不支持样式（颜色、字体、位置都没法存）
- VTT（WebVTT）：Web 视频标准，和 SRT 很像但支持更多元数据，HTML5
<track>标签原生支持。YouTube、B 站上传时都可以用这个格式 - ASS / SSA（Advanced SubStation Alpha）：字幕组的最爱，支持丰富的样式定义——字体、大小、颜色、描边、阴影、位置、动画都能存。文件结构相对复杂
- TXT：纯文本，没时间戳。适合做文字稿、做后续翻译、做 SEO 用的内容素材
AutoSubs 默认导出 SRT，这是最通用最安全的选择。如果你有样式需求，建议在目标剪辑软件里重新设置，而不是依赖字幕文件本身携带样式。
一个小贴士：把 AutoSubs 导出的 SRT 文件用记事本打开，会看到标准的时间码 00:00:15,230 --> 00:00:18,450，其中逗号是 SRT 规范要求的毫秒分隔符。如果某些软件只认点号（比如 00:00:15.230），那是 VTT 格式，可以在导出时选择对应格式，或者自己用记事本批量替换。
九、详细安装教程：三大平台全覆盖
这一节给小白朋友准备了逐步的安装说明。以莫潇羽的经验，装桌面应用这件事对新手来说最容易卡住，所以这里会尽量讲细。
9.1 Windows 平台
步骤如下：
- 打开浏览器，访问 https://github.com/tmoroney/auto-subs/releases/latest
- 找到当前最新版本的资源列表，下载名字类似
AutoSubs-windows-x86_64.exe的文件 - 下载完成后双击运行，按照向导点"下一步"即可
- 首次启动会提示下载模型，根据网络环境耐心等待几分钟
- 建议提前安装好最新版 Microsoft Edge WebView2 Runtime（大多数 Windows 11 自带，Windows 10 可能需要手动装一下）
安装包现在都做了数字签名，Windows Defender 一般不会拦截。如果确实被拦，右键选择"仍要运行"即可。
9.2 macOS 平台
macOS 下要注意区分你的芯片：
- Apple Silicon（M1/M2/M3/M4）：下载
AutoSubs-Mac-ARM.pkg - Intel 芯片（2020 年前的 Mac）：下载
AutoSubs-Mac-Intel.pkg
不确定自己是什么芯片的话，点击屏幕左上角苹果图标 → "关于本机"，看"芯片"或"处理器"那一栏。
下载完后：
- 双击 .pkg 安装包，走完引导
- 第一次打开可能会提示"来自身份不明的开发者"，这时候到"系统设置 → 隐私与安全性"里拉到最下面，点"仍要打开"
- 首次运行同样会下载模型
9.3 Linux 平台（Debian / Ubuntu 系）
Linux 用户通常更熟悉终端操作，两行命令搞定：
# 下载最新版 .deb 安装包
wget https://github.com/tmoroney/auto-subs/releases/latest/download/AutoSubs-linux-x86_64.deb
# 安装
sudo apt install ./AutoSubs-linux-x86_64.deb
# 如果出现依赖错误，用下面这条命令补齐
sudo dpkg -i AutoSubs-linux-x86_64.deb && sudo apt -f install装完之后在应用菜单里就能找到 AutoSubs 图标，或者在终端敲 autosubs 启动。
Arch 系和其他非 Debian 发行版暂时没有官方包，但可以通过源码自行编译（需要 Node.js 和 Rust 工具链）。
9.4 首次启动会做什么
第一次打开 AutoSubs，应用会：
- 检测系统环境（WebView 版本、可用磁盘空间）
- 提示你选择默认模型并下载（模型文件从 HuggingFace 拉取，一般 200MB – 1.6GB 不等）
- 初始化本地数据库，用来保存你的历史任务和偏好设置
- 如果检测到 DaVinci Resolve 安装路径，会提示你是否安装 Lua 脚本做集成
这一步做完之后，就可以开始用了。
十、实战使用：从零到一生成一条字幕
假设你手上有一个名为 interview.mp4 的访谈视频，里面有两个人对谈。下面是从零到一的完整流程。
10.1 第一步：导入文件
启动 AutoSubs，你会看到一个简洁的主界面。把 interview.mp4 直接拖进去，或者点"选择文件"按钮。
应用会解析文件，展示：
- 文件总时长
- 音频采样率 / 声道
- 检测到的格式
10.2 第二步：选择模型与参数
主要参数有这么几个：
- Model：选择 Whisper / Parakeet / Moonshine 之一。中文选 Whisper，英文视情况在 Whisper 和 Parakeet 之间选
- Model Size：在 Whisper 下有 tiny / base / small / medium / large 五档，模型越大越准但越慢
- Language：手动指定语言，或者选 Auto-detect 自动识别
- Translate to English：如果需要翻译成英文字幕，勾上这个
- Enable Speaker Diarization：启用说话人识别
- Max Speakers：预估的说话人数量上限，两人访谈就填 2，多人会议就填对应人数
- Max Words Per Line：每行字幕最大字数（中文场景建议 15–18，英文场景建议 8–12）
- Max Lines：每条字幕最多几行（通常 1 或 2）
10.3 第三步：开始转录
点击 Transcribe 按钮，界面切换到进度视图。你会看到：
- 顶部的进度条
- 实时的阶段提示（"正在预处理音频..." / "正在加载模型..." / "正在识别..." / "正在分离说话人..." / "正在格式化..."）
- 已识别好的字幕会在下方一条一条实时流出
等待时间取决于你的硬件和选择的模型。一段十分钟的双人访谈，M1 MacBook Pro + Whisper medium 一般在 1–2 分钟内完成。
10.4 第四步：微调字幕
转录完成后进入编辑器界面。你可以：
- 点击任意字幕条目，在右侧面板里修改文本
- 拖动字幕条目的边缘，调整起止时间
- 点击某条字幕的说话人标签，把 SPEAKER_00 改成"李明"，SPEAKER_01 改成"王芳"——修改会应用到所有同一说话人的条目
- 给不同说话人设不同颜色
- 合并两条字幕（选中相邻两条 → 右键 → Merge）
- 拆分一条字幕（光标放到拆分点 → 右键 → Split）
编辑器有 撤销 / 重做，可以放心尝试。
10.5 第五步：导出或发送到 Resolve
如果是独立模式，点击 Export：
- 选 SRT 格式可以直接导入任何剪辑软件
- 选 TXT 格式只有纯文本
- 可以复制到剪贴板
- 可以导出"按说话人拆分的多个文件"（这对后期制作访谈稿非常有用）
如果是 Resolve 模式，直接点 Send to Resolve，然后切换到 Resolve 窗口，就能看到字幕已经按时间码铺在了时间线上。
10.6 字幕的"每秒字数"：一个容易被忽略的专业细节
大多数工具生成的字幕看起来都差不多，但做过字幕翻译或者接过字幕外包的朋友都知道，字幕有一套职业规范。最核心的是一个叫 CPS（Characters Per Second，每秒字符数） 的指标。
Netflix 的字幕规范要求拉丁字母文字 CPS 不超过 17，中日韩（CJK）不超过 9；BBC 的规范是拉丁字母不超过 20。超过这个速度，观众在字幕消失前就来不及读完，会有"字幕跟不上"的糟糕体验。
AutoSubs 的格式化器内置了这条规则：
- 识别模型输出的原始文本片段可能会非常长（一句话连续 20 秒的独白就是一个长片段）
- 格式化器会根据你设置的 CPS 上限、每行字数、每条最多行数，把长片段自动切分成多条合适长度的字幕
- 切分时会优先选择标点处、停顿处切，而不是硬切在词中间
- 每条字幕的起止时间也会根据语音的实际节奏重新对齐
这就是为什么 AutoS
