3.2 实时转写：开会时字幕同步滚动的用法

实时和离线，到底选哪个

离线转写上线两个月后，老板的需求升级了：季度复盘会请了几个外部顾问，希望大屏上能实时出字幕，方便顾问当场确认决议表述。于是我加了实时语音识别这一路。先说我自己的结论：能离线就别实时，除非业务真的需要当场看字。

两者的差异我用一张表对比过，做选型时可以直接拿去：

维度 实时转写 离线转写
延迟 边说边出字，通常一两秒内 会后等几分钟
准确率 略低，流式截断会影响断句 更高，能利用完整上下文
成本 按流式时长计费，开多久算多久 按音频时长计费，价格档位更低
实现复杂度 要维持长连接、处理断连重推 提交后等结果，逻辑简单
对网络的要求 弱网下明显卡顿、丢字 有上传带宽就行
适合场景 大会投屏、远程参会、当场确认决议 例会、评审、培训等绝大多数会后场景

给老板算账的时候这表直接拍过去：离线覆盖九成的会，实时只服务少数几场关键会议，工具复杂度可控，账单也可控。实时转写比离线贵的部分，第五篇 5.4 节有完整复盘，这里先把技术差异讲清楚，钱的事到那篇再细算。

实时转写为什么要单独开一条连接

有人问为什么不复用离线的接口，答案是不能：离线是交文件、等结果的异步模式，实时是边推音频边收文本的流式模式，两者在工程上是完全不同的两条链路。离线的输入是完整文件，识别可以前后看全文来断句；实时只能看到已经推过去的音频，等于蒙着眼一边听一边写，准确率和断句自然差一截。理解了这个本质差异，也就能理解为什么实时更贵、还更不准——它贵在要维持一条全程在线的长连接，不准在永远缺后半句的上下文。

接入步骤：从建连接到落屏

实时转写的接入核心是一条流式连接，语音是一段段推上去的，识别结果也是一段段推回来。我们 Web 端的接入步骤：

  1. 建连接：前端通过 WebSocket 连到实时识别服务，握手时带上鉴权信息和音频参数（采样率、编码格式）。这里参数必须和实际推流一致，否则连上了也是乱码。鉴权信息临现场生成，不在前端写死，密钥管理参考 2.2 节临时密钥的思路。
  2. 推流：把麦克风采集的音频按固定帧长（比如每段 100 毫秒）切成小块，连续推上去。千万别攒一大段一起推，会明显加大延迟；帧长也别太碎，系统调用开销同样伤延迟。
  3. 收识别结果：服务端持续返回中间结果和最终结果。中间结果会随着后续音频不断修正——典型表现是一句话说到一半，前半句的字还会变，比如“下周去北京”可能先显示“下周去背景”再修正；只有落定标点的最终结果才适合直接渲染。
  4. 落屏：前端维护一个结果缓冲区，中间结果显示在“正在说”那一行，最终结果追加深进字幕列表。

会议室用的是一台迷你主机接投影，跑一个浏览器页面。整个字幕页纯静态，部署在内部服务器上，具体部署方式可以看 轻量建站实战——内部工具的页面托管，这是最省心的路子。选迷你主机而不是用会议室那台旧 PC，是因为旧 Windows 开机各种弹窗更新，当着客户的面弹个更新提示太丢人；迷你主机装好系统之后只开一个浏览器全屏，三个月没重启过依然稳。

会前检查清单

实时转写翻车的成本比离线高得多——离线失败重跑就行，实时失败可是当着全场的面黑屏。后来但凡有实时转写的会，我提前半小时过一遍这张清单：

检查项 通过标准 不过的后果
网络上行带宽 现场实测不低于推流需求的余量 字幕卡顿、积压
麦克风采音 测试说话能在字幕页正常出字 白开一场会
投影和字幕页 大屏能打开、字号坐最后一排能看清 看不清等于没有
兜底录音 本地录音已启动并确认在写文件 断网后内容丢失
参会人名单 已在前端登记，待会儿用于发言人标注 纪要对不上谁在说
离线模式预案 知道怎么一键切回离线流程 现场手忙脚乱

清单看着繁琐，跑过两次就成肌肉记忆了。有一次我偷懒没测麦克风，投影打开才发现麦克风被前一场培训拔了线，差点全员看着空字幕开会。从那以后清单里加了一条：会前播放一段测试音频，确认字幕页能正常出字，这一页才算通过。

字幕投屏展示的设计

第一版字幕页丑且难用：白底黑字、字号和网页正文一样大。老板坐在会议室另一头说看不清，同事说晃眼。改了几版才摸索出一套能用的：

  • 字体：无衬线黑体，字号按会议室最远座位到屏幕的距离折算，我们 8 米左右的会议室用了约 60 像素的字，差不多是常规网页正文的三倍。
  • 滚动：字幕只保留最新 8 到 10 行，旧行从顶部淡出，永远让最新一句话落在视线最舒服的位置，而不是一直在底部追加。
  • 配色：深色底配浅色字，投影仪在暗环境里白底太刺眼。
  • 发言人切换：识别结果带分段信息，段尾切换发言人时新起一段，行首标发言人名——发言人靠 3.3 节的分段结果匹配我们维护的参会人名单。最初没做标注，纪要干事时对不上谁说的，后来花一下午补上。
  • 兜底显示：断连或推流中断时，字幕底部显示连接中断恢复中的提示，不然大家会误会是不是会议结束了。

还有个小细节：字幕滚动的速度做了平滑过渡，而且只在最终结果到达时才滚动一次，中间结果变化只改“正在说”那一行——不然屏幕一直在抖，看久了头晕。

会议室现场还有个反光问题差点毁了这套设计：投影幕布正好对着窗户，下午开会反光严重，浅色字直接糊掉。最后是靠加厚遮光帘解决的，属于硬件问题硬件治，软件调多少参数都没用。这也印证了那句话：转写工具的上限往往不在代码里，在会议室的物理条件里。

弱网下的降级方案

办公室的会没事，但季度复盘会借了个外部场地，无线网络信号一般，实时转写第一次见识到弱网的威力：字幕成片地卡住，声音在响、屏幕没字，过几秒突然跳出一大段。

降级方案我分了三层：

现象 原因 降级动作
字幕间歇性卡顿 上行带宽不足 降低推流采样率，先保连续性
整体延迟越积越大 网络抖动、结果积压 前端丢弃过时的中间结果，只追最新结果
连接断开 网络中断或握手过期 自动重连，同时本地持续录音兜底
重连失败 场地网络持续不可用 提示切换离线模式，完整录音保留，会后走离线转写

最关键的一条是本地永远保留一份完整录音，哪怕实时字幕完全罢工，会议内容也不会丢——这个设计救过我们一次：那次外部场地的路由器中途挂了十多分钟，会后用兜底录音跑离线转写，纪要一分没耽误。另外断线重连有讲究：重连前先把缓冲的音频排个队，确认连接成功后从断点续推，而不是从头推一遍，不然中间内容会出现两遍。

实时转写返回的字段和离线完全一致，时间戳、分段、置信度的解读统一放在下一节。

内部怎么记账

实时转写比离线贵，这事大家都知道，但到底多贵，不记账是没感觉的。我们内部做了张极简的记账表，每场实时会议记一条，月底汇总：

场次 时长 模式 用途
周例会 50 分钟 离线 日常纪要
季度复盘 2 小时 实时 外部顾问在场，当场确认决议
全员大会 1 小时 实时 远程同事参会，需要看字幕

记了三个月结论很清楚：实时只占全部会议时长的不到两成，贵的那部分开销花在刀刃上。这张表后来也成了老板批预算时的依据——比起口头形容“实时贵一些”，一张能看出占比的表有说服力得多。成本构成和更细的账，第五篇 5.4 节会完整复盘。

字幕页如果想做得更交互（比如现场标注、收藏关键句），可以融入 AI 智能体开发实战里的前端 Agent 思路。

实时转写踩过的三个坑

除了弱网，实时转写还有几个它独有的坑，离线时代完全遇不到：

第一个是中间结果闪烁。有同事盯着字幕看久了头晕，因为同一行字在几秒内会变好几次。后来把中间结果的刷新频率降到原来一半，并且只在内容真正变化时才重绘，观感好了很多。

第二个是发言人换太快。实时转写也是按分段结果切发言人的，但实时分段偶尔会神经质地来回切，一分钟里切了三四次发言人，字幕 labels 跳来跳去。我们加了个冷却逻辑：同一发言人标签 30 秒内不重复切换，牺牲一点实时性换来稳定。

第三个是现场回音。外部场地的音响把投影声音折回了麦克风，识别结果出现成段的重复和幻听。治标办法是关掉音响附近的那支麦，治本还是录音规范（1.3 节）里强调的麦克风摆位——识别技术的上限永远在收音这一环。

为什么实时不做纪要

常被问：既然实时都出字了，为什么不干脆开会时把纪要也生成出来？我想过也试过，结论是放弃。原因有三：实时结果准确率略低（流式截断吃亏），当场出的纪要错处更多；会议内容经常前后反转，前半句说定的方案后半句推翻，当场提取等于提取了个寂寞；再有，实时提取会把所有人的注意力拉到屏幕上，变成大家看字幕而不是开会。所以我们的定位很清晰：实时转写只服务“当场可读”，纪要永远离线生成、会后发送。第四篇会详细讲纪要的结构化流程。

延伸阅读