SRT 字幕做好看的关键：先拿到单词级时间戳，再交给 AI 断句和纠错

很多人做字幕时，会把注意力放在“识别得准不准”。

真正影响观看感受的，往往是另外几件事：

一句话有没有被切得支离破碎
字幕出现和声音是否同步
人名、术语、品牌名有没有拼错
一行字幕会不会长到塞满屏幕

英文字幕相对省心。中文访谈就麻烦多了，尤其是几个小时的录音。单靠语音识别模型直接吐出 SRT，通常会得到一大坨文字，标点混乱，断句也很生硬。

一套比较稳的流程是：

音频
  -> 语音识别
  -> 获取单词级时间戳
  -> AI 加标点、断句、纠错
  -> 将修改后的文本重新对齐到原始时间戳
  -> 按时长和阅读长度拆分
  -> 输出 SRT

关键点只有一句话：不要只保存识别文字，要保存每个词对应的 start 和 end 时间。

为什么要拿单词级时间戳

普通语音识别结果可能长这样：

{
  "text": "今天我们来聊聊人工智能字幕制作"
}

这段文字能看懂，却不知道每个字什么时候说出来。你想把它切成两条字幕时，只能凭感觉估算时间。

单词级时间戳会更接近这样：

{
  "words": [
    {"word": "今天", "start": 0.00, "end": 0.42},
    {"word": "我们", "start": 0.42, "end": 0.76},
    {"word": "来聊聊", "start": 0.76, "end": 1.24},
    {"word": "人工智能", "start": 1.24, "end": 1.86},
    {"word": "字幕制作", "start": 1.86, "end": 2.40}
  ]
}

有了这些数据，字幕可以按真实语音位置切开：

1
00:00:00,000 --> 00:00:01,240
今天我们来聊聊

2
00:00:01,240 --> 00:00:02,400
人工智能字幕制作

时间戳是地基。没有它，后面的 AI 断句和纠错很容易变成“文字整理”，而不是字幕制作。

英文断句：标点符号就够用了

英文语音识别一般会返回单词级时间戳，模型也更容易识别句号、逗号、问号和感叹号。

基本处理逻辑可以这样写：

遍历带时间戳的单词。
发现句号、问号或感叹号，就记录一个候选断点。
判断当前字幕是否达到合适长度。
在自然停顿处切开。
用当前片段第一个单词的 start 作为开始时间，用最后一个单词的 end 作为结束时间。

英文字幕还要控制阅读长度。单条字幕不要塞进一整段演讲。一般可以参考：

单条时长：1 到 7 秒
每行长度：不超过 42 个字符
一条字幕：1 到 2 行
阅读速度：每秒约 12 到 17 个英文字符

这不是死规定。新闻、课程、访谈、短视频都可以有不同参数。你需要让观众有时间读完，而不是让字幕跟着语音狂奔。

中文难点：模型的“word”不一定是一个字

中文语音识别最容易踩坑的地方，是很多模型返回的 word 并不是单个汉字。

它可能返回：

今天 / 我们 / 来聊聊 / 人工智能 / 字幕制作

也可能返回：

今天我们 / 来聊聊人工 / 智能字幕制作

这类分词结果适合保存大致时间范围，却不能直接拿来做中文断句。因为中文断句依赖语义：

我觉得这个方案可以
今天先不做

和：

我觉得这个方案可以今天先不做

文字一样，停顿位置一换，意思和观看感受就完全不同。

中文字幕通常需要大模型完成三件事：

补充标点
按语义划分句子
修正明显的错别字和术语

但大模型处理后的文本已经发生变化，原来的时间戳不能直接套用。你还需要重新对齐。

推荐的处理流程

1. 先保存原始识别结果

不要一上来就把识别文字丢给大模型。先保存完整 JSON，至少保留这些字段：

{
  "text": "原始识别文本",
  "words": [
    {
      "word": "识别出来的词",
      "start": 12.34,
      "end": 12.78
    }
  ],
  "language": "zh"
}

原始结果相当于回滚点。后面 AI 改错了，或者对齐出现偏移，你还能重新处理。

2. 让大模型只处理文本结构

给模型的任务要写清楚。不要让它输出一篇解释报告，也不要让它自由发挥。

可以使用这样的提示词：

你是字幕编辑。请处理下面的中文语音识别文本：

1. 根据语义补充中文标点。
2. 将文本切成适合字幕阅读的短句。
3. 修正明显的错别字、同音字和常见识别错误。
4. 保留原本的说话顺序，不增添内容，不删减观点。
5. 不要改写口语风格。
6. 只输出处理后的文本，不要解释。

字幕长度要求：
- 每句尽量控制在 8 到 18 个汉字。
- 优先在自然停顿、语义完整的位置断句。
- 不要把人名、数字、专有名词拆开。

原始文本：
{{text}}

这里有个重要取舍：让模型修正错别字时，必须控制修改范围。

“AI”可能被识别成“爱”，“API”可能被识别成“AB”。模型若大幅改写，文字和时间就很难重新匹配。字幕校对不是文章润色，别让模型把主播的口语也顺手改没了。

3. 用文本对齐算法找回时间

AI 输出的文本里增加了标点，甚至修正了几个字。标点本身没有声音，也不需要占用时间。真正需要匹配的是汉字和词语。

可以按这个思路处理：

原始带时间戳文本：
今天我们 来聊聊 人工智能 字幕制作

AI 处理后的文本：
今天，我们来聊聊人工智能字幕制作。

去除标点并规范空格：
今天我们来聊聊人工智能字幕制作

将处理后的文本与原始词序列对齐

根据每个断句对应的最后一个词，确定字幕结束时间

实际代码里，可以使用：

SequenceMatcher 做简单字符序列匹配
动态规划做更稳定的编辑距离对齐
专门的文本对齐库处理插入、删除和替换

伪代码如下：

raw_tokens = load_timestamped_tokens()
fixed_text = call_llm(raw_tokens_text)

raw_chars = normalize(raw_tokens)
fixed_chars = normalize(fixed_text)

mapping = align(raw_chars, fixed_chars)

for sentence in split_sentences(fixed_text):
    matched_tokens = find_source_tokens(sentence, mapping, raw_tokens)

    subtitle = {
        "start": matched_tokens[0]["start"],
        "end": matched_tokens[-1]["end"],
        "text": sentence
    }

    save_subtitle(subtitle)

对齐时要注意三类情况：

插入：AI 补了标点。它没有对应的时间，直接挂在前后文字上即可。
删除：AI 删除了口头重复词。需要确认后面的文字还能继续准确匹配。
替换：AI 把错别字改正确。可以把它视为同一位置的字符替换，不要重新估算整段时间。

如果只是短视频，简单匹配通常够用。长访谈、多人对话、错字较多的录音，建议使用编辑距离或动态规划，稳定性会好很多。

长访谈不能一次丢给大模型

几个小时的访谈，文本量可能达到几十万字。一次性发送会遇到几个问题：

超出上下文长度
处理成本突然变高
模型容易漏掉后半段
断句风格前后不一致
中途失败后只能全部重来

正确做法是分块处理。常见的分块范围可以设为：

3 到 10 分钟音频
2000 到 6000 个汉字
或者按照语音识别模型的 segment 切分

分块不能随便按固定字数硬切。比如这一句：

我认为这个问题真正困难的地方在于

下一块才是：

大家没有把数据准备好

切开后，两个块都像半句话，AI 很容易加出奇怪的标点。

更稳的分块方式

可以给每个块预留少量重叠内容：

第 1 块：00:00 - 05:00
第 2 块：04:50 - 09:50

处理完后，根据原始 token 的位置去重。这样即使边界附近正好跨了一句话，也能保留上下文。

另一种方式是先按模型已有的 segment 切块，再检查块尾是否处于完整句子：

块尾是句号、问号、感叹号，直接切
块尾是逗号或没有标点，向后延伸到下一个自然停顿
延伸不要超过预设上限，避免单块无限变长

每个块都要保存：

{
  "chunk_id": 12,
  "audio_start": 300.0,
  "audio_end": 600.0,
  "source_token_start": 1820,
  "source_token_end": 3560,
  "text": "..."
}

这样出错时可以只重跑一个块，不需要重新处理整场访谈。

SRT 拆分还要做一轮检查

句子断好了，不等于 SRT 已经能直接交付。生成文件前，建议再检查下面几项：

控制字幕时长

单条字幕太短，观众来不及读。太长，又会拖着画面不走。

可以先设置一个范围：

最短时长：0.8 秒
最长时长：7 秒

低于最短时长的字幕，可以和下一条合并，前提是合并后不超出阅读长度。

超过最长时长的字幕，可以按逗号、连接词或语义边界继续拆分。

控制每行长度

中文一行放 12 到 18 个字通常比较舒服。具体要看播放器字体和画布宽度。

不要从人名、数字、英文缩写中间拆开：

错误：我们使用了 Whisper
       Kit 来识别

更好：我们使用了 WhisperKit
      来识别

避免字幕重叠

后一条字幕的开始时间不能早于前一条结束时间。发现重叠时，可以：

将后一条的开始时间推迟到前一条结束后
把前一条提前结束到自然停顿处
合并两条，再按长度重新拆分

字幕时间最多相差几百毫秒，观众可能觉得“还行”。一旦连续错位几秒，观看感受马上崩掉。

纠错要留痕，别直接覆盖原文

建议同时保存三个版本：

raw_text       原始识别文本
normalized_text 规范化后的匹配文本
subtitle_text  最终显示在画面上的字幕

例如：

raw_text：      我们用 Whisper 做识别
subtitle_text：我们用 Whisper 做识别。

遇到术语修正时，也可以保存变更记录：

{
  "original": "爱皮爱",
  "corrected": "API",
  "confidence": 0.86,
  "reason": "上下文判断为开发术语"
}

这对课程、会议和采访特别有用。人名、公司名、产品名都值得人工抽查。AI 的错别字通常不是平均分布的，专有名词才是重灾区。

Agent 能不能自动完成

能。

可以把流程拆成几个 Agent 工具：

ASR Agent
  负责调用 Whisper，输出带时间戳的 JSON

Punctuation Agent
  负责补标点和语义断句

Alignment Agent
  负责把处理后的文本映射回原始 token

Subtitle Agent
  负责按时长、行数和阅读速度生成 SRT

QA Agent
  负责检查重叠、空字幕、超长字幕和异常时间戳

不过，Agent 会消耗更多 Token，也会增加系统复杂度。只处理一段十分钟视频时，普通脚本加一次大模型调用就够了。

长访谈、批量内容、需要自动重跑的生产流程，再考虑 Agent 编排更划算。

不一定非要用 Whisper API

如果电脑配置还可以，本地跑 Whisper 往往已经够用：

音频不需要上传到第三方
不受接口限流影响
可以反复调整参数
批量处理成本更低
原始时间戳更容易完整保存

Mac 用户可以看看 WhisperKit：

https://github.com/argmaxinc/WhisperKit

它支持单词级时间戳，也支持说话人识别。做访谈、播客和会议字幕时比较实用。

本地运行时，别只看识别速度。还要测试：

中文普通话的准确率
中英文混说的表现
专有名词是否容易错
说话人切换是否稳定
长音频是否会出现时间漂移

同一个模型，在安静录音室和嘈杂会议室里的表现可能完全不同。拿自己的素材跑一小段，结论比看参数表靠谱。

一套可以直接照着做的检查清单

识别阶段

[ ] 保存完整 JSON
[ ] 确认每个词都有 start 和 end
[ ] 检查音频采样率和声道
[ ] 记录语言和模型版本

AI 处理阶段

[ ] 只让模型补标点、断句和纠错
[ ] 明确禁止增写内容
[ ] 长音频按自然边界分块
[ ] 给相邻块保留少量重叠
[ ] 保留原文与修正版

对齐阶段

[ ] 标点不参与时间匹配
[ ] 处理插入、删除和替换
[ ] 检查每条字幕都能找到原始 token
[ ] 发现大段无法匹配时，回退到原始文本

导出阶段

[ ] 检查字幕是否重叠
[ ] 检查单条字幕是否过短或过长
[ ] 检查每行长度
[ ] 检查人名、品牌名和专业术语
[ ] 用实际播放器完整看一遍

避坑清单

不要只让 Whisper 直接输出 SRT

它能快速给你一个结果，中文长音频的断句质量通常不够稳定。把它当作带时间戳的原始数据源，会更好用。

不要让大模型直接改写全文

字幕需要忠实记录说话内容。把“整理成更通顺的文章”和“修正识别错误”分开处理，结果会可靠很多。

不要按固定字数粗暴切块

切在半句话中间，后面的标点和时间对齐都会变麻烦。用 segment、停顿和重叠窗口处理边界。

不要忽略对齐

AI 输出的文字看起来很漂亮，时间戳却可能全部错位。字幕项目里，文字质量和时间质量必须一起验收。

不要跳过人工抽查

人名、数字、药品名、公司名、技术术语，自动纠错最容易在这些地方翻车。完整视频不必逐字校对，但高风险词一定要扫一遍。

结语

高质量 SRT 的核心不是某个神奇提示词，而是一条完整的数据链：

准确识别
  + 单词级时间戳
  + 语义断句
  + 可追踪的文本对齐
  + 字幕规则检查

英文素材可以靠标点快速处理。中文素材要把“断句”和“重新对齐”单独拿出来做。长访谈则要加上分块、重叠和失败重试机制。

把这几步搭起来，字幕就不会再是一团需要手工整理的文字，而会变成一份可以批量生成、反复修正、直接交付的 SRT 文件。