voice-to-text-tools 純前端音訊轉文字工具：瀏覽器自動分段長錄音，自備訊飛 API Key 轉逐字稿

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

當你手上有一段一小時的演講、訪談或會議錄音，最常卡住你的往往不是「辨識得好不好」，而是「這個檔案太大，沒有工具能整段吞下去」。訊飛的語音聽寫介面設計給短語句的即時聽寫，不少雲端轉文字服務也會限制免費時長。voice-to-text-tools（GitHub：aiyoubucuoyou/voice-to-text-tools，MIT 授權，約 32 顆星）這個開源專案選擇從成本與架構切入：你自己在瀏覽器裡把長錄音按介面長度切好，再一段一段遞給訊飛聽寫介面，中間不需要架伺服器，也不用月費訂閱。

它實際在做什麼：前端切片，後端是訊飛雲

要講清楚這個工具，得先把它拆成兩段，因為「純前端」這三個字很容易讓人以為整件事都在你電腦上完成，實際上並不是。

第一段是音訊切片，這一步真的在你瀏覽器裡跑。專案在網頁裡載入 FFmpeg 的 WebAssembly 版本，於是用戶端就有能力直接讀取並切割長檔案。當你把一段長錄音或影片丟進去，它會在你本機把音訊切成符合訊飛聽寫介面長度的片段（語音聽寫是面向短語句即時聽寫的設計，整段長會議直接丟會超過單次長度上限）。切片過程不離開你的瀏覽器，原始檔不會被上傳到這個專案的任何伺服器，因為這個專案根本沒有伺服器。

第二段是語音辨識本身，這一步是離開你瀏覽器的。切好的片段會逐段送進訊飛開放平台的聽寫介面（透過 WebSocket），辨識完成後，前端把每段的結果依序接回完整逐字稿，再讓你複製或下載成 TXT。換句話說，真正把聲波轉成文字的是訊飛那一端的模型，你電腦上並沒有跑任何 ASR 引擎。

這條界線很重要：切片在本地、辨識在雲端。專案名稱裡的「純前端」描述的是部署架構（沒有後端伺服器、沒有中繼），而不是「資料完全不出裝置」。把這一點講清楚，下面的取捨才會有意義。

技術上值得提的一個副作用是，在瀏覽器裡跑 FFmpeg 意味著切片這一步會吃你本機的 CPU 和記憶體。WebAssembly 雖然比純 JavaScript 快很多，但處理一兩小時的錄音時，瀏覽器分頁還是會明顯變重。實務上會建議轉寫長錄音時別同時開太多分頁、用桌機而不是老筆電，跑完再關掉分頁釋放記憶體。這也是「無後端架構」的交換條件：你省下了伺服器，但運算吃在自己機器上，轉寫速度跟你的硬體強弱直接掛鉤，而不是跟某朵雲的算力掛鉤。

Pin

上手流程：你得先自己去訊飛拿三把鑰匙

正因為沒有後端，工具本身不會幫你準備辨識能力，你得自己申請訊飛的介面憑證。整體流程大概三步：

到訊飛開放平台（xfyun.cn）註冊帳號並完成實名認證，再到控制台找到語音聽寫服務、建立應用，取得 APPID、API Key、API Secret 三項憑證。打開工具的網頁（不論是線上演示版或你本機雙點開 index.html），在設定欄填入這三項就能開始使用。憑證只存在你瀏覽器的 localStorage，不會被回傳給這個開源專案的作者。

這裡有個務實提醒：實名認證和介面申請是訊飛這一關，不是這個工具能幫你繞過的。如果你連申請介面憑證都覺得麻煩，那這個工具多半也不適合你，改用剪映、飛書之類把轉文字包成產品功能的服務會順手很多。這個工具的目標族群很明確，是「願意花十分鐘設定一次介面、換來之後每次長錄音都能自己跑」的人。

另一個要注意的是訊飛的計費邏輯會隨用量階梯變化。每日 500 次免費額度對個人偶爾轉一兩段長錄音多半夠用，但「一次」指的是一次介面呼叫，長錄音被切成幾十秒一段後，呼叫次數會累積得比你想像的快（例如一小時錄音切成一分鐘一段就要呼叫六十次起跳）。如果你要轉的量大，記得先到訊飛控制台估算成本，這個工具本身不會幫你節流，它只負責把切片和呼叫跑完。

Pin

隱私邊界：API Key 在本地，音訊內容會外送

這是這個工具最需要睜大眼睛看的一段。它的隱私承諾是真的，但只到「一半」的程度，另一半得你自己判斷。

「沒有後端伺服器」這句話是真的，憑證只寫進你瀏覽器 localStorage、作者端從頭到尾收不到，這部分也是真的，作者那邊從來拿不到你的 Key 或你的檔案。這點比起那些「免費轉文字、背後不知道怎麼處理你檔案」的小網站，確實是個加分項，至少架構上是可審計的，原始碼攤在 GitHub 上，懂技術的人可以自己檢查 index.html 到底把音訊送到哪裡。

但是，音訊片段這一步會經由網路送往訊飛。切片後的音訊會真實地抵達訊飛的雲端伺服器，被訊飛解析後回傳文字。訊飛的母公司是科大訊飛，是中國大陸的語音 AI 服務商，受到中國大陸的資料合規規範約束。如果你的錄音內容涉及營業機密、客戶個資、醫療或法律敏感資訊，這個工具並沒有讓你的音訊完全斷網、做到端到端本機處理，它只是把切片環節留在你機器上，辨識這一步還是會經過第三方雲端。

換個方式講：這個工具適合拿來轉你自己錄的演講筆記、課堂錄音、公開訪談，這類內容就算被雲端服務商「聽到」也不會造成實質損害。它不適合拿來轉你公司機密會議、客戶諮詢錄音、律師當事人對話這類一旦外流就會有實質後果的內容。如果你的場景屬於後者，你需要的不是「換個前端工具」，而是真正在本機跑的 Whisper 類方案（例如 MioSub 這類本機字幕工具，可以把轉錄這一步留在你電腦上）。

還有一點容易被忽略：辨識準確度不在這個工具的控制範圍內。它只是個把音訊切片後遞給訊飛的前端介接層，辨識準確率、方言支援、外語混用、專業術語的處理，全部取決於訊飛後端模型的能力。這個工具能控制的是切片精度和介面體驗，不能控制的是訊飛聽不聽得懂你的口音。

也因為辨識在訊飛端，工具本身不會幫你做語者分離（區分誰在講話）、不會做時間軸對齊（每段文字對回原始時間戳）、不會做雙語輸出。它輸出的是一段連續的純文字逐字稿，要這些進階處理的人得另外找工具。這也是它跟 MioSub 那類字幕工具最根本的差別：那邊要的是 SRT 帶時間軸的字幕檔，這邊要的是可複製可編輯的純文字稿，兩者解的問題相近但輸出形態不同。

跟同類方案的差別：它放在版圖的哪一層

把這個工具放回同類方案的版圖裡，會更清楚它的定位。大致可以分三層：

第一層是完全本機的語音辨識，代表是 OpenAI 的 Whisper 開源模型，可以透過各種桌面封裝在本機跑，音訊完全不出裝置，準確度也高。要承擔的是吃你電腦的算力（多半得裝好 CUDA、模型動輒幾個 GB），老機器跑長錄音會很慢，而且上手成本不低。如果你重視隱私多於方便，本機音訊工具的整理、OpenLess 這類語音工具和 Whisper 路線是更穩的選擇。

第二層是這個工具所處的位置，前端做切片、後端接雲端介面。好處是不用架伺服器、成本可控（訊飛每日有 500 次免費額度），介面也輕量。但相對要接受辨識在雲端、品質受限於訊飛、且得自己申請介面憑證。這層適合「內容不夠敏感、但希望控制成本和架構」的個人工作者。

第三層是整合型產品，例如剪映、飛書、Adobe Premiere 的自動轉錄，把轉文字包成完整產品功能，不用設定介面、有團隊協作、有歷史紀錄（代價是要登入、被綁在它們的工作區或訂閱制）。這層適合「要的是結果、不在乎過程」的使用者。

把這三層擺在一起看會發現一件事：voice-to-text-tools 的競爭力不在準確度（那由訊飛決定），也不在方便度（那要整合型產品贏），而在架構透明和成本可控這個組合。你能讀到完整原始碼、你能自架、你能算出每次轉寫要花多少介面額度，這三件事在同時滿足時，是其他方案不容易給的。對「想知道自己到底在做什麼、想知道自己的檔案去了哪」的使用者來說，這個透明度本身就是價值。反過來說，如果你要的是「一鍵出字幕、不用理解任何事」，這個工具對你就是負擔。

voice-to-text-tools 不是要跟 Whisper 比準確度，也不是要跟剪映比方便，它選的是中間這個偏技術導向的小眾位置：你願意自己設定介面、你的內容可以走雲端、你希望成本最低且架構透明。這個位置對獨立開發者、研究人員、偶爾需要轉長錄音的學生來說是合理的，對需要企業合規的團隊就不是。

Pin

適合誰、不適合誰

把上面的判斷收斂成具體的「適合」與「不適合」，會比再講一次架構更實用。

適合的人包括：偶爾需要把長演講、課堂、訪談錄音轉成逐字稿的個人使用者；需要快速架一個自用的轉文字頁面、直接丟到 GitHub Pages 或 Cloudflare Pages 這類靜態託管的開發者；以及重視架構透明、希望可審計、想自己算出每次轉寫要花多少介面額度的技術工作者。對這些人來說，這個工具的「自己設定一次、之後隨手可用」是真正的賣點。

不太適合的場景包括：對音訊內容有嚴格合規要求、不允許經過任何第三方雲端的企業使用者（請走本機 Whisper 路線）；需要團隊共用、多端雲同步、歷史紀錄管理的場景（這只是個單頁工具，沒有帳號體系）；連設定頁都不想打開、只想把檔案丟進去就拿到逐字稿的人，這工具的介面憑證欄會直接卡住你，走剪映或飛書那種把轉文字做成產品功能的路線省事得多；以及需要語者分離、時間軸字幕、雙語輸出這類進階輸出的人（這個工具只給你純文字逐字稿，要字幕檔請找字幕專門工具）。

部署與自架：本機雙點或丟上靜態託管

正因為專案就是一份靜態檔（index.html 加幾個資源），自架的難度非常低。最簡單的方式是直接 git clone 下來，雙點 index.html 就能在瀏覽器打開使用，不需要啟動伺服器。如果要在本機跑得乾淨一點，可以用 Python 的 python -m http.server、PHP 的內建伺服器、或 Node 的 npx serve 任選一個啟動。

要部署成自己隨處可用的線上版，把整個資料夾推到 GitHub Pages、Cloudflare Pages、Vercel 這類靜態託管都行，因為沒有後端，不需要資料庫、不需要運算單元。Fork 一份到自己倉庫、設定 Pages 分支、等幾分鐘就能拿到一個只有你自己用的轉文字網址。對有「我不想把錄音丟到作者架的演示站、我想要自己的版本」這種潔癖的人來說，這個自架彈性是這個專案真正的長期價值。

要記得的一點是，自架版本跟作者架的演示版功能完全一樣，差別只在於「檔案從哪個網址載入」。你不會因為自架就得到更強的辨識能力，也不會因為自架就讓辨識變成本機處理，後端還是訊飛的介面。自架的好處是架構自主和 URL 掌握權，不是隱私升級。

常見問題

訊飛介面的免費額度怎麼算？依照訊飛語音聽寫介面目前公開的說明，新建立應用通常每日會拿到 500 次免費呼叫量。這個數字會不會調整、怎麼計費，最終以你訊飛控制台看到的為準，這個工具不會增加或減少你的額度，它只負責把切片和呼叫跑完。

我的檔案會被這個工具的作者存下來嗎？專案根本沒有伺服器，所以無從存起。檔案切片在你瀏覽器本機完成，辨識時音訊片段直接送往訊飛介面，全程不經過這個開源專案作者架的任何中繼機器。

能不能不接訊飛、改成接別家介面？技術上可以，因為是開源 MIT 授權，你可以 fork 之後把介接邏輯換成其他語音聽寫服務。但這需要你懂前端 JavaScript，等於把這個工具當成起點自己改，不是開箱即用。

辨識準確度大概是多少？這個工具不決定準確度，由訊飛聽寫介面的能力決定。方言、口音、遠場收音、多人同時講話都會讓表現明顯下降，建議用你自己的錄音實測最準。要數字請看訊飛官方的測試報告，不要把別人量到的數字直接套到你的錄音上。

支援哪些檔案格式？因為前端用的是 FFmpeg WebAssembly，常見的音訊和影片格式（mp3、wav、m4a、mp4 等）都能處理。影片檔會被抽出音軌再送去切片和辨識，等於這個工具也能拿來處理「演講影片、教學影片」這類有畫面的素材，前提是你只要文字不要字幕時間軸。

專案資訊

專案位址是 github.com/aiyoubucuoyou/voice-to-text-tools，MIT 授權，主要語言是 HTML 加原生 JavaScript，使用 FFmpeg WebAssembly 處理音訊、訊飛語音聽寫介面（WebSocket）做辨識。線上演示版在 zhuan.dlidli.wang，本地版只要 git clone 後雙點 index.html 即可使用。專案規模不大、社群也小（約 32 顆星），但作為一個把切片和介接做完就好的單頁工具，運作上是完整的，且因為是 MIT 授權，你想自己改介接其他介面也完全合法。

要客觀看待的一點是，這個專案最近一次主要的程式碼更新落在 2026 年 5 月，之後沒有活躍的功能迭代，issue 數也是個位數。這意味著你拿到的會是一個相對穩定、但也相對「完成」的工具，不是一個持續在長新功能的產品。對自用來說這通常不是問題（它本來就是個把切片和介接做完就好的單頁工具），但如果你期待它未來會增加語者分離、時間軸對齊、雙語字幕這類進階功能，目前看來不會有。需要那些功能的人，前面提到的 MioSub 走的正是 Whisper 加多階段字幕處理的路線，是另一種不同取捨下的選擇。