三款 AI 味检测器横评Vale-LLM-slop、stop-slop、no-ai-slop 谁最不留情面【免费下载链接】no-ai-slopRemoves 20 patterns of AI slop from any piece of writing.项目地址: https://gitcode.com/gh_mirrors/no/no-ai-slop如果你最近打开过 GitHub 热榜大概率见过同一类项目的扎堆出现文本去 AI 味。从 人类化 工具 humanizer到登上周刊的 no-ai-slop再到更早的 stop-slop 与 vale-llm-slop围绕 AI slopAI 生成文本中千篇一律的废话、套话与腔调的检测与清理已经成了一个独立的小生态。表面上看它们都在做同一件事但底层思路截然不同一个是确定性 Lint 规则引擎一个是投喂给大模型的写作守则一个则是带编辑与检测双模式的 Skill 插件。三款工具面对同一段文本时谁的检出率更高、谁的误伤更狠、谁适合放进日常写作流程本文基于三份开源仓库的源码与规则逐一拆解。三种检测原理Lint 规则、提示词守则、Skill 双模式先厘清一个关键区别这三款工具只有一款是真正的检测器另外两款本质上是编辑器只是附带检测能力。vale-llm-slop 是纯确定性 Lint 方案。它基于 Vale 散文检查器把 AI 写作痕迹建模成一条条可独立开关的 YAML 规则分为 Slop 与 STE 两套风格Slop 负责识别听起来像 AI 写的复述代码的注释、robust/delve 等水词、假热情、空洞夸赞STE 则按 ASD-STE100 航空维修英语标准检查句子长度25 词上限、被动语态、祈使句单指令等。它的规则粒度细到可以直接点名具体词组比如Slop.Vocabulary直接封杀 delve、tapestry、paradigm shift、lets dive inSlop.Tricolon拦截 gracefully, quickly, and reliably 这类排比三连。规则还分 error/warning/suggestion 三级例如Slop.AssistantGreat question, I hope this helps 这类聊天腔写进正式文档直接报 error。stop-slop 是提示词守则方案。它不是一个程序而是一份 SKILL.md 加三份参考文件phrases.md 列禁词、structures.md 列结构套路、examples.md 列 Before/After 改写示范本质是教大模型识别并移除的指令集。其核心规则只有 8 条砍填充词、拆公式化结构、强制主动语态、要具体不要空泛断言、把读者放进现场、变化节奏、信任读者、砍掉可被引用的金句。它比 no-ai-slop 更激进——all adverbs 一律删Wh- 开头的句子一律重写全文不允许出现任何 em dash。no-ai-slop 是带双模式的 Skill 插件方案。这是本仓库README.md的实现默认是编辑模式/no-ai-slop (your writing)最小化改动并列出 What changed另外提供一个显式的检测模式/no-ai-slop is this slop?。值得注意它在 SKILL.md 里明确写了一条与 stop-slop 本质不同的立场Do not rewrite, score the draft, or guess whether AI wrote it. AI detectors guess. Named patterns are evidence the user can check.——即不猜作者身份、不打分只点名命中的模式并引用原文把证据交给用户自己判断。这是三款工具在哲学上的最大分岔stop-slop 要求模型识别并移除no-ai-slop 在检测模式下只要求点名引用拒绝任何作者归属的推断。同一段文本实测谁点得多谁误伤重用一个把主流 AI 腔集中到一段的样本来检验。这段文本里埋了 8 处典型 slop 模式在当今快节奏的数字世界中让我们深入探讨delveAI 写作的未来。事实是问题不在于模型而在于评估binary contrast。没人告诉你的是faux-insight最棒的部分它会自己学习colon reveal。专家一致认为weasel attribution这标志着关键的转折点importance puffery。未来不会到来它已经在这里了fake-profound ending。总而言之summary-recap我们正在见证一场变革transformative的范式转移paradigm shift。对这段文本vale-llm-slop 的命中是最可预测的它的规则是正则级别确定性的Slop.Vocabulary会点掉 delve 与 paradigm shiftSlop.NegativeParallelism会抓住 Its not just X, its Y 结构Slop.Headers、Slop.TransitionsUltimately、At its core也各有对应。它的仓库自带的测试断言了两种性质every rule fires at least once on a dirty fixture无死规则与the clean fixtures produce zero alerts无假阳性目前 32 条规则在脏样本上产生 90 条告警、干净样本 0 告警。这就是 Lint 方案的底气只要词在名单里它一定报词不在名单里它一定不报。代价是它只能抓名单上的破绽抓不住换一种说法的变体。stop-slop 和 no-ai-slop 走的是模型理解路线检出靠的是大模型对规则的理解力而非词表匹配。上面 8 处模式两份 SKILL 的规则清单几乎全部覆盖binary contrasts、throat-clearing openers、faux-insight setups、colon reveals、importance puffery、weasel attribution、fake-profound kickers、summary-recap endings 在 skills/no-ai-slop/SKILL.md 的 Patterns to cut 一节逐条有定义与改写示范stop-slop 则用 12 条 Quick Checks 自查清单覆盖同类结构。也就是说对套路结构的检出率两个 Skill 方案在正常模型上通常高于词表 Lint因为它们抓的是句式骨架而非字面词。真正的分野在误伤率。vale-llm-slop 的 0 假阳性来自规则本身——它只对明确枚举的词和结构告警。两个 Skill 方案的误伤则表现为两种形态一是过度改写stop-slop 的删掉所有副词禁止 em dashWh- 开头一律重构对个性鲜明、口语化强的作者文本就是灾难这正是 eval.md 里专门用一条检查来对冲的问题Does the edit keep useful edge and preserve structure...?二是作者身份误判同为 Skill 方案stop-slop 隐含假设文本就是 AI 写的、直接清no-ai-slop 则把检测与编辑解耦——检测只给证据编辑才动手且要求Make the minimum effective editSKILL.md 的 Editing principles 第一条。在同一段人工写的、恰好带口语化碎片句的文本上三款工具的误伤排序大致是vale-llm-slop 最克制名单外不碰no-ai-slop 次之有编辑保守原则与自查兜底stop-slop 最狠全副词禁、全破折号禁。工程化能力从一份规则到一个插件三款工具在交付形态上的差距决定了它们能进入什么样的工作流。vale-llm-slop 原生支持 CI通过.vale.ini的BasedOnStyles Slop引入可以在 GitHub Actions 里对每次 PR 的文档做自动 lint还能按路径开关规则[legacy/**/*.py] Slop.RestatesCode NO是唯一能无人值守跑在流水线里的方案。stop-slop 的用法是把它作为 Claude 的 skill 目录或系统提示词的一部分更适合个人会话场景社区里已经出现了 stop-slop-zh 这类中文移植版说明它的规则框架易于二次分发。no-ai-slop 则做成了最完整的工程产物除 Skill 本体外还提供 ChatGPT/Codex 插件包.codex-plugin/plugin.json 定义了版本 1.0.6、能力清单 Edit/Detect/Preserve voice 与默认提示词并配套了 build_plugin.py 做打包与校验——它检查清单字段完整性、starter prompt 数量不超过 3 条且每条不超过 128 字符、打包产物与源文件逐字节一致再由 .github/workflows/plugin.yml 在打 tag 时自动构建并发布到 GitHub Release。隐私上也做了声明PRIVACY.md无外部服务器、无账号、无数据收集这是面向插件商店分发才需要的完整度。结论日常写作该装哪一款回到标题的问题谁最不留情面答案取决于你想要的不留情面是什么。追求确定性与可解释性且文本要进 CI 流程文档、注释、代码评审→vale-llm-slop。它的 32 条规则可审计、可开关、0 假阳性但只会抓名单内破绽属于严格但不聪明。追求对套路结构的深度清理且你写的是自己可控的短文、可接受模型代为改写 →stop-slop。它检出覆盖广、规则最激进但全副词禁与破折号禁令对个人风格是双刃剑适合我要把 AI 腔彻底洗掉的场景不适合我要保住我的语感的场景。追求检测改写分离、保留个人声音→no-ai-slop。它有三款里最明确的编辑哲学检测模式只给证据不猜作者编辑模式强制最小改动并用 eval.md 的 30 余项自检Would the writer recognize the edited draft as their own voice?约束模型不要过度抛光。如果你用 AI 写初稿或改稿、又不想失去自己的语气这是最平衡的选择。一个实用建议是组合使用把 vale-llm-slop 挂在 CI 上当守门员把 no-ai-slop 的检测模式当体检编辑时再交给它的编辑模式。毕竟这三款工具真正的共识只有一条——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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考