humanizer

这是什么？适合谁？

humanizer（作者 blader）是一个「把 AI 腔调的文本改写得像真人写的」Skill：不改事实、只改表达。它的特殊之处在于整个 Skill 就是一份纯 Markdown 的 SKILL.md——不绑定任何特定平台，凡是支持 Agent Skills 规范的客户端（Claude Code、Codex、Cursor、Grok Build、Antigravity 等）装一次即可全局生效。2026-09-19 核验：GitHub 49,911★ / 4,030 fork，MIT，skills.sh 安装榜长期前三。

它的工作原理不是简单「降 AI 味」的模糊指令，而是内置了一套按强度与频率编号的 25 种 AI 写作特征模式（参考了 Wikipedia「Signs of AI writing」的整理），逐条标记后重写：先找出所有「舞台式陈述」（用句子宣布重要性而不是陈述事实）、按规则套用的节奏与格式、被包装成关键发现的普通事实等，按最强特征优先修改，改完还会对草稿做二次自查，再输出终稿。事实类信息（人名、数字、日期、引文、引用）只能来自原文或作者，缺了会追问而不是编造。

适合人群：

• 内容创作者 / 公众号作者：把 AI 起草的稿子改出个人手感
• 技术写作者：清理文档里 AI 生成的套话与结构化痕迹
• 学术 / 商务写作者：让措辞自然但不损失事实精度
• 多 Agent 工作流用户：一个 Skill 覆盖所有装了 Agent Skills 规范的客户端

不适合谁：想要「绕过 AI 检测器」的滥用场景——Humanizer 官方定位是提升可读性，不是对抗检测。

准备工作

• 任一支持 Agent Skills 的客户端：Claude Code 2.1.142+、Codex、Cursor 等
• 账号要求：无需注册任何服务
• 付费要求：Skill 本身免费开源（MIT）；改写消耗的是你所用客户端的模型额度
• 时间预算：安装 1 分钟，单次改写几秒到几十秒（取决于文本长度）

3 步快速上手

第一步：安装 Skill

npx skills add blader/humanizer --global

去掉 --global 则只装进当前项目；加 --agent <name> 或 --agent '*' 指定接收该 Skill 的 agent，装完重载 skills。

Claude Code 2.1.142+ 也可以走插件市场：

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

第二步：改写一段文本

/humanizer

[paste your text here]

或用自然语言：Please humanize this text: [你的文本]。

首个任务：把一段你用 AI 生成的 200 字介绍扔给它，观察输出——Humanizer 会展示它的工作过程：第一版重写、对仍然「像 AI」之处的简短批评、以及最终版本。

第三步：风格匹配与文件改写

想让改写更像你自己，附上写作样本：

/humanizer

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

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

指向文件时它会只改正文散文，保留代码、数据、frontmatter 与链接目标不动：Humanize the prose in docs/launch-post.md。

常见踩坑

1. 现象：装完不生效。 原因：安装后未重载客户端的 skills。 解决：重载对应 agent 的 skills；确认安装目标是当前项目还是 --global，路径别搞混。

2. 现象：Claude Code 里 /humanizer 无响应，但 /humanizer:humanizer 可以。 原因：插件版与 Skill 版的命令名不同——插件版应答名是 /humanizer:humanizer。 解决：按安装方式使用对应命令；两种方式装其一即可，不必都装。

3. 现象：改写后事实细节变了。 原因：Humanizer 的设计约束是「不编造」，名字、数字、日期、引文只能来自原文；若原文本本身有占位符（如「XXX 公司」），改写不会替你补全。 解决：改写前把事实信息补齐；缺信息时它会追问而不是猜。

4. 现象：改写力度不够，仍有 AI 腔。 原因：25 种模式中标注 weak alone 的特征单次出现不改，需要多条弱特征聚集在同一段才触发——这是为避免误伤刻意设计的保守策略。 解决：附上你的写作样本触发 voice matching；或对残留段落单独再跑一次并指明不满意的具体句子。

5. 现象：技术文档被改得过于口语化。 原因：未声明文本类型。 解决：Humanizer 对技术/参考类散文会保持中性平实，明确说明这是技术文档即可。

权限、安全与限制

• 内容面：改写只发生在你所用客户端的模型调用内，Skill 本身无网络服务、无账号体系。
• 事实安全：官方文档明确「不编造」原则——事实细节缺失时追问而非生成。
• 成本：Skill 免费；Token 消耗取决于文本长度与所选模型。
• 边界：不适用于需要保留原句逐字结构的场景（如法律引文），改写会重组句式。

小技巧

1. 先贴一小段样本做 voice matching，再给长文，个人风格还原度明显更高。
2. 对整篇文档让它「只改 prose、别动代码和 frontmatter」，可安全处理带配置的 Markdown。
3. 它会输出「初稿 + 自我批评 + 终稿」三段，读中间那段批评能快速学会识别自己文本里的 AI 特征。
4. 多客户端用户用 --agent '*' 一次分发给所有 agent，避免逐个安装。
5. 与「先用 AI 起草再人工把关」的流程组合：AI 出初稿 → Humanizer 去味 → 人工核事实，比纯手写快且质量稳。

进阶学习方向

• 25 模式体系：README 中按强度编号的完整模式表（A 组「舞台式陈述」等），可直接当作人工编辑 AI 文稿时的检查清单使用。
• 与其他写作 Skill 组合：站内已收录的 oh-story-claudecode（中文网文流程）自带「去 AI 味」环节，中文长篇创作可直接用那套；英文通用文稿用 Humanizer。
• Skill 分发生态：作为 skills.sh 榜单前三的项目，其「纯 Markdown、零运行时」的设计是编写跨客户端 Skill 的参考范本。

参考链接

• 官方仓库
• skills.sh 安装页
• Wikipedia: Signs of AI writing（方法论参考）

最后更新：2026-09-19 · 作者：MagicNetWorld · 基于公开资料整理，关键数据经 GitHub API 独立实测核验，AI 辅助生成