一句话总结
AI 编程助手让代码产出量激增，也让「能跑但不该通过审查」的低质量代码泛滥。开源项目 anti-slop 用 15 条 Oxlint 规则，在提交前拦截那些「低证据、低信号」的 TypeScript/JavaScript 模式——它不是追求绝对正确，而是拒绝 AI 时代的代码废料。
背景：AI 编程时代的「slop」问题
「Slop」这个词在 2024 年被牛津词典关注，最初形容低质量的 AI 生成内容。如今它有了编程语境下的新含义：AI 生成的那些「看起来能跑、实则埋雷」的代码。
AI 编程助手在提升效率的同时，也系统性地放大了几类坏味道：
- 为了通过类型检查而伪造证据：模型会无脑加
as any或堆叠类型断言，让报错「消失」，却掩盖了真实的类型错误。 - 幻觉 API：生成根本不存在的属性、方法、参数，运行时才暴露，静态检查难以发现。
- 未知类型泛滥：
any/unknown抹平了类型信息，IDE 补全和静态分析全面失效。 - 反射滥用：用
Reflect、typeof等动态机制绕过类型系统，把编译期错误推迟到运行期。
这些问题有个共同点：它们不是语法错误，而是「低证据、低信号」的代码模式。传统的 ESLint 规则大多关注风格和可读性，很难系统性地拦截这类模式。
anti-slop 是什么？
anti-slop 是一个基于 Oxlint 的插件，提供 15 条「意见鲜明」的规则，专门拒绝低证据、低信号的 TypeScript 和 JavaScript 代码模式。
它的设计哲学非常明确：
- 不是 npm 依赖，而是要被 vendored（内置）的：README 明确说「复制规则到你的仓库，读它们，改成符合你团队标准的样子」——规则是可审计、可修改的起点，而非黑盒。
- 用 agent skill 分发：通过
npx skills add让 AI 编程助手自动完成安装配置，这是它区别于传统 lint 工具的关键。 - 面向 AI 代码审查场景：规则针对的正是 AI 生成代码的高发坏味道。
项目 2026 年 8 月 12 日发布，使用 TypeScript 编写，标签包括 agent-skills、linting、oxlint、typescript。
15 条规则，四大分类
类型证据（5 条）—— 拒绝「伪造类型安全」
no-chained-type-assertions：拒绝嵌套类型断言（x as unknown as T），这是最典型的「伪造证据」no-widen-then-assert：拒绝先拓宽再断言的自欺式写法no-known-value-widening：拒绝显式地把值拓宽到宽泛类型require-safety-comment-for-type-assertion：强制为类型断言写安全说明注释no-known-value-widening系列：拦截丢失类型信息的显式标注
未知类型（3 条）—— 拒绝「类型信息蒸发」
no-unknown-parameters：拒绝未知类型的函数参数no-unknown-returns：拒绝未知类型的返回值no-unknown-type-aliases：拒绝未知类型的类型别名
反射 / 动态（3 条）—— 拒绝「绕过类型系统」
no-reflect-apply/no-reflect-get：拒绝反射式动态调用no-runtime-typeof：拒绝用运行时的typeof做类型判断
对象 / 模块（4 条）—— 拒绝「结构失控」
no-object-parameters：拒绝用「上帝对象」做函数参数no-conditional-empty-object-spread：拒绝用{}做条件展开来省略字段no-unsafe-dictionary-type：拒绝不安全的字典类型no-module-mocking：拒绝模块 mock 等测试侧的模式滥用
这些规则的共同目标不是「绝对正确」，而是提高代码的证据标准——每一处类型断言、每一个未知类型，都需要明确的理由。
安装与使用
anti-slop 提供了两条安装路径：
路径一：agent skill（推荐）
npx skills add dmmulroy/anti-slop --skill install-anti-slop
然后让 AI 编程助手「在当前仓库安装 anti-slop」。skill 会自动完成：复制插件 → 安装匹配版本的 oxlint 与 @oxlint/plugins → 合并进现有 lint 配置 → 启用全部规则 → 校验结果。
路径二：手动安装
复制 src/ 到目标仓库（如 tools/oxlint/anti-slop/），然后在 oxlint.config.ts 注册：
import { defineConfig } from "oxlint";
export default defineConfig({
jsPlugins: [
{ name: "anti-slop", specifier: "./tools/oxlint/anti-slop/index.ts" },
],
rules: {
"anti-slop/no-chained-type-assertions": "error",
"anti-slop/no-unknown-parameters": "error",
// ... 其余规则
},
});
因为规则是被 vendored 进仓库的，团队可以自由地放宽、收紧或改写规则，让它们贴合自己的编码规范——这正是作者想传达的核心理念：规则是起点，不是终点。
为什么 lint 是对抗 AI slop 的有效武器？
AI 代码审查（AI code review）已经很常见，但它有个盲区：AI 审查 AI 生成的代码，容易被同一套偏见带偏。而 lint 规则是确定性的、可解释的、可强制在 CI 里执行的。
anti-slop 的价值正在于此：
- 确定性：规则是明确的 AST 模式匹配，不存在「模型觉得没问题」的模糊地带
- 可审计：每条规则都能读源码，理解它在拦截什么
- 可进 CI：在提交前拦截，而不是等 code review 时靠人眼
- 面向团队：规则可以被改写，沉淀成团队的编码共识
对于大量使用 AI 编程助手的团队来说，把「拒绝 slop」变成一条 lint 门槛，是成本最低、效果最直接的质量防线。
同类工具对比
| 工具 | 定位 | 拦截目标 | 特色 |
|---|---|---|---|
| anti-slop | Oxlint 插件 | 低证据代码模式 | 面向 AI 代码，agent skill 分发，可 vendored |
| ESLint | 通用 lint | 风格 + 潜在错误 | 生态最大，规则海量，配置复杂 |
| Oxlint | 快速 lint | 兼容 ESLint 规则 | Rust 实现，性能极佳，是 anti-slop 的底座 |
| Biome | 一体化工具链 | 格式 + lint | 快速，但规则偏风格向 |
anti-slop 的独特之处在于它的选题——不是再造一个通用 lint 工具，而是精准打击 AI 时代最让工程师头疼的那几类代码模式。
适合人群
- 重度使用 AI 编程助手的团队：给 AI 生成的代码上一道质量门槛
- TypeScript / JavaScript 开发者：关注类型安全和代码可维护性
- 工程效能负责人：想把「代码证据标准」沉淀为团队规范
- 对 AI 代码质量话题感兴趣的研究者
总结
- AI 编程助手的普及系统性地放大了「低证据、低信号」代码的泛滥
- anti-slop 用 15 条 Oxlint 规则精准拦截伪造类型断言、幻觉 API、未知类型、反射滥用等模式
- 它的「vendored + agent skill 分发」设计，让规则可审计、可改写、可进 CI
- 确定性 lint 是对抗 AI slop 最直接有效的武器之一
- 面向团队的核心理念：规则是起点，不是终点
仓库地址：github.com/dmmulroy/anti-slop
数据来源：GitHub API（2026-08-13 查询）、项目 README
