去年開會(huì)還要手動(dòng)記筆記的人，今年已經(jīng)被同事當(dāng)成數(shù)字難民了。

2024年，實(shí)時(shí)字幕還是Zoom的付費(fèi)彩蛋；2026年，它成了所有會(huì)議工具的入場券。用戶要的不是錄音回放，是話音剛落文字已現(xiàn)的零摩擦體驗(yàn)。Whisper、Deepgram、AssemblyAI三家把流式音頻延遲卷進(jìn)了300毫秒以內(nèi)，瀏覽器API也終于松口——不用裝插件，直接抓標(biāo)簽頁音軌。

技術(shù)債務(wù)清零的時(shí)刻到了。

但別急著寫代碼。先看清數(shù)據(jù)怎么流：瀏覽器標(biāo)簽音頻 → MediaStream → AudioWorklet → WebSocket → 語音識別API → 轉(zhuǎn)寫文本。 raw PCM音頻從瀏覽器出來，切成100-250毫秒的小塊，WebSocket送到流式識別端點(diǎn)，部分結(jié)果和最終結(jié)果交替返回。難點(diǎn)不在單點(diǎn)，在整條管道的延遲控制，以及網(wǎng)絡(luò)抖動(dòng)、說話人切換、音頻重采樣這些邊緣場景的兜底。

第一個(gè)坑在這里：既要抓會(huì)議音（系統(tǒng)/標(biāo)簽頁音頻），又要抓自己的麥克風(fēng)，得把兩條MediaStream軌道混到一起。

混流代碼：比想象中臟，比文檔中少

大部分開發(fā)者第一次調(diào)用getDisplayMedia時(shí)都會(huì)愣住——這API設(shè)計(jì)的時(shí)候顯然沒考慮過"只要音頻不要畫面"的場景。視頻參數(shù)設(shè)false，音頻參數(shù)卻要展開一堆布爾值：回聲消除關(guān)、降噪關(guān)、采樣率鎖死16kHz。麥克風(fēng)那邊相反，回聲消除和降噪全開。兩個(gè)流進(jìn)AudioContext，createMediaStreamDestination打混，出來就是16kHz單聲道PCM——所有主流語音識別API的母語格式。

瀏覽器里做重采樣，比服務(wù)端做便宜一個(gè)數(shù)量級。這個(gè)細(xì)節(jié)能省下的服務(wù)器賬單，夠你多招一個(gè)后端。

別碰ScriptProcessorNode。它 deprecated 了，還跑在主線程上。AudioWorklet才是正解：

processor.js里注冊一個(gè)PCMProcessor，process方法把inputs[0][0]的buffer丟給port.postMessage，帶轉(zhuǎn)移所有權(quán)。主線程await audioContext.audioWorklet.addModule加載這個(gè)模塊，后面就能穩(wěn)定收音頻幀。主線程不卡，音頻不丟，這是能上線和不能上線的分界線。

WebSocket的隱形天花板：不是帶寬，是隊(duì)頭阻塞

音頻幀100毫秒一發(fā)，WebSocket看起來綽綽有余。直到某個(gè)用戶的Wi-Fi從5GHz跳到2.4GHz，延遲從30毫秒漲到300毫秒，你的緩沖策略如果沒做，整句轉(zhuǎn)寫會(huì)突然快進(jìn)式吐出，用戶體驗(yàn)直接崩盤。

Deepgram的流式API有個(gè)細(xì)節(jié)：它返回的partial transcript是"正在說的"，final transcript是"說完的"。你的UI要同時(shí)處理兩種狀態(tài)——partial用來實(shí)時(shí)滾動(dòng)，final用來落庫和生成待辦。很多開發(fā)者只接final，結(jié)果用戶看著字幕比說話慢兩拍，罵聲比延遲還高。

AssemblyAI的做法更細(xì)：它區(qū)分utterance（說話人一段完整發(fā)言）和word-level timing。做會(huì)議紀(jì)要時(shí)，utterance用來切分說話人；做實(shí)時(shí)字幕時(shí)，word-level timing能讓高亮詞和音頻精準(zhǔn)對齊。選型時(shí)先問自己：產(chǎn)品核心場景是"看懂"還是"搜到"？

Whisper的陷阱：本地跑還是云端調(diào)？

OpenAI把Whisper API的價(jià)格打到每分鐘0.006美元，但延遲在500毫秒左右徘徊。本地跑Whisper.cpp，M1 Mac上能壓到200毫秒以內(nèi)，代價(jià)是模型體積和首次加載的卡頓。瀏覽器里跑ONNX Runtime + Whisper Web，適合隱私敏感場景，但wasm的性能天花板明擺著。

有個(gè)中間路線：用Transformers.js在瀏覽器里跑distil-whisper，模型壓縮到原來1/6，精度損失不到2%。適合企業(yè)內(nèi)部部署，數(shù)據(jù)不出域。代碼量從"調(diào)API三行"變成"搭流水線三百行"，產(chǎn)品經(jīng)理聽到這里通常會(huì)沉默。

說話人分離（diarization）是另一個(gè)深坑。Whisper本身不做這個(gè)，Deepgram和AssemblyAI內(nèi)置了，但準(zhǔn)確率依賴訓(xùn)練數(shù)據(jù)分布。中文會(huì)議里中英夾雜、同音字人名、突然插話的"對對對"，都是現(xiàn)成模型的盲區(qū)。自研的話，ecapa-tdnn + spectral clustering的鏈路，標(biāo)注成本能讓你重新評估這個(gè)功能優(yōu)先級。

一個(gè)被低估的API：getDisplayMedia的音頻陷阱

Chrome 104之后，getDisplayMedia的音頻捕獲才穩(wěn)定可用。但macOS上有個(gè)詭異bug：如果用戶選了"整個(gè)屏幕"而不是"Chrome標(biāo)簽頁"，系統(tǒng)音頻可能混不進(jìn)MediaStream。解決方案是強(qiáng)制約束audio: { suppressLocalAudioPlayback: false }，或者在UI層引導(dǎo)用戶只分享標(biāo)簽頁。

Windows更麻煩。某些聲卡驅(qū)動(dòng)會(huì)把系統(tǒng)音頻和麥克風(fēng)混成單一流，你拿到的數(shù)據(jù)已經(jīng)是"臟"的，后端做說話人分離基本無解。這時(shí)候只能降級方案：提示用戶戴耳機(jī)，或者干脆放棄系統(tǒng)音頻，只轉(zhuǎn)寫麥克風(fēng)——也就是只記錄用戶自己說了什么。

Edge case的密度，決定了這個(gè)功能從demo到生產(chǎn)環(huán)境的距離。

成本賬：別只算API調(diào)用費(fèi)

Deepgram Nova-2，每分鐘0.0043美元；AssemblyAI Universal，每分鐘0.0037美元；Whisper API，每分鐘0.006美元�？雌饋聿罹嗖淮螅吭禄�10萬用戶、平均每周3小時(shí)會(huì)議，一年下來Deepgram比Whisper省4萬美元。

但這只是明賬。隱形成本在：WebSocket連接保活、音頻緩沖區(qū)的內(nèi)存占用、轉(zhuǎn)寫結(jié)果的存儲(chǔ)和索引、合規(guī)審計(jì)的日志留存。一個(gè)沒做流控的客戶端，能把服務(wù)器連接池打穿，賬單比API調(diào)用費(fèi)高十倍。

有個(gè)取巧方案：用VAD（語音活動(dòng)檢測）前置過濾。沒聲音的時(shí)候不發(fā)包，能省30-50%的流量。WebRTC的VAD太保守，Silero VAD在wasm里跑，精度高一個(gè)檔次，延遲增加不到20毫秒。

2026年的新變量：瀏覽器原生AI

Chrome 128開始內(nèi)測Web Speech API的流式識別，完全本地跑，零網(wǎng)絡(luò)延遲。但語言支持有限，中文準(zhǔn)確率比Whisper差一截，且沒有說話人分離。適合對延遲極度敏感、對準(zhǔn)確率容忍度高的場景——比如實(shí)時(shí)字幕，而非會(huì)議紀(jì)要。

更激進(jìn)的方案是WebGPU跑Llama 3.1 8B，端到端語音轉(zhuǎn)寫+摘要+待辦提取。但顯存占用和首次加載時(shí)間，目前只適合桌面端重度用戶。移動(dòng)端？等2027年吧。

技術(shù)選型沒有銀彈，只有場景適配。內(nèi)部工具可以容忍300毫秒延遲換準(zhǔn)確率，客服場景要的是200毫秒以內(nèi)的即時(shí)反饋，合規(guī)場景寧愿本地跑慢模型也不讓數(shù)據(jù)出域。

最后說一個(gè)細(xì)節(jié)。某團(tuán)隊(duì)上線實(shí)時(shí)轉(zhuǎn)寫三個(gè)月后，用戶反饋里最高頻的詞不是"準(zhǔn)"或"快"，是"能不能關(guān)掉"——有些人就是不想被機(jī)器記錄。他們在設(shè)置里加了一個(gè)顯眼的"暫停轉(zhuǎn)寫"按鈕，點(diǎn)擊率比預(yù)期高17%。

技術(shù)解決了能不能錄的問題，產(chǎn)品還要回答應(yīng)不應(yīng)該錄的問題。你的會(huì)議工具，準(zhǔn)備好面對這個(gè)17%了嗎？