三个去AI味工具的源码级对比：真正的差别在“AI味“的定义

三个去AI味工具的源码级对比：真正的差别在"AI味"的定义

【免费下载链接】no-ai-slopRemoves 20+ patterns of AI slop from any piece of writing.项目地址: https://gitcode.com/gh_mirrors/no/no-ai-slop

你让 LLM 写完的文档被退回，批注只有一行字："去点 AI 味。"no-ai-slop、stop-slop、humanizer 三个都声称能处理这件事。但我翻完规则文件，发现它们连"AI 味"是什么都没对上：一个列出 20+ 种模式，一个是黑名单加评分表，还有一个干脆不列。

改完你能不能交代清楚动了哪里

AI 文本去痕这件事，第一个问题不是它改得多干净，而是它改完能不能交代清楚动了哪里。因为团队里被编辑过的文字要接受复核，复核只认证据，不认态度。

no-ai-slop 在这件事上最坚决。它的 SKILL.md 把调用分成 edit 和 detect 两种模式，detect 模式的铁律写得很直白：

Do not rewrite, score the draft, or guess whether AI wrote it. AI detectors guess. Named patterns are evidence the user can check.

不改写、不打分、不猜作者是谁。理由也说得硬气：AI 痕迹检测靠猜，具名模式才是用户能核验的证据。这基本是 AI 痕迹检测替代路线——它不给概率分，只给命中的模式清单、对应原文和几个字的修法，你可以逐条指给同事看。而 edit 模式的工作流最后一步强制输出 What changed 段落，eval.md 的自检表里有对应检查，final read 一节还专门问了一句 "Would the writer recognize the edited draft as their own voice?"——自检的最后一问是让模型确认"作者认得出自己"，这种自我提醒在规则文件里不常见。

stop-slop 的改动痕迹以分数形式呈现。据社区拆解文章介绍，它由 8 条核心规则加 11 条 Quick Checks 自查表构成，路线图里还提到 5 维量化评分。这意味着它不会告诉你"我删了第二句"，而会告诉你"AI 味指数降了多少分"。发布前自查很方便，但复核时被问"这句为什么这么改"，指着分数会显得有点尴尬。

humanizer 在另一端。据社区实测拆解文章，它做的是整段重写：模型理解"人该怎么写"，直接产出一版更口语、更带个人痕迹的文本，默认不交代改了什么。自由度最高，代价同样清楚——你得自己 diff 两版才知道它动了哪里。同事问"这句为什么改成这样"，你只能答"因为这样更像人"，这种回答在评审会上站不住。

所以三者的差别是一个选择：留不留痕 🧾。文字要进评审流的话，no-ai-slop 是工程化做法，stop-slop 算半工程化（分数能留档，改动清单不留），humanizer 则适合"你自己就是唯一审稿人"的情况。

AI 味靠查表抓，还是靠模型判断

第二个问题更根本：LLM 写作里的"AI 味"，是不是查表能抓的东西？

no-ai-slop 把 AI 味建模成可枚举的集合。仓库 SKILL.md 里的 Patterns to cut 一节列了 20 多种模式，从二元对立（"It's not X. It's Y."）到假深刻结尾（"The future isn't coming. It's already here."），每条模式不只给名字，还给改写示范：二元对立的示范是 State Y directly，把 "The question isn't the model. It's the eval." 直接改写成 "The eval matters more than the model." 这是它 slop 清理里最扎实的部分——规则可执行，每一刀都有名字可引用。

但更让我在意的是它的豁免设计。词表开头是硬黑名单：

Banned outright: delve, foster, leverage, utilize, facilitate, streamline, robust, cutting-edge...

黑名单够硬，可对 often-empty 副词（just、literally、simply、actually 这类）并不一刀切，规则原文是："Cut them when they add nothing. Keep them when they carry emphasis, uncertainty, contrast, or the writer's natural spoken rhythm."——条件式保留。这个细节是它和纯查表最大的区别：查表抓得掉显眼的，拿不准的它交给判断测试。比如 portability test 只有一行："If a sentence could move unchanged to another person, company, country, or product, it is probably filler." 一句话原封不动能贴进任何一家公司的官网介绍，那它就是填充物。这类规则查表执行不了，得靠模型执行。

stop-slop 走的是反向思路。社区拆解记录到它的构成：phrases.md 和 structures.md 两个黑名单文件，加上核心规则四 "Be specific"——"影响深远""结构性问题"这类模糊断言、every/always/never 这类绝对化词，必须换成具体事物、数字、事实；拆解文章还配了 Before/After 示例，比如把"显著提升工程生产力"换成"评审时间从 30 分钟压到 8 分钟"这种带具体数字的说法。好处很明确：审稿退化成查表，结果可复现，跑两遍不会不一样；代价同样明确：不在清单里的模式抓不到，查表的上限就是清单的边界。

humanizer 没有可枚举的边界。据社区实测，它那里 AI 味不是一个模式集合，而是一个"不像人"的连续光谱——让模型理解人怎么写，直接重写。上限高，代价是不可控：你不知道它会改多狠，也不知道你那些带个人标记的句子会不会被顺手抹平。这正是 no-ai-slop 在 SKILL.md 里反复警告的："Do not make every paragraph equally tidy or rewrite distinctive lines merely for consistency."——别把每段都改得一样齐整，别为了统一去重写有辨识度的句子。

这里的选型可以转成一个问题：你能不能接受"它这次改得跟上次不一样"？不能，选查表加测试；能，而且只看最终读感，选光谱式。

从编辑器里粘 prompt，到 CI 里跑，差多远

第三个问题关乎落地。在编辑器里粘一句 prompt，和真在流水线里跑起来，是两种工程，三个工具

【免费下载链接】no-ai-slopRemoves 20+ patterns of AI slop from any piece of writing.项目地址: https://gitcode.com/gh_mirrors/no/no-ai-slop