Skip to content

實測五個繁中用語檢查工具：一個能用，一個的 --fix 會把「只是」改成「隻是」

2026年8月21日 1 分鐘
首頁 › tech
TL;DR 在 109 篇確實含中國用語的文章上，zhtw-mcp 精確率 29.4%、召回 85.2%，twlint 是 21.2% / 82.5%——但 twlint 有 195 個 error 級判斷是把合法正體字當簡體字（干→幹 60 次、只→隻 15 次），跑 --fix 會毀掉文章。最有用的發現不是誰勝出：zhtw-mcp 幫我補了五個自己漏抓的中國用語，也擋下一個我誤列的（審計）。工具的價值在校準你的清單，不是取代它。
#taiwan#linter#content-strategy#zh-tw#tooling
目錄
  1. 第一次：抽樣抽錯，量到的是抽樣不是工具
  2. 第二次：真值清單訂錯，把工具的正確答案算成錯的
  3. 第三次：採納錯，差點毀掉所有 AI 段落
  4. twlint：195 個 error 級判斷，全是把正體字當簡體字
  5. zhtw-mcp：誤判是用詞主張，不是字形破壞
  6. 差別來自規則的設計
  7. 如果你不寫程式
  8. 不管用哪個工具，這四件事一樣
  9. 更根本的做法：在 AI 寫之前就講清楚
  10. 如果你有 repo
  11. 參考資料

🌏 English version

LLM 的中文語料以中國內容為大宗，所以它寫出來的「繁體中文」常常是字形正確、詞彙錯誤：軟件、視頻、用戶、質量。

我站上本來有一條手工維護的 18 條 grep pattern 在擋，但它只是 checklist 上的一行字，靠人記得跑——所以從來沒跑過。我想把它換成有人維護的工具。

找了五個，全部實測。過程中我錯了三次，最後的做法跟出發時想的完全不同。

一、先把工具分類

五個候選不是五個同類的東西。先分清楚，後面才有辦法比。

類別專案做什麼
檢查器zhtw-mcp、twlint讀你的稿子，指出哪些詞該換
詞庫Chinese-Vocabulary-Radar只有資料，要自己寫程式用
簡繁轉換tongwen-dict、OpenCC把簡體文章轉成繁體

第三類先排除，因為它們結構上就幫不上忙。 實測 tongwen-dict 的 7,186 條詞彙：

视频 → 視訊       ✓ 在詞庫
視頻 → ✗ 不在詞庫
软件 → 軟體       ✓ 在詞庫
軟件 → ✗ 不在詞庫
用户 → 使用者     ✓ 在詞庫
用戶 → ✗ 不在詞庫

key 全部是簡體字，OpenCC 的 s2twp 同理。而 LLM 產出的問題文本是字形已經是繁體、詞彙是中國的——「視頻」不是「视频」，簡繁轉換器看它就是個已經轉好的正常詞。

這不是 bug，是目標不同：它們解「把簡體文章轉成台灣看得懂的樣子」，我要的是「檢查一篇本來就是繁體的文章裡有沒有中國詞」。輸入形態不一樣，詞庫的 key 就不一樣。

剩下兩個檢查器：

  • zhtw-mcp（sysprog21，MIT，Rust）依教育部《重訂標點符號手冊》與《國字標準字體》，跨海峽詞彙以 OpenCC 的 TWPhrases／TWVariants 為基礎，1,882 條規則。CLI 與 MCP 雙介面，歧義詞會反問宿主 AI 助理。
  • twlint（npm 上是 @termdock/twlint，Apache-2.0）ESLint 風格的 CLI，兩條規則：simplified-chars（error）與 mainland-terms（warning），詞庫分八個領域約 1,946 條。

二、我錯的三次

這三次比工具比較本身更值得看，因為它們是同一類錯：每一次我都以為已經有客觀數字了，但那個數字底下的假設沒被檢查。

第一次：抽樣抽錯，量到的是抽樣不是工具

第一輪我取 120 篇（ls src/content/posts/*/*.md | head -120）：

來源命中精確率
twlint --deep1,5880.3%
Chinese-Vocabulary-Radar1,4630.3%

我差點就寫成「現成詞庫全部不能用」。

後來查了一件事：那 120 篇裡，用戶、視頻、網絡、質量、軟件、界面 出現次數全部是 0。

樣本裡根本沒有要找的東西，精確率的分子必然接近零。head -120 按檔名排序，於是拿到的幾乎全是同一批文章。

在一份沒有陽性的樣本上量精確率，量到的是你的抽樣方法。

第二次：真值清單訂錯，把工具的正確答案算成錯的

改用確實含中國用語的 109 篇重測，這批有 567 次真陽性。第一次算出來是 zhtw-mcp 25.6%、twlint 18.6%。

但我的真值清單只有 17 個詞。zhtw-mcp 抓到 激活、插件、反饋、兼容、智能——這些是真的中國用語，卻因為不在我清單上而被算成假陽性。

補進去之後：

工具報出問題真陽精確率召回
zhtw-mcp（cross_strait）1,88855629.4%85.2%
twlint --deep2,52253521.2%82.5%

召回都在八成以上。這跟第一輪的「0.3%」是完全不同的結論。

反過來也有：我的清單把 審計 當中國用語，站內 36 次，zhtw-mcp 一次都沒報——而它是對的。那 36 次全是「SOC2 審計」，而審計部是中華民國的機關，這個詞在台灣是正規用語。

主要詞的實測抓取率：

詞文章裡zhtw-mcp 報
用戶424418
信號5251
視頻43
界面43
智能218（語境條件，沒誤報「人工智慧」）
質量143（排除物理語境）
審計360（正確不報）

第三次：採納錯，差點毀掉所有 AI 段落

上一節那五個詞，我全部收進了「必修」清單，然後跑批次替換。跑預覽的時候才發現 激活 收錯了。

站內 23 次 激活 全部是機器學習的 activation——激活空間、激活量化、非線性激活、激活監控。一次都不是「啟用」的意思。改下去會毀掉每一段講神經網路的文字。

同一次預覽還抓到兩個：貼標 → 貼上標籤 會撞到「貼標籤」變成「貼上標籤籤」；而腳本把這篇文章本身也改了——這篇在討論這些詞，表格變成「外掛｜19｜19｜外掛」。

zhtw-mcp 報 激活 沒有錯，錯的是我不看語境就收。工具給你候選詞，該不該收要看你自己的語料。

三、噪音的性質比精確率重要

29.4% 對 21.2%，八個百分點。但誤判的種類差很多，而那才是決定能不能用的關鍵。

twlint：195 個 error 級判斷，全是把正體字當簡體字

它說出現次數問題
簡體字「干」→「幹」60干擾、干預、若干
簡體字「污」→「汙」47兩者皆為正體，非簡繁關係
簡體字「只」→「隻」15只是、只有
簡體字「占」→「佔」14占卜、占星
簡體字「岩」→「巖」7岩是正體標準字形
簡體字「准」→「準」6准許、批准

這一整類是 error 級而且 --fix 會動它。跑下去會把「只是」改成「隻是」、「干擾」改成「幹擾」。

zhtw-mcp：誤判是用詞主張，不是字形破壞

它說出現次數我的判斷
場景 → 情境122有道理但我不打算改
開源 → 開放原始碼19正式文件對，部落格太累贅
循環 → 迴圈2程式語境對
函式 → 函數 / 函數 → 函式各 1兩個方向都有規則，內部不一致

這些是可以爭論的立場，不是壞掉的字。你不同意就關掉那條規則，不會有東西被改壞。

差別來自規則的設計

翻 zhtw-mcp 的 assets/ruleset.json，1,882 條規則裡有 413 條（22%）帶防誤殺機制：66 條有 exceptions、349 條有 context_clues、72 條有 negative_context_clues。

三個直接對上我遇到的坑：

文件 → 檔案 被主動標成 disabled，理由寫在資料裡：

tw 「文件」= document (正確用法)；cn 「文件」= file。裸詞歧義無法消歧，停用以避免誤判。複合詞 (文件夾→資料夾、頭文件→標頭檔) 不受影響

同一個詞，twlint 報了 50 次，Chinese-Vocabulary-Radar 報了 632 次。

用戶 → 使用者 帶 exceptions: ["用戶端", "用戶端作業系統"]。

只 的規則方向是反的：隻 → 只，type 標 confusable，說明是「OpenCC 轉換時可能誤植『只』(only) 為『隻』」。twlint 剛好把這個 bug 當成規則。

還有一個發生在建置階段：產生字元轉換表的 gen-s2t-tables.py 會印出 「Ambiguous: 15 chars excluded」——一簡對多繁的歧義字直接排除在自動轉換之外。twlint 那 195 個 error 全部屬於這一類。

優化 那條則帶 context_suggestions：出現「微服務／服務端／用戶端」建議「最佳化」，出現「流程／體驗／服務／營運」建議「改善／提升」。官方文件解釋了為什麼不把兩組都塞進 to——那會讓 IT 語境也失去自動修復。

四、所以我最後怎麼做

沒有把 zhtw-mcp 接進 CI。 它的噪音散在 187 個不同的詞上——關掉最吵的 50 條也只消掉 79%，109 篇還剩 294 次，平均每篇 2.7 次。當 pre-commit 硬閘門太吵。

但它做到一件更有價值的事：把我那份手工清單的錯都指出來了——三個詞收進必修、一個移除（審計）、兩個降成只提示（激活、智能）。

所以是三層分工：

角色用什麼為什麼
閘門（每次 commit 擋）你自己的窄清單零噪音，紅燈就一定要看
健檢（定期跑一次）zhtw-mcp找出「你不知道自己在用」的中國用語，拿去擴充清單
簡繁轉換OpenCC / tongwen它們本來就是做這個的

照這個做完之後，我站上 419 處中國用語被清掉，剩 8 處需要重寫整句的人工改完，然後才把檢查接進 CI。

五、你可以怎麼做

如果你不寫程式

上面整篇都在講指令和設定檔，但被 AI 寫出「軟件、視頻、用戶」困擾的人，多半是在 ChatGPT、Word、Notion 裡寫東西，不是在 repo 裡。

最省事：裝一個瀏覽器擴充功能。 中國用語雷達（Chrome）裝好之後，你在網頁上看到的中國用語會被標成黃色——包含你在 Google Docs、Notion、ChatGPT 對話框裡寫的字。不用設定，不用學指令。它只標不改，要不要改你自己決定。這反而是對的：沒有工具能替你判斷「質量」在你這句話裡是不是物理。

貼上去就好：線上轉換。 繁化姬貼文字選「台灣化」；Taiwan.md 用語轉換器有 3,901 條規則並標出改了哪裡。都不用註冊，缺點是長文要一直貼。

直接叫 AI 幫你對照。 如果你本來就在用 ChatGPT 或 Claude 寫稿：

請根據這份對照表，檢查以下文字裡有沒有中國用語，
只列出來不要直接改：
https://raw.githubusercontent.com/aronhack/Chinese-Vocabulary-Radar/refs/heads/main/chrome-extension/taiwan_china_vocabs.json

（貼上你的文字）

「只列出來不要直接改」這句很重要。 讓它直接改，你會失去判斷的機會，而它一定會改錯幾個。

不管用哪個工具，這四件事一樣

這是我上面那三次錯換來的，跟工具無關：

  1. 工具會把你領域裡的正常詞當成錯的。 我寫無人機，每一個「質量」都是物理；寫 AI，每一個「激活」都是 activation。你要能認出哪些是你的專業詞彙。
  2. 引用別人的話不要改。 引述中國受訪者說「這個視頻的質量真的不行」，那八個字一個都不能動——改了就是竄改引文。
  3. 專有名詞不要改。 「北京人工智能研究院」是機構名，「博客來」是書店不是「部落格來」。
  4. 批次取代之前先看過一遍。 對用 Word「全部取代」的人一樣成立：先按「尋找」看過所有結果，再決定要不要按「全部取代」。

更根本的做法：在 AI 寫之前就講清楚

與其事後抓，不如在 ChatGPT 的自訂指令、或 Claude 的 Project 說明裡加一段：

用台灣的中文寫。不要用：軟件、視頻、用戶、質量、默認、
插件、兼容、屏幕、鼠標、賦能、抓手、閉環、對標、復盤。
對應要寫成：軟體、影片、使用者、品質、預設、外掛、相容、
螢幕、滑鼠。

這比事後校對省力得多，而且列出「不要用什麼」比說「請用台灣用語」有效——後者太抽象，模型不知道你指的是哪些詞。

如果你有 repo

做成 CI 檢查的話：

  1. 從你自己的十幾個詞開始，不要從別人的 1,000 條詞庫開始。分兩級：A 級台灣沒有正當用法（用戶、視頻、軟件、插件…）紅燈擋 commit；B 級看語境（質量、智能、信號、反饋…）只提示。

  2. 排除四種區域：程式碼與行內程式碼、連結網址、blockquote 引述原文、參考資料的外部文章標題。還要有詞層 carve-out——用戶 會match到「用戶端」、對標 會match到「針對標註」、博客 會match到「博客來」。另外要能排除整篇文章，像這篇在討論這些詞，被檢查一定誤判。

  3. 用 zhtw-mcp 校準清單，不是取代清單。 跑之前先在 overrides.json 關掉你刻意使用的詞：

    {"from": "優化", "to": ["最佳化"], "type": "cross_strait", "disabled": true}

  4. 批次替換一定要先預覽，理由見上面第三次錯。

  5. 全綠之後才接成閘門。 我的順序：寫檢查（只報告）→ 清 419 處 → 人工改剩下 8 處 → A 級歸零 → 才接進 CI。倒過來做會擋死所有人。

來源

參考資料

相關文章

量產爬升的證據不在工廠，在「無法決標公告」裡 1 min 續航從 40 分鐘到 6 小時，換的不是電池是機體形態 1 min 類比 FPV 圖傳在台灣找不到條文可走 1 min