发布日期：2026-09-10 | 标签：AI 写作、Agent Skills、Claude Code、Codex

humanizer 是开发者 blader 于 2026 年 1 月发布的开源 Agent Skill，用一份 Markdown 规则文件让 Claude Code、Codex 等编程 Agent 改写"一眼 AI"的文字，同时保证不改动原文事实。2026 年 9 月 6 日发布的 v3.0.0 把 35 条识别规则合并为 25 条，本周新增约 5,900 Star，总量突破 4.6 万，与同类项目 no-ai-slop（7,800 Star）一起冲上 GitHub Python 周榜前列。两者的规则都源自维基百科 WikiProject AI Cleanup 维护的《Signs of AI writing》指南，核心判断是：模型默认写出"适合最广读者"的句子，而人写给一个读者、一个主题，所有 AI 味都是这种"默认选择"的痕迹。本文拆解 25 条模式的五大类、两款工具的安装与用法差异、语气匹配技巧以及适用边界，并说明为什么不该把 AI 检测器分数当作判断依据。

humanizer 是什么

humanizer 是一个以 Markdown 文件形式发布的 Agent Skill，作用是把 AI 生成的文字改写成像人写的，且不改变原意。项目由 GitHub 用户 blader 创建于 2026 年 1 月，MIT 协议开源，截至 2026 年 9 月 10 日有 46,014 Star、3,770 Fork，最新版本 v3.0.0 发布于 9 月 6 日。

它的工作方式与传统"AI 文本改写器"不同：

  • 不是独立软件，只是一份 SKILL.md，任何支持 Skills 的 Agent（Claude Code、Codex、Claude Desktop 等）都能加载

  • 改写前先按强度顺序标出全部"AI 味"位置，再重写、自查、出终稿，三步过程对用户可见

  • 明确禁止编造：人名、数字、日期、引文等事实只能来自原文或作者补充，缺信息时向用户提问而不是自己补

项目 README 引用了维基百科对成因的解释：大语言模型用统计方法猜下一个词，结果趋向"对最多情况都成立"的表达。humanizer 把所有识别规则归结为一句话，即每个 AI 味都是模型在替最广泛读者做选择时留下的痕迹。

什么是"AI 味"：25 条模式的五个类别

humanizer v3.0.0 把 AI 写作痕迹归为 25 条模式、五个类别，按出现频率和判定强度排序，前 5 条只要出现一次就值得改。

类别

编号

典型表现

处理方式

A. 摆架子而不陈述

1-5

"不是 X，而是 Y"；每段结尾一句金句；"让我们深入了解一下"

直接说结论，删掉铺垫和无人提出的反对意见

B. 按规律押节奏

6-11

凡列举必三项；连续句子同一开头；破折号当万能连接词

按含义需要的数量列举，改用句号和逗号

C. 拔高与借权威

12-18

delve、testament、landscape 等高频词；"标志着关键时刻"；"专家认为"

用平实词，保留事实删掉意义，写出具体来源

D. 按规律排版

19-21

加粗当装饰；标题加表情符号；弯引号

去掉装饰性加粗，标题用句首大写

E. 聊天残留

22-25

"好问题！""希望对你有帮助"；"据现有资料显示，似乎……"；标题在首句重复

删掉对话包装和免责声明

其中第 12 条是唯一的词表，收录约 30 个模型高频词，包括 actually、additionally、crucial、delve、enhance、fostering、pivotal、robust（比喻义）、showcase、tapestry、testament、underscore、vibrant。SKILL.md 强调，词表之外的正式用词单独出现不算问题。

标注 weak alone 的模式（第 8、9、10、11、21 条）只在同一段落出现多条时才计入，因为一个细心的作者完全可能有意使用其中任何一种。

humanizer 与 no-ai-slop 有什么区别

两者都是去 AI 味的 Skill，但 humanizer 面向"维基百科式"中性文本的系统修订，no-ai-slop 面向个人创作者的社交媒体和博客写作。

维度

humanizer

no-ai-slop

作者 / 发布

blader，2026 年 1 月

Peter Yang，2026 年 7 月

Star（2026-09-10）

46,014

7,869

规则数

25 条，五类分级

20 余条，含 10 条重点

规则来源

维基百科《Signs of AI writing》，随其更新同步

作者自行整理的社媒常见套话

核心承诺

不编造事实，缺信息就问

保留作者个人语气，列出所改内容

特色功能

语气匹配（提供 2-3 段自己的文字做样本）

检测模式（只标出套话，不判断是否 AI 写）；讽刺模式（反向生成最油的 AI 文）

安装渠道

Skills CLI、Claude Code 插件市场、Claude Desktop ZIP

Skills CLI、ChatGPT 插件、Codex

附加机制

校验器限制 SKILL.md 不超 400 行

eval.md 定义自检项

选择建议：处理技术文档、产品说明、百科条目等需要中性客观的内容，humanizer 的分级规则和"不编造"约束更合适；写个人博客、公众号、社交帖子，需要保留口吻和幽默感，no-ai-slop 的"保留语气"设计更贴合。两者都是 Markdown 规则，可以同时安装、分场景调用。

如何安装和使用 humanizer

humanizer 通过 Skills CLI 一条命令安装，安装后在 Agent 中以 /humanizer 触发。

步骤 1：安装

# 全局安装，所有项目可用
npx skills add blader/humanizer --global

# 只装到当前项目：去掉 --global
# 指定接收的 Agent：加 --agent <名称> 或 --agent '*'

Claude Code 2.1.142 及以上版本也可以走插件市场：

/plugin marketplace add blader/humanizer
/plugin install humanizer@humanizer

插件方式的触发词是 /humanizer:humanizer。Claude Desktop 用户可从 Release 页下载 humanizer-skill.zip 作为 Skill 上传。

步骤 2：直接改写一段文字

/humanizer

[粘贴要改写的文字]

也可以用自然语言："Please humanize this text: ..."。输出分三部分：第一版改写、对残留 AI 味的简短点评、最终版本。

步骤 3：改写整个文件

Humanize the prose in docs/launch-post.md

指向文件时，humanizer 只改散文部分，代码块、数据、frontmatter 和链接地址保持不动。

步骤 4：让改写像你自己写的

/humanizer

Here's a sample of my writing for voice matching:
[粘贴 2-3 段自己写的文字]

Now humanize this text:
[粘贴要改写的 AI 文本]

humanizer 会跟随样本的节奏、用词、标点习惯，包括你惯用的破折号。

no-ai-slop 的对应命令

npx skills add petergyang/no-ai-slop --skill no-ai-slop --global --yes
/no-ai-slop (你的文字)                 # 改写并列出改动
/no-ai-slop is this slop? (你的文字)   # 只检测、只引用问题句

去 AI 味适合哪些场景

去 AI 味 Skill 适合"AI 起草、人来署名"的一切文字，前提是文字的事实由作者负责。

  • 技术博客与文档：AI 辅助生成的 README、发布说明、教程常见"让我们深入了解"式开头和每节金句收尾，humanizer 的 A 类和 E 类规则针对性最强。用国内多模型平台起草时同样适用，例如在七牛云 AI 大模型广场里对比几款模型生成的同一段初稿后，再交给 humanizer 统一去味，比逐段人工修改省时间。

  • 公众号、知乎、小红书内容：中文平台读者对"不是 X，而是 Y"、三连排比、结尾升华同样敏感，no-ai-slop 的检测模式可以先给稿子"验毒"再决定改多少。

  • 维基百科及百科类编辑：humanizer 规则与 WikiProject AI Cleanup 指南同步，v3.0.0 已按最新指南删掉"同义词循环"（维基百科现认定这是人类写作习惯），新增"含糊关联"模式。

  • 求职信、申请文书、邮件：这类文字最怕"experts believe""a testament to"式的空话，C 类 7 条规则覆盖大部分。

  • 多语言内容：两款工具的规则以英文写成，但模式本身语言无关。中文文本可以直接喂入，模型会按同样逻辑识别"标志着""赋能""生态""不可或缺"等对应表达，效果需要人工复核。

为什么不能依赖 AI 检测器

维基百科指南明确不建议把 GPTZero、Pangram 等检测工具的分数当作判定依据，这也是 humanizer v3.0.0 主动删掉 ai-detection 关键词的原因。

指南给出的理由有三点：

  1. 检测工具优于随机猜测，但错误率不可忽视，改写、标记符号、空格变化或训练中未见过的新模型都会干扰结果

  2. 人类判断同样有限：一项 2025 年研究显示普通人辨别大模型文本的能力与随机猜测无异，重度用户约 90% 准确率，即每标 10 篇误伤 1 篇

  3. 人类口语和书写正在被大模型影响而趋同，检测难度持续上升

因此这两款 Skill 的定位都不是"骗过检测器"，而是把文字改得对读者更有用。no-ai-slop 的检测模式只引用具体套话，不判断是否 AI 所写；humanizer 的每条规则都要求"保留的每句话必须给读者带来新信息"。

常见问题

humanizer 会改变原文意思吗？ 不会。SKILL.md 规定所有事实性细节（名字、数字、日期、引文、引用）必须来自原文或作者补充。如果一句话需要一个原文没有的细节，humanizer 会向用户提问而不是自己编。README 里的里斯本游记示例特意注明了作者补充的旅行时间、酒店位置等信息，说明改写依赖这些输入。

humanizer 支持中文吗？ 规则文件是英文，但识别逻辑基于写作模式而非词汇表（第 12 条词表除外）。中文文本可直接使用，模型会识别对应的中文套话，建议改完人工通读一遍。

为什么 v3.0.0 从 35 条减到 25 条？ 发布说明称是"合并而无删减"。重复的破折号规则合并为一条，五个分散的工作流合并为一节，每条误报防护并入对应模式并标注 weak alone。只有两条被真正删除：虚假范围和同义词循环，因为维基百科最新指南把后者归为人类写作习惯。

humanizer 和 no-ai-slop 能同时装吗？ 可以。两者都是独立 Markdown Skill，触发词不同（/humanizer 与 /no-ai-slop），互不干扰。常见做法是先用 no-ai-slop 的检测模式看问题密度，再决定用哪个改写。

在 Codex 或 ChatGPT 里能用吗？ no-ai-slop 提供 .codex-plugin/plugin.json 元数据，可作为 ChatGPT 和 Codex 插件安装。humanizer 的官方安装路径是 Skills CLI 和 Claude Code 插件市场，Skills CLI 加 --agent '*' 参数可以分发到所有已支持 Skills 的 Agent。

结语

humanizer 和 no-ai-slop 在 2026 年 9 月同时登上 GitHub 周榜，反映出 AI 写作已从"能不能生成"转向"生成的东西能不能署名发出"。两者的规则均可追溯到维基百科 WikiProject AI Cleanup 维护的公开指南，数据以 2026 年 9 月 10 日 GitHub 仓库信息为准，规则细节以各自 SKILL.md 最新版本为准。

参考资料