用 Fable 把两个开源视频翻译项目缝成一套工作流

做视频翻译的人，大多遇到过同一个问题：一个工具字幕准，另一个工具兼容性好，真正顺手的全能方案却不常见。

VideoLingo 的优势是翻译质量和字幕效果。它能做出接近流媒体平台观感的字幕，但跨平台支持不够友好。

SmartSub 的覆盖面更广，macOS 也能用硬件加速。问题是它有时会把一句完整的话硬拆成几段，字幕读起来很别扭。

这两个项目放在一起，反而能互补。再接入 YouTube 下载模块，补上应对下载速度问题的配置，一套能跑起来的视频翻译流程就成形了。

这次真正省时间的地方，是用 Fable 处理项目组合。过去要自己看目录、查依赖、改接口、处理报错。现在，很多工作可以直接交给提示词完成。🤣

先搞清楚：你要拼的不是代码，而是一条流程

别一上来就对 Fable 说“把两个项目合并”。这个描述太空泛，工具很容易生成一个看起来完整、实际跑不通的壳子。

咱们要先把流程拆开：

获取视频
  ↓
提取音频或字幕
  ↓
语音识别
  ↓
翻译文本
  ↓
按语义重新分段
  ↓
生成字幕文件
  ↓
检查时间轴与格式
  ↓
导出或压制视频

VideoLingo 更适合承担翻译质量和字幕生成这一段。

SmartSub 可以承担跨平台运行、硬件加速和更通用的处理入口。

YouTube 下载模块负责把视频稳定地交给后面的处理流程。网络补丁则解决下载速度忽快忽慢、连接失败或访问受限等问题。

分工清楚，后面的提示词才有抓手。

这套组合怎么分工

VideoLingo：负责字幕质量

适合处理：

长句翻译
上下文理解
术语统一
双语字幕生成
字幕时间轴整理
更接近流媒体平台的字幕排版

如果你翻译的是课程、访谈、技术演讲，字幕质量比单纯“能翻出来”重要得多。一句话被拆得太碎，观众会不断回看，观看节奏直接断掉。

SmartSub：负责兼容性和本地运行

适合处理：

macOS 环境
跨平台启动
本地硬件加速
更通用的视频处理入口
批量任务执行

这部分很实用。你不需要为了一个字幕工具单独准备某种系统，也不必每次都手动切换环境。

YouTube 下载模块：负责输入端

视频翻译工作流常常不是卡在翻译，而是卡在下载。

下载速度慢、格式不兼容、音视频分离、访问失败，这些问题都会把后面的流程堵住。

接入下载模块时，建议保留几个基础能力：

支持输入视频链接
自动选择合适的视频和音频格式
支持音视频合并
支持断点续传
支持自定义代理或网络参数
下载失败时显示明确错误原因
下载完成后自动交给翻译流程

别只追求“能下载”。真正好用的工具，应该让你粘贴链接后少操心几步。

用 Fable 时，提示词要这样写

提示词不能只说功能目标，还要写清楚项目来源、模块分工、输入输出和验收条件。

可以直接参考下面的结构：

我想构建一个本地视频翻译工具，请基于以下开源项目设计统一工作流：

项目 A：负责高质量翻译、字幕时间轴和双语字幕生成。
项目 B：负责跨平台运行、macOS 支持和硬件加速。
下载模块：负责从 YouTube 获取视频，并处理音视频合并。

请完成以下工作：
1. 梳理各项目的入口、依赖和可复用模块。
2. 不重复实现已有能力，优先通过适配层连接模块。
3. 设计统一的输入格式和任务状态。
4. 支持视频链接、视频文件两种输入方式。
5. 翻译完成后输出 SRT、ASS 和双语字幕文件。
6. 在界面中显示下载、识别、翻译、导出四个阶段的状态。
7. 任意阶段失败时，保留中间文件并给出可读的错误信息。
8. 先给出项目结构和集成方案，再开始修改代码。

这类提示词有三个好处：

Fable 能知道每个项目该负责什么。
生成代码时不容易把功能重复写一遍。
出错后更容易定位是下载、识别还是翻译环节出了问题。

处理“字幕被暴力拆句”

这是视频翻译里很常见的坑。

原始字幕可能是一整句：

The model can summarize a one-hour meeting in less than a minute.

糟糕的拆分可能变成：

这个模型可以总结
一小时的会议
在不到一分钟内

每行看起来没错，连起来却很僵硬。

更合理的处理方式，是先按语义切分，再限制每条字幕的长度。可以给 Fable 加上这段要求：

字幕切分必须优先遵循语义完整性和自然停顿。
不要只按固定字符数截断。
单条字幕尽量保持一个完整意思。
避免在介词、助词、动词短语中间断开。
中文单条字幕建议控制在 18 到 24 个字左右。
连续两条字幕之间保留合理阅读时间。

还可以增加人工检查规则：

一条字幕不要只剩半个短语
人名、产品名、技术术语不要被拆开
标点尽量跟在对应句子末尾
说话人切换时重新分段
过短字幕要和相邻句合并
过长字幕要按语义停顿拆开

这几条比单纯要求“翻译得自然”更容易落地。

验收一套视频翻译工具，别只看“能不能跑”

至少拿三类视频测试：

技术演讲

检查术语、长句和上下文。比如 API、workflow、fine-tuning 这类词，不能一会儿翻成接口，一会儿翻成 API。

多人访谈

检查说话人切换、停顿和字幕归属。两个人抢话时，时间轴尤其容易乱。

日常口语视频

检查俚语、重复表达和语气。直译往往很生硬，字幕需要更接近真实对话。

可以用下面这份清单打分：

翻译是否出现明显漏句
专业词汇是否保持一致
字幕是否在合理时间出现
每条字幕是否读得完
中英文是否能同时阅读
下载的视频和字幕是否自动匹配
中途失败后能否继续处理
macOS 和 Windows 上表现是否一致

只有“跑通、好读、可恢复”，才算真正能用。

避坑清单

不要一次性接入所有功能

下载、识别、翻译、压制同时改，出错后很难判断问题在哪。按模块接入，每次完成一个小闭环。

不要把模型质量和字幕排版混为一谈

翻译准确，不代表字幕好看。语义、分段、时间轴、字体样式是四件事，需要分别验收。

不要忽略中间文件

音频、识别文本、翻译文本和字幕文件都应该保留可选缓存。重复处理同一个视频时，能省掉大量时间。

不要默认所有机器都能硬件加速

显卡、驱动、系统和运行库都会影响加速效果。提供自动检测和关闭加速的选项，遇到问题还能正常跑。

不要把网络补丁写死

下载配置应该支持开关和自定义参数。网络环境会变，写死某个方案，工具很快就会失效。

不要只测试短视频

两分钟视频跑通，不代表一小时访谈也没问题。长视频更容易暴露内存占用、时间轴漂移和任务恢复问题。

一套值得保留的提示词模板

后续你想继续加功能，可以用这个模板让 Fable 按步骤工作：

请在现有视频翻译工作流上增加一个功能：________。

当前流程：下载 → 识别 → 翻译 → 字幕生成 → 导出。

要求：
- 不破坏已有输入方式。
- 不重复实现已有模块。
- 保留中间文件和失败重试能力。
- 明确列出需要修改的文件。
- 先说明实现方案，再生成代码。
- 为新增功能补充一个最小可运行测试。
- 测试失败时说明原因和修复位置。

这比一句“帮我加个批量翻译”靠谱得多。你给出的边界越清楚，生成结果越接近真正能维护的项目。

写在后面

开源项目的价值，常常不在于单个工具有多完美，而在于能不能把合适的能力接到一起。

VideoLingo 解决翻译质量，SmartSub 解决跨平台和硬件支持，下载模块解决输入问题。Fable 则负责把这些零散能力组织成一条可操作的流程。

一年前，这类组合还需要不少手工工作。现在，项目结构、接口适配、错误处理和测试骨架，都可以交给几个清晰的提示词来推动。

真正需要你判断的，是每个模块该放在哪里，什么结果才算好用。代码可以生成，取舍还得自己做。

用 Fable 把两个开源视频翻译项目缝成一套工作流：字幕、下载、加速一次搞定