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連接?；睢⒁纛l緩沖區的內存占用、轉寫結果的存儲和索引、合規審計的日志留存。一個沒做流控的客戶端，能把服務器連接池打穿，賬單比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%了嗎？