企业官网建设流程全解析

三款 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 slop"（AI 生成文本中千篇一律的废话、套话与腔调）的检测与清理，已经成了一个独立的小生态。表面上看它们都在做同一件事，但底层思路截然不同：一个是确定性 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、let's dive in，Slop.Tricolon拦截 "gracefully, quickly, and reliably" 这类排比三连。规则还分 error/warning/suggestion 三级，例如Slop.Assistant（"Great 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 模式：

在当今快节奏的数字世界中，让我们深入探讨（delve）AI 写作的未来。事实是，问题不在于模型，而在于评估（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 shift，Slop.NegativeParallelism会抓住 "It's not just X, it's Y" 结构，Slop.Headers、Slop.Transitions（Ultimately、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 dash""Wh- 开头一律重构"对个性鲜明、口语化强的作者文本就是灾难，这正是 eval.md 里专门用一条检查来对冲的问题："Does the edit keep useful edge and preserve structure...?"；二是作者身份误判，同为 Skill 方案，stop-slop 隐含假设"文本就是 AI 写的、直接清"，no-ai-slop 则把检测与编辑解耦——检测只给证据，编辑才动手，且要求"Make the minimum effective edit"（SKILL.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