幾天前我寫了一篇關於某個 AI 語音輸入工具的文章，結論是它對我的非標準發音有接近 100% 的辨識率，直接讓打字成本歸零。我很滿意，也付費訂閱了。

今天，它在正常使用中把內部運作邏輯吐給我看了。

我沒有做任何 prompt injection，沒有試圖繞過任何防護。我只是像平常一樣對著手機說話。

系統回傳的不是我要的轉錄結果，而是它的內部推理過程——包括它用了哪些語音辨識引擎、怎麼綜合判斷、以及 LLM 的指令結構。

從意外輸出的內容來看，這個工具的架構比我想像中複雜：它不是單一 ASR 引擎，而是多個引擎並行，各自產生一份轉錄結果，然後 LLM 綜合判斷哪個對、怎麼合併。這解釋了為什麼準確率可以這麼高——不是單一模型硬撐，是讓多個模型互相補位。

但這次它搞砸了。其中一個引擎其實聽對了我說的話，但 LLM 的「語義邏輯推斷」認為另一個詞彙比較合理，正確答案被否決了。更諷刺的是，系統有偵測到我當時的使用情境，但卻沒有用這個資訊來做判斷。

我的推測是這樣：正常情況下，多個引擎的結果應該有足夠重疊，LLM 可以快速收斂。但我的發音讓各個引擎聽成完全不同的東西，推理鏈變得很長，某個環節出錯，導致內部邏輯跟著輸出了。

這件事發生了兩次，輸出的是不同段落的內容。

對我來說，這次經驗驗證了一些事。之前我在開發自己的語音輸入專案，架構概念類似——VAD + ASR + LLM 校正層。核心假設是：ASR 聽錯沒關係，只要後面的 LLM 夠強，就能從上下文推敲原意。這個產品用商業級資源驗證了這個假設，他們只是把「單一 ASR」升級成「多 ASR 並行」。

另外，我自己的專案從來沒出現過這種情況。原因很簡單：我的 prompt 就是「請校正這段文字」，LLM 不需要輸出推理過程，自然沒有東西會跑出來。簡單架構有時候反而更穩定。

我已經把這個情況回報給官方了。即使有這次的問題，這仍然是我用過最好的語音輸入工具。日常使用的準確率確實很高，這次只是剛好踩到邊界案例。

但這次經驗讓我意識到一件事：作為一個發音非標準的使用者，我天然就是這類系統的 stress tester。我正常使用就能觸發別人用 injection 技巧才能挖出來的東西。

或許我該開始收 bug bounty 了。