本地小模型能做 AI 文本检测吗？Deckard 浏览器扩展实测

AI 生成文本的自动检测目前仍是一个被低估的细分赛道。市面上商业化做得最好的是 Pangram，其检测能力出色但缺乏足够的竞争者。作者认为，未来几年主流社交平台大概率会在新发布的内容上扫描 AI 生成痕迹，并对其打标签或直接过滤。

为什么想要一款后台自动运行的检测工具

作者日常依赖 Pangram 来辅助判断一段文字是否由 AI 生成，但更理想的状态是浏览器能在用户主动浏览并进入任意网页时自动完成检测。在 Pangram 之上做云端调用是可以实现的，但需要付费，且把浏览器看到的所有文本都交给第三方并不让人放心。因此，他把目光转向了可以在本地运行的开源检测模型。

本地小模型能打吗？一份基准测试

作者在 AI 检测数据集上对多款本地小模型做了对比，结果如下（数字越低代表误报或漏报越少）：

Gradient MLX 4-bit：人类文本误报 2.712%，AI 文本召回 52.35%
EditLens RoBERTa-large 社区 INT8：误报 2.484%，召回 56.06%
Vanguard：误报 2.267%，召回 44.92%
Desklib：误报 3.008%，召回 45.04%
Raschka DistilBERT：误报 2.598%，召回 39.01%
Raschka Qwen3-0.6B：误报 2.028%，召回 28.67%
Raschka ModernBERT：误报 1.698%，召回 21.58%
TMR/Oxidane INT8：误报 1.595%，召回 19.35%

相比之下，Pangram 宣称检测率可达 99.66%、误报率仅 0.004%，但其模型体量比这些本地小模型大上一到两个数量级，无法在笔记本后台常驻运行。作者强调，这些小模型对 AI 文本的召回虽然不高，但配合约 2% 的误报率，仍足以作为「可疑信号」使用——只要不把单一标记当作定罪证据即可。

Deckard：基于 Gradient 模型的后台检测扩展

基于上面的数据，作者用 AI 辅助编程（vibecoding）开发了 Chrome 扩展 Deckard：

默认加载 Gradient MLX 4-bit 模型，在 Mac 上后台运行；
通过 Chrome 原生消息机制直接与本地模型通信，无需额外启动本地 HTTP 服务；
运行期间内存占用约 400MB 到 1.2GB，相当于多开五到六个 Chrome 标签页；
连续五分钟未使用会自动关闭，节省资源；
已在 YouTube AI 摘要等已知 AI 内容上验证有效，对 MacBook Pro 的温度与续航没有明显影响。

现状与展望

Deckard 距离 Pangram 这类商业服务仍有明显差距，但作者认为它已经「够自己用」，也值得对自动 AI 检测感兴趣的读者一试。文章最后判断，AI 检测模型会随着时间持续进步，Pangram 不会永远是唯一选项，未来 Deckard 中的本地模型也会被替换成 2 倍甚至 10 倍更强的版本。