Humanizer 深读：用维基百科的 AI 痕迹清单改写机器腔

它解决的问题不是“检测”，而是“读感”

很多团队把 prompt 调了几轮，事实、语气、长度都对了，交付前再读一遍，还是觉得哪里不对。句子太顺，情绪太满，每个段落都像在等掌声。Humanizer 针对的就是这个阶段：模型生成的初稿已经可用，但读起来仍然不像人写的。

它的目标不是绕过 AI 检测器。README 里写得很直白：detectors still flag most of its output。它要的是让读者——真实的人类读者——觉得这段文字是一个人写出来的。

这个定位决定了很多后续设计。它不追求“像人写的”这个模糊目标，而是把维基百科编辑用来识别 AI 文本的“Signs of AI writing”指南，转成了一组可检查、可执行的模式。维基百科的编辑每天面对海量疑似 AI 投稿，他们总结出的 26 个信号，比任何个人直觉都更系统。

26 个模式为什么从“最强五个”开始

Humanizer 把 26 个模式按强度分组。前五个模式单独出现就触发改写：“Not X but Y”、单句收尾、听起来很深奥的套话、卖关子的开场、和无人提出的反对意见争论。

这五个模式的共同点是：它们都在表演“这句话很重要”，却没有增加任何事实。比如“It's not just a feature, it's a shift”，句子结构本身在制造转折感，但“shift”并没有比“feature”多说出什么。再比如“Let that sink in”，它唯一的用途是提示读者该被震撼了。

后面的模式被标记为“weak alone”，单独出现不算问题。一个仔细的作者可能真的用了一次破折号、被动语态，或者一个连字符复合词。只有当同一个段落里多个弱信号叠加，才会触发修改。这个设计避免了机械地执行规则——它承认这些模式本身不是错误，错误的是它们被模型无意识地高频复现。

核心机制：默认选择与具体选择的区分

README 里有一段对工作原理的概括：语言模型写的是“最可能出现的下一个词”，所以默认情况下，它做出的选择能覆盖最广泛的读者和主题。而人做选择时，心里只有一个读者和一个主题。

Humanizer 查的每一个 tell，都是这种“默认选择”的某种形态。一句话用“pivotal moment”来替代一个具体事实，就是在用泛化的重要性信号来适配所有场景。一段文字用三个并列例子加一个教训收尾，就是套用了一个统计上最常见的段落节奏。

这个框架比“去掉 AI 味”更可操作。它把模糊的语感问题，翻译成了一个具体的问题：这段话里，哪些句子是在传递事实，哪些句子只是在传递“这是重要内容”的信号？后者的数量越多，机器腔越重。

改写过程也有明确约束。它不把原文结构当成不可动摇的框架，但检查改写稿时，要对照模式清单和原文的事实主张。名字、数字、日期、引用必须来自原文或作者，缺失的细节会主动询问，而不是编一个填进去。这个约束对 Agent skill 尤其重要——一个会“润色”出不存在数字的工具，比机器腔危险得多。

文件改写只动散文，不碰代码和数据

Humanizer 支持粘贴文本，也支持直接指向文件路径。指向文件时，它只改散文部分，代码、数据、frontmatter、链接目标都保持不变。

这个边界对开发者和技术写作者很关键。很多技术文档里，代码块和配置示例不能动，但周围的说明文字可能充满“showcasing”“robust”这类词。如果工具分不清两者，一次改写就可能破坏示例的可运行性。

它还支持声音匹配。用户可以先贴两到三段自己的写作样本，Humanizer 会跟随样本的节奏、用词、标点习惯，包括破折号的使用。这里有一个细节：破折号在 26 个模式里被标记为“weak alone”，但如果用户样本里大量使用破折号，工具会保留它们。规则让位于个人风格，而不是反过来。

一个完整的改写示例说明了什么

README 里的里斯本游记改写示例，展示了这套规则在实际文本上的效果。原文里的“charming hotel perched high”“breathtaking, panoramic views”“a beloved national treasure”“isn't just a place to visit; it's a place to fall in love with”全部被删掉或改写成平实的陈述。

改写后的文本没有变短到失去信息。酒店在 Alfama、台阶很多、腿很酸、Tram 28 要排四十分钟、蛋挞在 Graça 那家更好吃、城堡排队很长——这些事实都保留了下来，只是不再包裹在“unforgettable”“truly special”“simply divine”这类情绪套话里。

改写后的文字更接近一个人在旅行后给朋友发消息的写法：信息密度不变，情绪表达从形容词转移到了事实选择上。原文说“the experience is absolutely worth it”，改写后说“a long queue to get them”——后者把“值不值得”的判断留给了读者，而前者在替读者做判断。

边界与判断

Humanizer 有一个明显的适用边界：它假定输入的文本事实是正确的，只处理表达方式。如果模型在生成初稿时已经犯了事实错误，这个工具不会发现，也无意发现。它的工作范围是 prose，不是 fact-checking。

另一个限制来自它主动放弃的目标。README 明确说，绕过 AI 检测器不是目标，而且检测器仍然会标记大部分输出。如果使用场景是提交学术作业或需要“原创性检测”通过的内容，这个工具不解决那个问题，甚至可能让文案在检测器眼里依然可疑。

它依赖维基百科的“Signs of AI writing”指南，这意味着模式清单偏向英语写作的 AI 痕迹。中文写作里的机器腔有不同的表现，比如“综上所述”“值得注意的是”“在当今时代背景下”这类套话，不在 26 个模式覆盖范围内。对中文文案的处理能力，文档没有说明。

如果你已经在用 Claude Code、Codex 或其他支持 skill 的 Agent，并且经常需要把模型生成的初稿改成能直接发给读者的版本，Humanizer 值得装。它把“去 AI 味”从一个玄学问题变成了一个有清单、有优先级、有改写约束的流程。但如果你的核心诉求是让文本通过 AI 检测器，它帮不上忙，而且它自己就说了不干这个。