Gemini 3.5 Transcribe：會議逐字稿、存取管道與替代方案 (2026)
Google 於 2026 年 8 月 26 日推出了 Gemini 3.5 Transcribe。這是一款語音轉文字模型，能將原始音訊轉換為格式化文字，並針對預錄檔案提供說話者識別和字詞級時間戳記。本指南將介紹已發布的功能、適用的場景，以及在將逐字稿轉化為可發送的內容之前，還需要進行哪些處理。
Google 於 8 月 26 日發布的內容
該公告簡短且具體。Google 稱其為「我們迄今為止最精確的語音轉文字模型，專為智慧語音互動而設計。」
這種定位與舊版的語音辨識形成鮮明對比。根據 Google 的公告，傳統模型「難以處理背景噪音、複雜的專業術語和口吃修正」。Google 表示，這款新模型「能將原始音訊直接轉換為精確、修飾過且格式化的文字」。
公布了兩個準確度數據。根據 Artificial Analysis 的測量，該模型在即時串流使用場景下的平均字錯率為 4.0%，在非串流使用場景下則為 2.6%。
Google 還將其與先前使用的 Chirp 3 模型進行了比較。輸出最終結果的時間「縮短了 70%」，且在 FLEURS 基準測試中，即時串流的字錯率為 5.50%，非串流為 5.04%。
這些數字的重要性其實次於輸出結果的格式。更乾淨的原始文字檔案意味著在任何人使用之前，需要進行的編輯工作更少。
該模型提供的兩種方式
這裡有兩個獨立的 API，如果您要應用於會議場景，這個區分就非常重要。
| 模式 | Model ID | 適用場景 |
|---|---|---|
| 即時串流 | gemini-3.5-transcribe-live |
透過 Live API 進行低於一秒延遲的持續雙向串流 |
| 預錄音訊 | gemini-3.5-transcribe |
透過 Interactions API 處理錄音、會議和通話記錄 |
預錄音訊的路徑才是支援會議功能的路徑。Google 將其描述為「透過說話者識別和字詞級時間戳記，來轉錄錄音、會議、通話記錄等內容」。
說話者支援有明確的上限。該模型「能精確識別預錄音訊中的發言，並為最多三位說話者提供時間戳記」，而超過三位說話者的支援則被歸類為實驗性功能。
智慧轉錄究竟改變了什麼
公告中列出了四項功能，這些功能是其與普通逐字稿的實際差異所在。
口吃與贅詞修正。該模型可以處理自我修正（例如「我們星期二見面——不，星期三」）、移除贅詞，並自動格式化輸出內容。
自訂詞彙。您可以提供自己的專有名詞，以便在轉錄過程中保留專業術語和不常見的拼寫。
英數準確度。Google 特別指出了「郵遞區號和訂單 ID 等英數字元實體」，這通常是通用模型容易出錯的地方。
語言覆蓋範圍。該模型可自動偵測超過 85 種語言，包括地區口音和方言。
還有一個值得注意的函式呼叫功能。Google 表示，該模型「可以透過函式呼叫將複雜的任務（例如圖片生成和檔案分析）委派給其他 Gemini 模型」。目前該功能僅列於 Gemini macOS 應用程式中。
您今天可以在哪裡使用它
這不僅僅是一個僅限 API 的發布，這在模型推出時是相當少見的。
| 平台 | 具體功能 |
|---|---|
| Google AI Studio 中的 Gemini API | 建置模式，包括透過語音編寫應用程式程式碼 |
| Gemini Enterprise Agent Platform | 相同的模型，企業級部署路徑 |
| Android 上的 Gboard | Rambler 功能可將語音轉換為格式化文字 |
| macOS 上的 Gemini 應用程式 | 結合螢幕情境的語音指令 |
| Google Antigravity | 結合螢幕情境和對話歷史記錄的轉錄功能 |
| Chrome | 標示為即將推出，用於在任何輸入框中進行語音輸入 |
macOS 的描述是其中最像代理（agent）的一個。Google 表示，該模型讓使用者能夠毫不費力地「在游標所在之處摘要本地檔案、跨應用程式重用文字，或直接生成圖片」。這一切都只需透過語音即可運作。
有數個開發者平台被提及正在基於 Live API 進行建置，包括 LangChain、LiveKit、Pipecat 和 Vercel。
有一個關於存取權限的注意事項很容易被忽略。這兩個 API 路徑具有不同的模型 ID 和不同的進入點。因此，即時字幕建置和會議存檔建置是兩個獨立的整合，而不是同一個。
公告中未涵蓋的內容
這正是僅有逐字稿開始顯得不足的地方，而這個差距值得直接說明，而不是憑空猜測。
公告頁面描述的是文字輸出。它並未描述如何從音訊中產生試算表、圖表、簡報或書面報告。試算表、Excel、CSV、投影片、簡報、報告和儀表板等詞彙完全沒有出現在頁面上。
它所描述的是委派：該模型將檔案分析和圖片生成交給其他 Gemini 模型。因此，最終交付物是由其他工具在其他地方組合而成的。
這是一個合理的設計。這也是為什麼一份好的逐字稿並不能完成會議的完整閉環。
將逐字稿轉化為可發送的內容
逐字稿記錄了說過的話。但會議記錄通常還需要另外三樣東西：螢幕上顯示的數據、做出的決策，以及接下來誰負責什麼任務。
Powerdrill Bloom 則專注於這後半部分的工作。您只需上傳音訊以及會議實際討論的檔案，然後用自然語言描述您想要從中獲得什麼內容。
該 speech to text 頁面列出了支援上傳的音訊格式，包括 .mp3、.mp4、.m4a、.webm 以及其他幾種格式。它指出該功能「可在數秒內從您的音訊中獲取逐字稿、摘要和要點」。
公平地說，從另一個角度來看：該頁面並未描述說話者識別、字詞級時間戳記或即時串流。而這些正是 Google 所發布的功能。如果您需要對三人通話進行區分說話者並帶有時間戳記的輸出，那麼這款新模型是完成該步驟的更好工具。
兩者不再重疊的地方在於產出物。其 AI report generator 頁面涵蓋了將來源檔案轉換為書面報告的功能，而 Office 文件輸出功能則列在 Pro 方案中。
值得了解的其他替代方案
如果您的目標是會議記錄而非語音介面，還有其他三種途徑。
您會議平台自帶的摘要。在任何錄製的活動結束後，Microsoft Teams 會將錄音、共享檔案、筆記、議程和後續任務收集在同一個地方。智慧摘要功能需要 Teams Premium 或 Copilot 授權。
專用的會議記錄工具。這些工具會加入通話中、產生摘要，並將記錄保存在其產品內部。當會議本身就是核心產出物時，這非常實用。
文字輸出加上您的來源檔案。雖然設定速度較慢，但這是唯一能確保書面報告中的數據來自匯出資料，而不是來自某人朗讀內容的途徑。
適合哪一種取決於一個問題：會議中真正有價值的部分是人們說了什麼，還是數據顯示了什麼？前三種途徑能很好地服務前者。只有最後一種途徑能服務後者。
從逐字稿到交付物
Gemini 3.5 Transcribe 在解決特定問題上邁出了實質的一步。更乾淨的文字、最多三人的說話者識別、字詞級時間戳記以及超過 85 種語言，都減少了以往每次錄音後所需的編輯工作。
它無法做到的是決定會議產生了什麼成果。這仍然取決於討論背後的數據，這也是為什麼逐字稿和來源檔案應該放在同一個地方的原因。
我們與 Gemini Deep Research 的比較涵蓋了同一個問題的研究層面。若要將錄音及其來源檔案轉換為完整的摘要，請試用 Powerdrill Bloom。
此處的事實截至 2026 年 8 月 31 日，源自 Google 的公告頁面。
常見問題
什麼是 Gemini 3.5 Transcribe？
這是 Google 於 2026 年 8 月 26 日發布的語音轉文字模型。Google 將其描述為其迄今為止最精確的語音轉文字模型，能將原始音訊轉換為修飾過且格式化的文字。
Gemini 3.5 Transcribe 的準確度如何？
根據 Artificial Analysis 的測量，Google 公布的平均字錯率在即時串流使用場景下為 4.0%，在非串流使用場景下為 2.6%。在 FLEURS 基準測試中，這些數據分別為 5.50% 和 5.04%。
它能識別多少位說話者？
在帶有時間戳記的預錄音訊中，最多可識別三位說話者。Google 將超過三位說話者的支援描述為實驗性功能。
我該如何存取 Gemini 3.5 Transcribe？
透過 Google AI Studio 中的 Gemini API 以及 Gemini Enterprise Agent Platform。它還為 Android 上的 Gboard、macOS 上的 Gemini 應用程式以及 Google Antigravity 中的語音功能提供支援，並標示 Chrome 即將推出。
它會幫我撰寫會議摘要嗎？
該公告描述的是轉錄以及委派給其他 Gemini 模型，而非產出完整的檔案。要產生包含底層數據的書面記錄是一個獨立的步驟，且除了音訊之外，還需要來源檔案。