这次我们来看一个最近在 Rust 工具链生态里讨论度不低的项目anti-slop: Opinionated Oxlint rules。名字其实已经把定位说清楚了。它是一套建立在Oxlint之上的“意见化规则集”目标就是扫出代码里的slop。Slop 这个词在 AI 生成内容语境里很流行放到代码里它指的是那些“看着能跑、实际上没质量”的段落复述性注释、万能变量名、空泛的错误处理、模板化结构。过去我们靠 Code Review 人肉找这些问题现在这个项目想把它变成一条npx命令、一个 CI 门禁。它最值得关注的点可以概括成几个速度底座是 RustOxlint 是 Oxc 项目的一部分用 Rust 实现扫描速度比传统 ESLint 快很多适合做全仓检查Opinionated 规则集不用你自己一条一条讨论“什么算好代码”规则集直接给出立场开箱即用目标场景明确专门盯 AI 补全 / 生成代码里最容易出现的低质量模式接入成本低CLI 直跑、支持--fix自动修复、可以接 CI 和 pre-commit不必引入常驻服务硬件门槛几乎为零纯 CPU Node.js 就能跑不涉及 GPU、显存和 CUDA。这篇文章会带你完整走一遍先安装 Oxlint 和 anti-slop 规则集再用一份“典型 slop 代码”做验证看规则命中效果最后把扫描接入 CI 和本地提交检查。如果你正在用 AI 编程助手补全代码或者想给团队的代码质量加一道自动防线这篇可以直接收藏。1. 核心能力速览先给一张规格表方便你快速判断这个项目适不适合自己。能力项说明项目类型Oxlint 意见化规则集 / 规则配置包基础工具OxlintOxc 项目Rust 实现核心目标检测并提示 AI 生成 / 长期维护代码中的冗余、空泛、低质量模式运行环境Node.jsnpm / npxCPU 即可GPU / 显存无要求不依赖 CUDA启动方式CLI / npx 命令无常驻服务HTTP API无属于本地命令行工具批量任务支持一条命令扫描整个目录 / 多文件配置方式.oxlintrc.json 规则配置自动修复支持 Oxlint 的--fix能力适合场景前端/全栈工程 lint、AI 辅助编码后的代码检查、CI 质量门禁这里要特别说明一点由于 anti-slop 是规则集项目它的具体规则编号、安装包名可能随仓库版本变化。下面给出的命令和配置文件是 Oxlint 生态里的通用接入形态具体规则 ID 和插件名请以项目 README 为准。2. “代码 Slop”从哪来anti-slop 在解决什么问题2.1 什么是代码 Slop代码 Slop 不是简单的“烂代码”。它更像是一种没有灵魂的代码语法正确、逻辑基本通、测试可能也能过但读起来让人非常不舒服。AI 编码助手把这类问题放大了。补全工具倾向于生成“最常见的写法”而这个最常用往往等于动词加宾语、字段名加Data、函数名加Handler。于是代码库开始出现大量重复的模式每个函数前面挂一行复述函数名的注释每个异步调用外面套一个只打日志的 try-catch每个临时数据都叫data或result。传统 linter 管的是语法错误、未定义变量、明显 BUG 这类硬伤。而 slop 主要犯的是可读性和维护性的问题它不是“错误”而是“质量赤字”。anti-slop 这类规则集就是把质量赤字量化成可执行的规则让机器帮你盯住。2.2 典型 Slop 模式长什么样从实际代码里总结这类规则集通常瞄准以下模式复述性注释代码写getUser()注释还要写“// 获取用户”。注释完全没有增加信息量还容易和代码不一致万能命名data、result、temp、handleClick满仓跑离开上下文根本不知道变量承载什么业务含义过度判空if (user user.name user.name.length 0)这种三重保护其实可选链加一个判断就能表达假错误处理catch 块里只有一行console.log(err)吞掉异常后继续执行出了线上事故完全无处排查模板化注释与占位符// 这里需要实现、// TODO: handler以及抄过来忘改的示例域名类型放任参数、返回值随意标注anyTypeScript 的类型保护形同虚设无意义封装一个函数只调用了一次内部只是包了一层别的函数不仅没消除重复反而增加跳转成本。这类问题在 AI 补全代码里出现频率非常高。anti-slop 的定位就是把上面这些模式整理成 Oxlint 规则扫描时直接命中。2.3 Opinionated 意味着什么意见化规则集的意思是它不和你讨论直接给结论。大多数团队配置 lint 的一条条过规则开开关关半天。而 opinionated 规则集把“好代码长什么样”的核心判断替你做了标准统一、冲突少适合不想在规范上反复拉扯的团队。需要注意的是“意见化”不等于“绝对正确”。它适合作为质量红线但如果团队已有既定风格某些规则可能和你现有的规范冲突。更稳妥的方式是先以 warn 级别跑一段实际代码再决定哪些规则升级为 error。3. 环境准备本地需要装什么anti-slop 跑在 Oxlint 之上所以环境准备的核心是安装 Node.js 和 Oxlint。3.1 基础环境你需要一个 Node.js 环境。建议使用当前维护中的 LTS 版本作者写稿时常见的 LTS 是 20.x / 22.x具体以你项目要求为准。先确认 Node 和 npm 是否可用node -v npm -vanti-slop 是纯 CPU 工具不涉及 GPU、显存也不用装 CUDA。对桌面环境要求很低普通办公笔记本就能跑全仓扫描。3.2 安装 Oxlint在项目目录下把 oxlint 安装为 devDependencynpm install --save-dev oxlint如果想先快速体验不需要落地到 package.json也可以直接用 npxnpx oxlintlatest --version第一次执行 npx 会下载对应版本的包网络正常情况下几十秒内完成。注意不要和 ESLint 的配置混在一起Oxlint 是独立工具读取自己的.oxlintrc.json。3.3 初始化忽略文件大型仓库里node_modules、dist、build这类目录不应该参与扫描。Oxlint 默认会忽略部分目录但更稳妥的做法是显式声明# .oxlintignore node_modules dist build coverage这样后续批量扫描时输出结果只包含真正的源码文件。4. 安装 anti-slop 规则集并写入基础配置4.1 安装规则集如果 anti-slop 以 npm 包形式发布安装命令大致如下具体包名以仓库 README 为准npm install --save-dev anti-slop安装完成后在.oxlintrc.json里加载它。Oxlint 支持通过plugins字段引入第三方规则插件也可以直接把规则写在rules里。下面给出插件方式的基础配置{ $schema: ./node_modules/oxlint/configuration_schema.json, plugins: [anti-slop], categories: { correctness: error, perf: warn }, rules: { anti-slop/comment-redundancy: warn, anti-slop/no-vague-identifier: error, no-console: warn } }再次强调anti-slop/comment-redundancy、anti-slop/no-vague-identifier这两个规则 ID 是示例写法具体以项目实际规则清单为准。如果项目要求直接把规则合并进rules而不是用插件加载去掉plugins字段即可。4.2 理解规则严重级别Oxlint 的规则级别和 ESLint 类似off关闭规则warn输出警告不影响退出码error输出错误配合 CI 门禁会让任务失败。第一次接入时建议把大多数 anti-slop 规则设置为warn。跑一轮真实代码后看命中率、误报率再决定要不要升级为error。一上来全开 error很容易被大量历史问题淹没反而不利于推行。4.3 验证配置是否被加载执行下面的命令如果配置正确可以看到 Oxlint 正常启动并显示启用 rules 数量npx oxlint如果项目里还没有源码先创建一个src目录再扫。扫描结果末尾会给出警告和错误总数这就是配置是否生效的直观信号。5. 功能测试用一份典型 Slop 代码验证规则是否生效这一节是核心验证环节。我们准备一个故意包含大量 slop 特征的 TypeScript 文件跑一遍 anti-slop Oxlint看能不能命中目标。5.1 准备测试文件新建src/slop.ts// src/slop.ts // 生成随机数字 function generateNumber() { const result Math.random(); return result; } // 提交订单 async function submitOrder(payload: any) { try { // 调用订单接口 const response await fetch(https://example.com/order, { method: POST, body: JSON.stringify(payload) }); // 返回响应内容 return response.json(); } catch (err) { // 输出错误信息 console.log(err); } }这个文件里有几个明显的“味道”generateNumber里result是万能命名函数体只有一行变量定义纯粹多余每行代码上面都挂着复述性注释// 生成随机数字完全没有补充信息payload: any类型放任https://example.com是占位符 URLcatch 里只打日志错误被静默吞掉。5.2 运行扫描在项目根目录执行npx oxlint src/如果 anti-slop 中相关规则已开启输出大致会呈现如下形态具体 rule id 和文案以项目实际实现为准Found 5 warnings and 0 errors. src/slop.ts:3:10 warning anti-slop/no-vague-name variable result is vague src/slop.ts:7:1 warning anti-slop/redundant-comment comment only restates code src/slop.ts:8:28 warning no-explicit-any type of payload is any src/slop.ts:10:16 warning anti-slop/placeholder-url use placeholder URLs src/slop.ts:15:13 warning no-console unexpected console statement判断成功的标准是目标行号能对上且每条诊断都能指向一个具体问题。只要扫描器发现了上面至少一条 slop 相关命中就说明规则集已经生效。5.3 自动修复测试Oxlint 支持--fix会自动处理一部分可修复问题。注意像“变量命名太泛”这类问题通常无法自动修复但注释、多余变量、console 这类模式可能被清理。npx oxlint --fix src/slop.ts运行后打开文件检查是否有多余变量被内联是否有注释被移除或改写是否有 console 语句被删除业务逻辑有没有被动过。自动修复之后一定要跑一遍测试或至少手动验证避免工具改坏了逻辑。5.4 单规则调试如果只想看某一条规则在当前代码里的命中情况可以用--rule-name过滤npx oxlint --rule-name no-console src/slop.ts这条命令适合快速判断某个规则误报率高不高。团队在决定“开还是不开”某条规则时先用它跑一轮存量代码是最科学的评估方式。5.5 常见失败原因扫描结果为空配置没有加载成功检查.oxlintrc.json是否在项目根目录插件名是否正确只有基础规则生效anti-slop 规则没出现插件加载失败确认规则集安装包已存在并检查plugins里的包名和实际安装包名是否一致报了预期之外的大量历史问题建议先加 ignore 或降级为 warn不要一次性阻塞开发流程。6. CLI、CI 与批量检查把规则变成研发流程的一部分anti-slop 和 Oxlint 一样是纯 CLI 工具没有常驻服务也没有 HTTP API。它的“批量能力”来自命令行本身一条命令扫描全仓多文件并发检查。如果你的需求是团队级质量门禁重点看这一节。6.1 常用 CLI 参数参数作用示例--fix自动修复可修复问题npx oxlint --fix-D/--deny-warnings把 warn 升级为 error适合 CInpx oxlint -D--format json结构化输出方便接其他工具npx oxlint --format json--rule-name rule只看某个规则npx oxlint --rule-name no-console-c file指定配置文件npx oxlint -c .oxlintrc.json--max-warnings n超过阈值返回非零退出码npx oxlint --max-warnings 10在 npm scripts 里固化扫描命令是团队落地最简单的方式{ scripts: { lint: oxlint, lint:strict: oxlint -D, lint:fix: oxlint --fix } }6.2 GitHub Actions 集成CI 里直接跑npx oxlint -D即可。-D会把警告升级成错误这样任何 slop 命中都会让 CI 失败形成硬性门禁。name: lint-check on: push: pull_request: jobs: oxlint: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-nodev4 with: node-version: 20 cache: npm - run: npm ci - run: npx oxlint -D如果仓库较大只希望在 PR 变更文件上检查可以在 CI 脚本里用 git diff 过滤出本次修改的src/文件列表再传给 oxlint。这样扫描量小、反馈快也不会被历史存量问题阻塞。6.3 pre-commit / 本地提交检查配合 husky 和 lint-staged只对暂存区文件做检查能明显降低本地反馈成本npm install --save-dev husky lint-staged在 package.json 中配置{ scripts: { prepare: husky }, lint-staged: { *.{js,ts,jsx,tsx}: [oxlint --fix] } }然后创建.husky/pre-commitnpx lint-staged这样每次提交前只有你改动的文件会过 anti-slop 检查既快又不扰人。6.4 与 AI 编程助手规则文件联动一个值得留意的趋势是现在不少 AI 编程助手开始支持项目级规则文件像 CodeBuddy Rules、.cursorrules、AGENTS.md等。它们的作用是在 AI 生成代码时就给模型设定约束告诉它“这个项目不要写复述注释、不要用 any、不要吞异常”。而 anti-slop 是在代码落地后做检查。两者可以组成两道防线生成阶段AI 助手规则文件约束输出风格减少 slop 产生落地阶段anti-slop 在提交和 CI 时扫描兜住没有被约束住的问题。如果你在用某个 AI 编码助手强烈建议两件事同时做把团队规范写进助手规则文件同时把 anti-slop 接进 CI。前者降低生成问题比例后者保证规范可执行。7. 性能观察Rust 扫描器的资源占用情况Oxlint 之所以被社区关注很大程度是因为性能。它是 Rust 写的扫描 JavaScript / TypeScript 的速度通常比 ESLint 快一到两个数量级尤其在大仓库上优势更明显。7.1 资源需求anti-slop 作为规则集运行资源取决于 Oxlint 本身CPU正常多核处理器即可内存扫描普通中大型前端项目通常只需要几百 MB 到 1GB 级别实际以项目规模为准磁盘oxlint 安装包很小几十 MB 级别GPU / 显存完全不需要。7.2 量化一轮扫描耗时在项目根目录执行time npx oxlint src/观察 real 时间。典型的几千文件规模前端仓库从冷启动到输出结果通常在几秒内如果扫描完没有任何 hit输出会很快。建议记录三组数据冷启动扫描、关闭规则扫描、开启 anti-slop 规则扫描对照看规则集是否带来了明显性能损耗。7.3 影响扫描速度的主要因素文件数量全仓扫描时文件越多耗时越长这是主要变量是否开启类型信息Oxlint 大部分规则不依赖类型信息速度优势就此而来规则复杂度少数规则需要更深的 AST 遍历开启过多复杂规则会有少量影响机器核心数Oxlint 支持多线程并发扫描多核机器优势明显。如果 CI 上扫描时间超标优先做两件事缩小扫描目录范围或者按 PR diff 增量扫描。一般不需要降低 anti-slop 规则数量。8. 常见问题与排查方法问题现象可能原因排查方式解决方案oxlint: command not found依赖未安装或未进入 PATHnpm ls oxlint确认安装重新执行npm install --save-dev oxlint扫描结果完全没有规则命中配置未加载或目录不对在项目根目录执行npx oxlint -c .oxlintrc.json确认检查.oxlintrc.json位置和内容anti-slop 规则没生效插件包名写错或未安装npm ls anti-slop查看配置里的plugins字段按 README 修正包名和规则 ID警告太多CI 一直失败规则开得太激进使用--max-warnings先放开阈值分批次降低历史问题数再把规则升级为 error运行时报 Node.js 版本兼容问题本机 Node 版本过旧node -v升级到当前 LTS 版本自动修复改动过大--fix修改了预期外代码git diff 查看修复差异只在暂存文件上运行 fix或用--fix-type限制修复类型CI 扫描时间过长扫描了 node_modules 或 dist检查.oxlintignore把构建输出目录加入忽略列表--format json输出为空文件路径参数错误确认传入目录存在且含源码用绝对路径或项目根相对路径重跑9. 最佳实践与使用建议9.1 先开 warn再逐步收敛到 error不要一上手就把所有 anti-slop 规则设为error。正确顺序是用 warn 级别跑一遍全仓记录命中数量按规则 ID 统计误报率误报率低的规则直接升error误报率高的规则要么调整写法、要么暂时保留 warn并单独记录讨论清单。这种做法能让工具落地更平滑也不会让团队产生“lint 是来找茬的”这种抵触情绪。9.2 与格式化工具配合anti-slop 检查的是代码质量不是代码格式。格式问题请交给 Prettier、dprint 等工具。建议的本地流程是保存时格式化pre-commit 阶段跑 anti-slop 和 linterCI 上跑严格模式格式和逻辑分开各有工具职责清晰。9.3 AI 生成代码后必须跑一轮扫描如果你的团队开放使用 AI 编程助手建议定一条团队约定AI 生成的代码落地前必须过一遍 anti-slop。不是所有 AI 输出都有问题但批量补全的注释、命名、错误处理往往就是 slop 的高发区。把它变成固定流程比靠个人自觉可靠得多。9.4 版权、隐私与合规边界使用这类代码质量工具时有几个边界值得明确规则集本身如果是开源项目使用前确认许可证按许可证要求标注来源不要把公司专有代码片段直接粘贴给外部 AI 服务做分析防止机密泄露建议只在本地命令行环境跑扫描如果团队使用 AI 助手生成代码需要确认生成内容的版权、许可证和合规要求不同工具的使用条款不同涉及开源代码复用时注意许可证兼容性避免把 GPL 代码引入商业项目。工具解决的是代码质量问题合规问题依旧要靠流程和管理制度来兜底。9.5 保留一套最小可运行配置项目根目录建议长期维护一套最小可运行的 lint 配置一个.oxlintrc.json、一份.oxlintignore、一条 npm script。新成员克隆仓库后跑一条npm install npm run lint就能复现团队规范。配置越简单维护成本越低。10. 总结与下一步anti-slop 这个项目最值得尝试的地方是它把“代码有没有灵魂”这个偏主观的问题用一种可执行、可量化的方式做了表达。只要你的项目在用 Oxlint接入一套意见化规则集几乎是无痛的不依赖 GPU不需要常驻服务一条命令扫全仓也能在 CI 里当门禁。如果你是第一次验证建议先做三件事装好 Oxlint 和 anti-slop用一份 5.1 节那样的 slop 文件跑一遍确认规则能命中用 warn 级别对真实项目做一轮全量扫描评估误报率优先把误报率低、共识明确的规则升为 error并把扫描接进 CI。最容易踩的坑是两个一是插件名和规则 ID 没按项目 README 写导致规则集没被真正加载二是一上来全量开 error被历史问题淹没后不了了之。后面可以继续扩展的方向把规则集接入 AI 编程助手的规则文件让 AI 在生成阶段就减少 slop在 PR 的 diff 上做增量扫描提升 CI 反馈速度甚至可以结合团队自己的代码坏味道在 anti-slop 基础上维护一套私有规则形成“开源规则 团队自定义”的双层检查体系。建议先把基础流程跑通再把规则逐步收紧这套配置越早落地后面的代码债越少。