使用情境技術白皮書：在真實的通話裡，ZENSBUDS AI 的翻譯是怎麼發生的

上一篇我們講了 ZENSBUDS AI「能做什麼」。這一篇換個方式——用真實場景帶你走一遍：每個情境裡你會看到「使用者經歷了什麼」，以及「耳機與手機在背後做了什麼」。

先給一句話的背景：iOS 與 Android 為了安全，把每個 App 關進各自的沙盒（sandbox），通話中的語音串流不會開放給第三方翻譯 App。所以真正的工程不在手機軟體層，而在耳機——它是唯一同時接觸到「你的嘴」「你的耳朵」和「手機」的裝置，於是我們讓它當那座橋。這正是我們專利技術（patented technology）的核心（專利標題：Auxiliary Audio Device and Method Using Multiple Communication Channels）。

下面六個情境，會把這座橋怎麼搭、怎麼用，一個一個講清楚。

情境一：你打電話給只說對方語言的人

場景：你只說英文，要打給只說普通話的供應商 Wang。
目標：像平常一樣講電話，對方卻聽到流利的普通話。

你經歷的：戴上耳機、用平常的通話 App 撥號。通話一接通，你開口說英文；Wang 在他那頭聽到的是普通話。你講完一段、停頓一下，翻譯就送過去了。

背後發生的：

先講聲道對應——這是整套機制的基礎。經典藍牙 HFP 提供兩條單聲道：右單聲道保留給你的麥克風（你說的話），左單聲道保留給對方傳入的聲音。兩條合起來，就是一組立體聲。

1. 觸發：通話一接通，正門通道（HFP）被啟動；我們直接拿「通話協定的啟動」當開關，以此訊號打開旁路通道。好處有二——晶片上能寫的觸發條件本就稀少，這樣省下一個；旁路也不必整天開著，只在通話期間存在，最省電。
2. 擷取與複製：麥克風收音後，處理器把你的語音放上右單聲道，與（此刻多半是空的）左單聲道合成立體聲，並把這組訊號複製成兩份。
3. 正門（通道 1）：第一份以 HFP 照常送進通話 App，傳給對方——這是你的英文原音。（可由軟體設定關閉，讓對方只聽翻譯版本。）
4. 旁路（通道 2）：第二份用業界標準語音編解碼壓縮成小封包串流，走旁路送到手機上的翻譯程式。這一步是整個專利的關鍵——通話 App 的語音本來是封死的，但耳機握有同一份音訊，便從側門再輸出一份給翻譯程式。
5. 翻譯管線：翻譯程式先把立體聲拆回左／右單聲道，對語音做語音轉文字（STT），文字過語言模型翻譯（MT），再以文字轉語音（TTS）生成普通話，最後把結果（必要時 mono→stereo）重新編碼成「第三條資料流」。
6. 回傳與回注：第三條資料流走旁路（通道 2，或獨立的通道 3）送回耳機；耳機先在你耳裡播一次（讓你知道已送出、甚至能粗估長度與正確性），再把它重新以 HFP 編碼，從通道 1 回注通話 App——被當成「麥克風輸入」收下，經網路送達 Wang。

三種對話節奏，系統都接得住：

• 獨白（你講、對方安靜聽）：偵測到約 1.5 秒沒有聲音，就把這段編譯送翻。
• 你說故事、對方穿插「嗯」「OK」：系統比較左右聲道轉出的文字長度，判斷誰是主要說話者，優先翻較長的那一段——短插話不會干擾。
• 一來一往的互動：雙向都翻，依說話者與來源聲道決定翻譯方向，再以立體聲送回。

情境二：對方用你不懂的語言打給你

場景：日本客戶來電，全程說日文。
目標：你聽得懂，而且不錯過對方的語氣。

你經歷的：接起電話，你先聽到對方的日文原音，緊接著在耳邊聽到英文翻譯。你同時掌握了「他說了什麼」和「他是用什麼口氣說的」。

背後發生的：這是「情境一」的鏡像，但起點在對方。

1. 入站：Wang 的日文經網路進到你的通話 App，依慣例落在 HFP 的左單聲道（入站保留聲道），送進耳機。
2. 原音優先：耳機處理器先解碼這段音訊，透過 mono→stereo 在你兩耳（立體聲模式）或單耳（左右分聲模式）播出——所以你先聽到對方的日文原音，語氣、情緒一併到位。
3. 側門再輸出：與此同時，處理器把這段入站音訊複製一份、用標準語音編解碼重新壓縮，走旁路推回手機上的翻譯程式。關鍵同樣在這裡——通話 App 的入站語音本來不對外開放，但耳機已經收到了，便從側門再導出一份。
4. 翻譯：翻譯程式偵測到約 1.5 秒停頓後，對日文做 STT → MT → 生成英文 TTS，（必要時 mono→stereo）編碼成第三條資料流，走旁路送回耳機。
5. 播放：耳機解碼後把英文翻譯播給你聽——於是你先得到原音（語氣）、再得到翻譯（內容），順序一如真人口譯。
6. 可選回注：若開啟，耳機可把這段英文以 HFP 回注通話，讓 Wang 聽到自己那句話被翻成英文的版本。是否讓雙方都聽到翻譯，取決於翻譯音訊編碼時走的是 mono 還是 mono→stereo（由 App 或裝置設定決定）。

情境三：跨語言線上會議

場景：你在 Zoom / Teams / Google Meet 上，和不同語言的同事開會。
目標：邊聽邊懂，發言也能讓對方即時聽懂。

你經歷的：與一對一通話相同的體驗，只是參與者更多；你還會在畫面上看到字幕。

背後發生的：

• 為什麼平台無關：耳機是在音訊路由層運作，而不是鑽進 Zoom／Teams／Meet 的內部。對作業系統而言，會議 App 只是另一個建立了「通話音訊工作階段（call audio session）」的應用；該工作階段的啟動，就是我們打開旁路的觸發點。因此不需要任何會議軟體的 SDK、外掛或授權。
• 出站：你的發言如情境一般複製兩份——一份走通道 1 正常進會議、傳給所有與會者；一份走旁路給翻譯程式，生成對方語言後回注，讓遠端聽到你語言的翻譯；同一份文字結果可同步渲染成畫面字幕。
• 入站：會議 App 會把所有遠端與會者混音成單一下行串流，經通道 1 進耳機；耳機複製一份走旁路 → 翻譯 → 回耳機，你便聽到母語翻譯、並看到字幕。
• 多人場景的取捨：因為下行是混音後的單一串流，翻譯是對「當下正在說話的人」運作；當多人同時搶話，1.5 秒停頓偵測與依文字長度判斷主要說話者的機制會挑出主導發言來翻，避免把交疊的短語碎片硬翻。

情境四：面對面對話

場景：東京的市場、巴黎的飯店櫃台，你和店員當面交談。
目標：自然、順、不尷尬。

你經歷的：切到 Face-to-Face（對面）模式，把手機放在兩人之間；你說的話以對方語言從手機喇叭播出，對方說的話以你的語言進你耳朵。

背後發生的：

• 少了網路那一段：與通話情境最大的不同，是這裡沒有電信／VoIP 網路腳程。音訊迴路只在「耳機 ↔ 手機」本地完成，因此端到端延遲只剩下 STT＋MT＋TTS 的處理時間——這就是「幾乎沒有延遲感」的來源。
• 兩條翻譯方向並行：你的語音由耳機麥克風擷取 → 走旁路給翻譯程式 → 生成對方語言 → 由手機喇叭播給店員；店員的語音由麥克風擷取 → 翻成你的語言 → 回你耳機。兩個方向各自跑一遍 STT→MT→TTS，互不阻塞。
• 斷句與口語調校：同樣以約 1.5 秒停頓判定「一句講完了」；翻譯前的語音辨識模組會持續解碼、並依整句語意即時修正先前的辨識結果，針對日常口語的語氣與省略做校正，少了舊式逐字翻譯那種一頓一頓的停滯。
• 線上／離線通用：旅途中常沒有穩定網路，此模式同樣可在雲端與裝置端模型間切換（見情境六）。

情境五：通話錄音 ＋ 會後摘要

場景：一通重要的跨語言業務電話，你想留存紀錄。
目標：事後能回看逐字稿與摘要。

你經歷的：開啟錄音，通話結束後，你拿到的不只是一段錄音，而是分話者的逐字稿＋摘要。

背後發生的：

• 為什麼一般 App 錄不到：作業系統基於隱私，通常封鎖第三方對「通話音訊」的存取——這也是多數手機原生通話錄音受限的原因。但在我們的架構裡，雙向音訊早已被耳機複製、經旁路送到手機端的翻譯程式，等於跳出了通話 App 封死的緩衝區。
• 能錄什麼、怎麼分軌：因為出站走右單聲道、入站走左單聲道，且兩個方向各自有 STT 結果，錄音模組可以把它們存成分離的音軌：你的原音（語言 1）、對方原音（語言 2），以及兩個方向的 TTS 翻譯版本。左右聲道天然分離，讓分話者辨識（speaker diarization）幾乎是免費得到的。
• 逐字稿與摘要怎麼來：翻譯管線本來就為了翻譯而對雙向語音做了 STT；錄音其實只是把這條管線「順手產生」的文字與時間軸保存下來。通話一結束，逐字稿與摘要已經備好，可直接匯出。
• 格式：以標準 PCM／壓縮音訊保存，方便後續轉檔與分享。

情境六：沒有網路的時候（地鐵、飛機、偏遠地區）

場景：訊號斷斷續續，但你還是得溝通。
目標：離線也能用。

背後發生的：

• 切換邏輯：翻譯程式依當下網路條件選擇後端。判斷很務實——若頻寬足以承載這通語音／視訊通話，就足以呼叫雲端翻譯（如 Microsoft Azure、OpenAI）以追求最高準確度；一旦頻寬或延遲不行，立即退回裝置端模型。
• 裝置端怎麼跑：離線時，STT、MT、TTS 全部在本機完成，使用一個為行動裝置最佳化的輕量語言模型。少了網路往返，這條路的延遲反而更低，上限則受手機本身運算力限制。
• 即時修正：語音辨識模組以增量解碼持續辨識，並依整句逐漸成形的語意回頭修正前面可能聽錯的字——所以不會因為一個詞被聽錯，整句就崩掉。
• 架構不變，只換後端：重點是——不論線上或離線，音訊路由完全一樣（複製、旁路、翻譯、回注那一整套）；切換的只是「翻譯在哪裡算」。離線時音訊不離開裝置，附帶隱私上的好處。

技術原理：這座橋是怎麼搭的

上面六個情境，背後是同一套架構。以下把機制集中說明。

多通道：用兩到三條無線通道繞過沙盒

重點在通道 2：我們另闢一條旁路通道，這類通道本來不是設計來傳音訊的；我們把它重新利用成一條音訊旁路——這條路通話 App 看不到，但翻譯程式收得到。於是耳機可以做一件通話 App 不允許任何人做的事：把聲音複製一份，從側門送出去翻譯，再從側門拿回來，最後從正門塞回通話。

        ┌──────────────── 耳機（Auxiliary Device）────────────────┐
  你說話 →│ 麥克風 → 處理器 ─┬─[通道1 HFP]─────────────► 手機通話App → 對方
        │                 └─[通道2 旁路]─────► 手機翻譯程式
        │                                          │ STT→翻譯→TTS
        │   耳朵 ◄─ 處理器 ◄─[通道2/3 旁路]◄───────┘
        │                 └─[通道1 HFP] 回注 ──► 手機通話App → 對方（翻譯版）
        └──────────────────────────────────────────────────────────┘

聲道設計：兩種模式，依需求切換

收聽方式做成可選的兩種模式，兩種都跑在同一套低延遲引擎上：

• 左右分聲模式（預設）：原音走一耳、翻譯走另一耳。因為每側只需處理並播放單一串流，對運算與播放的負擔較低，最省電、續航最長（這也是我們把它設為預設的原因）。即使是左右分聲，仍享有低延遲引擎，翻譯幾乎即時跟上，不會讓兩耳互相打架。
• 立體聲沉浸模式：傳入語音做 mono→stereo，原音與翻譯都在兩耳呈現，你同時得到原音（語氣、情緒）＋翻譯（內容），最接近真人口譯的臨場感；代價是較高的處理與播放負擔，較耗電。

要最長續航用左右分聲；要最自然的臨場感切到立體聲。兩者皆可在 App 內切換。

延遲

「翻譯回注」這條路徑——音訊在耳機↔手機間往返、翻譯、再回注、再經網路送出——技術上可達到的最低額外延遲約為 0.35 秒。實際使用時會略高於這個數字，並會隨處理器與翻譯引擎演進而持續下降。

注意：0.35 秒是理想條件下的最低值，不是使用者整體感受到的端到端延遲（後者另含 STT＋MT＋TTS）。

結語：橋，不是攔截

ZENSBUDS AI 能在通話裡即時雙向翻譯，靠的不是「破解」哪個 App，而是換了個位置思考——讓最貼近你的那副耳機，當起手機內部 App 之間的橋。把聲音引導出來、翻好、再送回去，繞過了系統沙盒，卻完全沒有破壞它的安全邊界。

據我們所知，目前沒有其他品牌的翻譯耳機能在通話中做到即時雙向翻譯——這就是我們專利技術的核心，也是為什麼這套系統，能做到別人做不到的事。