圖說：墨寒在連續聲波中自然回應 Realtime 對話

圖說：墨寒的文字、一般語音與 Realtime 對話介面

昨天的 OpenAI 語音與 Windows 本機語音，主要都在回答一個問題：墨寒已經有文字了，要用什麼聲音把它說出來？

Realtime 則更像一通持續進行的電話。麥克風聲音一邊送出，系統一邊判斷我是否說完；回答的聲音又可能在完整文字出現以前就開始播放。它的吸引力很直接：等待比較少，對話比較像真人。

但我很快發現，「比較快」也代表原本排隊做的事情開始同時發生。只要其中一個訊號早到、晚到或重複到，墨寒就可能搶答、重複回答，甚至把系統提示當成我說的話。

一般語音像寄信，Realtime 比較像通話

非 Realtime 的一般語音路徑比較容易想像：我按下錄音，說完後送出一段音訊；系統把它轉成文字，再像一般文字訊息一樣請 AI 回答；拿到回答後才合成並播放聲音。

每一步都有比較清楚的前後順序。等待可能較久，但問題發生時也容易判斷卡在哪一段。

Realtime 則是長時間保持連線。它要處理開始說話、暫停、判定一句結束、輸入轉錄、回答音訊、回答文字、打斷與錯誤。這些事件不是永遠照我在紙上畫的順序到達。網路延遲一變，原本「先看到文字、再聽到聲音」可能反過來。

因此不能把一般語音那套等待邏輯原封不動套上去。Realtime 自己正在說話時，標準對話路徑若又啟動另一個等待計時器，兩邊就會同時爭奪表情與嘴型。

這也牽涉到一個我後來特別要求修正的觀念：畫面顯示「墨寒思考中」，只是在告訴使用者目前正在等待，不代表角色一定要立刻換成轉頭思考圖。Realtime 的等待通常很短，如果每次連線或送出資料都先演一次苦思，整段通話反而像不斷卡住。狀態文字與角色表情必須分開決定，真正的思考表情留給長時間、明確不確定或模型指定的情況。

快速回應最怕的是回答兩次

一段語音在處理過程中，可能先出現暫時文字，稍後才有確認完成的文字。如果每收到一次文字就送去回答，墨寒可能針對同一句話答兩遍。

為了讓記錄看起來即時，介面可以顯示進行中的內容；但真正觸發回答的，必須是確認後的使用者句子。同一個語音項目也要記住自己是否已經處理，避免重複事件再進來一次。

另一個更危險的狀況是沒有取得有效轉錄。背景噪音、極短聲音或辨識失敗，都不應該讓模型憑空接話。墨寒寧可告訴我這一輪沒有聽清楚，也不要假裝知道我說了什麼。

打斷不是粗魯，而是即時對話的基本能力

真人對話不會永遠等對方把整段演講說完。當墨寒正在回答，我可能想補充、糾正或直接停止。這時候不只是把喇叭靜音，還要讓正在進行的回答、嘴型與表情一起停在合理位置。

如果只停聲音，畫面可能繼續張嘴；如果只把畫面切回待機，舊音訊又可能從緩衝區冒出來。更麻煩的是，打斷後下一輪輸入必須乾淨開始，不能把上一輪殘留文字接到新問題。

我把這些感覺說成具體要求：停止後不得殘留說話狀態；舊回覆不能晚到後重新播放；新的使用者句子只觸發一次回答。Codex 才能沿著事件順序補測試，而不是只調一個「反應速度」數字。

還有一種常被忽略的打斷，是系統自己失敗。連線被拒絕、額度不足或網路斷線時，舊回覆也必須被視為終止，角色回到可再次操作的狀態。錯誤訊息要盡量說人話，讓我知道該檢查帳戶權限、網路或設定；不能只留下開發者看得懂的代碼，更不能仍顯示「通話中」讓人以為麥克風持續作用。

我們怎麼測一條會受網路影響的路？

真正的 Realtime 連線需要 API 權限、網路與服務狀態，不可能只靠一次成功通話就證明永遠正常。自動測試能做的是把事件順序拆開：完成轉錄來兩次是否去重、失敗轉錄會不會禁止自動回答、開始播放是否取消舊等待、停止後是否清理狀態。

實機則要聽延遲、打斷感受與長時間穩定性。這兩種證據各自回答不同問題。程式測試通過，不代表我的網路一定沒有延遲；一次通話順暢，也不代表重複事件的漏洞不存在。

我會至少走過幾種節奏：很短的問候、說到一半停頓、連續兩句、墨寒回答時插話、轉錄失敗後再說一次，以及從 Realtime 切回一般語音。這些情境比錄一段順暢展示更接近日常，也能檢查文字、一般語音與 Realtime 三條路有沒有各自殘留舊邏輯。

這也是我在文章中會持續區分「邏輯已測」與「多種真實環境仍待驗證」的原因。Realtime 很迷人，更容易因為一段流暢展示就讓人高估成熟度。

自然不是越快越好，而是每個人都知道何時輪到自己

做完這些調整後，我對「像真人」的理解又變了一點。人會在適當時候停下來聽，也會在沒聽清楚時詢問，不會因為追求零延遲就每半句搶答。

Realtime 的目標不是把所有等待消滅，而是縮短不必要的空白，同時保留清楚的輪替。墨寒要知道這輪是我在說、這句是否已確認、現在能否回答，以及被打斷後何時重新開始。

明天 Day 10，我會專門談「聽懂」這件事。聲音進了麥克風，不等於文字一定正確；有了文字，也不代表那一定是使用者真正說的內容。墨寒為什麼加入混合轉錄，又如何避免把提示詞自己念回來？

Realtime 的模型、權限與服務條件可能更新；本文以墨寒目前實作的狀態交接、去重與失敗處理觀念為主，不把單次連線經驗寫成普遍保證。