企业官网建设流程全解析

这次我们来看一个前端工程质量方向的项目：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. 核心能力速览

看完这张表其实已经能判断：anti-slop 不是给个人玩具项目用的，而是给“需要把代码品位变成团队约束”的工程团队用的。它最大的价值不是新增几十条语法检查，而是把很多 ESLint 默认规则看不见的“坏味道”变成可自动执行的 lint 告警，并且跑得足够快，快到大家不排斥在提交前跑一次。

2. 为什么需要 anti-slop：AI 时代代码质量问题

先说一个背景：现在 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 --version

Oxlint 默认就能跑，它内置了一批 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 核心对比

这里有个很重要的判断：anti-slop 不一定要替代 ESLint。更稳妥的做法是“双轨运行”：ESLint 继续负责已有的规则和插件，Oxlint 负责快速全量扫描和 anti-slop 强口味检查。两个工具在 CI 里可以并行，只是耗时不同。

7.2 迁移策略

如果团队决定从 ESLint 迁移到 Oxlint，建议分三步：

1. 先在现有项目里并行运行 Oxlint，对比它与 ESLint 的告警差异；
2. 把 ESLint 里仍然需要、但 Oxlint 还没覆盖的规则找出来，决定是接受遗漏还是继续保留 ESLint；
3. 将.eslintrc中兼容的规则映射到.oxlintrc.json，逐步切换。

Oxlint 对 ESLint 规则名的兼容性比较好，很多规则可以直接沿用，但第三方插件的规则需要看 Oxlint 的插件支持情况。迁移前最好在暂存分支上完整跑一次，带着告警数、规则名、文件路径一起对比，而不是直接一刀切切换。

7.3 什么时候不应该迁移

• 项目重度依赖 ESLint 私有插件，且 oxlint 没有等价替代；
• 需要非常细粒度自定义规则的团队，可能还是留在 ESLint 更合适；
• 已经有庞大 ESLint 配置体系、团队成员习惯成熟，迁移收益不高。

这种情况下，推荐的做法仍然是：把 anti-slop 当作额外的“告警雷达”加进现有流程，用 Oxlint 速度快这个优势做高频扫描，而不是颠覆现有规范。

8. 在 CI 与批量任务中使用 anti-slop

8.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 文件名列表，再传给 Oxlint：

git 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/checkout@v4 - uses: actions/setup-node@v4 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 让输出格式适配 CI

Oxlint 支持不同的输出格式，具体格式名以工具版本为准，常见如简洁格式或 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. 常见问题与排查方法

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 级规则。推荐流程是：

1. 选择一个小模块或新功能目录；
2. 开启 anti-slop 并全部设为warn；
3. 跑出告警列表，人工 review；
4. 确定有价值的规则并升级为error；
5. 推广到更大范围。

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 代码的产生。工具只是第一步，真正的价值在于团队愿意把代码质量标准定下来，并且用自动化手段持续执行。