OpenAI把实时转写延迟压到300毫秒，3行代码就能抄作业

去年开会还要手动记笔记的人，今年已经被同事当成数字难民了。

2024年，实时字幕还是Zoom的付费彩蛋；2026年，它成了所有会议工具的入场券。用户要的不是录音回放，是话音刚落文字已现的零摩擦体验。Whisper、Deepgram、AssemblyAI三家把流式音频延迟卷进了300毫秒以内，浏览器API也终于松口——不用装插件，直接抓标签页音轨。

技术债务清零的时刻到了。

但别急着写代码。先看清数据怎么流：浏览器标签音频 → MediaStream → AudioWorklet → WebSocket → 语音识别API → 转写文本。 raw PCM音频从浏览器出来，切成100-250毫秒的小块，WebSocket送到流式识别端点，部分结果和最终结果交替返回。难点不在单点，在整条管道的延迟控制，以及网络抖动、说话人切换、音频重采样这些边缘场景的兜底。

第一个坑在这里：既要抓会议音（系统/标签页音频），又要抓自己的麦克风，得把两条MediaStream轨道混到一起。

混流代码：比想象中脏，比文档中少

大部分开发者第一次调用getDisplayMedia时都会愣住——这API设计的时候显然没考虑过"只要音频不要画面"的场景。视频参数设false，音频参数却要展开一堆布尔值：回声消除关、降噪关、采样率锁死16kHz。麦克风那边相反，回声消除和降噪全开。两个流进AudioContext，createMediaStreamDestination打混，出来就是16kHz单声道PCM——所有主流语音识别API的母语格式。

浏览器里做重采样，比服务端做便宜一个数量级。这个细节能省下的服务器账单，够你多招一个后端。

别碰ScriptProcessorNode。它 deprecated 了，还跑在主线程上。AudioWorklet才是正解：

processor.js里注册一个PCMProcessor，process方法把inputs[0][0]的buffer丢给port.postMessage，带转移所有权。主线程await audioContext.audioWorklet.addModule加载这个模块，后面就能稳定收音频帧。主线程不卡，音频不丢，这是能上线和不能上线的分界线。

WebSocket的隐形天花板：不是带宽，是队头阻塞

音频帧100毫秒一发，WebSocket看起来绰绰有余。直到某个用户的Wi-Fi从5GHz跳到2.4GHz，延迟从30毫秒涨到300毫秒，你的缓冲策略如果没做，整句转写会突然快进式吐出，用户体验直接崩盘。

Deepgram的流式API有个细节：它返回的partial transcript是"正在说的"，final transcript是"说完的"。你的UI要同时处理两种状态——partial用来实时滚动，final用来落库和生成待办。很多开发者只接final，结果用户看着字幕比说话慢两拍，骂声比延迟还高。

AssemblyAI的做法更细：它区分utterance（说话人一段完整发言）和word-level timing。做会议纪要时，utterance用来切分说话人；做实时字幕时，word-level timing能让高亮词和音频精准对齐。选型时先问自己：产品核心场景是"看懂"还是"搜到"？

Whisper的陷阱：本地跑还是云端调？

OpenAI把Whisper API的价格打到每分钟0.006美元，但延迟在500毫秒左右徘徊。本地跑Whisper.cpp，M1 Mac上能压到200毫秒以内，代价是模型体积和首次加载的卡顿。浏览器里跑ONNX Runtime + Whisper Web，适合隐私敏感场景，但wasm的性能天花板明摆着。

有个中间路线：用Transformers.js在浏览器里跑distil-whisper，模型压缩到原来1/6，精度损失不到2%。适合企业内部部署，数据不出域。代码量从"调API三行"变成"搭流水线三百行"，产品经理听到这里通常会沉默。

说话人分离（diarization）是另一个深坑。Whisper本身不做这个，Deepgram和AssemblyAI内置了，但准确率依赖训练数据分布。中文会议里中英夹杂、同音字人名、突然插话的"对对对"，都是现成模型的盲区。自研的话，ecapa-tdnn + spectral clustering的链路，标注成本能让你重新评估这个功能优先级。

一个被低估的API：getDisplayMedia的音频陷阱

Chrome 104之后，getDisplayMedia的音频捕获才稳定可用。但macOS上有个诡异bug：如果用户选了"整个屏幕"而不是"Chrome标签页"，系统音频可能混不进MediaStream。解决方案是强制约束audio: { suppressLocalAudioPlayback: false }，或者在UI层引导用户只分享标签页。

Windows更麻烦。某些声卡驱动会把系统音频和麦克风混成单一流，你拿到的数据已经是"脏"的，后端做说话人分离基本无解。这时候只能降级方案：提示用户戴耳机，或者干脆放弃系统音频，只转写麦克风——也就是只记录用户自己说了什么。

Edge case的密度，决定了这个功能从demo到生产环境的距离。

成本账：别只算API调用费

Deepgram Nova-2，每分钟0.0043美元；AssemblyAI Universal，每分钟0.0037美元；Whisper API，每分钟0.006美元。看起来差距不大？月活10万用户、平均每周3小时会议，一年下来Deepgram比Whisper省4万美元。

但这只是明账。隐形成本在：WebSocket连接保活、音频缓冲区的内存占用、转写结果的存储和索引、合规审计的日志留存。一个没做流控的客户端，能把服务器连接池打穿，账单比API调用费高十倍。

有个取巧方案：用VAD（语音活动检测）前置过滤。没声音的时候不发包，能省30-50%的流量。WebRTC的VAD太保守，Silero VAD在wasm里跑，精度高一个档次，延迟增加不到20毫秒。

2026年的新变量：浏览器原生AI

Chrome 128开始内测Web Speech API的流式识别，完全本地跑，零网络延迟。但语言支持有限，中文准确率比Whisper差一截，且没有说话人分离。适合对延迟极度敏感、对准确率容忍度高的场景——比如实时字幕，而非会议纪要。

更激进的方案是WebGPU跑Llama 3.1 8B，端到端语音转写+摘要+待办提取。但显存占用和首次加载时间，目前只适合桌面端重度用户。移动端？等2027年吧。

技术选型没有银弹，只有场景适配。内部工具可以容忍300毫秒延迟换准确率，客服场景要的是200毫秒以内的即时反馈，合规场景宁愿本地跑慢模型也不让数据出域。

最后说一个细节。某团队上线实时转写三个月后，用户反馈里最高频的词不是"准"或"快"，是"能不能关掉"——有些人就是不想被机器记录。他们在设置里加了一个显眼的"暂停转写"按钮，点击率比预期高17%。

技术解决了能不能录的问题，产品还要回答应不应该录的问题。你的会议工具，准备好面对这个17%了吗？