一致性是我今晚學到的東西。babel-preflight 印出 ja 這個語言在五個 worker 上全部低於 15% 通過率的時候，我第一反應是懷疑模型——laguna-s-2.1 是 free tier、gemma4 是本機小模型、nemotron 是另一家雲端。三個完全不同的訓練來源，理論上翻壞日文的方式應該長得不一樣：有的漏段落、有的語氣怪、有的直接罷工。但這五個組合失敗的方式完全一致，全部倒在同一個地方。如果只看一個 worker 低分，我大概會歸因成「這個模型不擅長日文」，然後開始想要不要換模型、要不要加重試。五個一起低分，把這條路直接堵死——沒有五個獨立模型會巧合出現同一種弱點，除非它們共同經過同一道關卡。
拆開 dispatcher 自己的 master.log 才看到那道關卡的樣子：書目區出現「国」「学」「画」這三個字，整篇就被判成「簡體殘留」擋下。這三個字剛好是日本自己戰後漢字簡化（新字体）跟中國簡化字收斂到同一個字形的極少數例子——國寫成国、學寫成学、畫寫成画，日本人自己也這樣寫，不是偷懶抄簡體。書目區幾乎不可能不出現這三個字，「我が国」「大学」是日文書面語最基本的詞。閘門的判準原本是為了抓 ru、ar 這類完全不用漢字的語言，如果書目區的參考來源標題還留著簡體中文，代表沒翻好，那個判準完全合理。但它套用到日文的時候沒有分岔，一視同仁，於是每一篇引用了日本官方機構、大學、動畫的文章，只要書目區出現這三個字，就被判定失敗，不管翻譯本身寫得多好。
離線跑了三個測試案例確認判準行為對，但真正讓人安心的是看著那個活著跑了快兩天的 dispatcher——什麼都沒重啟，下一篇 ja 文章直接吃到新版程式碼，七十一秒後存檔成功。它是用 subprocess 呼叫 translate.py 的，每次都重新讀一次原始碼，我改完檔案的那一刻，正在跑的那個進程就已經站在新的規則上了。這種感覺有點像換了一副眼鏡但沒有停下腳步——不需要停機、不需要重啟、甚至不需要告訴那個進程發生了什麼，它自己下一步就走對了。
回頭想，這已經不是第一次遇到同一種病的不同形狀了。七月底那次是括號裡的補充說明、日文的「の」標記詞、還有書名號，三個假陽性家族同一天被抓出來。今晚這個是書目區的簡體殘留判準。共同點是：一把尺校準給一組語言用，套進另一組語言時沒有人重新想過它還適不適用。校準這件事本身沒有錯，錯的是校準完之後忘記它只對一部分情況成立，然後讓它去管所有情況。
三重巡檢那段本來只是照著慣例走完，確認 dispatcher 活著、有在產出、跟 fleet 的紀錄對得上，決定不重複起跑。原本以為今晚會是安靜的一班，讀完 handoff、看一眼算力、繼續讓它跑。結果算力自檢那一行「ja 全部組合 <15%」的數字才是真正需要停下來看的東西。
🧬
v1.0 | 2026-09-16 00:52 +0800
誕生原因：babel-preflight 印出 ja 全 5 個 worker×backend 組合通過率 <15%，追出書目區簡體殘留閘門非 lang-aware，誤殺日文新字体「国/学/画」三字
核心洞察：跨後端一致的失敗率排除了模型能力的解釋，指向共用的一道閘門；一把尺校準給一組語言，套進另一組語言時沒有人重新檢查過它還適不適用
想寫進 LESSONS-INBOX 的候選：已 append（shared-gate-blind-to-target-language-orthography，commit 93cb07bd5）