“这是一个需要专门检测器的发现类型。”BrassCoders对AI幻觉包导入的定义，给所有依赖AI编码助手的人提了个醒：你信赖的智能补全，可能正若无其事地“发明”着根本不存在的软件包。

形象点说，AI把 fastapi‑users 和 pydantic 这两个见过无数次的包名揉在一起，自信地写出了 from fastapi_users_pydantic import UserManager —— 语法完美，IDE 不警告，PyPI 上却只有 fastapi‑users，根本没有这个组合体。这种只在安装环节才被揭露的错误，只是一个麻烦；真正的危险在别处：如果攻击者抢注了那个幻觉包名，再植入恶意代码，那么一次普通的 pip install 就会变成供应链攻击。

BrassCoders 近期为其 OSS 核心加入了一个新标记，就是专为这类场景准备的：brasscoders scan --check‑package‑hallucination。有意思的是，因为这个检查需要向外联网，去确认包名是否真的存在于注册表，团队把它做成了可选开启项——这也是整个 OSS 核心里唯一会主动发起网络请求的路径。

为什么 Pyflakes、Bandit、Pylint 这些日常工具发现不了？因为它们只检查语法、类型和代码风格，全部脱网工作，不包存在性验证。而大模型本身又缺少“地面真值”校验：它只是在海量训练语料中学会了模式，看到 fastapi‑users 出现几万次、pydantic 出现几十万次，就理所当然地组合出一个“看起来对”的新名字。它不是撒谎，只是在做最有可能的下一个 token 预测——恰好这个预测指向了一个不存在的包。

已发表的研究也把这个问题摆上了桌面。Lasso Security 在 2024 年对商用代码补全模型的分析里，让模型完成实际的重构任务，结果发现：模型的确会以可测量的比例生成不存在的包建议。具体数值随基准和模型迭代而变，但“幻觉包名”这个模式始终没有消失。

攻击链本身并不复杂：攻击者监控 AI 生成的高频幻觉名称，注册同名恶意包并上传；开发者的项目里一旦保留了那条幻影导入，安装时恶意代码就入住了。这正是 BrassCoders 把它标记为“高严重性”的原因——它不是代码瑕疵，而是一个活生生的攻击面。

BrassCoders 的检测输出很直接：包名、源码行、高严重性，交给 AI 下游或人工审核去判断，是换成真实包、删除相关代码还是接受风险。把它接入 CI 流程后，就好比给每一行 AI 生成的 import 语句都过一遍“存在性安检”：看似多了一步联网查询，却把一整个幻觉包劫持的通道堵在了门外。