850毫秒。這是AI面試官說完話后，候選人干等麥克風(fēng)啟動的時間。放在真實面試場景里，這接近1秒的空白足夠讓對話徹底冷場——你會下意識懷疑自己是不是斷網(wǎng)了。

做intervu.dev的工程師最近公開了這個數(shù)字。這是個瀏覽器里跑的全語音AI模擬面試工具，候選人跟AI聊代碼、聊項目，全程不用打字。但就是這個不到1秒的延遲，讓產(chǎn)品體驗從"真人對話"跌成了"客服機(jī)器人"。

工程師的解決思路很有意思：既然TTS（文本轉(zhuǎn)語音）播放時用戶只能聽著，這段"強(qiáng)制靜默期"為什么不能拿來干點別的？

延遲從哪來：WebSocket的三次握手

問題出在對話輪轉(zhuǎn)的第三步。AI說完話，系統(tǒng)要打開麥克風(fēng)讓用戶回應(yīng)，而這一步需要新建一個WebSocket連接。DNS解析、TCP握手、WebSocket升級握手——這套流程在普通網(wǎng)絡(luò)環(huán)境下就要耗掉800-900毫秒。

測試環(huán)境多數(shù)時候沒問題，但網(wǎng)絡(luò)波動或高負(fù)載時，延遲會肉眼可見地惡化。用戶感受到的不是"技術(shù)限制"，是產(chǎn)品壞了。

工程師把延遲來源拆解得很清楚：TTS播放結(jié)束事件觸發(fā)→新建WebSocket→連接就緒→激活麥克風(fēng)→首包音頻抵達(dá)后端。整個鏈條里，WebSocket建立是剛性耗時，沒法壓縮。

但TTS播放本身創(chuàng)造了一個時間窗口。AI說話的那幾秒，用戶處于純接收狀態(tài)，系統(tǒng)卻閑著。這個窗口通常被浪費掉，而工程師決定用它來"預(yù)熱"連接。

預(yù)熱的具體操作：邊聽邊握手

代碼邏輯很直接。TTS播放開始的瞬間，后臺靜默啟動麥克風(fēng)WebSocket連接；TTS結(jié)束時，如果連接已就緒，直接激活麥克風(fēng)。最壞情況下預(yù)熱沒完成，就回到原來的按需打開模式。

實測數(shù)據(jù)：預(yù)熱成功時延遲壓到50-80毫秒；即使走fallback路徑，也比原來快一截。整體從850毫秒降到400毫秒以內(nèi)，降幅53%。

這個方案有個邊界條件：AI說話太短（1秒內(nèi)）時，預(yù)熱可能來不及完成。但面試場景里AI很少只蹦一兩個詞，這個corner case的觸發(fā)概率極低。

工程師在分享里提到一個細(xì)節(jié)：他們測量的是"TTS結(jié)束事件觸發(fā)"到"首包音頻抵達(dá)后端"的完整耗時，不是單純的連接建立時間。這意味著優(yōu)化覆蓋了全鏈路，沒有玩數(shù)字游戲。

為什么這個方法值得注意

語音AI的延遲優(yōu)化通常盯著模型推理加速、音頻編解碼效率，或者邊緣部署。這個案例反其道而行，在應(yīng)用層找到了一個"時間套利"的機(jī)會——利用人類對話的天然間隙，把網(wǎng)絡(luò)握手這種無法避免的開銷藏進(jìn)去。

類比一下：就像餐廳在客人看菜單的時候，提前把廚房預(yù)熱好。菜點完立刻能炒，客人不會覺得等了很久，盡管廚房準(zhǔn)備工作其實早就做了。

這種方法的遷移成本很低。不需要改基礎(chǔ)設(shè)施，不用換模型，純前端邏輯就能實現(xiàn)。對于已經(jīng)在瀏覽器里跑語音交互的產(chǎn)品，是個可以立即試水的優(yōu)化點。

工程師沒有透露intervu.dev的用戶規(guī)模，但從技術(shù)細(xì)節(jié)看，這個方案已經(jīng)在真實面試場景里跑了一段時間。fallback機(jī)制的存在也說明他們考慮過穩(wěn)定性，不是實驗室Demo。

語音AI的競爭正在從"能不能聽懂"轉(zhuǎn)向"對話流不流暢"。850毫秒到400毫秒的差距，用戶可能說不出具體數(shù)字，但一定能感覺到"這個更像真人"。

下一個問題是：當(dāng)延遲降到400毫秒以內(nèi)，瓶頸會轉(zhuǎn)移到哪里？是候選人的網(wǎng)絡(luò)環(huán)境，還是AI生成回復(fù)的速度，又或者是人們心理上對"即時回應(yīng)"的期待本身？