做語音交互的工程師都懂一個數(shù)字：400毫秒。超過這條線，對話就會卡殼；超過800毫秒，用戶直接出戲。一位開發(fā)者在搭建AI編程面試平臺時，實測到850毫秒的"死亡停頓"——AI說完話，候選人要等近一秒才能開口。他把這段調(diào)試過程公開后，技術(shù)社區(qū)炸了鍋。

這不是網(wǎng)絡(luò)慢，是時機錯了。

問題出在WebSocket連接的打開時機。AI語音結(jié)束→打開麥克風(fēng)連接→DNS解析→TCP三次握手→WebSocket協(xié)議升級，這套流程在常規(guī)網(wǎng)絡(luò)環(huán)境下就要800-900毫秒。開發(fā)者形容："像面試官說完話突然發(fā)呆，然后才想起要聽對方回答。"

他的解法堪稱"偷時間"——利用TTS（文本轉(zhuǎn)語音）播放的窗口期，提前把連接準備好。

850毫秒是怎么消失的

intervu.dev的對話循環(huán)原本有四步：用戶說話→AI處理生成回復(fù)→TTS播放語音→打開麥克風(fēng)等用戶回應(yīng)。前三步串行執(zhí)行，第四步卡在連接開銷上。

開發(fā)者實測發(fā)現(xiàn)，TTS播放時系統(tǒng)完全空閑。用戶正在聽，麥克風(fēng)還沒必要激活，但網(wǎng)絡(luò)層可以動起來。他把這個洞察寫成代碼：TTS一開始播放，后臺立即啟動WebSocket連接；等AI說完，連接早已就緒，直接切到麥克風(fēng)。

代碼邏輯很直白。`onTTSPlaybackStart()`觸發(fā)預(yù)加載，`onTTSPlaybackEnd()`檢查連接狀態(tài)：就緒就立即激活，沒完成就走兜底邏輯。最壞情況400毫秒，是AI說話太短（1秒內(nèi)）導(dǎo)致預(yù)加載沒跑完。正常對話場景下，延遲壓到50-80毫秒。

從"等連接"變成"等說話"，順序一換，體驗質(zhì)變。

預(yù)加載不是新發(fā)明，是時機選擇

瀏覽器里的預(yù)加載技術(shù)遍地都是：圖片懶加載、DNS預(yù)解析、TCP預(yù)連接。但語音場景的預(yù)加載有個特殊約束——不能搶資源。TTS播放本身占帶寬和CPU，如果預(yù)加載太激進，可能卡頓音頻。

這位開發(fā)者的做法是"輕量預(yù)加載"：只開連接，不傳數(shù)據(jù)。WebSocket的`onopen`回調(diào)標記就緒狀態(tài)，實際音頻流等TTS結(jié)束后再走。相當于提前占座，但不點菜。

社區(qū)討論里有人提到類似思路：WebRTC的ICE候選收集也可以預(yù)做，減少首次通話延遲。還有人問為什么不用HTTP/2或WebTransport——WebSocket的瀏覽器兼容性仍是2024年的硬需求，尤其是企業(yè)內(nèi)網(wǎng)環(huán)境。

50毫秒背后的取舍

優(yōu)化后的數(shù)據(jù)很干凈：常規(guī)連接50-80毫秒，短語音回退400毫秒。開發(fā)者沒提的是，這個方案犧牲了極短交互的響應(yīng)速度——如果AI只回一個"好"字，用戶反而要等更久。

這是產(chǎn)品決策。面試場景里，AI回復(fù)通常不止一句話，預(yù)加載有足夠時間完成。真遇到單字回復(fù)，400毫秒仍在可接受范圍，不至于擊穿體驗底線。

代碼里留了容錯：`onerror`時把`micConnectionReady`標為false，自動降級到按需連接。沒有為了優(yōu)化而優(yōu)化，把可靠性鎖死。

技術(shù)債和體驗債，他選了先還體驗債。

這個案例被轉(zhuǎn)發(fā)到多個技術(shù)論壇后，最熱的評論是："原來我的語音助手卡頓不是因為OpenAI慢，是自家代碼沒調(diào)好。"另一條則很扎心："花了三個月優(yōu)化大模型延遲，發(fā)現(xiàn)瓶頸在WebSocket握手。"

開發(fā)者最后補了一句：測量方式是從TTS結(jié)束事件觸發(fā)，到后端收到首段音頻數(shù)據(jù)。這個定義本身就有講究——如果從前端麥克風(fēng)激活算起，數(shù)字會更漂亮，但他選了用戶無感的真實端到端延遲。

現(xiàn)在的問題是：當你的AI產(chǎn)品還在卷模型參數(shù)時，有沒有先看過瀏覽器的Network面板？