一次過轉幾百條錄音：排隊、命名、對帳三張表

第一次做批量，多數人會寫一個 for 迴圈，把 300 個檔案掉入去。

跑到一半，網絡斷。你唔知邊幾條完成、邊幾條未開始。

再跑一次，全部重來。帳單出來，數字比預期多三成。

呢個唔係工具問題，係流程問題。

批量轉寫嘅難關有三個：重複收費、失敗無聲、對唔到帳。三個都可以用一張表解決。

本文講三張表、五種錯、一個退避策略。唔講接口點 call，接口細節見 ASR API 選型。

重點摘要

• 批量嘅第一張表係「來源清單」，冇同意狀態嘅錄音唔應該入隊。
• 第二張表係「任務台帳」，核心係冪等鍵：同一份檔案＋同一組參數，只可以有一個任務。
• 我哋冇自動去重。同一個檔案提交兩次，就係兩個任務、兩次收費。
• 第三張表係「對帳」：帳單音頻秒數要對得上你手上檔案時長，容差建議 0.5% 以內。
• 切段留重疊會令計費秒數多過實際時長，20 段各留 5 秒，就多 95 秒真金白銀。
• 429 唔係錯誤，係「你太快」。指數退避加抖動，最多重試五次。

批量唔等於「跑多幾次」

單條轉寫，你只需要處理「成功」同「失敗」。

批量要處理多兩件事：重複，同對帳。

重複 係指同一個檔案被提交多過一次。原因通常唔係大意，係「唔知上一次跑完未」。

對帳 係指「你畀咗幾多錢，同你收到幾多分鐘文字」要對得上。

單條嘅時候，兩件事都可以靠記憶。300 條就唔可以。

【獨家觀察】批量嘅成本唔在單價，在「你幾時發現有三條漏咗」。等到交付日才發現，代價係整批校對要再做一次，因為你唔知邊幾段係用舊稿。

表一：來源清單，先決定邊條唔應該轉

呢張表喺提交之前就要有。欄位唔需要多，但要有紀律。

同意狀態 一欄最多人省。省咗之後，你會在某一日被問「呢條錄音有冇問過客人」，然後答唔出。

錄音同意同保留嘅實務清單，會議場景嘅做法 已經寫得好清楚；批量嘅分別只係「一條一條查」變成「一欄篩」。

篩法很簡單：同意狀態空白嘅，唔提交。等補齊再一次過。

表二：任務台帳，核心係冪等鍵

第二張表記錄「每一條提交咗咩、而家點」。

冪等鍵（idempotency key） 係指「同一份輸入＋同一組參數，永遠對應同一個任務」。有咗佢，你隨時可以安全重試，唔會產生第二個任務。

最簡單嘅做法：sha256(檔案內容) + 參數版本號。

用內容哈希而唔用檔名，因為檔名會重複、會改名、會多一個 (1)。

台帳最少要有九個欄位：

狀態機只有四格，唔好加更多。加得多，你就會出現「狀態 7 到底算唔算完成」呢類問題。

失敗嘅處理只有一個動作：把該條 status 重設，重新提交。其他條目唔動。

呢個做法令你可以隨時停，第二日續。長檔嘅斷點續傳係同一套思路，只係粒度由「一條」變成「一段」，見 長會議錄音流程。

同一個檔案提交兩次，就係兩次收費

呢一點要講明白：我哋冇自動去重。

同一個檔案提交兩次，會產生兩個任務，各自計費。

所以冪等鍵唔係「好習慣」，係防漏財嘅閘。

【實測】我哋見過最常見嘅重複來源，係「輪詢 timeout 之後重試」。你等咗 90 秒未見結果，以為失敗，再提交一次；其實第一個任務跑得好地地。

解法：timeout 之後唔好即刻重提。先查台帳有冇 job_id，有就查狀態。

表三：對帳，容差 0.5% 以內

第三張表係月結用。

公式好簡單：把台帳嘅 billed_seconds 加總，同帳單對；再同來源清單嘅 duration_seconds 加總對。

對帳容差 係指「你接受幾大百分比差異，唔使逐條查」。

建議 0.5% 以內。超過就要查，因為差異通常有三個具體來源：

1. 量度方法唔同：你用 ffprobe 量嘅時長，同平台解碼後嘅時長可能差幾十毫秒（開頭靜音、編碼延遲）。
2. 切片重疊：你切 20 段，每段前後各留 5 秒重疊，總共多 190 秒。（20 段 × 2 × 5 秒，頭尾各一次。）
3. 重複提交：同一條出現兩次。

第一種係正常，第二種係你嘅設計選擇，第三種係要修嘅 bug。

例如你見帳單比預期多 3.2%，而切片重疊只解釋到 1.1%，剩低 2.1% 就要逐條對 idem_key 有冇重複。

對唔到帳嘅時候，唔好先懷疑平台。九成情況係自己嘅表有重複 row。

併發同 429：退避，唔好硬衝

429 Too Many Requests 係 HTTP 標準狀態碼，意思係「你送得太密」，唔係「你嘅請求有錯」（MDN 說明，2026-10-31 查閱）。

處理原則三條：

• 唔好即刻重試。即刻重試只會令情況更差。
• 用指數退避加抖動：1 秒、2 秒、4 秒、8 秒，每次加隨機 0 至 1 秒。抖動係防止你所有 worker 同時醒返。
• 最多五次。五次都 429，就代表你嘅併發設定超咗實際額度，要調低。

併發上限唔好一開始設到盡。先用 4 條跑 20 個檔案，量實際每條耗時，再逐級加上去。

【獨家觀察】批量嘅瓶頸通常唔在平台，在你自己嘅上載頻寬。300 條 30 分鐘 Opus 大約 4GB，家用寬頻上載要幾個鐘。呢個時候加併發只會令每條更慢。

五種失敗，五種處理

最後一種要多講一句。audio_url 路線由伺服器代你下載，所以私網位址會被拒。呢個係防 SSRF（2026-10-31 查閱）嘅設計，唔係設定錯誤。

你嘅檔案要有一個公開可讀、或者帶簽名嘅 https 網址。簽名有效期設短，但唔好短過排隊時間。

壓縮參數同 4.5MB 換算，音檔壓縮指南 有實測數字。

抽樣校對：每批 10 條，每條 3 段

批量最容易出事嘅係「全部都跑完，但質素靜靜跌」。

原因通常係某批錄音條件特別差：電話線、回音房、多人重疊講話。

做法：每批抽 10 條，每條抽開頭、中間、結尾各 30 秒，對原音。

錯誤分類四種就夠：專名、數字、語言切換、漏句。

分層抽樣比隨機抽樣有效。按「來源系統」同「錄音條件」分層，每層至少抽一條。原因係 ASR 嘅錯誤率對錄音條件極敏感，Whisper 論文報告嘅跨資料集差異就以倍計（arXiv 2212.04356，2026-10-31 查閱）。

漏句最難發現。文字讀落去通順，但少咗一句。所以抽樣要對音頻，唔可以只讀稿。

量度方法嘅完整協議見 WER 實測方法。

保存：平台 90 日，你要嘅可能係 7 年

轉寫結果喺平台保留 90 日，之後由每日清理程序移除。

你可以逐條刪，刪除即時生效，30 日內徹底清除。

但企業要嘅保存期通常係 3 年到 7 年。所以正確做法係：收到 text 即刻搬去自己嘅 storage，台帳嘅 text_path 寫你自己嘅路徑。

唔好寫平台回傳嘅 URL。佢會過期，過期之後你嘅台帳就變成一本查唔到內容嘅帳。

保存政策同刪除 SLA 要寫入委外合約。八條必寫條款見 轉寫委外合約。

幾時唔應該做批量

批量唔係萬能。三種情況唔好做：

• 只為「之後可能有用」。冇明確用途嘅錄音，轉完都冇人讀，只係多一份要保管嘅個人資料。
• 同意未齊。補齊之前，唔好轉。
• 你真正需要嘅係摘要，唔係逐字稿。300 條逐字稿冇人睇得完；抽 30 條出重點，效果更好。

第三點最常見。採購問「可唔可以全部轉」，答案係「可以，但你會唔會全部睇」。

如果答案係唔會，就唔好轉。

常見問題

300 條錄音要跑幾久？

冇通用答案。先跑 10 條，量每條平均耗時，再乘 30，計入 429 退避同重試。你要嘅係「可預測」，唔係「最快」。

改詞表再跑同一條，會唔會再收費？

會。參數變咗就係新任務。所以詞表要喺第一批之前定好，唔好跑完才補。詞表點設見 粵語熱詞辨識。

失敗重跑會唔會雙重收費？

唔會。失敗嘅任務唔收費。你要小心嘅係「以為失敗但其實成功」嘅重複提交。

中途可以停嗎？

可以。台賬記住每條狀態，第二日續跑未完成嘅。呢個係台帳最大嘅好處：你唔需要一次過跑完。

對帳差 1%，要唔要逐條查？

先看切片重疊有冇計入。如果冇切片、冇重複提交，仍然差 1%，就抽 10 條查 billed_seconds 同實測時長嘅差距，多數係量度方法差異。

關於呢篇文

本文由港嘢內容團隊整理。上限、費率、保留期取自我哋公開 API 文件（2026-10-31 查閱）；HTTP 429 同 SSRF 嘅定義取自 MDN 同 OWASP（2026-10-31 查閱）。三張表嘅欄位設計來自我哋處理批量轉寫嘅實務經驗，唔係通用標準，你可以按自己嘅系統增刪。想睇單條長檔點處理，讀 長會議錄音流程；想睇成本同人手打字比較，讀 轉文字 vs 請人打字。有問題歡迎 聯絡我們，公司背景見 關於港嘢。

資料來源：港嘢公開 API 文件（同步 4.5MB／8 分鐘、非同步 200MB／4 小時、HK$0.80 每音頻小時按秒計、失敗不收費、90 日保留、刪除後 30 日內徹底清除）；MDN 429 Too Many Requests；OWASP Server Side Request Forgery；AssemblyAI 提交與輪詢（非同步任務模式，2026-10-31 查閱）；ffmpeg silencedetect（切段找靜音位）；Whisper 論文（arXiv 2212.04356，跨資料集錯誤率差異）。本文由港嘢內容團隊編輯及覆核。