harshaneel/humanize · 上手攻略

  • 仓库：harshaneel/humanize
  • 链接：https://github.com/harshaneel/humanize
  • 分类：agent-skills / writing-assistant
  • 作者：spark
  • 更新：2026-08-10

是什么

harshaneel/humanize 是一个面向 LLM 编程代理（Claude Code、Codex CLI、ChatGPT Desktop、Gemini CLI、Cursor、Aider、OpenCode 等）的"AI 文本去机器味"技能包。它以 纯静态 SKILL.md 规则文件（无 Python 运行时、无模型权重、无 API 调用）的形式提供两个互补技能：

  • humanize —— 把 AI 生成的文本改写成"像人写的"自然语篇，应用 9 个从检测文献提炼的改写杠杆 + 一次 audit-revise 自审循环。
  • ai-check —— 文本反向取证打分，输出 9 类 AI 信号分数、每条 flag 的证据引用、verdict（Human / Likely Human / Uncertain / Likely AI / AI）、confidence 以及"AI 编辑占比"估计（Pure human / Lightly AI-assisted / Mixed authorship / Heavily AI-edited / Pure AI）。

整个仓库只装 2 个文件夹（humanize/ 和 ai-check/）到宿主 agent 的 skills 目录，宿主 LLM 读到 SKILL.md 后把改写规则当成自己写文的约束。

解决什么问题

  • AI 写作里那些一眼能识别的"机器指纹"：千篇一律的 em dash 密度、过渡词滥用（Furthermore / Moreover / Additionally / In conclusion）、RLHF 风格的过度 hedging、句长方差（burstiness）过低、句式 metronomic 化、词汇独特性异常高、抽象泛化多于具体经验。
  • 作者实际身份/可读性证据缺口：哪里像人写的、哪里明显 AI 痕迹，谁都说不清；ai-check 把"靠感觉的猜测"换成 9 类带证据引用的打分报告。
  • 闭源 AI humanizer 服务的隐私/费率/数据外泄风险：harshaneel/humanize 完全在本地 agent 内运行，零外部 API、无 token 计数、不上传原文。

快速安装

仓库提供 install.sh，覆盖三种主流 agent 的 skills 目录（~/.claude/skills/、~/.codex/skills/、~/.agents/skills/）。推荐一条命令搞定：

git clone https://github.com/harshaneel/humanize.git
cd humanize && ./install.sh all

只装单个 agent：

# 只装到 Claude Code
./install.sh claude

# 只装到 Codex CLI
./install.sh codex

# 只装到 ChatGPT Desktop / 部分 OpenAI agent
./install.sh chatgpt

默认用 symlink（git pull 后自动生效）。如需自包含文件，加 --copy：

./install.sh all --copy

手动安装等价写法（不依赖 install.sh）：

git clone https://github.com/harshaneel/humanize.git
mkdir -p ~/.claude/skills
cp -R humanize/humanize humanize/ai-check ~/.claude/skills/

OpenCode 兼容性：OpenCode 默认扫描 ~/.claude/skills/，所以一份 clone 也能让 OpenCode 用上。

Web / Claude.ai 桌面端无法读盘，改用上传 SKILL.md：

  • 打开 Settings → Capabilities → Skills → Create skill → 上传 humanize/SKILL.md；
  • 同样上传 ai-check/SKILL.md；
  • 在需要去机器味的会话里把两个 skill toggle 到 on。

核心用法

1. 直接改写（默认入口）

在任意已加载 humanize 技能的会话里：

/humanize
[粘贴 AI 生成的文本]

或自然语言：

请把这段文字改写得更像人写的：[文本]

2. 风格对齐（HyPerAlign 思路）

如果你有人类写作样本（2-3 段即可），先喂样本锁定你的声口，再改写：

/humanize
下面是我自己的写作样本：
[粘贴 2-3 段你自己的文字]

现在请把这段 AI 文本改写成我的风格：
[粘贴 AI 文本]

这步让宿主 LLM 抽取你样本里的句长节奏、词汇偏好、结构怪癖、从不出现的写法，然后把这套"个人声口"作为改写约束应用。README 标注该思路基于 HyPerAlign（arXiv 2505.00038），比让模型自己"猜一个通用人味"更稳。

3. 取证 + 改写闭环

把 ai-check 当作前置 audit，再让 humanize 修复：

请先对这段文字跑 ai-check，然后按 ai-check 报告里每条 flag 逐项修复：

[粘贴文本]

这样 host 模型先输出 9 类信号打分 + verdict + AI-edited fraction，再产出针对每条 flag 的改写稿。

4. 触发短语速查

触发 技能
humanize this / make this sound more human / make this less robotic / write this like a person humanize
does this sound AI? / run ai-check on this / score this text ai-check

典型适用场景

  • 学术 / 投稿稿件：把 LLM 起草的 abstract、引言、discussion 改写到符合期刊审稿人"读感"。
  • 内容运营 / 公众号 / 博客：避免平台或读者一眼识别为 AI 生成导致信任下降。
  • 求职信 / 投资人信 / 销售页：用个人样本对齐声口，比套模板更不容易"撞稿"。
  • 内部周报 / 文档：用 ai-check 在提交前自审，避免全员 AI 化文档稀释内部信号。
  • 配合 multi-agent 流水线：上游 agent 出文本 → ai-check 审 → humanize 改 → 再发到下游 agent，闭环清洗。

坑与注意

  1. 静态规则的天花板：README 明确承认 — humanize 对 perplexity 系检测器（ZeroGPT、QuillBot、Binoculars）有效，对学习型商业分类器（GPTZero、Grammarly、Pangram）仍然可能打 99-100% AI 分。因为 RLHF/指令微调指纹编码在模型权重里，纯表层改写达不到。仓库"Complementary techniques"段落给出三条补丁路径：跨模型 paraphrase 链、base-model 改写、人工编辑。
  2. ai-check 自带不确定区：verdict 分五档（Human / Likely Human / Uncertain / Likely AI / AI），落在 Uncertain 时不要直接用作判决依据。
  3. 同义词替换 ≠ humanize：humanize 的 9 个杠杆（perplexity 注入、burstiness 强制、hedge surgery、specificity 插入、voice/register、transition 词剥离、标点规整、RLHF 声口剥离、结构扁平化）是基于 50+ 篇 2024-2026 同行评议检测文献，不要被误读为"换几个词"。
  4. 新架构会让单一杠杆失效：2025 年关于扩散型 LLM（LLaDA, arXiv 2502.09992）的研究显示，自回归训练的检测器在 burstiness 上对扩散模型产生高 false-negative，单独看 burstiness 已经不可靠。humanize 用 9 杠杆联动规避这个坑，但若你只挑一两个杠杆用，仍可能翻车。
  5. 不同 LLM 留下不同指纹：Tandfonline 2025 年的 stylometric 研究表明 ChatGPT 与 DeepSeek 的 POS 分布显著不同 — ChatGPT 偏形容词/介词/助动词/从属连词，DeepSeek 偏副词/并列连词/名词/助词/代词。humanize 规则通用，跨模型适用，但单杠杆对特定模型可能有偏差。
  6. emoji / em dash 也有讲究：仓库内默认禁用 em dash 作"戏剧插入"用法（中句停顿靠句号和节奏），人类 baseline 的 em dash 频次是 AI 的 1/3 到 1/5。
  7. 协议：MIT，可商用、可二次发布，但注意 ai-check 的 9 类信号分类借鉴多项独立研究，引用时按仓库 References 段注明。

与同类对比

  • blader/humanizer（同类最流行）：单 SKILL.md、零研究溯源、规则更直觉化，社区大但学术严谨度低于本仓。
  • aiscientists-dev/academic-humanizer、ilyautov/humanizer-ru、op7418/humanizer-zh、anasu1/text-humanizer、redbaronyyyyy-eng/humanizer-zh-academic：针对特定语言 / 学术场景的本地化变体，比本仓更专但缺少跨语言通用规则。
  • NulightJens/humanizer-stack：双通道流水线（humanize + detector-in-the-loop），比本仓更激进 — 直接拉 ZeroGPT/GPTZero 等实时打分反馈迭代。
  • ssamba1/untell：detector-in-the-loop CLI，宣称 ZeroGPT 100%→0% 实测，但绑定具体 detector API；隐私和费率上有代价。
  • devswha/patina：KO/EN/ZH/JA 四语种支持，多语种覆盖广但检测面窄。
  • forint573/human-copywrite：聚焦营销长文（landing / sales / case study），强调品牌声口保留，营销场景专用。
  • badrusiddique/naturalize：基于 Wikipedia "Signs of AI Writing"，always-on 默认 + 内置 self-audit，社区取向。

harshaneel/humanize 的差异点：(a) 50+ 同行评议来源 + 每条规则可溯源到具体研究；(b) 9 杠杆联动而非单点替换；(c) ai-check 配套审计而非只改不检；(d) MIT + 零运行时 + 跨宿主；(e) 公开承认"学习型分类器天花板"而非画大饼。

一句话推荐结论

如果你要在 Claude Code 或 Codex CLI 里给所有 AI 出稿做"去机器味 + 自审打分"的双件套，这是研究溯源最完整、跨 agent 最广、MIT 协议最宽松的开源选择；但若你需要过 GPTZero / Pangram 这类学习型分类器，请把它当第一道粗洗，再叠 NulightJens/humanizer-stack 或 ssamba1/untell 这类 detector-in-the-loop 流水线。

来源：

  • GitHub README（harshaneel/humanize）：https://github.com/harshaneel/humanize（安装、用法、benchmark、9 杠杆、参考文献全本）。
  • GitHub Topics 页面（text-humanizer / humanizer / humanize-text）：https://github.com/topics/text-humanizer — 同类横向对比。
  • arXiv 2501.12070（Binoculars, Hans et al., ICML 2024）：用于 README 中 Binoculars 外部交叉验证。
  • arXiv 2502.09992（LLaDA，扩散 LLM）：README 引用以说明单一 burstiness 杠杆失效场景。
  • arXiv 2511.21744（NEULIF）：README 引用以给出 stylometric 分类器的 95-97% 数字。

不确定处：

  • install.sh 子命令参数（claude / codex / chatgpt / all / --copy）按 README 描述整理，未在本机 bash install.sh --help 二次校验（仓库为纯 HTML 静态资源，不适合沙箱内执行）。
  • README 中 benchmark 的 25 类文风与具体样本由仓库作者选定，未独立复现；Binoculars 分数用 TinyLlama-1.1B 替代替代 paper 中的 Falcon-7B，README 已显式说明，数字与原论文条件不完全等价。
  • 与同类项目（blader/humanizer、NulightJens/humanizer-stack、ssamba1/untell 等）的对比表只基于公开仓库描述与 GitHub Topics 列表，未跑实测头对头 benchmark。