从说话到字幕，中间发生了什么

一条实时字幕是一次小型的调度奇迹：一句话在说话人继续之前就变成了字幕。悬浮层背后有四个阶段，理解它们就能解释你看到的延迟和错误。

1. 采集与编码

浏览器把音频以 32 位浮点、设备采样率（通常是 48kHz）交给 JavaScript。语音模型期望的是 16kHz 单声道 16 位 PCM。TanLens 在 AudioWorklet 中完成转换，不阻塞界面，然后每次请求发送约两秒音频。

两秒是刻意的取舍。更长的片段给识别器更多上下文，更短的片段降低延迟但词不够。对话场景两秒合适；长句讲座稍微长一点，断句通常更好。

2. 语音识别

识别器把音频变成带时间戳的词。Deepgram 这类流式服务会在你说话时返回中间结果，这正是字幕“即时感”的来源。Whisper 这类请求式服务每个片段返回完整句子，更慢，但在嘈杂音频上往往更准。

无论用哪种，模型都需要标点与断句。没有它们，翻译阶段拿到的是一堵词墙，输出的也是一堵词墙。

3. 翻译

字幕翻译不是文档翻译。它应该参考前几句、在术语表没有指定时保留人名、并写出朗读速度下能看完的自然短语。

TanLens 把带编号的若干行连同最近上下文和术语表发给翻译模型，再把编号输出映射回原始分段。如果模型返回的结构不对，就显示原文，而不是显示一条坏字幕——缺失的翻译比误导性的翻译更好。

4. 渲染

悬浮层更新时不应引起页面重排。TanLens 使用 Shadow DOM、固定定位，不做影响布局的动画。中间结果淡入，最终结果替换它。屏幕阅读器通过 aria-live 区域得到同样的文本。

延迟到底花在哪里

当前 HTTP 路径会先采集两秒音频分片，随后再叠加上传、识别、翻译和渲染耗时；这些都受网络与服务商影响。TanLens 尚未公布生产环境的 p50 或 p95，未来的延迟数字应来自端到端遥测，而不是某个服务商单独阶段的耗时。

可以调整的地方

• 需要速度时选流式识别；音频质量差、需要准确率时选请求式。
• 会话中保持目标语言不变，让术语表与上下文保持一致。
• 用短句。字幕是读的，不是研究的。
• 不要给受 DRM 保护的播放器加字幕还指望标签页捕获一定可用；先实测具体内容。

诚实的总结：实时字幕是一条流水线，而不是一个模型。最好的结果来自按内容选择每个阶段的取舍，而不是追逐单一基准数字。