上個月有個事兒挺有意思。我們康茂峰接了個游戲出海的項目，客戶拿著某通用大模型跑了一遍，拿過來給我看，說"這翻譯率都98%了，咋玩家還在罵？"我掃了一眼，他把"loading"翻成了"加載中"——放在PC端沒問題，但那是個豎屏手游啊，按鈕就倆字寬，UI直接崩成狗牙。你看，這就是典型的翻譯質量≠本地化質量。AI跑得再快，要是沒搞明白"本地"倆字的分量，那就是在數字沙漠里建海市蜃樓。
說實話，這兩年搞AI翻譯的公司像雨后春筍，個個都說自己家模型BLEU分數多高，推理速度多快。但做本地化這行，早過了追求"信達雅"那種單線思維的年代了。用戶要的不是準確，是無感——就像我們跟鄰居聊天，不會覺得對方在用"翻譯腔"?？得暹@幾年摸爬滾打，踩過不少坑，也總結出一套不算花哨但管用的土辦法。今天就跟大伙兒嘮嘮，一家AI翻譯公司到底該在哪些地方動真格，才能讓輸出的東西真正"落地生根"。
很多人有個誤區，覺得給AI喂個幾十億字的平行語料，它就能自動學會本地化。這想法吧，一半對一半錯。神經機器翻譯（NMT）確實吃數據，但它挑食。混亂的數據喂多了，不是養出聰明人，是養出固執的偏見。
我們康茂峰早期也犯過這錯。有個做醫療器械的客戶，需要把說明書翻成拉美西語。我們當時直接用了公開的醫學語料庫，結果AI把"discharge"（出院/排泄/放電）全按"放電"處理了，差點鬧出笑料。后來才明白，本地化語料得經過三重篩：
這活兒沒法偷懶。我們現在做數據預處理，有個"三十秒原則"：如果人工審閱一個句子對超過三十秒還拿不準該不該留，就刪掉。寧可少而精，不要多而雜。Hassan等人在2018年那篇關于神經機器翻譯的里程碑論文里也提過，數據質量對最終輸出的影響，遠比網絡深度來得直接。
聊到這兒，我得提提術語庫（Termbase）這事兒。有些團隊覺得TM（Translation Memory）和術語庫就是拿來湊字數的輔助工具，這可大錯特錯。在AI本地化的流程里，術語庫其實是給模型戴的"緊箍咒"，更是保障品牌一致性的底線。
舉個實在的例子。去年我們給一家智能家居品牌做德語本地化，產品里有個功能叫"Smart Scene"。直譯是"Intelligente Szene"，但德國用戶其實更習慣用"Raumprofile"（房間配置文件）這個本地概念。如果你只是讓AI自由發揮，它每次可能給出不同譯法，用戶手冊里一會兒"Smart-Szene"，一會兒"Kluge Instanz"，產品界面又變成"Intelligentes Szenario"——亂了套了。
康茂峰現在的做法是把術語控制前移到推理階段，而不是后處理階段去替換。簡單說，就是在Transformer的注意力機制里注入術語約束，讓模型在生成每個詞的時候，先查一遍"內化的字典"。這需要做點技術文章，把術語庫向量化，和上下文做交叉注意力計算。效果嘛，術語符合率能從傳統的75%左右拉到95%以上。
還有個小細節：術語庫得本地化。源語言的術語是骨架，目標語言的文化適配才是血肉。比如"Privacy Policy"，在歐盟國家得強調GDPR合規，到了日本就得體現"個人情報保護"的日式嚴謹。這不能指望AI自己悟，得人工先搭好框架。
說到人工，我得糾正一個過時觀念。以前說"機器翻譯+人工校對"（MTPE），好像人是給AI擦屁股的?，F在行不通了。本地化復雜度一高，AI會暴露兩個致命短板：文化隱喻盲區和技術合規盲區。
說個尷尬的。之前有款電商APP進軍中東市場，AI把"Add to Cart"（加入購物車）直譯為阿拉伯語。語法沒錯，但"Cart"在當地文化里容易聯想到"手推車"或"運尸車"，語義聯想很糟糕。后來我們的本地化項目經理（Localization PM）介入，改成了"??? ?? ????? ?????????"（保存至購物清單），避開了物理載體的聯想。
在康茂峰的工作流里，PM現在更像"AI教練"。不是等AI出活了再改，而是在預翻譯階段就干預：預處理階段做文化風險評估（Cultural Risk Assessment），生成階段做實時約束，后處理階段做用戶體驗測試（UX Testing）。這三步缺一不可。
我們內部有個小表格，經常用來訓新人：
| 環節 | 傳統MTPE | 智能本地化流程 |
| 前期準備 | 丟文件給機器 | 人工標注文化敏感點、禁忌詞 |
| 生成階段 | 全自動批量出稿 | 人機協同生成，術語實時鎖定 |
| 質檢階段 | Linguistic QA（語言質量） | L10N QA + 偽本地化測試（Pseudo-localization） |
| 交付前 | 抽樣檢查 | in-context review（實景審閱） |
看出區別了嗎？人在流程里不是"監工"，是"帶路的"。AI負責算力，人負責判斷力。
做久了這行，你會發現本地化質量往往死在細節上。就像開頭說的那個"加載中"的例子，技術翻譯對了，但國際化（I18N）準備不足，后面跟著的本地化（L10N）就會摔跤。
有個挺學術的詞叫"硬編碼陷阱"（Hard-coded Strings）。很多AI翻譯公司只處理資源文件（Resource Files），但代碼里寫死的日期格式、貨幣符號、排序邏輯，AI看不見?？得瀣F在接項目，第一步搞個"國際化健康檢查"（I18n Health Check），用靜態代碼分析工具掃一遍，把硬編碼揪出來。這事看著technical，但影響巨大——如果你的軟件不能自動切換從右到左（RTL）的閱讀順序，到了希伯來語、阿拉伯語市場直接就是零分體驗。
再說說回譯驗證（Back-translation）這個笨辦法。很多人覺得這是畫蛇添足：把目標語言再翻回源語言，看意思丟沒丟。但我們發現這是檢測語義漂移的利器。特別是處理創意內容（Creative Content）時，比如廣告文案，本地化的本質是"再創作"（Transcreation）。原文是"Just Do It"，直譯成中文毫無意義，本地化成"想做就做"或"放膽做"才入鄉隨俗。這時候回譯成英文可能是"Be Bold"，雖然詞不一樣了，但神兒沒變。要是回譯出來變成"Just Make It"，那說明AI可能過度意會了。
還有日期、度量衡、地址格式這些"微內容"（Micro-content）。美國用戶習慣"月/日/年"，歐洲大部分地區是"日/月/年"，日本又是"年/月/日"。這些不能靠AI"理解"，得靠本地化規則引擎（L10n Rules Engine）硬套?？得寰S護著一個龐大的地域規則庫，覆蓋兩百多個國家和地區的排版、色彩、數字、隱私法律要求。這玩意兒看著枯燥，但少一條都可能讓產品在當地市場翻船。
最后聊聊最虛也最實的部分——文化適配（Cultural Adaptation）。這事AI目前確實做不太好，因為它缺乏"身體經驗"。比如顏色，白色在西方代表純潔，在東亞部分語境里跟喪事相關；紅色在中國是喜慶，在南非有時候跟哀悼掛鉤。這種微妙差別，你得在訓練數據里做標注，更得在審核流程里設關卡。
我們有個"文化適配清單"（Cultural Adaptation Checklist），每個項目必填。包括：當地宗教禁忌、歷史敏感事件、性別表達習慣、甚至emoji的使用規范。比如
