SRT 丢给大模型校对：断句优化、错字修正、格式统一的进阶流程

一、为什么“直接丢给大模型”会翻车：问题定义与主线

字幕校对的直觉做法是：把整份 SRT 复制进对话框，附一句“请修正错别字并优化断句”，然后期待一份干净的结果。实践过的团队大多经历过同一类挫败：模型把时间轴改乱了、把口语化表达“润色”成了书面语、把专有名词统一成了另一个错误写法，甚至在长文件里悄悄丢了几条字幕。这些问题并非模型能力不足，而是任务定义本身存在结构性缺陷。

要理解这一点，需要先明确 SRT 校对到底包含哪些可分离的子任务。笔者认为，至少可以拆成四层：文本层（错字、别字、漏字、多字）、结构层（断句位置、单行字数、行数上限）、规范层（标点体系、数字写法、专名译法）、时间层（起止时间码与文本的对应关系）。四层中，前三层是纯文本问题，第四层是结构化数据问题。把它们混在一次生成里，模型必须在同一个输出中同时满足语义、格式与数值三类约束，出错概率自然上升。

本文的主线由此确立：不要让模型直接输出最终 SRT，而是让它输出一份“受约束的文本修订建议”，由确定性程序负责回写时间轴与格式。这条主线贯穿后文所有章节。它的价值在于把“生成”与“校验”分离：模型负责它擅长的语义判断，程序负责它擅长的精确回写。任何一步出错，都可以定位到具体环节并回滚，而不是面对一份面目全非的成品束手无策。

本文评述：把 LLM 定位为“协处理器”而非“编辑器”，本质上是软件工程中“关注点分离”原则在 AI 工作流中的再现。模型的不确定性无法消除，但可以通过接口设计把它限制在可控范围内。

从产业现状看，字幕生产的自动化程度差异极大。流媒体平台通常有成熟的 ASR + 人工校对流水线，而中小团队与个人创作者往往依赖剪映、Whisper 等工具自动生成字幕后手工修补。据 OpenAI 在 Whisper 论文中报告的数据，其 large-v2 模型在中文语音上的词错误率（CER）在常见测试集上仍有可观空间（Radford et al., 2022, Robust Speech Recognition via Large-Scale Weak Supervision），这意味着自动字幕的原始质量并不足以直接发布。校对环节的自动化因此具有真实且普遍的需求。

二、SRT 的结构本质与中间表示（IR）设计

2.1 SRT 的三元组结构

SRT 文件由若干“字幕块”顺序拼接，每个块包含三部分：序号、时间码行、文本行（可多行），块之间以空行分隔。时间码格式为 HH:MM:SS,mmm --> HH:MM:SS,mmm，使用逗号作为毫秒分隔符（部分工具输出点号，属于非标准变体）。这个结构看似简单，却包含一个关键约束：序号与时间码是“机器可读的骨架”，文本行是“人类可读的血肉”。校对只应触碰血肉，骨架由程序维护。

1
00:00:01,200 --> 00:00:03,800
今天我们聊一个特别容易被忽略的问题

2
00:00:03,900 --> 00:00:06,500
就是字幕的断句到底应该怎么断

2.2 为什么需要中间表示

如果直接把 SRT 原文交给模型，模型看到的是一份“文本 + 数字”的混合体。它可能出于“优化”的动机调整时间码，也可能在合并短句时删掉序号。更隐蔽的问题是：当模型把两条字幕合并成一条时，它必须自行决定新时间码的起止值，而这个决定往往缺乏依据。

中间表示（Intermediate Representation, IR）的思路是：把 SRT 解析成结构化对象数组，每个对象包含 index、start、end、text 四个字段。送给模型的是“带编号的纯文本列表”，模型返回的是“修订后的带编号文本列表”，程序再按编号把新文本写回原对象，时间码保持不变。这样，模型永远不需要接触时间码，也就不会改坏它。

字段	类型	是否交给模型	说明
index	int	是（作为行号）	用于回写定位，模型只读不改
start / end	timecode	否	由程序维护，模型不可见
text	string	是	校对的核心对象
speaker（可选）	string	视情况	多人对话场景需要保留

笔者认为，IR 设计是整条管线中最容易被低估、却回报最高的环节。它把“模型可能改坏时间轴”这一整类风险从根上消除，代价只是几十行解析与回写代码。对于任何计划批量处理字幕的团队，这都是第一件应该做的事。

三、断句优化：语义完整性与阅读节奏的双约束

3.1 断句不是“切分”，而是“再分段”

ASR 输出的断句通常基于声学停顿，而非语义边界。结果是常见的两类问题：一是把完整语义单元切断，例如“我们今天要讨论的是 / 字幕校对”；二是把多个语义单元挤在一条里，例如把两句话塞进同一时间窗。前者影响理解，后者影响阅读节奏。

断句优化因此需要同时满足两个约束。第一是语义完整性：一条字幕应尽量对应一个完整的语义单元，避免在主语与谓语、动词与宾语之间断开。第二是阅读节奏：单条字幕的显示时长与字数需要匹配观众的阅读速度。业界常用的经验值是中文单行不超过 15—20 字、单条不超过两行、显示时长不少于 1 秒（BBC 字幕规范、Netflix 中文 Timed Text 风格指南均有类似建议）。

3.2 让模型做“语义边界标注”而非“直接改写”

一个稳健的做法是让模型只输出“建议的断句点”，而不是输出重写后的字幕。具体而言，把连续若干条字幕合并成一段文本，要求模型在合适位置插入分隔符（如 |），程序再根据分隔符数量与原始时间码重新分配。这样模型只需判断“哪里是语义边界”，不需要处理时间分配，任务难度显著下降。

输入：
今天我们聊一个特别容易被忽略的问题就是字幕的断句到底应该怎么断

期望输出：
今天我们聊一个特别容易被忽略的问题 | 就是字幕的断句到底应该怎么断

本文评述：这种“标注式”提示把生成任务降级为分类任务，模型的输出空间从“任意文本”收缩为“在固定文本中插入分隔符”，幻觉空间被大幅压缩。代价是模型无法修正文本本身的错误，因此断句与纠错应当分两轮进行，而不是合并成一次请求。

3.3 节奏约束的量化

语义边界确定后，还需要用规则检查节奏。可用的量化指标包括：每条字幕的字符数（CPS，characters per second）、显示时长、以及相邻字幕的间隔。下表给出一组工程中常用的阈值参考，具体数值应结合目标平台规范调整。

指标	建议阈值	超标处理
单行字符数	≤ 20 字	在语义边界处再分
单条行数	≤ 2 行	拆分为两条
显示时长	≥ 1.0 秒	与相邻条合并或延长
字符速率 CPS	≤ 9 字/秒	延长时长或精简文本
相邻间隔	≥ 2 帧	避免闪烁，微调时间码

需要强调的是，这些阈值是工程经验值而非硬性标准。不同平台、不同语速、不同受众的容忍度差异很大。纪录片可以接受更长的单条字幕，而短视频平台的观众对高频切换更适应。工程上应把它们做成可配置参数，而不是写死在代码里。

四、错字修正：中文 ASR 误差机理与上下文纠错

4.1 中文 ASR 错误的典型类型

中文 ASR 的错误与英文有本质差异。英文是音素级识别，错误多表现为单词替换；中文是音节级识别，同音字、近音字替换极为普遍。常见的错误类型包括：

• 同音替换：“在座”误为“在做”，“权利”误为“权力”；
• 近音替换：前后鼻音不分（“因”与“应”）、平翘舌不分（“四”与“是”）；
• 分词错误：把“人工智能”切成“人工 / 智能”后各自识别；
• 专名误识：人名、地名、品牌名、术语被替换为常见词；
• 口语残留：语气词、重复、口误被原样保留。

这些错误的共同特点是：单看一条字幕难以判断，必须结合上下文。这正是大模型相对传统规则纠错的优势所在。传统方法依赖词典与语言模型打分，对专名和长距离依赖处理能力有限；大模型可以借助整段语境判断“这个词在这里是否合理”。

4.2 上下文窗口的取舍

给模型多少上下文，是一个需要权衡的工程问题。上下文太短，模型缺乏判断依据；上下文太长，成本上升且可能引入无关干扰。实践中常用的策略是“滑动窗口 + 重叠”：每次处理 N 条字幕，相邻批次重叠 M 条，重叠部分用于保持语境连续。N 的取值通常在 20—50 条之间，M 取 3—5 条。

本文评述：滑动窗口的代价是边界处可能出现不一致的修订。例如同一专名在窗口 A 被改为写法 X，在窗口 B 被改为写法 Y。解决办法是在管线中维护一份“术语表”，把已确认的专名固化下来，在后续批次的提示中作为约束传入。这一思路与机器翻译中的术语一致性管理一脉相承。

4.3 纠错的“最小改动”原则

大模型在纠错任务上最常见的失败模式是“过度修正”：把口语化表达改成书面语、把短句合并成长句、把方言词替换成普通话词。这些改动在语言质量上未必是错的，但违背了字幕“忠实于原声”的基本要求。

因此提示词中必须明确“最小改动”原则：只修正明显的错别字与识别错误，不改变语序、不替换同义词、不删除语气词、不合并句子。为了便于校验，可以要求模型以“原词 → 新词”的形式列出改动，而不是直接返回全文。这样程序可以逐条核对，人工也可以快速审阅。

请只修正明显的错别字与识别错误，遵循最小改动原则。
输出格式为每行一条：行号 | 原词 -> 新词 | 理由
不要返回完整文本，不要改变语序，不要替换同义词。

五、格式统一：标点、数字、专名与行宽规范

5.1 为什么格式统一比纠错更棘手

错字修正有相对客观的对错标准，而格式统一更多是“约定”问题。同一份字幕中，数字可能时而用阿拉伯数字、时而用汉字；标点可能时而用全角、时而用半角；专名可能时而用音译、时而用意译。这些不一致单看每条都不算错，但放在一起就显得不专业。

更麻烦的是，格式规范往往因平台而异。YouTube 的中文字幕偏好简洁标点，Netflix 的风格指南对数字、缩写、标点有详细规定，国内视频平台则各有习惯。因此格式统一的第一步不是“让模型改”，而是“先确定规范”。

5.2 可规则化的部分交给规则

格式统一中相当一部分是纯机械替换，完全不需要模型参与。例如：全角标点转半角（或反之）、连续空格压缩、省略号统一为六点、破折号统一为双连字符或长破折号、数字千分位处理等。这些用正则表达式即可完成，速度快、结果确定、零成本。

格式项	处理方式	是否需模型
标点全半角	正则替换	否
省略号、破折号	正则替换	否
数字写法	规则 + 例外表	部分
专名统一	术语表 + 模型判断	是
行宽控制	按字符数切分	否

5.3 专名统一：术语表的工程价值

专名统一是格式任务中最需要模型参与、也最容易出错的部分。一个实用做法是：先用模型从全文中抽取候选专名（人名、机构名、产品名、术语），人工确认后形成术语表，再在后续所有批次中作为强约束传入。术语表可以用简单的“错误写法 → 正确写法”映射表示，程序在回写前先做一轮确定性替换，模型只处理术语表未覆盖的情况。

笔者认为，术语表是字幕校对管线中最具复用价值的资产。一个团队处理同一领域的内容越多，术语表越完善，模型需要“自由发挥”的空间就越小，整体质量越稳定。这与软件工程中“把不确定性收敛到配置层”的思路完全一致。

六、时间轴对齐：文本改动后的重同步算法

6.1 文本长度变化带来的对齐问题

即使模型只做最小改动，文本长度也会变化。如果一条字幕被拆成两条，或者两条被合并成一条，时间码就需要重新分配。这是整个管线中最需要算法介入的部分。

对于“一条拆两条”的情况，最简单的做法是按字符数比例分配时长。例如原字幕时长 3 秒、文本 20 字，拆成 12 字与 8 字两条，则时长分别约为 1.8 秒与 1.2 秒。这种方法简单但不够精确，因为它假设语速恒定。更精确的做法是利用词级时间戳（如果 ASR 提供了 word-level timestamps），按实际发音时间切分。

6.2 强制对齐工具的使用

当文本改动较大时，比例分配不再可靠。此时可以借助强制对齐（forced alignment）工具，把修订后的文本与原始音频重新对齐，得到新的时间码。常用的开源工具包括 Montreal Forced Aligner（MFA）、WhisperX 等。WhisperX 在 Whisper 的基础上引入了音素级对齐，能够输出词级时间戳，对字幕场景尤为适用。

本文评述：强制对齐是“用计算换准确”的典型手段。它需要原始音频，因此只适用于有音频源的场景；对于只有 SRT 文件、没有音频的情况，只能依赖比例分配与规则调整。工程上应根据输入条件选择合适策略，而不是强求统一方案。

6.3 时间码的合法性校验

无论采用哪种对齐策略，回写后都必须做一轮合法性校验。检查项包括：起止时间是否为正、结束是否晚于开始、相邻字幕是否重叠、间隔是否过短、总时长是否与音频一致。这些检查可以用简单脚本完成，是防止“改坏时间轴”的最后一道防线。

• start < end，且两者均 ≥ 0；
• 第 i 条的 end ≤ 第 i+1 条的 start（允许极小重叠）；
• 单条时长 ≥ 最小阈值（如 0.5 秒）；
• 相邻间隔 ≥ 最小阈值（如 2 帧）；
• 最后一条的 end ≤ 音频总时长。

七、提示工程：把校对任务写成可验证的契约

7.1 契约式提示的四个要素

把提示词当作“接口契约”来写，是提升输出稳定性的有效方法。一份合格的校对提示应包含四个要素：角色与目标（你是谁、要做什么）、输入格式（数据长什么样）、输出格式（结果长什么样）、约束与禁止项（什么不能做）。四者缺一不可，其中输出格式与禁止项对稳定性影响最大。

角色：你是中文字幕校对助手。
目标：修正错别字与识别错误，标注语义断句点。
输入：每行格式为「行号 | 文本」。
输出：每行格式为「行号 | 修订后文本 | 断句点位置」。
约束：
1. 只修正明显错误，遵循最小改动原则；
2. 不改变语序，不替换同义词，不删除语气词；
3. 断句点用 | 表示，仅在语义边界处标注；
4. 若某行无需修改，原样返回；
5. 不输出任何解释性文字。

7.2 少样本示例的作用与风险

在提示中加入一两个输入输出示例（few-shot），可以显著提升格式遵循度。但示例也带来风险：模型可能过度模仿示例中的具体改动，把示例里的专名写法套用到实际内容上。因此示例应尽量使用与正文无关的通用句子，避免引入具体术语。

本文评述：few-shot 示例本质上是在“教格式”，而不是“教知识”。如果发现模型开始模仿示例内容而非格式，说明示例过于具体，应替换为更抽象的模板。

7.3 结构化输出的强制

对于工程管线，最理想的输出是结构化数据（如 JSON）。主流 API 大多支持 JSON 模式或函数调用，可以强制模型输出符合 schema 的结果。例如定义 {"line": int, "text": string, "breaks": [int]} 的数组，程序直接解析即可，无需正则提取。这比“让模型输出自然语言再解析”稳定得多。

八、工程管线：批处理、缓存、回滚与成本控制

8.1 管线总体结构

一条完整的字幕校对管线可以划分为六个阶段：解析、预处理、模型调用、回写、校验、导出。每个阶段职责单一，输入输出明确，便于单独测试与替换。

SRT 文件
  ↓ 解析
结构化对象数组（IR）
  ↓ 预处理（规则替换、术语表）
清洗后的 IR
  ↓ 分批 + 提示构造
模型修订建议
  ↓ 回写（按行号）
修订后 IR
  ↓ 校验（时间码、格式、一致性）
合格 IR
  ↓ 导出
新 SRT 文件

8.2 缓存与幂等

批量处理时，重复调用模型既费钱又不稳定。一个实用做法是对每个批次的内容计算哈希，把“哈希 → 模型输出”存入本地缓存。这样重跑管线时，未变化的批次直接命中缓存，只有内容变化的批次才重新调用。这既降低成本，也让结果可复现。

幂等性同样重要。同一份输入多次运行应得到相同输出（在温度设为 0 的前提下）。如果发现结果不稳定，应检查是否使用了非零温度、是否批次划分不一致、是否缓存未命中。

8.3 成本估算与模型选择

字幕校对是典型的“输入输出等长”任务，token 消耗主要取决于字幕总量。以一份 60 分钟视频、约 900 条字幕、总字数约 1.5 万字为例，加上提示词与上下文重叠，实际输入 token 可能在 3 万—5 万之间。按主流 API 的定价区间估算，单份成本通常在可接受范围内，但批量处理数千小时内容时仍需关注。

模型档位	适用场景	取舍
小型/轻量模型	格式统一、简单纠错	成本低，复杂语境判断弱
中型模型	常规纠错 + 断句	性价比均衡
大型模型	专名密集、专业术语多	质量高，成本与延迟上升

笔者认为，模型选择不应一刀切。可以先用轻量模型跑一遍，再用规则检测出“可疑片段”（如包含未登录专名、句子结构异常），只把这些片段交给大模型复核。这种“分级处理”策略在成本与质量之间取得较好平衡。

8.4 回滚与版本管理

任何自动化改动都应可回滚。建议在管线中保留原始 SRT 与每一步的中间产物，并为每次运行生成唯一版本号。这样当发现某批次改动有问题时，可以精确定位到具体阶段并回退，而不是从头重来。对于团队协作场景，把 SRT 纳入 Git 管理也是可行做法，diff 视图能直观展示每处改动。

九、质量评估：指标、抽检与 A/B 验证

9.1 自动指标

字幕校对的质量评估可以借鉴机器翻译与文本纠错领域的指标。常用的是字错误率（CER）与句错误率（SER），计算方式是拿模型输出与人工校对的“金标准”对比。此外还可以统计改动率（改动字符数 / 总字符数），用于监控模型是否“改得太多”。

指标	含义	监控意义
CER	字符级错误率	整体准确度
SER	句级错误率	整句可用性
改动率	改动字符占比	是否过度修改
格式合规率	符合规范的条目占比	格式统一效果

需要说明的是，上述指标的具体数值因数据集与任务难度而异，本文不引用未经核实的“某模型达到多少 CER”之类数字，读者应以原始论文或官方评测报告为准。

9.2 人工抽检的设计

自动指标无法覆盖语义层面的问题，人工抽检仍是必要的。建议采用分层抽样：从不同批次、不同内容类型（对话、旁白、专业术语密集段）中各抽取一定比例，由校对人员按统一标准打分。抽检结果应反馈到提示词与术语表的迭代中，形成闭环。

9.3 A/B 验证的落地

当团队想比较两种提示策略或两个模型时，可以设计 A/B 验证：同一批字幕分别用方案 A 与方案 B 处理，由不知情的校对人员盲评，统计偏好比例。这种方法的成本不高，但能提供比“感觉更好”更可靠的依据。

十、前沿预判与结语

10.1 端到端字幕模型的进展

学术界正在探索“语音到字幕”的端到端方案，跳过“ASR + 后处理”的两段式流程。这类模型直接以音频为输入、以带时间戳的规范字幕为输出，理论上可以避免中间环节的误差累积。但端到端方案对训练数据要求极高，且难以针对特定平台的格式规范做定制，短期内难以完全替代流水线方案。

本文评述：端到端与流水线并非替代关系，而是适用于不同场景。对于格式要求固定、内容领域单一的场景，端到端可能更高效；对于需要灵活调整规范、处理多语种多领域的场景，流水线仍是更务实的选择。

10.2 多模态校验的可能性

未来的字幕校对可能引入多模态信息。例如，结合视频画面判断说话人身份，从而更准确地修正人名；结合口型与音频判断发音，辅助区分近音字。这些方向已有初步研究，但工程化尚需时日。

10.3 结语

把 SRT 丢给大模型校对，本身没有错；错在把“丢”当成“交”。真正可靠的流程，是把大模型放进一条有解析、有约束、有校验、有回滚的管线里，让它做语义判断，让程序做精确回写。这条主线看似增加了工程复杂度，实则把不可控的生成风险转化成了可控的工程问题。对于任何需要批量处理字幕的团队，这套思路都值得投入时间落地。

10.4 拓展资源

• Whisper 官方仓库与论文：github.com/openai/whisper
• WhisperX 词级对齐工具：github.com/m-bain/whisperX
• Netflix 中文 Timed Text 风格指南：partnerhelp.netflixstudios.com
• BBC 字幕规范（Subtitle Guidelines）：bbc.co.uk/accessibility
• Montreal Forced Aligner：montreal-forced-aligner.readthedocs.io

主要参考文献