繁體中文 AI 去人味工具評選指南：GitHub Repo 比較與對抗測試方法論
簡介
隨著 AI 生成內容普及，「去 AI 味」（Humanize）成為內容團隊的關鍵需求。本文整理 GitHub 上針對繁體中文／台灣語境設計的 Claude Code Skill 與開源專案，並提供對抗式評估方法論，協助團隊建立可重現的工具選型流程。
一、台灣繁中專用版本對照表
以下專案明確針對台灣用語、教育部標點、簡轉繁錯字修正等在地化需求設計，適合作為受控測試候選。
| 專案名稱 | 開發者 / 來源 | 核心特點 | 適用場景 |
|---|---|---|---|
| Humanizer-zh-TW | kevintsai1202 | 掃描 24 種 AI 痕跡、打散排比句、混合長短句、中國用語→台灣慣用詞（優化→調整、上下文→脈絡） | 一般內容行銷、部落格、社群文案 |
| Humanizer-zh-tw (Tenten) | tentendev / Tenten | 涵蓋 25 種 AI 寫作模式、內建中國用語污染偵測、五條改寫原則、完整繁中說明書 | 企業內容團隊、需文件完整度的專案 |
| writing-humanizer | shyuan | Claude Code Plugin 形式、偵測改寫 31 類 AI 模式、類別數量同類最多 | 快速原型驗證、大量文本批次處理 |
| humanizer-zh-TW-Pro | slivenred | 語氣比對、誤判防護、SEO 事實保留機制 | SEO 長文、擔心事實遺失的發布場景 |
備註：kevintsai1202 版本由開發者「凱文大叔」重構自英文原版 Humanizer，社群評價效果類似「精明的台灣總編輯」。Tenten 版本為內容團隊在地化產出，文件完整度較高。
二、中國簡中／通用版本參考基準
若不侷限台灣語境，以下專案在簡中或通用場景星數與討論度較高，可用於比較「去 AI 味」策略差異：
- Humanizer-zh (op7418)：英文原版漢化，移除翻譯腔與機械排比，強調引導文字加入真實立場與觀點。
- stop-slop (hardikpandya)：目前星數最高，附帶禁用短語表、結構性 AI 習慣清單，核心規則「每個句子都要有一個真實的人在做動作」，拒絕被動語態。
- humanize-chinese (voidborne-d 改編版)：提供偵測、改寫、學術降 AIGC、風格轉換完整工作流，適用論文降重、知網／維普檢測場景。
- anti-ai-smell (androidzzt)：走 linter + 詞表路線，規則式檢測取代模型改寫，適合追求可重現、可稽核結果的場景。
- qu-ai-wei (LifelongLazyLearner)：簡中去 AI 味工具，支援
npx skills CLI直接安裝，作為簡中基準對照。
三、Tenten 組織三大核心 Repo 深度比較
Tenten 組織下三個專案雖同屬「繁中去 AI 味」，但設計哲學與目標受眾明顯不同：
| 專案 | 核心定位 | 主要能力 | 差異化亮點 |
|---|---|---|---|
| shuorenhua-zh-tw | 全方位清理 | 去 AI 腔、清中港用語、修簡轉繁錯字、教育部標點、支援七種出版語體 | 唯一明確支援「修簡轉繁錯字」與「教育部標點」，適合混雜簡體殘留字或標點不合規範的原始文件 |
| Better-Humanizer-zh-TW | 出版業專用 / 送印等級 | 深度潤飾、繁中、英文、簡中三語版本說明 | 瞄準「可直接送印」的嚴格校對標準，理論上更不容忍編輯標記殘留 |
| speak-human-tw | 規則覆蓋率與可稽核評分 | 抓 38 種 AI 寫作痕跡、校正中國用語與半形標點、交稿前自評分機制 | 社群關注度快速上升（一週星數 +355），規則庫品管流程嚴謹（需多來源反覆點名且不誤傷正常用法） |
選用建議
- 若 speak-human-tw 已在既有測試中綜合表現最佳，下一輪建議納入 Better-Humanizer-zh-TW 驗證其「送印等級」標準是否能解決舊版 shuorenhua-zh-tw 的編輯標記殘留問題。
- 確認 shuorenhua-zh-tw 是否為測試版本的更新版——其新增的簡轉繁錯字修正與教育部標點功能若未涵蓋在前次測試，可能影響品質分數重新評估。
- 優先納入受控測試的候選：
Humanizer-zh-TW (kevintsai1202)與writing-humanizer (shyuan)，兩者明確主打台灣正體中文與 Claude Code Skill 格式，涵蓋 AI 痕跡類別數量與 speak-human-tw 的 38 種相近或更多。
四、對抗式評估方法論：偵測器 vs. 去人味工具
單看「主觀評分」不足以驗證去人味效果，業界標準採用對抗評估框架，將「偵測準確率」與「規避成功率」置於同一受控框架。
4.1 基本框架
- 建立已知標籤樣本集 三類：
- 純 AI 生成
- 純人類寫作
- 經過去人味改寫的 AI 文本
- 多偵測器同時掃描：Originality.ai、GPTZero、Copyleaks、Winston AI 等主流工具（準確率約 84%–91%）。
- 測量關鍵指標：
- 真陽性率（TPR）在特定假陽性率（FPR）操作點（如 FPR=1% 時的 TPR）
- AUROC 從接近 1 拉低至接近隨機猜測
- 規避成功率：改寫後通過偵測器判定為人類的比例
4.2 業界常見測試維度
| 測試維度 | 常見做法 | 參考來源 |
|---|---|---|
| 偵測工具準確率 | 已知標籤樣本測 Originality.ai、GPTZero、Copyleaks、Winston AI | Hacker News 90 天實測 |
| 規避成功率 | 同批 AI 文本跑多款去人味工具，再送回同一偵測器測「通過率」 | Hacker News 90 天實測 |
| 動態對抗學習 | 白箱/黑箱設定，測偵測器遭遇最小幅度改寫多快失效 | ACL 學術論文 |
| 偵測器補丁測試 | 針對已知規避手法（注入隨機空格）建立灰名單，測更新後識別力 | GPTZero 官方研究 |
4.3 關鍵限制與避坑指南
- 表層擾動 ≠ 可靠解法：多數規避工具僅套用開源 T5 模型做同義詞替換或注入攻擊（隨機空格），偵測器廠商通常數天內更新灰名單重新識別。
- 語意完整性為先：去人味改寫若犧牲語意完整性，即使暫時騙過偵測器，長期也不算可靠解法。
- 格式偏誤：所有偵測工具面對高度樣板化內容（條列式、how-to）準確率下降 15%–20%，樣本必須涵蓋多種文體（技術文件、行銷文案、部落格、學術風格）避免單一格式主導評估結果。
五、升級既有 EVAL 流程的實務建議
若現有流程使用 Claude Opus 匿名評分，建議加入**「偵測器往返測試」環節**：
- 將三個 Skill 改寫後的成品，分別送入至少兩款不同架構的公開偵測器（一款以困惑度為主、一款以分類器為主）。
- 觀察「AI 味分數」與「偵測器判定結果」是否一致。
- 驗證主觀評分（如「AI 味 34.0」）是否真對應到偵測工具判定為人類寫作的結果，避免評分機制與實際規避效果脫節。
最小可行性驗證清單
- 建立 3 類標籤樣本集（各 ≥ 30 篇），涵蓋 ≥ 4 種文體
- 選定 2–3 款不同架構偵測器作為基準
- 記錄改寫前後的 TPR/FPR/AUROC 變化
- 記錄規避成功率與語意保真度（人工抽樣驗證）
- 建立誤判防護機制：標記「過度改寫導致事實遺失」與「編輯標記殘留」案例
結語
選擇去人味工具不應只看星數或單一主觀評分。建議團隊：
- 先定義驗收標準（出版送印級 vs. 一般行銷文案 vs. SEO 長文）
- 建立對抗式評估基線（多偵測器、多文體、盲測）
- 以受控實驗納入候選（優先 kevintsai1202、shyuan、Better-Humanizer-zh-TW）
- 持續監控偵測器更新，避免表層擾動策略失效
唯有將「去 AI 味」視為持續對抗的工程問題，而非一次性提示詞優化，才能在偵測器演進中維持內容通過率。