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

## 一句話總結

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

## 核心重點

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

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

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

4.  **極低成本與部署**：
    *   **成本**：幾乎為零。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. 最終解決方案架構
*   **技術組合**：
    1.  **聲音抓取**：利用 Chrome 單一頁面聲音通道抓取音訊。
    2.  **逐字稿轉換 (ASR)**：使用 **Deepgram** API。
        *   特點：極快，平均延遲約 0.2 秒。
    3.  **翻譯服務**：使用 **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)
    *   實戰生 (會員名稱)

## 操作流程整理

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

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

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

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

## 值得注意的限制或風險

1.  **串流平台兼容性**：Chrome 單一頁面聲音通道會被 Netflix 等部分串流平台擋住，無法使用於所有平台，但 YouTube、Twitch 等平台可用。
2.  **通用 API 的延遲問題**：通用型 Live API（如初期使用的 Gemini Live）對於延遲要求極高的即時翻譯場景並不適合，可能導致音畫不同步。
3.  **AI 誤導風險**：直接使用 AI 執行複雜任務時，可能會因 AI 的鼓勵而陷入錯誤迴圈，消耗 Token 與金錢（「AI 仙人跳」）。
4.  **翻譯機制的潛在誤解**：DeepL 的「斷點預譯」機制可能在句子未完整時顯示部分翻譯，需確保用戶理解此即時性優化機制，避免誤以為翻譯錯誤。

## 逐字稿辨識疑點

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

## 可延伸追問

1.  **技術細節**：Chrome 單一頁面聲音通道的具體 API 或技術實現方式為何？是否有官方文件支持開發者直接調用？
2.  **擴展性**：此架構若應用於多語言即時翻譯，Deepgram 與 DeepL 的組合是否仍能維持 0.3 秒的低延遲？
3.  **競爭對手分析**：VTOL 與 Mistral 作為參考對象，其具體定價模型與商業化策略為何？與自行開發的 Chrome 外掛相比有何優劣？
4.  **AI 互動策略**：除了詢問「哪些服務做得好」，是否有其他更有效的方式引導 AI 提供技術架構建議，避免陷入「AI 仙人跳」？
5.  **未來趨勢**：隨著 AI 模型發展，未來是否會有更內建於瀏覽器的低延遲翻譯功能，使得自行開發 Chrome 外掛的需求降低？