Humanizer：给 AI 写作「去 AI 味」的瑞士军刀

一、它解决的是什么问题？

当你在 Claude Code、OpenCode 中写完一段文字，让 AI 帮你润色或翻译之后，有没有觉得总觉得哪里不对——读起来四平八稳，挑不出毛病，但就是少了那股"人味"？

这就是"AI 味"。它有几个典型特征：句子长度高度一致、用词偏正式、喜欢用"symbolizing""underscoring"这类大词、动不动就来一句"这一技术标志着XX领域的重要里程碑"。读者往往说不出哪里不对，但就是觉得这段文字不像人写的。

Humanizer 正是为解决这个问题而生。它是一个专门给 Claude Code 和 OpenCode 使用的技能（skill），运行机制就是一份 Markdown 文件，内置了一套完整的"AI 写作痕迹检测与修复指南"，涵盖 29 种常见 AI 写作模式，并附有修复前后的对比示例。

简单来说：它的"运行时"就是 LLM 本身——你把有 AI 味的文字丢给它，它调用 Claude（或你的本地模型）来执行这份指南里的检测和改写逻辑，最终输出"人类写的"文字。

二、项目背景与作者

Humanizer 的作者是 blader，GitHub 账号下仅有这一个公开仓库。这个项目没有复杂的架构，没有 CI/CD，没有版本迭代的 Release Notes——它本质上是一个"知识密集型"的 Markdown 文档，但偏偏靠 29 种模式 + 双轮改写机制，拿下了 20000+ stars。

这个数字本身就很说明问题：LLM 编程工具（Claude Code、OpenCode）的生态里，"让 AI 输出更像人"是一个真实、高频的需求。这类工具写出来的代码注释、README、API 文档天然带着上文说的"AI 味"，社区急需一个"润色工具"。

Humanizer 的方法论核心来自 Wikipedia 的 "Signs of AI writing" 指南——这是一个由 WikiProject AI Cleanup 维护的社区页面，汇集了 Wikipedia 编辑者们在数千篇 AI 生成内容中观察到的写作规律。作者将这份指南产品化，变成了 Claude Code 可直接调用的 skill。

三、核心功能：29 种 AI 写作模式

Humanizer 的技术核心是 SKILL.md 中的 29 种 AI 写作模式检测表，分为以下几大类：

内容层面：显著性夸大（如"标志着里程碑""具有深远意义"）、蹭知名度（硬扯 NYT/BBC 等媒体背书）、表语-ing 分析（symbolizing、reflecting、showcasing 套话）、营销语言（"令人惊叹的""叹为观止的"）、模糊归因（"专家们认为""研究表明"但不说谁）等。

修辞层面：破折号滥用、Rule of Three 滥用（强行凑三个并列项）、AI 偏好的词汇（"however""moreover""therefore"等高频学术词）、被动语态过度使用、负面平行结构等。

风格层面：无灵魂表达（每句长度一致、无观点只有中性陈述）、无第一人称、无幽默感、无不确定性表达。

四、双轮改写机制

这是 Humanizer 区别于普通"润色工具"的关键。它不仅检测和修复 AI 模式，还有第二轮"反 AI 审计"：

• 第一轮：按 29 种模式逐一扫描文本，替换/改写有问题的表达。
• 第二轮（Final Audit Pass）：专门问自己"这段文字哪里还明显是 AI 写的？"——简短回答剩余的 AI 特征，然后基于答案再改一遍。

这个设计解决了一个常见问题：单轮润色往往只能处理最明显的 AI 模式，细节处的"AI 味"会在定稿时依然残留。双轮机制让最终输出的文字在多个 AI 检测器面前都更安全。

五、声纹校准（Voice Calibration）

Humanizer 还支持一个进阶功能：声纹校准。

如果你在调用时提供一段自己的写作样本（2-3 段你自己的文字），skill 会先分析你的句式节奏、用词习惯、段落开头方式、标点偏好、常用短语，然后将这些特征"迁移"到改写中，而不是套用通用的"自然"输出。

这解决了一个痛点：单纯的"去 AI 味"可能导致"通用人类味"——每个用 Humanizer 润色过的文字风格趋同，声纹校准让输出保持个人特色。

六、部署与使用

部署难度：极简（1分钟）

Humanizer 没有 Dockerfile、没有 docker-compose、不需要 GPU、不需要任何服务器资源。它本质上是一个 Markdown 文件，使用方式只有一种：

# Claude Code 用户
mkdir -p ~/.claude/skills
git clone https://github.com/blader/humanizer.git ~/.claude/skills/humanizer

# OpenCode 用户
mkdir -p ~/.config/opencode/skills
git clone https://github.com/blader/humanizer.git ~/.config/opencode/skills/humanizer

然后在 Claude Code 或 OpenCode 中直接调用：

/humanizer

[粘贴你要润色的文字]

无需 API Key、无需网络请求（如果模型已在本地运行）、无服务器——完全本地化的 LLM 辅助写作工具。

七、局限与争议

Humanizer 的本质是一个 Prompt 工程产物，它的局限性也很明显：

1. 依赖模型能力：如果底层 LLM 本身能力有限（如早期的 GPT-3.5），按照指南改写后的文字依然可能生硬，输出质量高度依赖模型的推理能力。

2. 无法处理结构性问题：Humanizer 擅长处理词汇和句式层面的 AI 模式，但如果原文逻辑结构本身有问题（如论点跳跃、论证不充分），它只能在表面层做修补，无法重构逻辑。

3. 风格可能趋同：不加声纹校准时，所有用户输出的文字会趋向"通用自然风格"，反而可能失去个人声音。

4. "道高一尺"的博弈：随着 AI 检测器越来越精准，Humanizer 的"去 AI 味"策略也在不断升级（当前版本 2.5.1），但这场猫鼠游戏没有终点。

5. 用途争议：Humanizer 的本质是"让 AI 文字更难被检测为 AI 生成"，这一特性可能被用于学术论文、新闻稿件等场景的 AI 辅助标注隐瞒，引发一定的伦理讨论。

八、行业意义与增长

Humanizer 在 Claude Code 生态中扮演了一个微妙角色：它不是让 AI 写更多内容，而是提升 AI 写作质量的下限。对于需要发布文档、博客、技术文章的开发者来说，这个工具填补了一个真实空白——不是"让 AI 帮我写"，而是"让 AI 帮我写得更好、更像人"。

20000+ stars 证明了这一需求的规模。它的增长曲线也反映了一个趋势：随着 LLM 编程工具普及，配套的"润色/优化"工具链正在成为生态中的重要一环。

技术规格一览

维度	信息
协议	MIT License
主语言	Markdown（SKILL.md 作为运行时）
依赖	Claude Code 或 OpenCode
最低资源	无（纯客户端）
最新版本	v2.5.1
兼容平台	Claude Code + OpenCode