影片筆記：泛科逆向工程！英文即時翻譯擴充工具三天打造完成！直播字幕

一句話總結

講者分享如何在三天內，透過逆向工程參考 VTOL 與 Mistral 等現有工具，利用 Chrome 單一頁面聲音通道結合 Deepgram 與 DeepL API，以極低成本（近乎零）與極低延遲（0.3秒）完成 NVIDIA GTC 臺北 2026 黃仁勳演講的即時繁體字幕翻譯外掛。

核心重點

從「執行者」轉向「引導者」的 AI 使用思維：

• 初期直接使用 Gemini Live API 處理聲音與翻譯，因延遲過高（約兩秒）導致音畫不同步而失敗，甚至被 AI 誤導繼續消耗 Token（稱為「AI 仙人跳」）。
• 透過詢問 AI「哪些服務做得好？」及「如何做到低延遲？」，成功引導出 VTOL 與 Mistral 的技術架構線索，進而找到正確技術路徑。

關鍵技術突破：Chrome 單一頁面聲音通道：

• 放棄抓取電腦整體聲音輸出，改採 Chrome 瀏覽器內部的「單一頁面聲音通道」（Single Page Audio Output）。
• 此機制類似 Chrome 輔助功能中給聾啞人士使用的無障礙字幕，能直接對接瀏覽器底層聲音數據。
• 優點：聲音乾淨、無雜音、精準抓取特定分頁聲音。
• 限制：Netflix 等部分串流平台會擋住此通道，但 YouTube、Twitch 等平台可用。

最終解決方案架構與效能：

• 架構：Chrome 單一頁面聲音通道抓取音訊 -> Deepgram API（ASR 逐字稿） -> DeepL API（翻譯）。
• 效能：總延遲控制在 0.3 秒左右，符合 0.5 秒內的目標。
• DeepL 機制：採用「斷點預譯」，在說話者尚未講完一句話時，若出現斷點即先送出翻譯，讓用戶感覺更即時，但完整句子呈現時才會顯示完整翻譯。

極低成本與部署：

• 成本：幾乎為零。Deepgram 註冊贈送 200 美金額度（估算可用兩百年），DeepL 註冊贈送 50 萬字翻譯額度（直播一小時約消耗 4 萬字）。
• 部署：開發為 Chrome 外掛，需開啟「開發者模式」載入未上架外掛進行內部測試。外掛對話框可移動，以便在 OBS 中調整位置嵌入直播畫面。

詳細大綱

A. 背景與挑戰

• 活動背景：NVIDIA GTC 臺北 2026 黃仁勳直播演講，需進行即時繁體字幕翻譯。
• 需求條件：
• 即時性：延遲必須極低（目標 0.5 秒內）。
• 準確性：正確率高，無延誤。
• 在地化：避免對岸用語或簡體中文，需符合臺灣用語習慣。
• 環境限制：需作為 Chrome 外掛運行，並能嵌入 OBS 直播畫面。
• 時間壓力：從接到任務到完成僅剩三天（前期有三天「裝死」思考期）。

B. 初期失敗嘗試：Gemini Live API

• 初始構想：收電腦聲音源 -> 送入 Google Gemini Live API -> 直接輸出字幕。
• 問題發現：
• 延遲過高：平均需兩秒才能出現字幕。
• 音畫不同步：觀眾聽到的是當下內容，畫面顯示的是兩秒前（兩句話前）的內容，造成視覺與聽覺不協調。
• AI 誤導：Gemini 鼓勵繼續做下去，導致在錯誤迴圈中消耗 Token 與金錢（被稱為「AI 仙人跳」）。
• 結論：通用型 Live API 不適合對延遲要求極高的即時翻譯場景。

C. 技術突破：發現關鍵架構

• 參考對象：
• VTOL：Chrome 外掛，效能優於講者初期開發版本。
• Mistral：法國公司服務，支援 OBS 連線，效能良好。
• 核心發現：
• 這些服務並非抓取電腦整體聲音輸出，而是利用 Chrome 瀏覽器內部的「單一頁面聲音通道」（Single Page Audio Output）。
• 類似 Chrome 輔助功能中給聾啞人士使用的無障礙字幕功能，直接對接瀏覽器底層聲音數據。
• 優點：聲音乾淨、無雜音、精準抓取特定分頁聲音。
• 限制：Netflix 等串流平台會擋住此通道，但 YouTube、Twitch 等平台可用。

D. 最終解決方案架構

• 技術組合：

聲音抓取：利用 Chrome 單一頁面聲音通道抓取音訊。

逐字稿轉換 (ASR)：使用 Deepgram API。

• 特點：極快，平均延遲約 0.2 秒。

翻譯服務：使用 DeepL API。

• 特點：繁體中文資源豐富，翻譯品質佳，能避免對岸用語。
• 效能表現：
• 總延遲控制在 0.3 秒左右，符合 0.5 秒內的目標。
• DeepL 採用「斷點預譯」機制：在說話者尚未講完一句話時，若出現斷點即先送出翻譯，讓用戶感覺更即時，但實際完整句子呈現時才會顯示完整翻譯。

E. 成本與部署細節

• 成本：幾乎為零。
• Deepgram：註冊贈送 200 美金額度，足夠使用數百小時（講者估算可用兩百年）。
• DeepL：註冊贈送 50 萬字翻譯額度，直播一小時約消耗 4 萬字。
• 部署方式：
• 開發為 Chrome 外掛。
• 需開啟 Chrome 的「開發者模式」以載入未上架的外掛進行內部測試。
• 外掛對話框可移動，以便在 OBS 中調整位置。

F. 經驗總結與 AI 互動思維

• AI 的角色轉變：從「直接執行者」轉變為「引導者與諮詢者」。
• 透過詢問 AI「哪些服務做得好？」，獲得 VTOL 與 Mistral 的線索。
• 透過詢問 AI「如何做到低延遲？」，獲得關於 Chrome 聲音通道與專用 API 的技術指引。
• 思維建議：
• 不要只問「怎麼做」，要尋找「好的學習對象」或「範例」。
• 利用 AI 記錄技術軌跡，讓後續使用者無需重複踩坑。
• 換個方式與 AI 互動，許多看似做不到的事情可能透過正確的工具組合得以實現。

工具 / 模型 / 名詞整理

• 硬體/平台：
• RTX (GPU)
• DGX (系統)
• OBS (直播軟體)
• Chrome (瀏覽器)
• YouTube (串流平台)
• Twitch (串流平台)
• Netflix (串流平台，會擋住聲音通道)

• 軟體/服務/API：
• Gemini Live API (Google，初期嘗試失敗的通用 API)
• VTOL (Chrome 外掛，參考對象)
• Mistral (法國公司，Chrome 外掛/OBS 整合，參考對象)
• Deepgram (ASR 逐字稿 API，核心組件)
• DeepL (翻譯 API，核心組件)
• Google 機器翻譯方案 (YouTube 內建，僅顯示一行，被認為較不好)

• 活動/組織：
• NVIDIA GTC 臺北 2026
• 泛科學 (PanSci)
• 實戰生 (會員名稱)

操作流程整理

需求分析與初期試錯：

• 確認 NVIDIA GTC 臺北 2026 即時翻譯需求（低延遲、繁體中文、嵌入 OBS）。
• 嘗試使用 Gemini Live API 直接處理聲音與翻譯，發現延遲過高（約兩秒）導致音畫不同步。
• 識別到通用 Live API 不適合高即時性場景，並警惕 AI 誤導消耗資源。

技術調研與架構發現：

• 利用 AI 詢問「哪些服務做得好？」及「如何做到低延遲？」。
• 發現 VTOL 與 Mistral 等工具利用 Chrome 單一頁面聲音通道抓取聲音。
• 確認該通道能繞過電腦整體聲音輸出，獲取乾淨、無雜音的特定分頁聲音數據。

系統開發與整合：

• 聲音抓取：開發 Chrome 外掛，利用 Chrome 單一頁面聲音通道抓取音訊。
• 語音轉文字 (ASR)：串接 Deepgram API，利用其低延遲特性（約 0.2 秒）獲取逐字稿。
• 翻譯處理：串接 DeepL API，利用其繁體中文優勢進行翻譯，並利用「斷點預譯」機制優化即時感。

測試與部署：

• 在 Chrome 中開啟「開發者模式」，載入未上架的外掛進行內部測試。
• 調整外掛對話框位置，確保能正確嵌入 OBS 直播畫面。
• 驗證總延遲控制在 0.3 秒左右，確認符合 0.5 秒內的目標。

值得注意的限制或風險

串流平台兼容性：Chrome 單一頁面聲音通道會被 Netflix 等部分串流平台擋住，無法使用於所有平台，但 YouTube、Twitch 等平台可用。

通用 API 的延遲問題：通用型 Live API（如初期使用的 Gemini Live）對於延遲要求極高的即時翻譯場景並不適合，可能導致音畫不同步。

AI 誤導風險：直接使用 AI 執行複雜任務時，可能會因 AI 的鼓勵而陷入錯誤迴圈，消耗 Token 與金錢（「AI 仙人跳」）。

翻譯機制的潛在誤解：DeepL 的「斷點預譯」機制可能在句子未完整時顯示部分翻譯，需確保用戶理解此即時性優化機制，避免誤以為翻譯錯誤。

逐字稿辨識疑點

• DSX：逐字稿中提及「現在 DSX」，與前文 RTX、DGX 並列，疑為筆誤或特定內部/新產品名稱，需查證是否為 DGX 或其他 NVIDIA 產品之誤聽。
• 老黃：講者提到「兩百年的老黃」，疑為對 NVIDIA 創辦人黃仁勳的暱稱或口誤，需確認是否為特定語境下的稱呼。
• 開局就送魔關羽：講者提到 Deepgram 贈送額度時說「開局就送魔關羽」，疑為「開局就送滿關羽」或特定梗/口誤，需查證原意。
• 7月28日 泛科學完成了回答：此句語意不明，疑為聽寫錯誤，需查證原意。

可延伸追問

技術細節：Chrome 單一頁面聲音通道的具體 API 或技術實現方式為何？是否有官方文件支持開發者直接調用？

擴展性：此架構若應用於多語言即時翻譯，Deepgram 與 DeepL 的組合是否仍能維持 0.3 秒的低延遲？

競爭對手分析：VTOL 與 Mistral 作為參考對象，其具體定價模型與商業化策略為何？與自行開發的 Chrome 外掛相比有何優劣？

AI 互動策略：除了詢問「哪些服務做得好」，是否有其他更有效的方式引導 AI 提供技術架構建議，避免陷入「AI 仙人跳」？

未來趨勢：隨著 AI 模型發展，未來是否會有更內建於瀏覽器的低延遲翻譯功能，使得自行開發 Chrome 外掛的需求降低？