AI Slop Detector v2.6.1 自审：我植入了3个坏文件——它抓住它们了吗？

Source: Dev.to

AI 代码看起来可以“生产就绪”，但实际上几乎没有实现任何功能。

• 它通过了 lint。
• 它遵循了清晰的架构。
• 它可以发布。

然而——当你追踪执行路径时——几乎没有任何承载负载的逻辑。

这就是 AI slop：不是坏代码，而是 看似完整却空洞的代码。

我构建了 AI Slop Detector，把那种模糊的“感觉不对”转化为可检查的信号。

随后我不得不面对一个令人不安的可信度测试：

这个工具会指责我自己的仓库吗？

v2.6.1 是一次可信发布

此版本侧重于 可审计性 和 稳定性：

• 依赖规则不再是“代码中的魔法”——它们已移至 YAML 并动态加载（减少隐藏假设）。
• 测试 + 覆盖率加固：165 个测试、整体覆盖率 85 %，以及 CI 门禁覆盖率从 0 % → 88 %。

目标：让工具更难出现回退，更容易被信任。

自我审计

我像任何人一样对其自身代码库运行检测器：

slop-detector --project .

整体结果：CLEAN
赤字得分：19.78 (数值越低越好)
行话膨胀度：0.11

原文报告注释： 我将完整的自检报告以 PDF 原样发布——不做编辑、不做删减、不重新排版，也不做解释性修改。

“CLEAN”并不意味着“完美”。
它的含义是：这里有足够真实的实现，值得进行审查。

真正的实验：我植入了 3 个“已知有问题”的文件

单靠得分很容易产生怀疑，于是我特意在仓库中添加了三个故意有缺陷的示例，以观察检测器是否 因正确的原因触发。

1) 空壳

一个 0 行 的文件得分 100.00，报告直白说明：

“空文件：无可分析内容 → 删除 / 实现 / 标记为存根。”

翻译：有时代码“存在”却什么也不做——这应该被显而易见地标记出来。

2) 危险结构（structural_issues.py）

得分 71.21，标记出会悄然腐蚀系统的模式：

• 捕获所有异常
• 可变默认值
• 星号导入
• 全局状态

翻译：代码可以运行，但仍会在以后变得难以信任或调试。

3) 行话 + slop 鸡尾酒（generated_slop.py）

得分 96.77，触发了诸如：

• “state‑of‑the‑art”
• “transformer”
• “optimized”

……以及经典的 slop 模式。

翻译：华丽的语言和薄弱的实质常常相伴而生。

反转

它甚至标记了我自己的措辞：cli.py 中的 “production‑ready”。
该工具不仅审计代码——还审计 声明。

为什么这是 AI 时代的审查问题

大多数工具回答的是过去的问题：

• “语法是否有效？”
• “是否安全？”
• “是否复杂？”

AI 时代的工作流需要先问一个问题：

这里是否真的有有意义的实现？

AI Slop Detector 不是裁决机器。
它是一个 审查信号，把“看起来不错，但……”转化为可度量的后续行动。

快速开始

pip install -U ai-slop-detector

# 单文件
slop-detector mycode.py

# 整个项目扫描
slop-detector --project .

CI 门禁模式（软 / 硬 / 隔离）

# 软：仅报告（永不失败）
slop-detector --project . --ci-mode soft --ci-report

# 硬：阈值触发构建失败
slop-detector --project . --ci-mode hard --ci-report

# 隔离：逐步强制执行
slop-detector --project . --ci-mode quarantine --ci-report

一个快速审查问题

“这个函数实际上与它包装的内容有什么不同？”

如果答案回到文档字符串的承诺而不是具体行为，通常说明它只是脚手架。

如果你尝试了它

我期待真实案例：

• 你遇到的误报
• 它漏掉的令人信服的空洞
• 能代表你在 PR 中看到的情形的示例想法