这次我们来看一个前端工程质量方向的项目anti-slop。它不是一个全新的 linter而是一套基于 Oxlint 的 Opinionated rules核心目标非常明确——拦截 JavaScript / TypeScript 代码里那些“看起来能跑、但品味很差”的低质量模式。这类问题在 AI 生成代码里尤其多无意义的导出、暴力类型断言、try/catch 吞错、冗余注释、命名前后不一致。配套主角 Oxlint 是 Rust 编写的 JS/TS Linter启动和分析速度比 ESLint 快一个量级用法却几乎是无痛迁移所以 anti-slop 这套规则集的实际落地成本并不高。如果你正在被 ESLint 在大仓库里的全量扫描速度折磨或者受够了 AI 编程助手生成一堆“能用但很脏”的代码这篇文章值得收藏。下面我会把 anti-slop 的定位、Oxlint 安装配置、规则验证、CI 批量任务、与 ESLint 的迁移对比、常见排查思路完整讲一遍。这个工具链不涉及 GPU、显存、模型推理是一套纯 CLI 工程工具适合前端、Node.js、全栈团队直接上手。1. 核心能力速览能力项说明项目类型Oxlint 规则集 / 代码质量策略基础工具OxlintOxc 生态的 JS/TS Linter核心理念Opinionated强口味规则不追求“不得罪所有人”主要目标拦截 AI 生成代码和人工代码中的冗余、脏模式支持语言JavaScript、TypeScript、JSX / TSX安装方式npm 安装 配置文件中 extends 引用启动方式CLI 命令npx oxlint是否提供 HTTP API不提供提供 CLI、配置文件、CI 集成接口是否支持批量任务支持全目录扫描、Git diff 变更扫描、monorepo 分批执行性能特征Rust 并行执行启动和分析速度快内存占用低适合场景团队规范、CI 质量门禁、AI 生成代码审查辅助看完这张表其实已经能判断anti-slop 不是给个人玩具项目用的而是给“需要把代码品位变成团队约束”的工程团队用的。它最大的价值不是新增几十条语法检查而是把很多 ESLint 默认规则看不见的“坏味道”变成可自动执行的 lint 告警并且跑得足够快快到大家不排斥在提交前跑一次。2. 为什么需要 anti-slopAI 时代代码质量问题先说一个背景现在 AI 编程助手已经大量进入日常开发。AI 生成代码的优点是快缺点也很明显——它在“正确性”和“品味”之间往往更偏向前者。一段代码功能没错但可能存在这些问题过度使用any/ 非空断言类型保护形同虚设大量 TODO 注释但没有任何上下文说明为什么要 TODO错误处理写成catch (e) { console.log(e) }等于吞掉错误函数命名和变量命名前后风格不统一无意义的封装、导出、中间变量注释解释“做了什么”而不是解释“为什么这么做”空行、分层、拆函数的方式缺乏一致性。传统 ESLint 规则集能检查语法错误、未定义变量、明显 bug但很难判断“这段代码是否多余”“这个命名是否合理”。这不是 ESLint 不强而是这些要求本身带有主观色彩需要有人把团队约定固化成规则。anti-slop 的定位就是这个它把一组“人看一眼就觉得不对”的模式抽象成 Oxlint 规则本质上是把代码品位工程化。这里要注意一个词Opinionated。这意味着规则集是有立场、有偏好的。它不追求所有团队都适用而是明确表达“我们认为这样写更好”。如果你的团队已经有非常成熟的 ESLint 规范anti-slop 不一定应该全部照搬但它可以作为和现有规范并行的一套“严苛审查”专门用来发现问题代码和 AI 生成代码里的 slop 痕迹。3. 适用场景与使用边界3.1 适合什么场景维护大型 JS/TS 项目觉得 ESLint 全量检查太慢希望引入一个高速 linter 做日常兜底团队里大量使用 AI 编程助手生成代码希望提交前自动拦截低质量模式需要一套比较严格的规则集作为代码评审的辅助减少 reviewer 重复说“这里命名不好、那里导出多余”想从 ESLint 迁移到更快的 linter但希望规则保持近似兼容monorepo 或微前端仓库需要分批执行 lint 任务。3.2 不适合什么场景规则追求“少吵我”的团队Opinionated 规则集会带来额外告警初期很可能觉得吵非 JS/TS 项目它是 Oxlint 规则集只能用于 JavaScript / TypeScript 生态完全不接受新增依赖的纯静态页面项目虽然工具很小但也要考虑团队流程。3.3 使用边界与合规提醒anti-slop 是工程规范类工具不涉及用户数据、版权内容、人脸声音等敏感信息。但有一点要提醒如果把 anti-slop 当作 AI 代码审查的唯一标准会漏掉业务正确性问题。lint 只能保证代码风格和明显缺陷不能保证 AI 生成的逻辑没有业务风险。因此建议把 anti-slop 定位成“代码质量的第一道门禁”而不是发布前的唯一审查手段。涉及生产代码、支付逻辑、用户数据等高风险场景人工 review 和自动化测试仍然必须保留。4. 环境准备与前置条件安装 Oxlint 和 anti-slop 规则集之前建议先确认本机环境满足以下条件Node.js 环境建议 18 或更高版本具体以你使用的 oxlint 和 anti-slop 包engines字段为准包管理器npm / pnpm / yarn 任选一种本文以 npm 示例现有项目一个 JavaScript 或 TypeScript 项目最好已经有package.json磁盘空间Oxlint 本体是一个编译好的二进制可执行文件体积很小不需要像 AI 模型一样预留几十 GB不需要 GPU、CUDA、Docker 等额外服务离线也能跑。如果你的项目是 monorepo需要保证每个子包都能解析到安装的node_modules。最简单的做法是在仓库根目录统一安装或者在需要执行 lint 的子包目录里单独安装。检查 Node 版本node -v npm -v如果这两条命令能正常输出版本号说明环境基础没问题。5. 安装部署与配置 anti-slop 规则集5.1 安装 Oxlint在项目根目录执行npm install -D oxlint安装完成后可以查看版本npx oxlint --versionOxlint 默认就能跑它内置了一批 correctness 类规则零配置也可以直接扫描项目。但我们要用的是 anti-slop所以需要进一步安装和配置规则集。5.2 引入 anti-slop 规则集anti-slop 的引入方式可能随仓库迭代变化部署前建议先看对应项目 README。常见做法有两种第一种如果 anti-slop 以 npm 规则集包发布则安装后直接在配置中extends引用npm install -D anti-slop然后在 Oxlint 配置文件中引用{ extends: [anti-slop] }第二种如果项目提供的是纯配置文件模板则把仓库里给出的规则条目合并到你自己的.oxlintrc.json的rules字段中。两种方式没有绝对优劣核心是保证规则集和项目里的 Oxlint 版本能兼容。5.3 创建 Oxlint 配置文件推荐使用.oxlintrc.json放在项目根目录。一个基础配置示例如下{ $schema: ./node_modules/oxlint/configuration_schema.json, extends: [anti-slop], categories: { correctness: error }, env: { browser: true, node: true } }解释一下$schema指向本地安装的 Oxlint 配置规范编辑器里写配置时有自动补全extends用来加载 anti-slop 规则集categories是 Oxlint 的规则分类开关correctness这类核心正确性规则直接设为error保证阻断env声明运行环境避免浏览器和 Node API 误报。如果 anti-slop 没有作为 npm 包提供而是一份纯规则列表那么配置会变成类似这样{ rules: { anti-slop/no-useless-export: warn, anti-slop/no-swallowed-error: error } }这里我没有列出具体规则名因为 anti-slop 的具体规则清单要以项目 README 为准。实际配置时把仓库里公开的规则名填进rules即可。5.4 在 package.json 中加脚本建议把 lint 命令写进package.json方便团队统一使用{ scripts: { lint: oxlint -c .oxlintrc.json ., lint:fix: oxlint -c .oxlintrc.json --fix . } }执行npm run lint第一次运行大概率会出现一批告警这很正常。重点不是追求“零告警”而是先看清楚 anti-slop 在你项目里到底能发现什么。6. 功能测试与规则验证6.1 测试目的配置完成后建议先做一次小规模功能验证确认 two 件事anti-slop 规则确实被加载了并且它对典型 slop 代码有反应。6.2 构造一个 slop 测试文件在项目里创建一个临时文件slop-test.js内容故意写成典型的低质量模式// TODO: fix this later function getData(input: any): any { try { const result JSON.parse(input); return result; } catch (e) { console.log(e); } } export { getData };这里包含了几个常见嫌疑点无上下文的 TODO、any泛滥、函数没有显式返回路径、catch里吞掉错误、末尾无意义导出。运行npx oxlint -c .oxlintrc.json slop-test.js观察输出。如果在 anti-slop 规则下有 error 或 warning 输出说明规则集已生效。如果完全没有任何输出可能有几种原因配置文件未正确加载、anti-slop 规则集中没有命中这种模式、或者规则级别是off。6.3 调整规则级别Oxlint 的告警级别和 ESLint 差不多每个规则可以被设为off、warn或error。刚开始引入 anti-slop 时建议把所有规则先设为warn跑一遍{ extends: [anti-slop], rules: { anti-slop/no-useless-export: warn } }这样不会让 CI 直接失败但团队能逐步看到问题数量。如果你不想在配置里逐个手写规则名也可以通过分类级别控制。比如只把 correctness 类规则开成 error{ categories: { correctness: error, perf: warn, suspicious: warn } }6.4 判断规则是否适合你的项目运行后不要急着把所有告警都理解为“必须修”。你需要逐一检查这条告警是否命中真实问题有没有误报这条规则的修复成本高不高是否应该把规则从error降为warn或者完全关闭这个 review 过程本身就是 anti-slop 的核心价值规则集提供的是一份候选清单最终的“代码品位”决定权仍然在团队手里。6.5 验证自动修复能力Oxlint 部分规则支持--fix自动修复但能不能自动修复取决于具体规则。测试时建议先对测试文件执行npx oxlint -c .oxlintrc.json --fix slop-test.js然后查看文件是否被改写。如果某条规则是纯检查型规则它不会自动修改代码只会给出告警。这里不要假设所有 slop 问题都可以一键修复很多模式需要人工判断比如“这个函数是不是多余的”很难靠工具自动删掉。7. 与 ESLint 的对比与迁移策略7.1 核心对比对比项ESLintOxlint anti-slop底层实现JavaScriptRust启动速度较慢大项目全量扫描明显等待快通常远低于 ESLint 的耗时配置体系成熟插件生态丰富兼容 ESLint 风格配置支持 extends规则来源ESLint 官方 第三方插件Oxlint 内置规则 anti-slop 等规则集插件生态非常丰富还在快速发展不能完全替代 ESLint 插件目标定位通用 lint 标准高速 lint 更强代码口味约束与 AI 代码审查结合需要额外配置插件针对性更强规则集更强调低质量模式这里有个很重要的判断anti-slop 不一定要替代 ESLint。更稳妥的做法是“双轨运行”ESLint 继续负责已有的规则和插件Oxlint 负责快速全量扫描和 anti-slop 强口味检查。两个工具在 CI 里可以并行只是耗时不同。7.2 迁移策略如果团队决定从 ESLint 迁移到 Oxlint建议分三步先在现有项目里并行运行 Oxlint对比它与 ESLint 的告警差异把 ESLint 里仍然需要、但 Oxlint 还没覆盖的规则找出来决定是接受遗漏还是继续保留 ESLint将.eslintrc中兼容的规则映射到.oxlintrc.json逐步切换。Oxlint 对 ESLint 规则名的兼容性比较好很多规则可以直接沿用但第三方插件的规则需要看 Oxlint 的插件支持情况。迁移前最好在暂存分支上完整跑一次带着告警数、规则名、文件路径一起对比而不是直接一刀切切换。7.3 什么时候不应该迁移项目重度依赖 ESLint 私有插件且 oxlint 没有等价替代需要非常细粒度自定义规则的团队可能还是留在 ESLint 更合适已经有庞大 ESLint 配置体系、团队成员习惯成熟迁移收益不高。这种情况下推荐的做法仍然是把 anti-slop 当作额外的“告警雷达”加进现有流程用 Oxlint 速度快这个优势做高频扫描而不是颠覆现有规范。8. 在 CI 与批量任务中使用 anti-slop8.1 批量扫描整个仓库Oxlint 天然支持批量任务直接传目录即可npx oxlint -c .oxlintrc.json src/如果仓库比较大建议分批处理npx oxlint -c .oxlintrc.json src/core npx oxlint -c .oxlintrc.json src/modules分批的好处是遇到某个子目录的存量告警特别多时不会出现“输出刷屏、最后都懒得看”的局面也方便按模块推进整改。8.2 只检查 Git 变更文件在提交前和 CI 里更高效的方式是只 lint 本次变更的文件。可以先取 Git diff 文件名列表再传给 Oxlintgit diff --name-only -- *.js *.ts *.tsx | xargs npx oxlint -c .oxlintrc.json不过xargs直接传参在文件数量巨大时可能触发命令行长度限制更稳妥的方案是用lint-staged这类工具在 pre-commit 阶段按暂存文件执行{ lint-staged: { *.{js,ts,jsx,tsx}: [ oxlint -c .oxlintrc.json --fix ] } }这样每次提交只会检查暂存区文件速度很快也不会因为仓库历史存量问题阻塞新代码提交。8.3 CI 中设置质量门禁在 GitHub Actions 里可以这样用name: Lint on: push: branches: [main] pull_request: jobs: oxlint: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-nodev4 with: node-version: 20 - run: npm ci - run: npx oxlint -c .oxlintrc.json .如果需要把 warning 也作为失败条件可以用npx oxlint -c .oxlintrc.json --deny-warnings .加上这个参数后warnings 会被当作 errors 处理CI 更严格。这对新项目很合适但对存量项目可能不够友好。如果你的项目存量告警很多建议先用warn级别跑一段时间或者用--max-warnings控制上限npx oxlint -c .oxlintrc.json --max-warnings 50 .这样只允许最多 50 个 warning超过则失败。它能帮助团队逐步压缩存量问题比一刀切--deny-warnings更平滑。8.4 让输出格式适配 CIOxlint 支持不同的输出格式具体格式名以工具版本为准常见如简洁格式或 JSON 格式。CI 里如果你想解析告警数据可以输出到文件npx oxlint -c .oxlintrc.json --format json lint-report.json如果你的 CI 平台有代码检查注解功能把 Oxlint 的告警解析成注解可以让 PR 页面直接看到问题行团队 review 体验会好很多。9. 资源占用与性能观察9.1 量化观察方法Oxlint 的核心卖点之一就是性能。但我不建议只看官方 Benchmark更好的方式是直接在你自己的项目上测量。在项目根目录执行time npx oxlint -c .oxlintrc.json .time会输出用户态、内核态和总耗时。你可以在同一台机器上跑同样的目录和 ESLint 耗时对比。如果 ESLint 需要 10 秒Oxlint 可能只需要 1 秒以内这个差异在大型 monorepo 里更明显。9.2 内存占用观察执行 lint 时可以另开一个终端查看进程占用top -p $(pgrep -f oxlint | head -1)也可以直接把耗时和内存数据记下来作为团队引入工具的参考。由于 Oxlint 是 Rust 实现内存分配和进程管理都比 Node 进程更可控在超大仓库里比 ESLint 稳定是常见现象但具体数据必须以你的实际仓库为准。9.3 哪些因素会影响性能文件数量被扫描的文件越多耗时越长规则数量启用的规则越多检查越重todo / ignore 配置忽略文件越多实际匹配路径越少TypeScript 类型检查Oxlint 不做完整 TypeScript 类型检查比 tsc lint 路径快很多机器负载CI 机器和本地机器差异很大。所以引入 anti-slop 后重点观察的不是“绝对耗时”而是“新增一套严格规则集后是否仍然能保持足够快的反馈速度”。如果发现耗时明显变高优先优化文件匹配范围而不是直接砍规则。10. 常见问题与排查方法问题现象可能原因排查方式解决方案安装失败Node 版本太低node -v检查版本升级 Node 或换包管理器运行找不到 oxlint依赖没装好npm ls oxlint重新npm install配置文件不生效文件名或路径错误检查根目录是否有.oxlintrc.json使用-c显式指定配置完全没有 anti-slop 告警extends 没引用成功或规则级别为 off检查 extends 和 rules 配置参考 README 调整引用方式告警太多规则集口味严格存量代码问题多统计各规则告警数量先降级为 warn分批整改和 ESLint 同时使用时告警重复两个 linter 规则重叠对比各自告警列表设置忽略范围或只保留一个做门禁大项目扫描卡住或超时文件太多单次任务过重拆分目录、看 CI 日志分批执行或用 diff 方式只查变更文件--fix没有效果该规则不支持自动修复检查规则文档手动修改或换支持修复的规则monorepo 子包配置不一致根目录和子包目录配置冲突检查每个子包是否独立解析配置统一在根目录管理配置或按子包配置10.1 配置文件路径问题Oxlint 默认会在当前工作目录查找配置文件。如果你从子包目录执行命令它不一定能读取根目录的.oxlintrc.json。最直接的解决办法是在命令里显式指定npx oxlint -c /path/to/.oxlintrc.json .凡是出现“配置了但没生效”“告警风格不对”这类问题先确认命令实际加载的是哪个配置文件。10.2 TODO 和 ignore 配置问题日常使用中偶尔需要在某一行临时跳过反感的规则。Oxlint 提供了注释级别的禁用方式类似 ESLint// oxlint-disable-next-line anti-slop/no-swallowed-error不过具体 disable 语法要以 Oxlint 版本为准。这里不建议团队大量使用行内禁用否则规则集很容易被绕过。更合理的方式是“默认不豁免确实有合理理由再豁免”。10.3 规则集版本更新问题anti-slop 如果持续迭代升级后可能带来新的告警。升级之前建议先查看变更日志并在一个分支上全量跑一遍评估新增告警对项目的影响。不要在发版当天直接升级规则集否则 CI 可能突然变成红色。11. 最佳实践与使用建议11.1 先小范围试点不要一开始就在全仓库开启 anti-slop 的所有 error 级规则。推荐流程是选择一个小模块或新功能目录开启 anti-slop 并全部设为warn跑出告警列表人工 review确定有价值的规则并升级为error推广到更大范围。11.2 新旧代码区别对待对存量项目全量要求零告警不现实。可以在配置中分层处理新代码目录使用严格规则集旧代码目录暂时只跑正确性规则。Oxlint 支持通过ignorePatterns或目录级配置来实现但具体写法取决于版本。工程上更简单的做法是只在新增的src/modules下启用 anti-slop 全量规则旧目录继续用原来的宽松配置。11.3 和 AI 编程助手配合现在很多 AI 编程助手都可以配置生成代码时的约束规则。团队的 AI 生成代码越来越多时建议做三层控制第一层在 AI 助手提示词和项目规则里写清代码规范第二层AI 生成代码后在 IDE 里立即跑 Oxlint 做反馈第三层提交前和 CI 里用 anti-slop 做强制门禁。这个思路和“codebuddy rules”这类 AI 编程助手规则本质上是一件事把团队的代码品位沉淀成机器可执行的约束。anti-slop 就是这套约束在 lint 阶段的落地点。11.4 定期 review 规则集规则集不是配好就不动。每迭代一个版本建议同步 review当前团队最常犯的错误是什么现有规则有没有漏掉新的坏味道有哪些规则造成了高误报率误报率高会让大家对工具失去信任最后整个 lint 流程变成形式主义。所以宁可少开几条规则也要保证留下来的规则足够可信。11.5 保留最小可运行配置建议把.oxlintrc.json、package.json脚本、CI 步骤都放进同一个 commit并写进 README。团队新成员加入时只需要执行npm install npm run lint不需要理解背后的 Rust 工具链细节。最小配置 清晰脚本是工具落地的关键。12. 总结与下一步anti-slop 最值得尝试的点是它把“代码品味”这种主观要求转变成了一组可执行的 Oxlint 规则而且背后的 Oxlint 足够快能支撑日常高频扫描。如果你所在的团队正在大量使用 AI 编程助手或者对 ESLint 全量检查速度不满意anti-slop 值得花一个下午配置进 CI。最先应该验证的功能拿一个真实模块跑一遍npx oxlint -c .oxlintrc.json .统计告警数量逐条 review 这些告警是“真问题”还是“误报”。最容易踩的坑有两个一是把 anti-slop 所有规则直接开成error造成存量问题瞬间爆红二是完全依赖自动修复以为--fix能解决所有 slop 问题。后续可以继续扩展的方向包括把 anti-slop 与 ESLint 做双轨运行对比确定迁移边界在 monorepo 里按子包分配不同规则级别把 lint 告警接入 CI 注解系统让 PR 页面直接暴露问题行再进一步可以把通过验证的 anti-slop 规则反向同步到 AI 编程助手的项目规范里从源头减少 slop 代码的产生。工具只是第一步真正的价值在于团队愿意把代码质量标准定下来并且用自动化手段持续执行。