humanizer 实战：为什么你的 AI 文案一检测就露馅

事情的起因

上周 Franky 在群里丢了一个截图：SFD 官网上一篇刚发的文章，丢进 AI 检测器，得分 92% 「AI 生成」。

那篇文章是我（好吧，是同事 Agent）写的。内容没问题，结构没问题，信息密度也不低。但读起来……就是「一眼 AI」。

问题出在哪？不是内容差，是表达模式太标准了。

AI 味到底是什么？

AI 检测器不看内容对错，它看的是统计学特征：

• 困惑度（Perplexity）：句子里每个词出现的「意外程度」。AI 倾向于选高概率词，所以困惑度偏低
• 突发性（Burstiness）：句子长度的变化。AI 写的文章句长很均匀，人类写的忽长忽短
• 过渡词频率：「首先」、「其次」、「综上所述」、「值得注意的是」——这些词在 AI 文本里出现的频率比人类高一个数量级

说白了，AI 写文章就像用自动巡航开车——安全、平稳，但一看就没有人在握方向盘。

humanizer 技能是干嘛的

OpenClaw 的 humanizer 技能，核心功能就一个：把「AI 味浓」的文本改得像人写的。

它不是什么魔法，干的活儿其实很朴实：

• 把标准化的过渡词换成口语化表达
• 打乱句子长度，混入短句
• 加入观点性词汇（「我觉得」、「说实话」、「这事儿」）
• 去掉套话和空洞的总结
• 引入具体的数字、人名、场景

安装很简单：

clawhub install humanizer

实战：改一篇文章

拿之前那篇 92 分的文章举个例子。原文是这样的：

值得注意的是，AI Agent 正在深刻改变软件开发的工作流程。
在这个快速发展的时代，我们需要关注以下几个关键点：
首先，自动化测试能够显著提升代码质量。
其次，持续集成和持续部署是不可或缺的基础设施。
综上所述，合理运用AI工具将为团队带来巨大价值。

这段文字放在博客上，任何一个 AI 检测器都会亮红灯。太标准了，标准到不自然。

经过 humanizer 处理后：

AI Agent 确实在改变我们写代码的方式。不是那种「颠覆行业」的改变，是很实际的事情——比如昨天，我们的测试 Agent 自动跑完了 847 个用例，找到了 3 个漏掉的边界条件。Franky 看了一眼说：「这才叫干活。」

持续集成？那是底线。没有 CI/CD 的 AI 工具链就像没装刹车的车，跑得越快死得越惨。
一句话：别把 AI 当万能药。它是帮手，不是老板。用对地方，比盲目跟风有用。

这段再丢去检测器，分数降到了 23%。

踩坑记录

坑 1：过度「人性化」。有一次处理一篇技术文档，humanizer 把「API 端点」改成了「这个小接口」，把「响应时间」改成「等它回话的时间」。技术文章需要专业术语，不是所有地方都要口语化。

坑 2：中文适配。humanizer 默认规则是英文的。中文有自己的一套 AI 味——「值得注意的是」、「不可否认」、「在这个 XX 的时代」。我们在 SFD 实验室的 SOUL.md 里写了一个禁令列表，比 humanizer 自带的规则管用得多。

坑 3：丢失信息密度。humanizer 有时候为了「更像人」会删掉一些技术细节。改完后一定要过一遍，确认没有丢掉关键信息。

和其他技能配合

在 SFD 的内容产线里，它是这样嵌入的：

写作 Agent 初稿 → humanizer 去 AI 味 → 人工审核 → 发布

对于批量处理的场景，可以结合 translate-cli 技能：写完中文版 → humanizer 去味 → translate-cli 翻译成英文版 → 英文版再用一次 humanizer。这样三语版本都能保持自然。

SFD 编者注

这篇本身就是用 humanizer 处理过的。原始版本写了三段「值得注意的是」被我一刀全砍了。写文章这事儿，跟做菜一样——调料放得越少，越能看出功底。