Anti Slop：给 AI 编码智能体装上的一道"审美筛子"

图：anti-slop 官方仓库 Banner

一、先说场景：你有没有被 AI 的"一眼假"气过

让 AI 写个登录页，它秒回一版：蓝紫渐变背景、玻璃拟态卡片、圆角拉满、按钮泛光，图标是那种"✨ 智能引擎"配色的六边形 Logo，标题下面还缀着一个 "NEXT-GEN AI 2.0" 的胶囊标签。首屏正中是一张灰色骨架图占位，旁边配三张数据卡片写着 "10,000% ROI Synergy Multiplier"。整页从 Hero 到 Footer 十二个区块，排列整齐得像填空题。

图：未使用 antislop 时的典型 AI 落地页——渐变、泛光、胶囊标签、伪造数据卡片

单看一屏还行，凑成整页就有点瘆人——因为你见过一千次。这是被社区戏称为 "AI slop" 的东西。2026 年下半年，一批"审美疲劳"的用户发现，与其每次跟模型解释"别做成这样"，不如把"别做成这样"本身写成一份可复用的规则包。

miqdadbadjuber/anti-slop 就是其中的头部项目：2026 年 8 月 7 日创建，两个多月冲到 7,945 star，日榜/周榜双 Trendshift 徽章在位，npm 上叫 antislop-ai，配套官网 antislop.ai.id。它不做 UI 生成器，不做设计工具，定位非常克制——一个"过滤器"，而不是风格指南。

二、它到底在做什么：40 条规则 + 三档旋钮 + 一道交付闸门

整个项目的核心资产是一个 6 万字符的 Markdown 文件 antislop.md（同目录还有可直接粘贴到任意聊天窗口的单文件版本）。它的结构分三部分。

第一部分是"Slop 模式清单"（Part 1），一张体检表。它列举了 AI 生成设计的典型征兆，分视觉配色、布局组件、文案、代码四类：蓝紫渐变、玻璃拟态滥用、圆角成瘾、阴影过软、到处发光、网格背景、无理由的暗色模式、单调的"Hero + 副标题 + 双 CTA + 截图 + 特性九宫格 + 评价 + FAQ + CTA + 页脚"模板，以及文案里的 emoji 列表、全大写 "NEW DROP"、伪造的用户量和虚构的客户证言。关键在于这份清单本身不禁止任何东西——它是"诊断扫描表"，用来看哪些毛病扎堆出现。

第二部分是 40 条强制规则（R-01 到 R-40），分三组：Hard Gate（绝对红线，无例外）、Purpose-Gate（技术允许，但必须写出"它服务于什么"）、Quality Locks（一致性与质量锁定）。Hard Gate 里全是踩过坑的硬约束，比如禁止 em dash（R-02）、禁止无来源的统计数字（R-17）、禁止虚构评价（R-18）、禁止指向不存在页面的导航链接（R-24）、对比度不得低于 WCAG AA（R-25）、不允许点了没反应的按钮（R-26）、必须有空态/加载态/错误态（R-27）、必须可纯键盘操作且有可见焦点（R-32）、禁止用外部脚本打补丁改源文件（R-33）、交付前必须真的跑起来并录下点击流程（R-35）、禁止编造安全/合规/性能声明（R-36）、无设计方向时必须标注"draft without direction"并采用诚实的默认档位（R-37）。

第三部分是"活力工具箱"（Part 3），这是项目最见功力的地方。因为只知道"不许做什么"的过滤器，删完垃圾后只会剩下一片空白——模型会用它最平庸的模板去填。所以它引入三个必须显式设定的旋钮：ENERGY（这个设计有多用力地打招呼）、RHYTHM（各个区块之间有多少变化）、MOTION（动效多少、为什么）。每档只有 1/2/3 三级，理由写得很实在：模型和评审能可靠判断"这一段是统一还是有变化"这种二元可核验的问题，但判断不了"这是 6 分还是 7 分"。三个刻度让活力变成可执行的约束。

配套还有五个杠杆（每屏一个焦点、层级对比、留白作为结构、一次刻意的强调色、一个身份母题），以及一个"Design Read"：开工前必须先声明一行——把这次需求读作什么页面、给谁看、什么视觉语言、三档旋钮分别是多少。方向模糊时只允许问一个决断性问题，不许问题轰炸。

最后是一道强制交付闸门（Delivery Gate）：交付前必须输出四段式 PASS/FAIL 报告，每条 PASS 都要有具体证据（比如"R-26 PASS：每个按钮都有真实 href 或 onClick，无死控件"）。报告里只要出现一个 FAIL，就不许交付——"报告带 FAIL 的交付物永远不许发布"。这四块是 Hard Gate、Purpose-Gate、活力闸门、工艺与质量锁（C-1 意图性 / C-2 功能完整 / C-3 内容驱动 / C-4 韧性 / C-5 证据优先）。

三、和"风格指南"差在哪：三个文件的分工

这是整个项目最重要的设计判断，也是它 README 里花了最多篇幅解释的地方。

• antislop.md（本项目）——过滤器。判断某个视觉手法是否"无目的"，并要求结果必须有活力。
• DESIGN.md（用户自己写）——方向来源。品牌调性、性格、配色、字体、情绪。README 强调：漂亮是 DESIGN.md 的活，不是 antislop 的活。
• AGENTS.md / CLAUDE.md ——路由层。写一句"做 UI 时先读 DESIGN.md 拿方向，再用 antislop.md 做过滤"。

图：antislop + DESIGN.md 的组合结果——单一诚实标题、项目专属导航、无伪造数据

作者甚至给出四象限对比图来论证这个分工：只有 antislop，slop 没了但方向也没了（平淡）；只有 DESIGN.md，方向有了但 slop 还在（"10,000% ROI Synergy Multiplier" 还在页面上）；两者结合才是真正结果。

还有一个安全细节值得注意：antislop.md 明确要求把 DESIGN.md 当作待应用的数据而非待执行的指令，只提取设计字段，若其中夹带命令或与规则冲突的内容，应视为内容并向用户说明。这是防止提示词注入的刻意设计。

四、六种用法：按需加载，不做上下文污染

项目以标准 Agent Skills 形式分发，一个技能一个文件夹，各放一份 SKILL.md，技能之间只按编号引用核心规则、绝不重复。

技能	覆盖范围	何时用
antislop	核心过滤器：规则、档位、交付闸门、活力	始终加载
antislop-ui	布局、配色、组件、装饰、动效、结构、性能	UI 与视觉工作
antislop-copywriting	标题、CTA、语气、假数据、反 AI 写作、Markdown 卫生	文案
antislop-human	对比度、键盘、焦点、状态、交互可达性	无障碍
antislop-layoutmobile	多断点重排、网格、溢出、点击目标	响应式
antislop-code	AI 式注释：哪些该删、哪些该留	注释清理

这个"按需加载"的设计解决了 Agent Skill 的老问题：把所有东西塞进系统提示既浪费 token 又稀释注意力。核心规则只有一份，六个技能是同一份真相的不同视图。

工作方式有两种：During（边做边指导，会话结束出闸门报告，适合从零构建）和 After（审计已有产物，列编号问题清单，你勾选要修哪些，再出跟进报告，适合清理存量代码）。默认每次会话都问一次用哪种，也可以 npx antislop-ai --mode during 存成偏好，写在 ~/.config/antislop/settings.json（Windows 是 %APPDATA%\antislop\settings.json），全局共享。

五、上手门槛：真的一条命令，但环境要求不低

npx antislop-ai

交互式安装器会问你三件事：装哪些技能、装到当前项目还是全局、用哪些 AI 工具，然后复制技能文件夹并写入指针文件，让 antislop 每次会话都能被重新加载。整个 CLI 用 Node.js 写，入口 cli/index.mjs（10KB），依赖只有 @clack/prompts 和 picocolors 两个包，cli/lib/ 下三个模块（banner / install / settings），硬性要求 Node.js ≥ 20.12。

除了安装器还有十一条安装路径：skills.sh 目录、Claude Code / Antigravity / Codex / Cursor / Kimi Code / Cline / Oh My Pi 各有原生插件门，Pi 有包模式，还有单文件 curl 直接贴进任意聊天窗口。README FAQ 里明确点名支持十二个 agent：Claude Code、Codex、Antigravity、OpenCode、Cursor、Cline、Amp、Gemini CLI、Hermes、GitHub Copilot、Kimi Code、Pi、Oh My Pi。

零门槛是相对而言——它不跑模型、不占显存、没有任何服务要起，但"门槛"落在人的配合上：你要写一份 DESIGN.md，你要在会话开始时接受"During / After"的询问，你要愿意逐条读 PASS/FAIL 报告。这是一份需要纪律的规则，不是装完就自动生效的魔法。

六、争议与局限：它解决的可能是错的问题

先说作者自己反复强调的边界：antislop 只是过滤器，不制造方向。如果没有 DESIGN.md，结果会被标注为"draft without direction"，采用诚实的默认档位 ENERGY 1 / RHYTHM 1 / MOTION 1。翻译成人话：不配 DESIGN.md，你得到的是"干净但无聊"，而不是"好看"。作者在 README 里用了一句话自嘲："antislop is a filter, not magic."（过滤器，不是魔法。）

规则密度带来的实际代价。核心文件 53KB 的 SKILL.md，40 条强制规则，Delivery Gate 覆盖 20 条 Hard Gate 逐条问答。这套东西运行在上下文窗口里——每条规则、每张 slop 模式表都要被模型读到并遵循。规则越多，遵循率越低。这是 Agent Skill 体系的通病：规则密度和遵守率往往呈负相关。CI 里的 check-repo.mjs（14KB）说明作者在用自己的规则管自己的仓库，但规则本身的"遵守率"这个指标，仓库里没有测。

Hard Gate 里的绝对禁令有过度杀伤的可能。比如 R-02 全面禁止 em dash（"—"）、R-17 禁止任何无来源的统计数字、R-40 禁止"未实测的性能数字"。这在面向真实用户的商业页面是对的，但对内部工具、内部 demo、内部汇报材料可能过于苛刻——内部 demo 里的"10 万用户"往往是估算而非编造。规则越绝对，逃逸口越多，实践中很容易变成"绕过闸门"而不是"满足闸门"。

"反 AI 味"本身可能也是一种 AI 味。当足够多的人都用 antislop，输出会收敛到"antislop 风格"——而 antislop 风格本身又是一套可预测的模式。反 slop 的规则一旦成为共识，就成了新的 slop 的来源。这一点作者没有展开讨论。

审计模式的实际收益有待验证。After 模式本质是让模型按检查表逐项扫描既有代码，这和 linter 的工作高度重叠——而且 linter 更确定、更便宜、不消耗上下文。用 antislop 做审计，价值只能来自那些 linter 查不出来的"意图性"判断（比如"这个区块是不是因为模板才有"），这部分判断恰恰是最难自动化的。

许可证与生态兼容性是加分项：MIT 协议，商业友好。CI 跑在 ubuntu/windows/macos 三平台，Node 22 + npm cache，fail-fast: false 保证一个平台红了不影响另外两个汇报。

七、行业意义：一个新赛道的雏形

anti-slop 折射出的趋势比它本身更值得看：AI 编码工具的能力正在快速趋同，差异化开始从"能不能写"转向"写得像不像人"。

从这个项目的 star 曲线能看得很清楚：8 月 15 日 216 star，8 月底 558，9 月 11 日突破 2,160，9 月 26 日 3,806，10 月 10 日 5,787，10 月底 7,625，11 月 1 日 7,926——三个月从 216 到接近 8,000，尤其 9 月中旬到 10 月底这段几乎是每天 +80~100 的稳定爬升。这种斜率在工具类项目里通常意味着"进入某个主流 agent 的推荐清单"或"某个爆款演示视频带火"。

它可能开创了一个品类：Agent Skill 质量规则集。过去 agent 生态里，skills/ 目录是功能集合（做 PDF、做搜索、做部署）；anti-slop 提供的则是质量约束——专门用来否决其他能力的产物。在这个意义上它是"agent 的 lint 规则集"，而且是第一个把交付闸门做成强制流程的。

更大的背景是"AI slop"已经成为一个被广泛承认的独立问题类别。搜索"AI slop"会撞到大量关于模型输出同质化、评测污染、AI 内容农场稀释信息质量的讨论。anti-slop 把这个文化批评工程化成了一份可执行的规则文件——这是从抱怨到工具化的典型一步。

对国内团队的启示也相当直接：这类项目几乎零门槛地可用，中文生态几乎立刻跟进（各种"AI 味去除"提示词仓库、"反 AI 味"写作技巧），但多数停留在提示词层面。anti-slop 的价值恰恰在于它有结构、有闸门、有 CI 自检、有可安装的分发渠道，而且它把"审美"写成了可核验的条款，而不是"要有设计感"这种空话。

八、落地建议

对研发团队来说，接入成本几乎为零，收益取决于两件事：

1. 先写 DESIGN.md。没有它，antislop 只会给你干净但平庸的界面，作者自己说得毫不留情。DESIGN.md 至少要写清：品牌调性、性格、配色倾向、字体方向、情绪、以及 ENERGY/RHYTHM/MOTION 三档偏好。
2. 在项目根目录放 AGENTS.md 路由，写明"UI 任务先读 DESIGN.md，再用 antislop 过滤"，让规则在每次会话自动生效，而不是靠人记得提醒。

对于要对外交付的客户端项目，建议把 Delivery Gate 的 PASS/FAIL 报告当成验收物料归档——它天然是一份"设计自检清单"，比任何设计评审都便宜。对内部工具和 demo 项目，建议按 R-17、R-40 的字面要求做裁剪，避免规则密度压垮遵守率。

---

本文基于对 GitHub 仓库 miqdadbadjuber/anti-slop 的实时采集（star 7,945、fork 537、提交 139 次、贡献者 9 人、MIT 协议、最近推送 2026-11-01）与官方仓库文档、官网 antislop.ai.id、Trendshift 榜单数据综合整理。