企业官网建设流程全解析

从"联名请愿禁 AI"到 no-ai-slop：2026 反 AI 水货运动全景图

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

2026 年，开发者社区对 AI 的态度经历了一次明显的转向。年初还沸沸扬扬的"百人联名请愿，在项目里禁用 AI 辅助开发"事件，是这场情绪浪潮的顶点；而到了下半年，社区给出的答案不再是"封禁"，而是一套以 no-ai-slop 为代表的"反 AI 水货"（anti-slop）工具链。本文结合全网社区情报与 no-ai-slop 仓库源码，复盘这场运动从情绪到工程的完整路径，并拆解文本反 slop 与代码反 slop 两条战线各自的技术思路，以及下一步可能的爆发点。

一、时间线复盘：情绪顶点之后，工程化接棒

这场运动有清晰的三段式轨迹。

第一阶段是情绪宣泄。触发点是某仓库中 1.9 万行由 Claude Code 生成的代码引发的百人联名请愿，其中包括 Node.js 核心成员。请愿的核心诉求很直接：在项目里禁止 AI 辅助开发。它反映的不是某个人的洁癖，而是开源维护者对"AI 生成代码涌入主分支、却无人能为其质量背书"的普遍焦虑。请愿是快照式的事实声明，它没有给出"什么样的 AI 代码算合格"的操作定义——这正是它注定无法成为终点的原因。

第二阶段是工具爆发。2026 年 9 月上旬，no-ai-slop 以写作 Skill 形式开源，五天斩获 3.7K star；9 月 10 日起，CSDN 等平台开始出现"去 AI 味的 Skill 为何登上 GitHub 周榜第一"的实测拆解文章；9 月 12 日与 9 月 19 日的 GitHub 周榜、9 月 20 日的周报中，no-ai-slop 均与 humanizer 一同被列入"AI 去痕"代表项目。头条平台上也出现了"2.3k Star 的 no-ai-slop 一次揪出 20+ 种废话"等跟进内容。截至本文写作时，该仓库已积累超过 12k star、833 个 fork，却只有 23 次提交——几乎是一个"单文件规则集"撑起的热度。

第三阶段是生态蔓延。与 no-ai-slop 同期走红的还有 stop-slop（8 条核心规则 + Quick Checks 自查表 + 5 维评分）、Vale-LLM-slop（基于散文 linter 的 prose linting 规则包）、Continue 内置的 Anti-Slop 检查（识别 10 种 AI 代码坏味道）、anti-slop（面向 Oxlint 的 TypeScript 代码质量规则），以及 Hallmark 这类把"60+ 项 slop test"当作落地页门禁的工具。社区媒体的跟进也从"是什么"转向"怎么配"——包括如何在 Claude Code 中集成、如何统一 Key 跑通调用链路。这说明"反 AI 水货"已经从口号变成了一门可以配置、可以度量、可以进入 CI 的工程实践。

二、仓库解剖：no-ai-slop 到底做了什么

理解这场运动，值得先回到源头，看 no-ai-slop 仓库里真实存在的规则系统。

一份文件，两种工作模式

仓库的核心是 skills/no-ai-slop/SKILL.md，它在文件头部声明了两种互斥的任务：Edit（默认）和Detect。

• Edit 模式：对用户草稿做"最小有效编辑"，输出改后全文加一段What changed说明；
• Detect 模式：只点名命中的 slop 模式、引用原文、给出一句话修法，不重写、不打分、不猜测是否由 AI 生成。

最后一条是关键设计。SKILL.md里明确写着："AI detectors guess. Named patterns are evidence the user can check."（检测器靠猜，命名的模式才是用户可以核对的证据。）它把立场从"AI 归属判定"——一个几乎无法可靠解决的问题——转移到了"可举证的模式清单"上，这让它在方法论上远比"AI 含量检测"站得住脚。

20+ 种模式与三层词表

SKILL.md的 Patterns to cut 部分逐条定义了典型 AI slop，本文仅摘录几类有代表性的：

• Binary contrasts（二元对比）："This is not X. It's Y."。修法直截了当：直接说出 Y。"The question isn't the model. It's the eval." 应改为 "The eval matters more than the model."
• Throat-clearing openers（清嗓开场）："Here's the thing"、"Let me be clear"，直接删除并进入正题；
• Colon reveals（冒号悬念）：名词短语 + 冒号 + 小写戏剧性揭示，如 "The best part: it learns."，改为普通陈述句；
• Fake-profound endings（伪深刻结尾）："The future isn't coming. It's already here."——不要求改写成更好的比喻，而是直接删掉，让草稿停在最具体的那句话上。

此外还有 faux-insight setups（"What nobody tells you"）、weasel attribution（"experts agree"）、synonym cycling（同一事物换词轮播）、dramatic fragments、superficial analysis、negative listing、robotic rhythm 等。规则之外，文件还维护了三层词表：直接封杀的禁词（delve、leverage、utilize、cutting-edge、paradigm shift 等 30 余个）、常为空洞的副词（just、literally、fundamentally 等）、常为空转的短语（it's worth noting、at the end of the day、in today's world 等）。值得注意的是，词表规则都附了保留条件："保留当它承载语气/不确定性/作者口头节奏时"——它反的是模式化，不是这些词本身。

自检闭环：eval.md 与"最小有效编辑"

仓库里还有一份容易被忽略的文件 skills/no-ai-slop/eval.md，它是技能对自己输出的检查清单：是否保留作者的口吻与节奏、是否放过强的人类句子、是否让每个句子"挣到自己的位置"、是否通过"可移植性测试"（一句话挪到别的公司/产品上依然成立，就说明它是水词）。工作流要求编辑完成后逐条自检，任一 fail 即返工。这构成了一个"规则 -> 执行 -> 自检"的闭环，也是它区别于"一键润色"类提示词的根本：它把编辑者的主观判断拆成了可验证的条目。

工程化与分发

仓库虽小，工程化并不简陋。.codex-plugin/plugin.json 声明了 ChatGPT/Codex 插件元数据，版本号 1.0.6，category 为 Productivity，能力标签是 Edit / Detect / Preserve voice；scripts/build_plugin.py 负责把SKILL.md、eval.md、图标、许可与隐私文件打包成 zip 并做一致性校验；.github/workflows/plugin.yml 在 push 与打 tag 时自动构建并附到 GitHub Release。PRIVACY.md 则明确声明这是一个纯 skill 插件：不跑外部服务、不要求账号、不采集数据——这恰好回应了请愿运动里"AI 进项目"最敏感的数据与可控性担忧。

三、两条战线：文本反 slop 与代码反 slop

把时间线上的项目归拢，会发现"反 AI 水货"实际存在两条并行但方法论同源的战线。

文本战线以 no-ai-slop、stop-slop、humanizer、Vale-LLM-slop 为代表。它们的共同动作是：把"AI 味"拆成可枚举的模式与词表，再以提示词技能、prose linter 或独立工具的形式嵌入写作/编辑流程。区别在于执行方式：no-ai-slop 依赖大模型按规则改写；Vale-LLM-slop 用确定性规则做静态扫描，可进 CI；stop-slop 则额外给出了 5 维量化评分，试图把"去味效果"变成可比较的数字。这一战线的核心洞察是：AI 生成的平庸有可识别指纹，而指纹可以被规则化地抹除。

代码战线则以 anti-slop（Oxlint 规则集）、Continue Anti-Slop 以及最初的联名请愿为代表。anti-slop 拒绝链式断言、unknown 泛滥、无注释强制转换——用 lint 规则逼程序员写出"有依据"的代码；Continue 的 Anti-Slop 在临时 worktree 中基于 diff 范围检查，识别 10 种坏味道（过度冗余注释、样板代码爆炸、过度抽象等），核心原则是"移除仪式感，保留功能性"。请愿虽然以"禁用"为诉求，但代码战线的成熟产物全部走的是"规则拦截"而非"整体禁入"的路线——这其实是对请愿目标的一次温和修正：不是不让 AI 写，而是让不符合质量定义的 AI 产物进不了主分支。

两条战线共享同一个方法论内核，可以归纳为三点：

1. 从猜归属转向命名模式。判定"是不是 AI 写的"不可靠，命名"这里有哪种 slop 模式"可核对、可讨论、可修；
2. 把品味翻译成规则。"写得不像人话"无法执行，"删掉冒号悬念、禁用 delve、恢复主动语态"可以执行；
3. 让反 slop 成为工作流的一环。无论是SKILL.md的 Edit 模式、Vale 的 CI 集成，还是 Continue 的 diff 范围检查，反 slop 都从"事后吐槽"变成了"事中门禁"。

四、下一个爆发点在哪里

基于现有情报与仓库源码，可以给出三个方向判断。

第一，从"技能"走向"门禁"，并最终走向"评分基准"。no-ai-slop 当前是 skill 形态，依赖人工触发；Vale-LLM-slop 已把同类规则带入 CI，Hallmark 已把 slop test 做成上线门禁。下一步的合理演化是：把SKILL.md中的模式清单编译成确定性检查器，对文本与代码同时做 diff 级扫描，形成"反 slop 覆盖率"这类可度量的工程指标——就像今天的代码覆盖率。届时"AI 去味"会从个人写作习惯升级为团队质量规范。

第二，从"去味"升级为"风格保持"。no-ai-slop 的差异化卖点始终是 "without flattening your personal voice"，SKILL.md反复要求先识别作者的词汇、节奏、粗粝感、幽默与离题，再做最小编辑。这个方向目前靠提示词约束实现，脆弱且不可复现。下一代工具很可能引入"风格画像"：先采样作者的既有文本建立风格基线，再在去 slop 时做差异最小化。这与 5 维评分、风格白名单（stop-slop 路线图里已提到的方向）互相印证。

第三，战线向全内容形态蔓延。情报显示，反 slop 已从技术写作扩展到 SaaS 落地页（Hallmark 的 60+ 项门禁）、产品文案、社媒帖子。随着 AI 生成内容在营销、文档、客服语料中占比上升，"slop 标准"很可能会像无障碍标准一样，成为内容管线里的默认关卡。

最后需要泼一盆冷水：规则化反 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