AISlop 实战指南:用 40+ 规则自动检测 AI 代码中的垃圾代码
AI 编码工具(Claude Code、Cursor、Codex 等)让开发速度飙升,但有个隐形成本:代码质量在悄悄滑坡。测试通过了、Lint 也过了,但代码里残留着 AI 特有的”脏东西”——叙事性注释、吞掉的异常、幻觉导入、重复的工具函数、写了一半的 TODO。这就是所谓的 AI slop(AI 代码垃圾)。
今天介绍的开源工具 AISlop(MIT 协议)就是专门解决这个问题的。它用 40+ 条静态分析规则,覆盖 7 种语言,亚秒级运行,无需 LLM,确定性输出。简单说:它是个专门抓 AI-generated code smells 的 linter。
快速上手
无需安装,直接跑:
npx aislop scan
这会扫描当前目录下所有支持的文件,输出各部分质量评分和总得分。如果只想看变更部分:
npx aislop scan --changes # 对比 HEAD 的变更 npx aislop scan --staged # 暂存区文件
输出示例(JSON 格式):
npx aislop scan --json
会得到一个结构化的评分报告,包含每个文件的详细问题列表和总体分数(0-100)。
安装选项
如果不想每次用 npx,可以装到项目中:
npm install --save-dev aislop yarn add --dev aislop pnpm add -D aislop
然后在 package.json 中添加脚本:
{
"scripts": {
"lint:aislop": "aislop scan",
"lint:aislop:ci": "aislop ci"
}
}
支持的语言和规则
AISlop 目前覆盖 7 种语言:
| 语言 | 文件扩展名 |
|---|---|
| TypeScript / JavaScript | .ts, .tsx, .js, .jsx |
| Python | .py |
| Go | .go |
| Rust | .rs |
| Ruby | .rb |
| PHP | .php |
| Java | .java |
40+ 规则涵盖的典型 AI 残留模式包括:
- 叙事性注释:
// 这里我们遍历数组并过滤出符合条件的元素(代码已经自解释) - 吞掉的异常:
try { ... } catch (e) { / ignore / } as any滥用:TypeScript 中无意义地绕过类型系统- 幻觉导入:引用了
package.json中不存在的依赖 - 重复工具函数:多个文件中出现相同的 helper 函数
- 死代码:定义了但从未调用的函数或变量
- TODO 桩代码:
// TODO: implement this留空的函数体 - 超长函数:超过合理行数的巨型函数
- 不一致的命名风格:同一作用域内混合 camelCase 和 snake_case
CI 集成
AISlop 最实用的场景是融入 CI 流水线。它内置了 CI 模式:
npx aislop ci
在 ci 模式下,可以配置最低分阈值,低于阈值则 CI 失败:
ci: failBelow: 80
配合 GitHub Actions:
name: AISlop Quality Gate
on: [pull_request]
jobs:
slop-check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Check AI slop
run: npx aislop ci
还可以在 PR 上显示质量徽章:
[](https://scanaislop.com)
Pre-commit Hook
AISlop 支持注册到 Claude Code 等 AI 编码工具的编辑钩子,在每次 AI 生成代码后自动检查:
npx aislop hook install --claude
这样每次 Claude Code 写完代码提交前,AISlop 会自动扫描变更内容,把质量缺陷直接暴露给开发者。也可以安装为标准的 Git pre-commit hook:
npx aislop hook install
自动修复
部分规则支持自动修复,省去手动改的麻烦:
npx aislop fix # 安全修复 npx aislop fix -f # 激进修复(包括删除未使用的文件、清理依赖)
自动修复会处理格式问题、未使用的导入、死代码等机械性问题。更复杂的模式(如吞掉的异常、幻觉导入)需要人工判断。
配置进阶
配置文件位于 .aislop/config.yml,支持:
exclude: - "**/*.test.ts" - src/generated - vendor/ rules: narrative-comment: warn # 叙事性注释仅警告 swallowed-exception: error # 吞掉异常报错 hallucinated-import: error # 幻觉导入报错 ci: failBelow: 80 reportOnly: ["narrative-comment"] # CI 中忽略这类问题 extends: ../../.aislop/base.yml # 支持继承父级配置
实际效果
HN 评论区有用户反馈了真实使用体验:有人在代码库中跑 AISlop 后,”检测到了一些有价值的问题,能够传给 agent 进行验证和修复”。也有人指出某些规则与 ESLint 有重叠,但 AISlop 的价值在于它专门针对 AI 产生的代码模式,而这些模式传统 linter 很难覆盖。
比如 Claude Code 经常在迭代过程中留下未使用的函数,ESLint 的 no-unused-vars 可能不会触发(因为函数被导出),但 AISlop 能识别出这是 AI 迭代残留的死代码。再比如幻觉导入——AI 根据训练数据中的常见 API 生成了导入语句,但该包根本不在 package.json 中。
AISlop vs 传统 Linter:一个真实对比
拿一个典型的 AI 生成代码场景来看。假设 Claude Code 生成了这个函数:
// 异步获取用户数据并处理返回结果
async function fetchUserData(userId: string) {
try {
// 使用 fetch API 发送 GET 请求
const response = await fetch(`/api/users/${userId}`);
// 将响应转换为 JSON 格式
const data = await response.json();
return data;
} catch (error) {
// 发生错误时静默处理
}
}
ESLint 对此完全静默——语法正确、类型正确、无未使用变量。但 AISlop 会报出:
- 叙事性注释(3 处):每行代码上方都有 AI 惯用的”注释伺候”风格
- 吞掉的异常:
catch块完全为空 - 潜在
as any隐患:如果userId传入类型不匹配,静默失败
这就是 AISlop 的独特价值——它不关心代码能不能跑,而是关心”这段代码是不是 AI 风格的有毒代码”。
在现有工作流中集成
如果你已经在用 ESLint 或 oxlint,AISlop 可以作为补充层加入。推荐的做法是:
开发阶段:在 AI 编码工具(Claude Code、Cursor)的 hook 中注册:
npx aislop hook install --claude
这样每次 AI 写完代码后自动扫描,开发者在接受 AI 的变更前就能看到质量警告。
Code Review 阶段:在 CI 中以 warn 级别运行,给 reviewer 提供 AI 代码质量参考:
npx aislop scan --changes --json > aislop-report.json
合并前:在 CI 中设硬性质量门槛,低于阈值阻止合并。
深层思考:AI Slop 的本质
为什么 AI 代码容易产生这些模式?根本原因不是 AI “不聪明”,而是 AI 的生成逻辑与人类开发者的写作习惯不同:
- 叙事性注释:AI 被训练为”解释代码”而非常写代码,当它不确定人类需要什么风格的代码时,默认输出带注释的”教学版”
- 吞掉的异常:AI 见过大量”先写 try-catch 再回来处理”的草稿代码,但作为生成者它不知道后续如何处理
- 重复的工具函数:AI 每次生成的上下文窗口有限,看不到同一代码库中其他地方已经写了同样的 helper
- 幻觉导入:AI 的记忆中某个 API 很常见,但当前项目的
package.json里并没有
理解了这些模式背后的原因,就会明白它们不是 AI “质量差”的标志,而是AI 工作方式的自然产物。AISlop 的价值不在于”惩罚 AI”,而在于帮开发者快速定位这些可以优化的问题点。
总结
AISlop 解决了一个真实的痛点:AI 代码质量的可视化。它不替代 ESLint、oxlint、Rector 等现有工具,而是在它们之上补充了AI 特有的代码模式检测。核心优势是:
- 零配置:
npx aislop scan即可,30 秒开始用 - 确定性:不用 LLM,结果完全可复现
- CI 就绪:质量门禁 + 分数徽章,融入现有流程
- 7 种语言:不限前端,后端项目同样适用
- MIT 协议:开源免费,无商业限制
如果你在用 AI 编码工具做日常开发,建议在项目里加上 AISlop 做质量门禁——不是不信任 AI,而是像 code review 一样,多一道检查总是好的。
GitHub: github.com/scanaislop/aislop | 使用:
npx aislop scan