谷歌把語音識別藏了11年，開發者現在才玩明白

　　2013年Chrome 33就內置的Web Speech API，直到2024年才被開發者真正用起來。一個瀏覽器原生支持的語音轉文字接口，長期被AI應用開發者忽視——不是因為技術門檻，而是因為沒人把它和LLM（大語言模型）串成閉環。

　　這篇文章要解決的，就是怎么把"聽到的話"變成"AI能回的答案"，全程不用安裝任何語音識別SDK。

　　Web Speech API分兩塊：SpeechRecognition負責聽，SpeechSynthesis負責說。本文只用到前者——把麥克風輸入轉成文字。

　　核心代碼就三行。實例化識別對象，綁定事件監聽，啟動識別：

　　const recognition = new SpeechRecognition();
recognition.addEventListener("result", handleResult);
recognition.start();

　　瀏覽器會自動處理音頻采集、噪聲過濾、語音端點檢測。你不需要懂聲學模型，也不需要調采樣率。Google把ASR（自動語音識別）的復雜度全部封裝在瀏覽器底層。

　　但有個限制：Chrome要求頁面必須通過HTTPS或localhost運行，否則麥克風權限申請會被靜默拒絕。很多開發者在本地調試時卡在這一步，其實是協議問題，不是代碼問題。

　　前端只做兩件事：采集語音、展示結果。識別出的文字通過HTTP POST發給后端，后端調用AI接口（OpenAI、Claude、Gemini任選），再把回復返給前端渲染。

　　這個架構的關鍵在于流式傳輸。SpeechRecognition支持連續識別（continuous: true），用戶說話過程中文字會實時追加到輸入框。配合WebSocket或SSE（服務器發送事件），AI的回復也能逐字顯示，模仿ChatGPT的打字效果。

　　后端用Node.js+Express足夠。一個極簡的prompt路由大概長這樣：

　　app.post('/chat', async (req, res) => {
const { text } = req.body;
const response = await aiClient.chat.completions.create({
messages: [{ role: 'user', content: text }]
});
res.json({ reply: response.choices[0].message.content });
});

　　前端推薦用Vite打包，托管到Firebase Hosting。一鍵部署、全球CDN、免費SSL證書，適合快速驗證想法。

　　后端容器化后丟給Google Cloud Run。注意設置并發數（concurrency）為1，因為SpeechRecognition的流式特性會讓單個請求占用連接較長時間。默認的80并發會把實例打爆。

　　另一個細節：Cloud Run的冷啟動約2-3秒，而語音識別通常在5秒內完成。如果用戶第一句話就觸發冷啟動，總延遲可能超過7秒——體驗斷崖式下跌。建議設置最小實例數為1，或者前端加loading狀態管理預期。

　　完整的代碼倉庫和分步截圖在原文檔中，從空項目到線上可用大約需要40分鐘。

　　這套方案最省的地方在于：你不需要為語音識別付費。Google承擔了ASR的算力成本，你只需要為LLM的token和托管流量買單。對比阿里云、訊飛等第三方語音接口，長期能省掉30-50%的語音相關支出。

　　但依賴瀏覽器API也有代價。Safari至今不支持SpeechRecognition，Firefox需要手動開啟flag。如果你的用戶群體iOS占比高，還是得回退到原生方案或第三方服務。

　　有個開發者把這套流程接進了自己的CRM系統，銷售打電話時實時轉寫客戶需求，AI自動生成跟進話術。他反饋說最意外的收獲是：語音輸入的prompt質量比打字高——用戶說話更自然，少了很多"請""麻煩"之類的禮貌用語，AI反而理解得更準。

　　你現在最想把語音交互塞進哪個場景？是客服機器人、代碼助手，還是給家里的老人做個語音備忘錄？