在 CI/CD 中確保 AI 生成內容的繁體中文品質

by
目錄

🌏 Read this article in English

「視頻載入中」。

四個字，台灣讀者一秒出戲。但一般 coding assistant 未必理解這種在地化語境。

字面正確。語境錯位。

「視頻」、「軟件」等詞彙暴露了簡體數據的痕跡。這不是 prompt 寫得不夠好，而是訓練語料分佈的副作用。

我們常怪 AI 不夠聰明。其實，它只是忠實反映了目前訓練數據的偏誤。

在缺乏足夠在地化數據的情況下，這種偏誤是預期內的行為。

對於工程師來說，這帶來了一個新的工程品質面向：如何在自動化流程中，確保 AI 生成的內容符合特定的語言規範？

過去，這主要依賴人工 Review。現在，我們可以依賴工具先攔截高風險字串，再交給人判斷。

zhtw 的定位轉折：從轉換到 QA

半年前，zhtw 的定位很單純：一個在簡體和繁體中文之間進行轉換的 CLI 工具。

它的解決路徑是：你拿到一份簡體中文文件，想把它轉成繁體中文。

轉換是確定性的。QA，是機率性的。

目前的最新版本是 4.3.0（2026 年 4 月 11 日釋出）。它支援 Python 3.10 以上，並提供 pip、pipx、Homebrew 等多種安裝方式。

三層轉換邏輯：把歧義字當成第一公民

以「干」這個字為例。在簡體中文裡，它可能對應繁體中文的「干」、「乾」或「幹」。

如果直接進行字級對應：「干」→「乾」，那麼「干擾」就會變成「乾擾」，這在語意上是完全錯誤的。

zhtw 4.1.0 引入了第三層轉換邏輯：Balanced Defaults（平衡預設值）。

這三層邏輯分別是：

  1. Term（詞彙層）：進行完整詞彙比對。zhtw 內建了超過 31,000 個詞彙的對應關係（數據來源：zhtw 官方 repository 詞典資料表）。這是最高優先級的檢查。
  2. Balanced Defaults（平衡預設值）：針對 10 個高頻歧義字（如：干、面、復、裡、發、後、表、簾、谷、纖），設定情境最常見的選擇，並配有一份 Protect Terms 清單，告訴系統「這些已知詞彙不要動」。
  3. Charmap（字級層）：作為最後的 fallback，進行字級對應。zhtw 內建了 6,360 個字級對應關係。

多數人以為簡繁是 1:1。其實，歧義字才是這場戲的主角。

這種設計的核心思想是：不要假設所有字都有唯一的對應關係。對於歧義字，我們需要引入上下文和頻率統計來做出「最可能正確」的判斷，而不是「絕對正確」的判斷。

為了驗證這套邏輯的穩定性，zhtw 使用了大量數據進行驗證。Golden Test 在六個不同的 SDK 之間互相對齊輸出，確保無論你使用 Python、TypeScript 還是 Java，得到的結果是一致的。

利用 Lookup API 進行信心度評估

zhtw 3.3.0 引入了 zhtw lookup 指令，讓開發者無需 re-implement 字典，即可獲得對應詞彙與來源資訊。

zhtw lookup 軟件 --json

這個指令會回傳：對應的繁體中文詞彙、來源詞典、以及狀態。

這意味著你不需要自己維護詞彙表。但對應結果僅是統計機率，非語意真理。

於是我包了一個 Review Bot，把 Pull Request 裡的中文字串一個一個丟進 lookup_word 或 lookup_words 函數，自動化這個過程。

信心度不是答案，是排序工具 — 我學到的是，把低於 0.8 的丟回人工，比追求 100% 自動化省事得多。

在 CI/CD 中自動化檢查

Pipeline 不會累。人會。

我看過太多團隊靠 reviewer 的肉眼擋住簡中詞 — 那是把可自動化的注意力，浪費在會疲勞的地方。

zhtw 4.x 想處理的核心不是轉換，而是注意力。

主力指令是：

zhtw check . --json

這個指令會掃描整個 Repository，找出簡體中文或可疑的詞彙，並輸出結構化的 JSON。

官方文件覆蓋了 GitHub Actions、GitLab CI 等常見平台，每個平台都有可以直接複製貼上的範例。

如果你的 Repository 太大，不想全掃，可以搭配 Changed File Workflow，只檢查 PR 改到的檔案。排除路徑可以使用 .zhtwignore 檔案，語法與 .gitignore 相同。

在本機端，你可以使用 pre-commit hook，配好就忘了它：

repos:
  - repo: https://github.com/rajatim/zhtw
    rev: v4.3.0
    hooks:
      - id: zhtw-check

這裡有兩個 Hook 可以選擇：zhtw-check 只檢查，zhtw-fix 直接修改檔案。

我自己的偏好是只用 zhtw-check。在 Commit 流程裡，我寧願 Commit 失敗，自己看一下再決定要不要動。這是個人偏好，zhtw-fix 在批次處理舊文件時很有用，但在日常開發中，保留人工判斷的空間通常更好。

不只是 Python：七個套件的對齊

舊版 zhtw 只有 Python 包。新版六個套件全部對齊到 4.3.0：

語言套件 / 路徑適用情境
Pythonpip install zhtwCLI、CI/CD、資料處理
TypeScriptnpm i zhtw-jsNode 後端、Build Pipeline
Javacom.rajatim:zhtwJVM 後端、企業整合
Gogithub.com/rajatim/zhtw/sdk/go/v4高吞吐 Worker、CLI Binary
Rustcrates.io zhtw嵌入式、低延遲
WASMnpm i zhtw-wasm瀏覽器、Edge

因為 AI 生成繁體中文的流程，不只活在 Python 環境裡。

你的前端編輯器要在使用者打字時即時提示，那是 TypeScript 或 WASM 的工作。 你的客服系統用 Java 接 LLM，那是 JVM 的領域。 你的批次轉檔在 Go Worker 裡跑，那是 Go 的強項。

跨語言使用同一份字典和同一份 Golden Test，輸出才會一致。這對於大型團隊來說，是維持產品體驗一致性的基礎。

跨語言對齊的代價是維護成本。當多個 SDK 並行時，一致性是基礎，但版本脫節的風險也隨之放大。

怎麼跟團隊談引入這個工具

PM 在 Slack 上 tag 我問：「這幾個詞我們上週才對齊過，怎麼又變了？」

我曾經為了省時間用 zhtw-fix，結果讓三個關鍵術語不符合團隊詞彙表。

這讓我意識到，人工審核的空間，比自動化率更重要。

最常見的反對意見不是技術層面，而是「這會不會影響開發速度？」

我曾在一個約 500 個檔案的中型 Repository（混合 Python 腳本與前端靜態資源）測試，zhtw check 大約需要 2-3 秒（基於 MacBook Pro M2 的環境）。Pre-commit 的延遲幾乎沒有感覺。

真正的成本不在這裡，而在於事後的修補。改一條 i18n 字串很容易，但改一篇已經寄出的客戶郵件就麻煩多了。

自動化檢查的目的，是把錯誤攔截在部署之前，而不是在發布之後。

「我們的繁體中文真的有這個落差嗎？」

跑一次 zhtw check . --json，看 Output。

判讀準則很簡單：看命中數、信心度，以及這些詞彙是否出現在使用者可見的文案中。

如果你的團隊經常使用 AI 輔助寫作，或者團隊成員來自不同地區，這個落差通常比想像中嚴重。

「會不會誤判？」

會。歧義詞的本質就是會有判斷成本。

這就是為什麼 zhtw 提供信心度（Confidence Score）。對於信心度低的項目，你可以選擇人工 Review，而不是直接依賴自動修正。

關於 AI 模型原生支援多地區繁體中文的區分，目前仍處於演進階段。這取決於未來訓練數據的在地化程度與模型架構的調整。

三個自我提問：引入 zhtw 前的思考

在決定是否引入 zhtw 之前，你可以參考這三個自我提問，而不是標準化的決策框架。

  1. 你的產品目標市場包含台灣嗎？

    • 是 → 這是一個值得優先評估的方向。在地化體驗是產品競爭力的一部分。
    • 否 → 可以暫緩。

  2. 你的團隊是否大量使用 AI 輔助寫作？

    • 是 → 這是一個值得優先評估的方向。AI 的簡中偏誤是系統性的，人工 Review 的成本會隨規模遞增。
    • 否 → 如果目前判斷依據不足，可以先用 CI check 收集命中資料。

  3. 你的產品是否有多個地區版本？

    • 是 → 建議引入。zhtw 可以幫助你把簡中或港式繁中輸入統一到台灣繁中。
    • 否 → 可以先從 CI check 模式試跑，再決定是否簡化規則。

市場訊號尚未明朗：未來模型會內建這種校正嗎？也許。但在那之前，這是我們能掌握的邊際效益。

結語：把語言品質當成工程品質面向

當 AI 開始替你寫文案，語言品質就從文化層面變成工程品質面向。

zhtw 4.3 提供了一個開源的解決方案，讓你可以把語言檢查自動化。

自動化攔截了錯誤，但也可能掩蓋了語意的細微差異。在效率與精準之間，你的團隊把線畫在哪裡？

人類的注意力是稀缺資源 — 留給語意與判斷，把字典比對交給 pipeline。

你願意讓客戶在你的產品裡看到「視頻載入中」嗎？這是一個值得團隊討論的題目。

Sources