什么是 AI“幻觉依赖”？如何验证生成代码中的软件包

“幻觉依赖”指 AI 在代码或安装建议中给出看似合理、实际并不存在的软件包名称。如果这些名称后来被第三方注册，开发者未经核验就安装，可能把错误推荐变成新的软件供应链入口。

幻觉包与恶意包有何区别

幻觉依赖首先是生成内容与真实包生态不一致的问题；恶意包则涉及发布者在软件中加入有害行为。两者可能连接起来，但不能等同：一个不存在的包不等于已发生攻击，一个真实存在的包也不等于可信。

研究者在 16 个模型生成的 576,000 个 Python 和 JavaScript 样本中观察到了包幻觉现象。该研究支持这一风险确实存在，但其比例取决于模型、提示和实验设置，不能直接解释为所有当前 AI 代码的受攻击概率。原始论文

第一步：确认推荐指向哪个项目

不要只搜索包名是否存在。沿官方项目文档找到安装命令，再检查包仓库是否反向链接到同一项目。核对维护组织、名称拼写、版本历史和代码来源；对突然出现的新包、缺少说明的安装脚本，先暂停准入。

下载量和近期提交可以帮助决定审查顺序，但无法单独证明安全。成熟组件可能长期稳定而少发版本，新项目也未必不可信，关键是来源与用途是否可解释。

第二步：固定经过审查的工件

确认包后，记录精确版本和依赖关系，保留锁文件及审核结论。Python 项目可根据构建流程启用 pip 的哈希校验模式，并覆盖传递依赖。哈希能够核对是否取得预期文件，但如果首次选择的文件本身有害，哈希不会把它变安全。pip 安全安装文档

第三步：在隔离环境检查安装和运行

安装过程可能执行构建脚本，因此不要让未经审核的依赖接触生产密钥。检查包实际提供的 API 是否与需求一致，关注安装和测试期间的外部连接、文件写入及额外下载，再决定是否允许进入受控依赖仓库。

第四步：把新增依赖变成审查事件

代码评审中应突出新增包和版本变化，而不仅查看业务代码。SCA、恶意包情报和仓库策略可以辅助筛查，团队仍需记录风险判断和负责人。后续发布者、源码地址或下载工件发生变化时，要重新检查。

让 AI 再确认一次包名有用吗？ 可以提供线索，但不能替代访问官方文档和仓库的独立核验。

只使用已批准的包就足够了吗？ 还要固定版本、跟踪通告并评估升级。批准的是特定来源与使用条件，不是对包名作永久安全保证。