AI 写代码时编造依赖包，为什么可能变成供应链风险

AI 写代码时最常见的问题，不一定是语法错。很多时候，它会给出一段看起来很合理的代码，还顺手推荐几个依赖包。问题在于：这些依赖包可能根本不存在。

如果只是运行失败，这还只是效率问题。但一篇 2026 年 arXiv 论文《When LLMs Invent Rust Crates: An Empirical Study of Hallucination Patterns and Mitigation》提醒我们，依赖包幻觉可能不只是“模型又胡说了”，而是软件供应链安全问题。

这篇文章属于 AI 前沿研究观察专题。专题会持续关注论文、工程实践和产业信号里真正影响 AI 落地的变化。

这篇论文研究的是 Rust 生态里的 crate 幻觉。Rust crate 可以理解成 Rust 项目里的依赖包。论文作者关注的问题是：当大语言模型生成 Rust 代码时，它会不会推荐不存在的 crate？这些幻觉有什么模式？能不能缓解？

依赖包幻觉是什么

所谓依赖包幻觉，就是模型在生成代码时推荐了一个看起来像真的包名、函数名或导入路径，但这个依赖在真实包管理生态里并不存在。

例如，一个模型可能根据命名规律编出一个听起来合理的包名。它可能像真实库一样有清晰名字，甚至和任务高度相关。对不熟悉生态的开发者来说，这种输出很容易让人误以为“应该只是我没装”。

过去我们常把这类问题当作模型准确率问题：模型不懂，所以写错了。但放进工程流程里，它的性质会变复杂。

如果开发者把模型建议的包名直接复制进配置文件，再运行安装命令，正常情况下会失败。但如果有人提前注册了这个包名，安装就可能成功。此时，问题就从“找不到包”变成“装进了一个未知来源的包”。

为什么它会变成供应链风险

软件供应链攻击经常利用一个特点：开发者和自动化系统会信任包管理器里的名字。

如果一个不存在的包名被模型反复编造，而攻击者发现了这种模式，就可能抢先注册这个包名。之后，只要某个开发者或自动化流程采纳了模型建议，就可能安装到攻击者准备的包。

这类风险不需要模型有恶意。模型只是在补全一个看起来合理的答案。但系统把这个答案接进真实安装、构建、部署流程后，就可能产生后果。

这也是 AI 编程安全里最容易被低估的一点：模型输出本身只是文本，风险来自它被执行、安装、调用和发布。

为什么论文选择 Rust crate

论文把 Rust crate 作为研究对象，是因为 Rust 生态和 Python、JavaScript 不完全一样。不同语言生态的包命名习惯、包管理器、开发者行为和安全机制不同，幻觉模式也可能不同。

论文摘要指出，过去关于包幻觉的研究更多集中在 Python 或 JavaScript；这项工作则面向 Rust 代码生成做大规模实证研究。作者构建了多来源数据集，包括 Stack Overflow、GitHub 和 LLM 生成任务，并比较商业模型和开源模型在不同解码设置下的表现。

论文还提出一个值得注意的观察：Rust 中的幻觉行为可能和此前 Python、JavaScript 研究里的发现不同。摘要称，不同模型表现出相对一致的幻觉率，而且这些率对模型参数设置的敏感度较低。

这类结论仍要放在论文实验设定下理解，不能直接外推到所有 AI 编程工具。但它足够提醒开发者：不要以为换一个模型，依赖幻觉就自然消失。

普通开发者应该怎么做

对普通开发者来说，不需要先变成安全专家。最重要的是把一个习惯写进工作流：

AI 生成的依赖，不等于真实依赖。

至少应该做几件事：

• 查包是否真的存在；
• 查包的官方文档和仓库；
• 看维护者、版本、发布时间和下载情况；
• 确认包名没有拼写相似问题；
• 不要在生产项目里直接安装陌生包；
• 对自动生成的依赖变更做人工 review。

如果使用的是 Rust，可以检查 crates.io、docs.rs、GitHub 仓库和项目文档。如果是 Node.js、Python 或其他语言，也应该在对应生态里做同样核验。

企业团队应该怎么改流程

企业团队的问题更复杂，因为 AI 生成代码可能进入 CI、自动化构建、内部脚手架或 Agent 工作流。

这时只靠“开发者小心一点”不够。更稳的做法是把依赖风险前置到流程里：

• 建立允许使用的依赖白名单或可信来源规则；
• 对新增依赖做自动扫描；
• 在 CI 里拦截未知包、低信誉包和近期创建包；
• 要求 AI 生成代码附带依赖来源说明；
• 对包名、版本、许可证、维护状态做统一检查；
• 禁止 Agent 自动安装陌生依赖后继续执行高权限任务。

如果团队已经在使用 AI coding agent，还应该记录 Agent 何时建议了哪些依赖、谁批准了安装、安装后进入了哪些环境。这些记录不是形式主义，而是出问题时能否追溯的基础。

这件事对普通人有什么启发

普通人不一定写 Rust，也不一定管理企业代码库。但这个问题能说明一个更大的规律：

AI 给出的内容越像真的，人越容易跳过核验。

过去我们担心 AI 写错事实。现在更现实的问题是，AI 写出的东西可能进入真实系统。一个编造的包名、一个不存在的 API、一个错误的命令、一个看起来合理的链接，都可能从“文本错误”变成“现实后果”。

所以使用 AI 工具时，最重要的能力不是会问，而是知道哪些地方必须停下来查证。

在写作里，数字和来源要查；在财务里，账户和金额要查；在代码里，依赖和命令要查；在企业系统里，权限和日志要查。

Kunpeng AI 观察

AI 编程工具真正进入工程现场后，安全边界会变得更细。过去我们评价 AI 写代码，常看它能不能生成正确函数、能不能通过测试、能不能修 bug。现在还要补一层：它引入了什么外部依赖？

依赖包幻觉提醒我们，AI 编程不是一个单独的模型问题，而是模型、包管理器、开发流程、权限系统和供应链治理共同构成的问题。

对小团队来说，不需要一开始就上很重的安全体系。但至少要做到：

1. AI 建议的新依赖必须人工确认；
2. 生产项目不要直接安装陌生包；
3. CI 中加入依赖扫描；
4. Agent 的自动执行权限要有限制；
5. 依赖变更要能追溯到来源和批准人。

AI 写代码会越来越常见。真正稳的团队，不是不用 AI，而是让 AI 的每一步都能被验证。

Sources

• arXiv: When LLMs Invent Rust Crates: An Empirical Study of Hallucination Patterns and Mitigation