Shipping DIALØGUE 令我明白多語言 AI 產品真正難喺邊
DIALØGUE 支援 7 種語言,但真正嘅多語言工作唔係翻譯 strings。真正麻煩嘅係 audience-local 日期、TTS 一致性、UI language drift,仲有判斷邊啲位嘅 quality 值得你慢落嚟做好。
而家 AI 最誘惑人嘅其中一件事,就係你可以好快咁加新語言。我知,因為我自己一直都係咁做。我先係喺 48 小時內為 DIALØGUE 加咗 5 種語言,之後又喺 4 日內將成個 blog archive翻譯成 10 種語言。
前面嗰兩篇講嘅係速度。呢一篇講嘅,係速度 cover 唔到嗰啲位。
翻譯係最容易 demo 出嚟嘅部分,同時亦都係最危險、最容易俾人高估嘅部分。
機器而家可以用好驚人嘅速度,將文字由一種語言搬去另一種語言。但呢件事唔代表個產品就自然會變得 native。以我嘅經驗,真正嘅多語言工作,通常喺四個位浮出水面:時間、聲線、UI systems,同 fallback behavior。個產品係令人覺得 thoughtful,定係令人覺得假,通常就係喺呢啲位分勝負。
實際上,大概係咁:
| Translation Work | Product Work | |
|---|---|---|
| 佢 cover 啲乜 | Strings、copy、labels | 日期、layout、聲線、fallbacks |
| 邊個會發現有錯 | Bilingual reviewers | 該 locale 嘅每一個 user |
| AI 點樣幫到手 | 好快 produce translations | 判斷唔到 product-level fit |
| 修正成本 | 重新翻譯個 string | 重新設計個 component |
| 幾時先發現問題 | Code review 嗰陣 | 真係有人用咗之後 |
第一個 bug 唔係翻譯,而係時間
最令我意識到呢件事嘅其中一個 fix,其實同 copy 完全冇關。
對 recurring shows 嚟講,DIALØGUE(對話)會自動生成 episode titles。最直觀嘅做法聽落好 harmless:show 名,加今日日期。
但當你嘅 audience 喺東京,而個 server 仲喺度用加州時間思考,就完全唔係嗰回事。
如果一個日本 listener 打開一個 daily show,東京已經係 3 月 14 號,但個 episode title 仲係寫住 3 月 13 號,因為 server 仲係咁理解,個產品會即刻令人覺得有啲唔對路。唔係壞咗。只係好唔上心。
所以最後我改咗個 episode title 嘅邏輯,令佢會用 audience 所在 locale 同 timezone 嘅本地日期,而唔係 server default。
呢個只係一個細細嘅 implementation detail。但正正就係重點。
多語言產品唔只係文字問題。佢其實係 context 問題。
冇 local context 嘅語言,好多時只不過係一個比較有禮貌版本嘅錯誤。
Lesson 1:聲線本身就係產品一部分
我愈做 DIALØGUE 深,呢件事就愈清楚。
呢個產品係建基於 dialogue、pacing、personality 同 audio 之上。即係話,佢嘅 quality bar 天生就比一般 SaaS 介面高好多。
當我加新 templates 嘅時候,我好快就發現,多語言 support 絕對唔只係:
- 翻譯個 template 名
- 翻譯 landing page copy
- 然後 shipping
以其中一個 template 為例,我要諗清楚以下所有嘢:
- host profiles
- audience profiles
- dialogue guides
- 畀 TTS 用嘅 voice instructions
- 每種語言自己嘅 localized naming conventions
呢啲設計喺英文入面本身已經有,但佢同樣需要日文版同越南文版。因為 hosts 之間嘅 chemistry 本身就係產品一部分,唔係上面再鋪一層 cosmetic layer。
如果你個產品會生成內容,voice 唔係裝飾。voice 係 infrastructure。
有啲嘢可以文法完全正確,但仍然令人覺得冇靈魂。
我喺 Chinese 各種變體,仲有 spoken content 上,對呢件事感受特別深。標準普通話可以 technically 完全啱,但擺喺某啲情境底下,仍然會太 formal。英文入面好自然嘅 conversational rhythm,一旦太 literal 咁搬去另一種 product language,可能就會突然變得好官腔。喺一個市場有用嘅笑位,去到另一個市場可能就只剩返平平直直嘅解說。
所以我而家好重視 tone guides 同 host profiles。唔係因為我想每個 output 都聽落好「品牌化」。而係因為 voice drift 係令一個多語言 AI 產品好快變 generic 嘅最快方法之一。
而 generic,係有代價嘅。
Lesson 2:UI 長度係產品問題,唔係翻譯問題
呢件事聽落好小,直到你真係 ship 一個 app 出街。
之後佢就會突然無處不在。
當我做 DIALØGUE 嘅 iOS localization 時,件事已經唔再係「翻幾個 screens」咁簡單。佢變成咗 7 種語言、253 個 strings。
而就算做到呢一步,工作都仲未完。
我需要重新 wiring 啲 input components,確保 app language picker 真係可以一致咁控制 UI language。placeholders、buttons、pricing labels、status text,全部都要跟住走。如果唔係,你就會見到典型嘅「半翻譯 app」問題:
- 一個 screen 會跟住你揀嘅語言
- 另一個 screen 仲顯示緊英文 placeholder
- status labels 仲停留喺原本嗰種語言
- app technically 係支援多語言,但體驗就唔係
一個喺英文入面好乾淨嘅 button,去到德文可能即刻變得 awkward。 一條本身好齊整嘅 pricing line,去到法文可能會換行。 一個幾 punchy 嘅 settings label,去到日文可能又完全唔同反應。
如果你個 localization workflow 到 text generation 就停,呢啲問題通常會喺好後期、而且幾尷尬嘅時候先浮出水面。
所以我愈來愈覺得,多語言工作必須當成一個完整嘅 product system 去處理:
- copy
- layout
- spacing
- truncation rules
- component behavior
- screenshot QA
文字機器可以生出嚟。但真係去開 Simulator 嘅,仍然係人。
Lesson 3:fallback behavior 會揭穿產品到底成熟到咩程度
呢件事喺 audio products 入面,比起 text products 更加重要。
我最近喺 DIALØGUE 做過其中一個最有用嘅 fix,喺外面睇其實幾 boring:TTS thresholding 同 per-segment consistency。
最初個 whole-script TTS gate 太樂觀。長 podcast 會直接撞過真正嘅 input limit,先白白浪費幾次 failed retries,之後先 fallback。某啲 runs 入面,呢件事等於系統要多浪費大概 12 秒本來可以避免嘅 latency,先至自我修正返。
就算係英文,呢件事都已經幾煩。
去到多語言 flows 就仲衰,因為 voice consistency 本身就更加難維持。
呢個 fix 唔係「換個更好嘅 model」。呢個 fix 其實係 product work:
- 降低 whole-script synthesis 嘅 threshold
- 早啲將長 episodes 轉做 per-segment mode
- 為每個 segment 加 opening / middle / closing guidance,保持節奏同能量
- 將前一段 dialogue 嘅幾行內容當 continuity context 傳入去,避免下一段聽落似另一個 show
呢啲就係 fallback behavior。呢啲就係成熟度。
如果某種語言專用嘅 TTS 聲線聽落唔啱,會點? 如果生成出嚟嘅答案開始撈埋幾種語言,會點? 如果喺一個 localized flow 中間突然彈出 untranslated error message,會點? 如果一段長 script 撞穿咗 model limit,會點?
就係喺呢啲時刻,你先睇得出多語言 support 只係 feature,定已經係 foundation。
當個 system 明顯係真心想幫手時,users 通常都幾寬容。 但當個產品畀人感覺 careless,嗰種寬容就會好快消失。
Lesson 4:知道幾時 coverage 根本唔值
真正嘅 business question 唔係:「我可唔可以再 support 多一種語言?」
真正要問嘅係:
- 呢種語言會唔會打開真實嘅 usage 或真實嘅 distribution?
- 我可唔可以喺 UI 同 output 兩邊都維持一個可信嘅 quality bar?
- 我可唔可以處理 failure cases,而唔會製造出 support debt?
如果答案係唔得,咁你 launch 嘅就唔係 multilingual capability,而只係 multilingual surface area。而冇 quality 支撐嘅 surface area,會靜靜地侵蝕 trust。
Lesson 5:多語言產品需要自己一層 evals
呢個可能係我由 DIALØGUE 同 blog archive 入面得到最大嘅 takeaway。
多語言品質,特別係一去到規模,唔可能淨係靠直覺判斷。
你需要明確嘅 checks:
- locale-specific 日期同 timezone behavior
- 術語一致性
- UI overflow
- fallback language rules
- 各 segments 之間嘅 TTS consistency
- host / personality drift
- 真實 user flows 入面嘅 output quality
換句話講,多語言產品都需要 evals。
而我覺得,呢度正正就係好多 AI builders 最容易跌入去嘅坑。我哋太容易俾 model 可以 produce 幾多嘢吸住,反而花少咗時間去 durable 地定義咩叫做「好」。
細規模時,仲勉強 manage 到。
一去到大規模,就會變得危險。
呢件事令我而家點睇
我而家比以前任何時候都更加 optimistic 去睇多語言 AI 產品。
AI 的確改變咗 economics。佢的確擴大咗一個人或者一個細 team 可以 shipping 嘅範圍。佢的確令一啲唔係太耐之前仲聽落好唔現實嘅 product ambitions 變得可能。
但同一時間,佢都拉高咗對 product judgment 嘅要求。
因為一旦語言擴張變得容易,quality 就會變成真正嘅 differentiator。而多語言產品入面嘅 quality,並唔係單靠翻譯就會出現。佢嚟自 context、voice、interface fit、fallbacks、review loops,同埋你有幾誠實咁定義「到底幾多先算 native enough」。
呢個就係 DIALØGUE 教識我嘅事。你 support 越多語言,你其實就喺做越多嘅 product management,無論你會唔會咁叫佢。
如果你個產品真係多語言,工作唔會喺 strings 翻譯完嗰一刻完結。真正嘅工作,係由嗰度開始。
如果你想睇下呢種思路 produce 咗啲乜,DIALØGUE 而家已經以 7 種語言 live。仲有,我估多語言呢一層之後都會繼續教我新嘢,愈多人用,學到愈多。通常都係嗰啲幾令人 humble 嘅 lessons。
如果你都喺度做多語言產品,我真係好想知:你係喺邊一刻意識到,最難嗰個 bug 同翻譯其實完全冇關?
Cheers, Chandler
常見問題
建一個多語言 AI 產品最難嘅部分係咩?
唔係翻譯。AI 而家對呢一部分已經處理得相當好。最難嘅係翻譯以外嗰啲位:要識得處理 timezone 嘅 formatting、跨 TTS segments 嘅 voice consistency、因為字串長度唔同而爆位嘅 UI components,仲有當某個特定 locale 出事時嘅 fallback behavior。呢啲係產品問題,唔只係語言問題。
我應唔應該幫自己個 AI 產品加更多語言?
前提係你維持到 quality。每加一種語言,都會帶嚟持續嘅 product work:layout QA、voice tuning、按 locale 處理日期同數字 formatting,以及 fallback paths。如果你個產品依賴 nuance 同 generated content,例如 podcasts、長文寫作或者 conversational AI,咁佢嘅門檻一定比一個簡單 transactional interface 高得多。
你會點 test 多語言 AI features?
建立一層明確嘅 evals。對 DIALØGUE 嚟講,意思係要檢查 locale-specific 日期、TTS segment consistency、7 種語言入面嘅 UI overflow,仲有生成出嚟嘅 host dialogue 有冇 personality drift。當你 support 超過兩三種語言,就唔可以再只靠直覺。個 surface area 太大,唔可能淨係靠手動 spot-check。
AI 令 localization 變得更容易,定更困難?
兩樣都有。AI 令初始翻譯快得多、平得多。但同時佢亦會製造一種虛假嘅完成感。文字啱咗,你就會以為個產品 ready。真正嘅工作,context、voice、UI fit、fallbacks,仍然需要 human judgment。AI 提高咗 multilingual coverage 嘅 floor,但 ceiling 依然係 product craft。





