humanizer：给AI写的东西抹掉机器痕迹的Agent技能

一段文本读起来像不像 AI 写的，很多时候不取决于内容对不对，而取决于一些很细的痕迹：破折号用得过于工整、三段式排比、每段开头都是同一类过渡词、结论永远落在「」。humanizer 要做的事情很单一——把这些痕迹找出来并抹掉，而不是把整段话重写一遍。它以一个 Agent 技能的形式存在，用 Python 实现，MIT 协议开源，仓库在 GitHub 上已经拿到 55329 颗星标。

它到底在改什么

humanizer 的定位是「移除文本中 AI 生成写作的迹象」。注意这个措辞——它不生成新内容，也不做改写润色，而是针对一批已知的 AI 写作模式做减法。仓库的主题标签覆盖 agent-skills、ai-humanizer、ai-writing、chatgpt、claude、claude-code、codex、cursor，说明它是按「代理技能」的形态设计的：你把它挂到自己的编码代理或写作代理上，代理在输出文本前先过一遍 humanizer 的规则。

这种形态带来的直接结果是，它不挑输入来源。无论文本最初是 ChatGPT 写的、Claude 写的，还是人写完又被 AI 润色过一遍，只要命中了那些模式，就会被处理。Hacker News 上围绕它的讨论有 15 条，其中一条标题提到它是「基于 50 篇研究论文」的静态 AI 文本去痕工具，另一条则把同样的思路搬到了芬兰语上，用 26 个模式来检测 AI 生成的芬兰语文本。这说明 humanizer 背后是一套可枚举、可复用的模式清单，而不是一个黑盒模型。

放进日常工作流是什么体验

把它当作代理技能使用的典型路径是这样：在 Claude Code 或 Cursor 里写东西，代理按你的要求产出初稿，humanizer 在交付前介入，逐条比对模式清单，把命中的地方改掉。整个过程不需要你手动复制文本到另一个网页工具里再粘回来，也就没有「换个平台处理」这一步的上下文丢失。

第二个场景是批量处理。因为它是 Python 写的、MIT 协议，可以嵌进脚本里跑。手上有一批 AI 生成的商品描述、邮件模板或文档草稿时，比起一个个丢进在线去痕网站，本地跑一遍更省事，也不必把内容上传到第三方服务。

第三个场景偏检查用途。写作者自己写完一段，不确定有没有沾上 AI 腔，可以让 humanizer 过一遍，看它标出哪些地方——这比笼统地问「这段像不像 AI 写的」更有反馈价值，因为你能看到具体是哪几个模式被触发了。

差异最实质的一点在于「改写」和「去痕」的区别。在线工具为了让你看不出 AI 痕迹，往往把整句换一种说法，结果是内容被稀释、术语被替换，专业文本经不起这么折腾。humanizer 走的是另一条路：内容不动，只动那些暴露来源的句式特征。对技术文档、合同条款、需要保持原意的文本来说，这个取舍更安全。

它不解决什么

humanizer 处理的是写作痕迹，不是事实错误，也不是逻辑漏洞。一段话如果观点本身就是错的，去掉 AI 腔之后依然是错的，只是读起来更像人写的。指望它来提升内容质量会失望。

它也不是检测工具。仓库定位是「移除迹象」，不是「判断这段是不是 AI 写的」。想拿它做 AI 内容鉴别，方向反了。另外，模式清单再全也有边界，新出现的 AI 写作习惯未必立刻被覆盖，效果取决于清单的更新频率。

语言方面，从社区讨论看，模式是针对特定语言整理的——芬兰语那条讨论就是单独做了 26 个模式。这意味着非英语文本的处理效果，取决于是否有人为这门语言整理过对应的模式，不能默认所有语言一视同仁。

谁该把它加进工具箱

已经在用 Claude Code、Cursor、Codex 这类代理写东西的人，加一个 humanizer 几乎没有额外成本，它本来就是为这种工作流设计的。需要批量处理 AI 文本、又不想把内容传到外部服务的人，本地 Python 脚本这条路更合适。反过来，只偶尔写一两段、且不介意手动粘贴的人，直接用一个网页工具就够了，为这个装一套代理技能属于过度配置。

55329 颗星标说明它在开发者社区里确实被大量采用，MIT 协议加 Python 实现则意味着你可以直接读源码、改模式清单，把它调成符合自己写作习惯的版本——这一点是闭源在线工具给不了的。

FAQ：常见问题

humanizer 和在线 AI 去痕工具有什么本质区别？

humanizer 是挂在代理上的技能，按模式清单对文本做减法，不改写内容本身，文本在本地处理不上传。在线工具多为改写或同义替换，需要把文本粘贴到对方服务器，容易稀释原意。

humanizer 能用来检测一段文字是不是 AI 写的吗？

不能。它的定位是移除 AI 生成写作的迹象，属于处理工具而非检测工具。想判断文本是否由 AI 生成，需要另找专门的检测方案。