AsrTools 免費語音轉文字實測，四個引擎只剩必剪介面能用

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

AsrTools 是一套開源的語音轉文字桌面工具，把整批錄音或影片丟進去，就能輸出 SRT、TXT 與 ASS 字幕檔，不用顯示卡、不用自己裝辨識模型。它在 GitHub 上有 3,482 顆星、322 次 fork，授權採 GPL-3.0。先給 2026 年 10 月 14 日的實測結論：介面上四個辨識引擎，只剩必剪那一條路能跑通；剪映與快手兩條通道已經在大廠那一端關門，選單上的 Whisper 則是按下去會直接報錯的未完成品。

對讀者最有用的消息是，還活著的必剪介面非常好用。我用倉庫自帶的官方測試音檔實跑，2.4 秒完成轉錄，逐字內容與時間軸都正確，全程不用註冊帳號、不用申請金鑰。壞消息是它的免費有清楚的來源與邊界：你的音檔會整包上傳到 B 站的伺服器，而且這條通道什麼時候關，決定權不在這個工具身上。

這篇的數字與狀態來自一輪完整的第一手檢查：我把倉庫抓下來，讀完四個引擎的原始碼，用官方測試音檔逐一實跑引擎層，也逐一翻過專案的 issue 與版本紀錄。先講清楚邊界：我測的是辨識引擎本身，沒有安裝 Windows 圖形介面版，操作手感與批次穩定性不在這篇的判斷範圍。

實測結果：四個引擎只剩必剪這條路能走

圖形介面的引擎選單用代號 B、J、K、Whisper 標示四個選項，原始碼裡對應的就是必剪、剪映、快手與 Whisper 四個引擎檔。四個選項在 2026 年 10 月 14 日的實測結果如下。

Pin

必剪引擎走的是 B 站會員中心的字幕上傳介面。流程拆開看是四步：先申請上傳資格，照伺服器給的分片大小把音檔切塊上傳，再回報每個分片的校驗值，最後建立辨識任務並輪詢結果。整段流程不需要任何登入憑證，伺服器直接放行。實測的測試音檔是一段中文說明，轉出來的逐字稿與語音內容完全相符，時間軸切得乾淨，格式就是標準 SRT。對「把錄音快速變字幕」這個需求來說，這條路今天是真的能走。

有一個對繁體工作流程很實際的細節：辨識結果是簡體中文字。倉庫裡官方自己提交的測試輸出檔就是簡體逐字稿，我這輪實測的輸出也是簡體。整個原始碼裡沒有任何簡轉繁的處理，所以拿到逐字稿後要自己再加一道轉換，無論是丟給編輯器全域替換，還是接後處理工具。辨識的是普通話內容無疑，但字面呈現以服務端回傳為準，這一點在把 SRT 直接交給後製之前要先知道。

「快」的來源也值得看懂。整個工具走的是雲端批式架構：音檔上傳後建立一個辨識任務，客戶端做的事情只有輪詢狀態，直到伺服器把結果算完吐回來。2.4 秒的實測耗時，是 B 站機房在算，你的電腦只負責等。這也解釋了為什麼這個工具敢標榜多執行緒批次處理（介面預設開三條執行緒）：排隊與運算都不在本機，多丟幾個檔案只是在雲端多排幾個任務。

剪映引擎的狀態比較微妙，也最有警示價值。它的流程是把音檔先傳到位元組跳動的物件儲存空間，再提交辨識任務、輪詢結果。上傳這一步在實測時完全成功，儲存位址順利拿到，連上傳用的臨時憑證都是伺服器當場簽發的；但提交任務時被伺服器擋下，回覆的理由是客戶端版本過舊，查詢拿到的也是同樣的拒絕。把這個流程翻譯成讀者語言：音檔已經出門、放上了別人的伺服器，卻換不回半個字。這個錯誤不是新鮮事，2025 年 4 月起就有使用者陸續回報，當時有人貼出的拒絕理由是參數無效，與我這輪收到的版本過舊不同；錯誤訊息會換，卡在提交關這件事一年多來沒變，倉庫端也沒有跟進修復。

現在實際裝了這個工具的人會看到什麼畫面？選了剪映或快手引擎按開始處理，圖形介面會跳出處理失敗的錯誤提示，背景日誌裡記的則是伺服器拒絕後程式取不到結果的例外。2026 年 8 月還有用戶回報跳出 412 錯誤的版本，到 10 月初有人附和同樣遭遇，都沒有得到答覆。要誠實標註的是：412 那個案例我沒有重現，我的必剪實測在同一時間正常，錯誤是否與網路環境或地區有關，單機單日的測試回答不了。

快手引擎死得更徹底。請求一送出去，伺服器直接回覆該辨識效果已停用，這是平台方主動把匿名字幕生成的入口下架，屬於服務端關門，客戶端怎麼改都救不回來。同樣的停用回覆在 2025 年 5 月的 issue 裡就有用戶貼出過，也就是說這條通道已經斷了一年半以上。

Whisper 這個選項則是從來沒真正通車。原始碼裡有兩道鎖：圖形介面選到它會直接丟出尚未實作的例外；引擎檔本身引用了一個從頭到尾沒有定義的常數，載入模組就會出錯，而且它需要的 openai 套件沒有列在安裝需求裡，需求清單只有 requests 加上圖形介面兩個套件。本來這條路最接近「辨識在自己機器上跑」的期待，但在這個專案裡它只存在於選單文字。想要本地 Whisper 路線的人，可以看我們先前介紹過的瀏覽器 Whisper 轉錄工具，或是走本地部署的 ClearerVoice Studio 語音辨識。

免費的來源：把辨識寄放在大廠的匿名介面上

三條曾經可用的引擎有同一個設計哲學：不帶金鑰、不登入帳號，把音檔直接丟向大廠伺服器。必剪那條走 B 站的上傳介面，剪映那條走位元組跳動的字幕介面與物件儲存，快手那條走快手的AI效果介面。整個工具裡沒有任何本地辨識，README 說的不需要 GPU 是實話，因為算力從頭到尾都在別人家的機房。換句話說，它的免費是借用大廠開給自家客戶端的匿名額度，身分是你自己的音檔。

原始碼裡還能看到作者逆向還原的深度。剪映那條的上傳流程，完整重演了桌面剪映客戶端的行為：先向剪映的介面索取臨時的上傳憑證，再用一套與雲端儲存服務相容的簽名演算法，把音檔以分片方式寫進位元組跳動的物件儲存。換句話說，在剪映端看來，這個工具與一般的剪映用戶沒有分別，這正是它能免費用、也正是它說斷就斷的原因：對方只要改一處參數驗證，所有偽裝成客戶端的請求就一起失效。

剪映引擎還有一個多數介紹文不會提的細節：每次送出請求前，程式會先連到掛在工具自身更新網域上的簽名伺服器換取請求簽名，沒有簽名就連不上剪映的介面。我測試當天這台伺服器還在正常回應，但這代表工具從來就不是點對點直連，中間一直站著一個不在你手裡的節點：這台簽名伺服器停機，或剪映端改協議，引擎都會死。實際劇本是後者先發生。另外原始碼裡有一個寫死的裝置識別碼，2024 年之後所有用戶共用同一組，等於整個用戶群在剪映伺服器眼裡是同一台裝置，這種集體身分遇上風控時是整批一起承擔。

為什麼壞了一年多沒人修？因為鎖本來就裝在大廠的門上。這類透過逆向分析客戶端通訊來借用服務的工具，壽命取決於對方什麼時候換鎖：快手選擇直接停用整個效果，剪映端則把這個舊版客戶端擋在門外。這不是 AsrTools 的伺服器故障，而是它借用的通道被收回。理解這一點，就能預期所有同型工具的共同命運，也能解釋為什麼修復責任很難落在工具作者身上。程式碼裡也留有線索：必剪引擎檔開頭帶著獨立函式庫的版本號，說明這套逆向成果本來就是在開源圈流轉的現成品，作者的下一個專案則是換成自己維護的同源版本。一扇門關上，撞門的每個工具只是時間先後不同。

隱私的邊界要在這裡畫清楚。必剪介面能用，意味著你的每一個音檔都會以匿名身分上傳到 B 站伺服器換取免費辨識。會議錄音、採訪素材、私人對話這類內容，要不要交給第三方平台，是使用前要自己做的判斷；工具不會替你把關，介面上也不會再提醒你一次。

倉庫凍結一年多，作者搬去了下一個專案

專案狀態用數字講最直接：主分支最後一次合併停在 2025 年 6 月；最後一個 Windows 安裝包是 2024 年 11 月的 v1.1.0，這個版本累積下載約 3.2 萬次。三萬多個下載配上一個不再移動的主分支，就是這個工具現在的寫照。取得管道也只剩兩條：GitHub release 頁的 7z 免安裝包，或從原始碼自己跑，核心依賴只有 requests 一項，圖形介面再補 PyQt5 與其元件庫。沒有 Mac 版安裝包，issue 裡有人開了需求也沒有下文。

把版本紀錄攤開看，會看到一條短促的曲線：2024 年 9 月首次發布，首版累積下載只有 190 次；一個月後的 v1.0.1 衝到九千多次；再一個月後的 v1.1.0 來到三萬二千次，三個月連發三版，然後安裝包就停在這裡。採用曲線還在爬升的時候開發就收手，這條曲線與其說是棄坑，更像作者判斷這個形態的產品已經做完，把力氣轉向下一個更完整的東西。使用者在 issue 裡留下的需求線索也很清楚：Mac 打包版、對外 API、類似剪映的文稿匹配，這些在舊倉庫都沒有下文，答案最後都指向了作者的下一個專案。

Pin

授權是 GPL-3.0，對個人使用者的意義很簡單：自由下載、自由改程式，但若把修改版散布出去，要連原始碼一起交出來。想把引擎接進自家產品再對外提供的人，先讀完條款再動工。另外要分開看的是：軟體本身開源，不等於它呼叫的辨識服務獲得任何授權，這兩層是不同的東西。

作者沒有消失，只是搬家了。README 第一段就是他自己的宣告：更多功能已經在下一個專案 VideoCaptioner（卡卡字幕助手）實作。那個專案同樣掛在他名下，16,230 顆星，2026 年 9 月還有新的提交，而且持續維護同源的必剪與剪映引擎，再加上本地 faster-whisper 選項與基於大型語言模型的字幕斷句、校正、翻譯流程。一個更具體的證據是它的測試目錄：必剪與剪映引擎各自掛著自動化測試檔，引擎介面一改，測試會先紅給作者看。對讀者來說，這是同一個引擎思路的活體版本，比 AsrTools 更值得放進長期工作流程。

來自使用者的聲音也反映了這個狀態。2026 年 7 月有人留言，希望作者不要放棄這個這麼好用的軟體；8 月有人回報處理時跳出 412 錯誤，底下有人加一句我也遇到，至今沒有官方回應。issue 區還有人來推銷商業替代品，留言區的直接反應是嫌棄：大家要的就是免費、能一次吃下幾小時音檔的通道。這些對話側寫了工具的真實價值，也側寫了它的脆弱。

該不該裝：先問你的音檔能不能出門

先把使用場景擺回桌上看，判斷才準。這類工具的典型用戶是替影片打字幕的自媒體工作者、把播客變逐字稿的製作者，以及需要把長段錄音整理成文字的人。AsrTools 對應的設計也都圍繞這些場景：輸出格式在帶時間軸的 SRT、純文字 TXT 與 ASS 之間選，v1.1.0 起影片檔可以直接丟進去、程式會先抽出音軌再送辨識，介面預設開三條執行緒跑批次；手上如果是一堆格式不一的舊檔，先批次轉成 mp3 再進來最省事，可以搭配我們介紹過的音訊轉檔工具。issue 裡留過一句很有代表性的用戶評價：它能把幾個小時的音檔一次吃完，而且免費。這句話前半是它的價值，後半是它的風險。

• 音檔不敏感、用 Windows、要批次把錄音變字幕：可以裝。必剪介面今天能用而且快，輸出的 SRT 與 TXT 可以直接接進後續流程，字幕要再翻譯可以接我們介紹過的 Anto SRT 字幕翻譯器。請記得先拿一個小檔案試跑，確認通道還開著。
• 音檔涉及隱私：不建議。整包上傳 B 站伺服器這件事不會因為工具好用而改變。會議、採訪、私人錄音請走本地路線，例如前面提到的本地 Whisper 或 ClearerVoice。
• 要的是長期穩定的生產線：選同作者的 VideoCaptioner，或自架 Whisper 服務。把 AsrTools 當備用的快速通道就好，不要把流程綁在一個四分之三引擎已經失效的工具上。

如果你在乎的是辨識引擎的來源與可控性，開源模型路線值得認識：阿里的 FunClip 語意剪輯工具示範了用自家開源辨識模型完成轉錄與剪輯的做法，模型權重就在你手裡，沒有誰能遠端關門。這也是逆向介面路線與開源模型路線最本質的差別：前者免費但壽命由別人決定，後者要自己出算力但通道永遠開著。

我的整體判斷：AsrTools 可以收藏，收藏的方式是把它當免費通道的即期票，而不是長期資產。哪天必剪介面也回一個錯誤碼，這個工具就正式走進歷史。實際使用前拿小音檔先試跑一次，是確認通道還開著最快的方法；對一個引擎大半失效的工具來說，這一步省下的是一整批等待處理的素材時間。這篇的實測時間點是 2026 年 10 月中，借用型工具的狀態變化快，晚於這個時間讀到的人，請把試跑那一步當成必要流程。