聽一場台北、新加坡或香港的真實會議，你會發現幾乎沒有人講純中文。「這個 sprint 我們先把 deck 做完」「先跟 client align 一下 scope」——英文詞理所當然地坐在中文句子裡。這不是講話隨便，這就是華語科技與商務圈的工作語言。可是當你想用說的把這種話打成字，多數語音輸入就開始出狀況：它要嘛把英文絞成亂七八糟的中文近似音，要嘛在切到英文時把中文丟掉。問題的根，是很多工具在動工之前，就先逼你或逼自己選定「一種語言」——而真實的職場語音，從來不是一種語言。這也是在 Mac 上用中文語音輸入最容易踩到的地方之一。
為什麼「先選一種語言」注定會壞
傳統語音辨識的假設是：一段音訊屬於某一種語言。於是工具會先判定語言，再用那種語言的模型去解。判定成「中文」，那句「先把 deck 做完」裡的 deck 就會被硬套成某個中文近似音，變成一個莫名其妙的詞；判定成「英文」，整句中文就塌成一片。真正的麻煩在於，混講的切換往往發生在一個子句之內、甚至一個詞的邊界上——你沒有在兩句話之間乾淨地換語言的空檔可以讓它判斷。任何「一段音訊一種語言」的架構，遇到中英混講都會在切換點上流血。
混講不是雜訊，是結構
要處理好混講，得先承認它有結構，不是隨機的噪音。嵌進中文的英文，通常是有規律的：專有名詞（產品名、公司名、工具名）、產業術語（sprint、scope、deck、roadmap）、還有一些就是講起來比中文順的詞。它們在句子裡扮演的是名詞或術語的角色，語法上仍然被中文的骨架托著。一個懂這件事的工具，不會把英文當成需要「翻譯」或「猜音」的異物，而是把它保留成它原本的英文詞，同時把包著它的中文寫成通順的中文。你要的，是一句乾淨的話——中文是中文，英文詞是那幾個英文字——從一段中途換了好幾次語言的語音裡，重新組裝出來。
大小寫、術語、還有那些你天天在打的詞
混講做得好不好，魔鬼藏在很小的地方。英文術語該不該首字母大寫？產品名的正確拼法是什麼？「api」還是「API」？「github」還是「GitHub」？這些細節，正是一個只會音譯的工具會全部搞錯、而你事後得一個一個去修的地方。更進一步，每個團隊都有自己反覆在講的專有名詞——同事的英文名、內部專案的代號、你們產品的功能名——一個通用模型從沒聽過它們，只會用聽起來最接近的常見詞去頂替，每次都錯。一個能學你自己詞彙的工具，會把這種「每次都要改」變成「教過一次就好」。
為什麼這對亞洲團隊特別重要
在許多亞洲團隊裡，中英混講不是偶爾為之，而是預設的溝通模式。這代表如果語音輸入處理不了混講，它在你日常大部分的訊息與郵件上，其實都不堪用——因為你大部分的話本來就是混的。反過來說，一個能把混講當成常態、而不是例外來處理的工具，價值不只是「多支援一種語言」，而是它終於對得上你真正說話的方式。你不必為了遷就工具，刻意把話講成純中文或純英文；你可以照平常那樣講，讓整理文字的工作交給它。當團隊裡不只兩種語言在流動時，這件事還會再放大一層，我們在跨國團隊的多語語音輸入裡談得更遠。
怎麼測
功能列表上的「支援中英文」不會告訴你它處不處理得了混講。一次真正的實測會。用你平常在會議或訊息裡真的會用的講法——中英夾雜、帶著你們產業的術語和幾個專有名詞——講一段，然後讀回來的結果。中文是不是通順的中文？英文詞是不是原封不動、拼寫和大小寫都對？還是你得回頭把被音譯絞爛的英文一個個救回來？如果你發現自己在做的，正是這種把混講善後的功夫，那這個工具就還沒真正對上亞洲職場說話的方式。能把中英混講一次組裝乾淨的語音輸入，第一次回來的，就該是一句你可以直接送出去的話。如果你想退一步、先看懂各種語音打字做法的全貌，這份語音打字完整指南會有幫助。