humanizer：先把 AI 写作痕迹叫出名字

很多人说“去 AI 味”，说到最后其实只有一个要求：自然一点。

这个要求太宽了。AI 听完以后，通常会把句子改短一点，把连接词删掉一点，再补一点口语感。读起来确实没那么正式，但不一定更像人写。很多时候，它只是从一种模板，换成另一种模板。

我想拆 humanizer，是因为它没有停在“自然一点”这四个字上。它先把 AI 写作痕迹拆成具体类型，再让 AI 按类型检查、改写、复查。

这篇不把它当检测器讲，也不把它当 Python 工具讲。它是一个标准 Skill，本质上是一份写给 AI 的审稿规则。

1. 先把来源说清楚

仓库在这里：

https://github.com/blader/humanizer

核心文件是：

SKILL.md

仓库里还有 README.md、AGENTS.md 和 Claude Code plugin 相关配置。真正让这个 Skill 工作的，是 SKILL.md 里的那套说明。

AGENTS.md 里也写得很明白：这个仓库是一个 portable agent skill，运行时产物就是 SKILL.md。没有 build step，也没有代码要跑。

这点要先说清楚，不然很容易误会。

它的用法更接近“把一套审稿规则交给 AI”，让 AI 按规则做编辑。

2. 它的实现很朴素

SKILL.md 开头有一段 frontmatter。

里面写了几件事：

name: humanizer
version: 2.8.2
license: MIT
compatibility: any-agent
allowed-tools: Read / Write / Edit / Grep / Glob / AskUserQuestion

这些信息的作用，是告诉不同的 agent：这个 Skill 叫什么、当前版本是多少、允许用哪些工具。

真正的规则在 frontmatter 下面。

它先给 AI 定了一个任务顺序：

1. 识别 AI patterns
2. 重写，但不要简单删除
3. 保留原意
4. 匹配原来的 voice

这个顺序比“帮我润色一下”具体很多。

它要求 AI 先审稿，再动手改。先看文本里命中了哪些模式，再决定怎么改。改的时候还要覆盖原文的信息，不能为了去味把内容删薄。

长文尤其需要这条边界。很多去 AI 味工具会把文章改得很干净，顺手也把作者原来的停顿、犹豫和细节删掉。humanizer 至少先给了一个边界：rewrite, don’t delete。

3. 它先校准作者声音

humanizer 里有一块叫 Voice Calibration。

如果用户给了自己的写作样本，它会先读样本，再看几个东西：

• 句子是短促，还是偏长？
• 用词是随意，还是正式？
• 段落通常怎么开头？
• 标点有什么习惯？
• 有没有固定口头禅？
• 转场是靠连接词，还是直接进入下一点？

这块很实用。

因为去 AI 味最怕把所有人都改成同一种“自然”。一个技术作者的自然，和一个旅行博主的自然，不是一回事。公众号文章也一样，有的人可以多一点闲谈，有的人就适合直给。

所以 humanizer 不是只删 AI 词，它还试图回答一个更细的问题：这篇文本应该像谁写？

如果没有样本，它才退回默认写法：自然、节奏有变化、适当有观点。

4. 它把问题分成 33 类

humanizer 最重的部分，是那 33 个 AI 写作模式。

README 里把它们分成 5 组。这样看会清楚很多：

内容模式：6 类
语言和语法模式：7 类
样式模式：14 类
聊天机器人残留：3 类
填充和犹豫：3 类

具体摊开，大概是这张表：

分组	里面主要抓什么
内容模式	意义抬高、媒体背书、-ing 空分析、广告腔、模糊归因、套路化挑战段
语言和语法模式	AI 高频词、绕开 is/are、否定式排比、三件套、同义词轮换、假范围、被动语态
样式模式	em dash、加粗滥用、标题大小写、emoji、弯引号、短横线词组、金句姿态、空转场、碎句戏剧感
聊天机器人残留	I hope this helps、Would you like、Great question 这类对话口吻
填充和犹豫	In order to、could potentially possibly、泛泛积极结尾

第一组是内容层面的假抬高。

比如 significance inflation。常见写法是：

stands as
serves as
marks a pivotal moment
broader landscape

问题出在它会把普通事实抬成“重要节点”“广阔图景”。很多 AI 文本看起来很有气势，就是这么来的。

第二组是语言和语法层面的惯性。

比如 not only...but...、rule of three、同义词轮换、被动语态堆叠。AI 很爱把内容写得对称、完整、顺滑，但这种顺滑读多了会假。

第三组是样式层面的痕迹。

比如滥用加粗、标题 Title Case、emoji、inline-header list，还有 em dash。humanizer 对 em dash 很狠，要求最终稿里不能有 em dash 或 en dash，要改成句号、逗号、冒号、括号，或者重写句子。

第四组是聊天机器人残留。

比如：

I hope this helps
Would you like...
Let me know if...
Great question!

这些话本来是对话里的客套，放进文章正文里就很刺眼。

第五组是收尾和姿态。

比如 generic positive conclusions、persuasive authority tropes、signposting announcements、manufactured punchlines。简单说，就是文章最后非要积极一下，或者每段都摆出“我看穿本质了”的姿态。

这些分类的价值在于：AI 味不再是一团感觉，而是一张问题表。

5. 它怎么改：不是一遍出稿

humanizer 的 Process and Output 也值得看。

它要求 AI 先读输入，标出上面那些模式。然后写一版 draft rewrite。

写完第一版后，还要问自己一句：

What makes the below so obviously AI generated?

也就是：下面这版为什么还是一眼像 AI？

这一步挺关键。

很多改写工具的问题，是第一版改完就交付。humanizer 则要求再做一次残留味检查，看是否还有句式太齐、语气太像宣传稿、结尾太像金句、em dash 没清干净。

最后才给 final rewrite。

所以它的工作流不是：

原文 -> 改写

而是：

原文 -> 标问题 -> 初改 -> 反问残留 AI 味 -> 终稿

这一步让它比普通提示词稳一点。

6. 它还写了误杀边界

我比较喜欢 humanizer 的一块，是 Detection Guidance。

它提醒 AI：不要看到一个特征就乱判。

比如完美语法不等于 AI。正式词汇不等于 AI。一个 em dash 也不等于 AI。很多职业作者本来就写得很干净，很多编辑器也会自动替换引号和标点。

它还列了一些应该保留的“人写痕迹”：

• 具体又古怪的细节。
• 没有完全解决的矛盾感。
• 作者能解释的第一人称选择。
• 长短句自然变化。
• 插入语、自我修正和真实停顿。

去 AI 味不能把文章磨平。真正危险的是，AI 把所有“不整齐”的地方都当成毛病，最后改出来一篇干净但没人的稿子。

humanizer 至少知道要保留这些不那么完美的地方。

7. 它对中文有什么限制

humanizer 的基础语境还是英文。

它抓 em dash、not only but also、rule of three、-ing 分析、Title Case 这些英文痕迹很有用。放到中文里，就不能照搬。

这里可以顺手看一下中文版 Humanizer-zh。

仓库在这里：

https://github.com/op7418/Humanizer-zh

它的 SKILL.md 里写得很清楚：核心内容翻译自 blader/humanizer，实用工具部分参考了 hardikpandya/stop-slop。

所以它做的不是重新发明一套中文规则，而是先把英文 humanizer 的问题分类翻到中文里，再加上中文例子和一些更像审稿清单的规则。

它的任务顺序也差不多：

1. 识别 AI 模式
2. 重写问题片段
3. 保留含义
4. 维持语调
5. 注入真实个性

和英文版相比，Humanizer-zh 目前整理的是 24 种模式，分成 4 组：

分组	数量	例子
内容模式	6	过度强调意义、广告腔、模糊归因
语言和语法模式	6	AI 高频词、否定式排比、三段式法则
风格模式	6	破折号、粗体、emoji、弯引号
交流模式和填充词	6	协作交流痕迹、知识截止日期、谄媚语气、填充短语

比如英文版会抓 serves as、vibrant、not only...but...，中文版就对应成：

作为/充当
充满活力的
不仅……而且……
行业报告显示
此外
至关重要

这一步对中文用户有用。你不用先理解英文 AI 写作批评里那些术语，直接看中文例子就能知道它在抓什么。

但它也有一个边界：它更像“英文 humanizer 的中文适配版”，还不是专门为中文公众号写作定制的规则。

中文更常见的是这些东西：

在 AI 浪潮下
真正重要的不是……而是……
这不仅是工具，更是一种能力
形成闭环
持续赋能

还有一种近几年很常见：短句堆叠，每一行都像在压一个判断。

所以我不会把 humanizer 或 Humanizer-zh 当中文最终答案。它们更适合当第一层：帮你学会给问题命名。

中文改稿，还要加中文自己的场景规则。比如公众号开头要快一点进入具体卡点，少讲时代背景；技术解释要保留术语，不要为了口语化把实现讲错；长文改写时还要留住节奏，不能把所有停顿都删掉。

8. 对写自己的 Skill 有什么启发

humanizer 最该学的地方，是它把“审稿口味”写成了可执行规则。

如果你要写一个公众号风格 Skill，不要只写：

写得自然一点。
不要有 AI 味。

这类话太虚，AI 只能猜。

可以学 humanizer 的写法，把规则拆开：

• 先保护事实、术语、文件名和引用。
• 再列出常见问题，比如空背景、机械转折、价值拔高、短句堆叠。
• 每一类给 Before 和 After。
• 允许普通句子存在，不要求每段都像结论。
• 最后加一轮残留味自查。

这样写出来的 Skill，才有机会稳定复用。

9. 我的判断

humanizer 不是万能去味器。

它的强项，是把英文 AI 写作痕迹整理成一套清楚的审稿流程。它没有脚本，没有模型，也没有自动检测接口。它靠的是一份很细的 SKILL.md：先命名问题，再给例子，再规定改写流程，最后提醒 AI 别误杀人写的痕迹。

对中文公众号作者来说，它最适合作为“问题命名课”。先学会看见问题，再谈改写。

只让 AI “写得自然一点”，最后大概率还是模板。把问题说清楚，AI 才有机会真的帮你改。