harshaneel/humanize 是一個 MIT 授權的 GitHub repo。HN RSS 擷取到的頁面顯示它有 78 stars 和 7 forks，repo 內容把兩個 LLM 技能打包成單檔 SKILL.md：humanize 負責改寫文字，ai-check 負責用九類訊號評分並引用證據。
工程上應先看 README 自己劃出的證據範圍，少看「Best static AI text humanizer」這種標語。README 的 benchmark 支持它壓低 perplexity 和表面統計訊號，對 ZeroGPT、QuillBot、Binoculars 這類偵測方法比較有說服力；對 GPTZero、Grammarly、Pangram 這類 learned classifier，README 明確說沒有保證，甚至提到同一批 humanized output 會被評成 99 到 100% AI。
靜態技能的好處是整合成本低#
humanize 的設計很輕。repo 說它沒有訓練模型，沒有 API call，也沒有 detector-in-the-loop。技能本體就是 host LLM 會讀的一份規則書，Claude Code、Codex CLI、ChatGPT、Gemini、Cursor、Aider、OpenCode、Continue 和 Copilot 都可以用，差別只在安裝路徑。
README 提供的 install.sh all 會安裝到 /.claude/skills、/.codex/skills 和 ~/.agents/skills。用 symlink 安裝時，git pull 之後規則會跟著更新；用 copy 安裝時要重跑 install script。對團隊來說，這種部署方式的好處很直接：沒有金鑰，沒有外部服務，SKILL.md 可以直接 review。
代價也同樣清楚。靜態規則只能改寫 host LLM 的輸出行為，無法觀察商業 detector 的即時回饋。偵測器更新後，規則要靠人維護。
benchmark 證明的是表面訊號改善#
README 的測試集有 25 個 AI-flavored input，涵蓋 tech blog、postmortem、product launch、academic abstract、business email、Slack update、README intro 等 25 種 register。humanize 改寫後，repo 用兩個 scorer 檢查輸出。
內部 scorer 是 ai-check。25 筆輸出的平均分數是 5.24，median 是 5，判定結果是 6 筆 Human 和 19 筆 Likely Human，沒有 Uncertain 或更差的結果。
外部 scorer 是 Binoculars。README 使用 TinyLlama-1.1B base 與 TinyLlama-1.1B-Chat，而 Binoculars 論文使用的是 Falcon-7B。這個替代配置會影響證據強度，因為測到的是 Binoculars 演算法的輕量版本。結果仍然完整列出：平均分數 0.9928，median 0.9889，範圍 0.9010 到 1.0737，全部高於 README 引用的 low-FPR threshold 0.854。
這些數字能支持一件事：humanize 在 README 的測試條件下，能把文字推到 rule-based scorer 和 cross-perplexity scorer 的 human side。這些數字不能推出另一件事：它能穩定通過 learned commercial classifier。
learned classifier 是 README 自己承認的天花板#
README 對限制寫得比一般 humanizer 工具誠實。它把 GPTZero、Grammarly 和 Pangram 放在 learned classifier ceiling 裡，理由是現代偵測器抓到的可能是 RLHF 和 instruction-tuning fingerprint，而非單純的句長、標點或 transition word。
這對工程判斷很重要。rule-based skill 可以要求模型少用 hedge、移除 assistant register、增加句長變化、少用公式化 transition，這些都是可觀察的輸出形狀。learned classifier 如果從模型權重留下的分布特徵下手，表面重寫就只能逼近，不能保證跨過邊界。
README 也列出補強方法，例如 detector-scored best-of-N、iterative paraphrase、base-model paraphrase 和 manual edits。這些方法已經超出「單檔 SKILL.md、零 runtime dependency」的範圍。換句話說，humanize 的低整合成本和偵測器適應能力之間有明確取捨。
ai-check 比較像寫作品質 linter#
ai-check 的輸出包含 verdict、confidence、九類 signal breakdown、每個 flag 的 evidence quote，還有 AI-edited fraction estimate。這種格式對 review 流程有用，因為它讓「哪裡像 AI」變成可以指認的句子和訊號。
把 ai-check 當真相標籤就超出來源能支持的範圍。README 自己說兩個 scorer 都偏向 perplexity 或 surface stats；learned classifier 可能給出完全不同結果。比較穩的用法是把 ai-check 放在寫作流程裡，檢查 hedge、重複結構、過度平滑的段落和標點習慣。
適合放在內部寫作流程，不適合當作者身份證明#
humanize 最有用的地方，是把「AI 味」拆成工程師可以 review 的規則：字詞可預測性、句長變異、hedge、結構扁平化、具體性、register、transition、標點和 RLHF voice strip。這些規則不神祕，也不需要外部服務。
README 目前能證明的範圍停在這裡：25 類文本在 ai-check 和 TinyLlama Binoculars 配置下都落在 human side；同一份 README 也承認，GPTZero、Grammarly、Pangram 這類 learned classifier 仍可能把輸出判成 AI。這個邊界比 star 數更值得看。