它是什么
Humanizer 是一个 Agent Skill（智能体技能包），作用是把"读起来像 AI 写的"文本重写成更像真人书写的版本，同时不改变原文所表达的意思。它本身只是一份 Markdown 文件（SKILL.md），因此任何支持 skills 机制的智能体都可以加载它，不绑定特定模型或厂商。
要理解它为什么存在，需要回到大语言模型的工作方式。模型生成文字时，本质上是在预测"最可能出现的下一个词"，因此默认会挑选对最广泛读者、最广泛题材都安全的表达。这种"最大公约数"式的选择反复叠加，就形成了可识别的 AI 文风：强调多于信息、节奏由规则而非语感决定、普通事实被包装成关键转折、以及从对话上下文里遗留下来没删干净的客套话。Wikipedia 的《Signs of AI writing》把这类现象总结为"结果总是倾向统计上最可能、且适用于最多种情况的那个答案"。Humanizer 的策略不是把文字刻意改"糙"，而是把上述默认选择替换成更具体、更有指向性的表达——因为真人写作时，心里想的是一个读者和一个具体题材。
项目以 MIT 协议开源。
核心功能 / 内容清单
- AI 痕迹识别与排序：Humanizer 会先标出它在文本中找到的每一处"AI 味"（tells），并按明显程度从强到弱排列。这让使用者能看清问题集中在哪些句式或段落，而不是只得到一个笼统的"像 AI"的判断。
- 不受原结构约束的改写：起草改写稿时，它不把原文的句子顺序和段落划分当作必须保留的框架，允许合并、拆分、重排。这一点很关键，因为相当一部分 AI 痕迹恰恰藏在"三段式列举""每段一个总分结构"这类骨架里，只换词不换骨架是去不掉的。
- 双重校验：改写稿会同时对照两套基准——一是 AI 写作的典型模式（改完之后是否还有残留），二是原文的事实主张（改完之后是否还在说同一件事）。这一步是"改文风不改事实"的关键保障。
- 声音匹配（voice matching）：如果你提供 2–3 段自己写的样本，Humanizer 会模仿样本的节奏、用词习惯、标点偏好乃至刻意的个人怪癖——包括你习惯用破折号它就保留破折号。这解决的是"读起来像人写的"和"读起来像我写的"之间的差距。
- 文件级处理：可以直接给一个文件路径（例如
docs/launch-post.md），让它重写该文件中的正文，省去复制粘贴的步骤。 - 跨智能体可用：纯 Markdown 形态，通过 Skills CLI 安装后可分发给一个或多个 agent，不依赖插件运行时。
典型使用场景
场景一：对外内容发布前的终稿润色。 你用 AI 起草了一篇产品发布博客、周报或客户邮件，事实、数据、结论都核对无误，但通篇是"不仅仅是……更是……""在当今快速发展的环境下"这类模板句式，读起来没有具体的人在说话。做法是直接调用 /humanizer 并粘贴正文，或者写一句"Humanize the prose in docs/launch-post.md"让它处理文件。它先给出痕迹清单和改写版本，你逐条比对痕迹位置，确认原文的事实与主张没有被改动，再决定采用。适合把它放在"AI 起草 → 人工核对事实 → Humanizer 润色 → 人工终审"这条链路的倒数第二步。
场景二：需要保持个人声音的长期写作。 如果你有固定的专栏、博客或内容账号，风格一致性本身就是资产。这时先在技能里附上 2–3 段自己以往的文字作为声音样本，再给出待改写的 AI 文本，让改写稿贴近你本人的语感。样本的体裁最好和目标文本接近——用随笔样本去匹配技术文档，匹配效果会打折扣。
场景三：清理对话残留。 AI 生成后直接复制出来的文本，常常带着"希望这对你有帮助""如果你还有其他问题"之类的收尾，或是对上一轮对话的指代。这类内容不属于文章本身，Humanizer 会将其识别为"从聊天里遗留下来的文字"并处理掉。
适合谁用
- 内容创作者与编辑：把 AI 辅助产出的稿子过一遍，降低"一眼 AI"的观感，同时保留人工对事实的把关权。
- 市场、公关与运营：对外文案对语气的敏感度往往高于对信息密度的要求，模板腔会直接影响可信度。
- 开发者与技术写手：README、发布说明、技术博客草稿这类文本既需要准确，又容易被 AI 写得过于"营销化"。
- 日常用 AI 办公的人：邮件、汇报、总结等需要留有人味的场景。
- 不太适用的情况：法律、合规等要求措辞严格固定的文本；需要逐字保真的引用与合同条款；以及任何把"去 AI 痕迹"当成规避内容披露义务手段的用途——那不是这个工具的设计目的。
快速上手
通过 Skills CLI 安装（通用方式）：
```bash
npx skills add blader/humanizer --global
```
去掉 --global 则只安装在当前项目。可以加 --agent <name> 或 --agent '*' 来指定哪些 agent 接收该技能，安装后需要重新加载这些 agent 的 skills。技能响应 /humanizer。
Claude Code 2.1.142 及以上版本可用插件方式：
```text
/plugin marketplace add blader/humanizer
/plugin install humanizer@humanizer
```
插件方式响应的调用名是 /humanizer:humanizer。
Claude Desktop：把仓库下载为 ZIP，作为 skill 上传。手动安装：把 SKILL.md 复制到目标 agent 的 skill 目录。
使用有三种等价路径：直接调用 /humanizer 后粘贴文本；用自然语言请求（"Please humanize this text: …"）；或给出文件路径。想要声音匹配，就在待改写文本之前附上 2–3 段你自己的写作样本。以上安装与调用细节请以官方 README 为准，不同 agent 的 skills 目录约定可能有所差异。
注意事项
- 它是技能文件，不是独立应用。没有界面、没有服务端，必须由支持 skills 机制的宿主 agent 执行。宿主是否支持、如何加载，需要按该 agent 的文档确认。
- 改写必然带来措辞变化。尽管 Humanizer 会对照原文主张做校验，涉及数字、人名、时间、引用的部分仍应人工复核，作者对最终文本负全责。
- 两种安装方式的调用名不同：CLI 装出来是
/humanizer，插件装出来是/humanizer:humanizer。如果调用没反应，先确认自己用的是哪一种。 - 注意安装范围。
--global会作用于所有项目，在团队协作或共享环境中，先在项目级验证效果再决定是否全局安装。 - 声音匹配的效果取决于样本。样本太短、体裁差异太大，或本身也是 AI 生成的，匹配结果会明显打折。
- 不要用于规避披露义务。它的定位是风格润色工具，不是用来把 AI 生成内容伪装成人工原创以绕过平台规则或学术规范的。
- 协议：MIT，可自由使用、修改与再分发，保留原始版权声明即可。