1. 你以为的“小错误”正在变成供应链上的“大窟窿”——先看几个真实场景先说一个我在技术社区里看到的真实帖子也是这篇文章的引子。一个后端开发在项目里需要用到一个“解析用户代理字符串”的库他随手把需求扔给AI助手AI给出了一个包名说“用这个很成熟文档齐全”。他pip install之后代码跑通了CI也过了直到一个月后安全团队做依赖审计才发现那个包在PyPI上压根不存在——它是AI根据训练数据中成千上万个相似包名“推算”出来的一个幻影。而更讽刺的是那个包名对应的真实位置早被某个抢注者注册成了一个仿冒包代码一旦拉下来服务器上的环境变量、密钥文件全得裸奔。这不是个例。过去半年我陆陆续续排查过好几个“构建失败找不到模块”的案子最后都指向同一个根因AI生成的代码里出现了一个不存在的依赖而这个依赖被原样写进了 requirements.txt 或 package.json。我把这类问题统称为“AI代码依赖陷阱”。它跟传统的“拼写仿冒攻击”“恶意包投毒”有本质区别——传统攻击是有人故意挖坑而AI幻觉依赖是模型无意中画了一个坑但坑里恰好有人等着。这篇文章想讲清楚三件事第一AI幻觉为什么在“依赖名”这件事上特别容易翻车技术原理到底是什么 第二为什么现行的代码扫描、安全审计手段很难拦住这类“假依赖” 第三我实战中踩坑后的完整排查链路以及现在团队里在用的三层防护方案。如果你正在用AI辅助编程或者你的团队已经允许AI写代码这篇文章建议耐心看完。依赖层面的幻觉跟语法层面的幻觉完全不是一个量级——语法错了编译器会报错依赖错了整个供应链的可信边界直接崩塌。2. “假依赖”到底假在哪从大模型生成机制拆解幻觉产生的三个环节2.1 大模型不检索事实它在“续写”看起来合理的词很多人对AI编程助手有个误解以为它像个编译器一样从某个知识库里精确查找并返回正确的包名。实际上大模型的生成逻辑是概率补全——它根据上文逐个预测“下一个最可能的词”。拿依赖名来说当你输入“Python解析User-Agent的库有哪些”模型并不会去实时查询PyPI的注册表它只是在训练数据里见过的所有“解析UA库”相关文本之间做概率采样。它知道这类问题通常伴随哪些词汇出现于是拼装出一个“高概率存在”的字符串。问题就在这里高概率不等于真实存在。训练数据里的包名不是结构化同步的今天PyPI上新增的包、更名的包、下架的包模型根本不知道。它只记得在2023年之前某个版本的README里出现过user_agent_parser这个写法还把它和另一个库ua-parser的特征混在了一起于是就生成一个user-agent-parser-lite这种既像又不像的名字。我管这个叫“语义惯性”——模型不是查不到正确的包而是被同类文本的高频词汇带跑了。2.2 词频污染越流行的前缀越容易被“顺拐”到错误包还有一个长期被低估的因素训练数据中的词频分布。像js-、react-、python-、django-这样的前缀在开源仓库文本里大量出现模型对这些前缀的“路径依赖”极强。一旦你问它“有没有一个处理日期格式的Node库”它大概率会往date-前缀的方向生成。于是你就可能得到date-utils-ts这样的名字。这不是恶意但后果跟恶意投毒几乎一样如果恰好有攻击者提前注册了这个包并在里面塞了恶意脚本你的构建过程就变成了供应链入侵的门户。更麻烦的是AI生成的幻觉包名往往具有“高仿性”——它像某个流行包但多了个连字符、不同后缀或者换了大小写。这种相似性会绕过人的直觉审查因为开发者潜意识里会觉得“我见过这个包”。你见过的是它的近亲而不是它本身。2.3 时间冻结模型知识截止日就是供应链风险的起跑线模型的知识截止日是一个比想象中严重得多的隐患。软件生态是高度动态的一个包今天还叫foo明天因为商标问题改名了一个库的API接口在新版本里被彻底移除一个曾经流行的项目停止维护后名字被另一个人接管。当AI用“知识截止日之前的世界”来回答“现在应该装哪个包”时它给出的答案天然带滞后性。如果只是语法上的API不兼容那还好最多改几行调用代码。但如果它推荐了一个已经在官方源上下架的包名而这个包名被别有用心者抢注为新包那问题就完全变味了——你以为引用了“老牌的稳定库”实际上装了一个“新生的伪装库”。我见过一个案例一个在国外运营的Node项目AI推荐了某个npm包来加密数据但那个老包早就被原作者废弃了。废弃之后名字落到了另一个人手里新版本里带着挖矿脚本。要不是这个项目在测试环境里先跑了一周挖矿进程被监控系统揪出来后果不堪设想。2.4 测试假阳性AI连“它自己写的代码”都没测过这里要单独提一个更隐蔽的坑——AI不但会生成错误依赖还会围绕这个错误依赖生成“自洽”的调用代码、测试用例和README说明。你让AI写一个“用包xxx-tool实现图片压缩”的功能它不只是推荐这个包还会顺便写出import xxxTool from xxx-tool、调用.compress()方法、捕获异常的处理逻辑。全程代码风格统一、逻辑合理就像真有其物。开发者照着写完一跑测试发现“居然全通过了”其实不是代码对而是AI“顺着自己编出来的API”写了配套的测试桩测的是自洽的假想接口根本不是真实世界的包。CI绿了但绿得毫无意义。这种“自我验证”造成的信任错觉比直接报错还可怕。3. 防不住的老朋友为什么传统供应链防线对AI幻觉依赖几乎失效3.1 传统供应链攻击的检测思路默认前提是“包真实存在”先说清楚类型区别。软件供应链攻击大体分几类恶意包投毒攻击者注册一个有吸引力的包名受害者主动安装依赖混淆利用私有包与公共包的同名冲突诱导解析器拉到恶意公共版本上游被入侵一个正常的流行包被植入恶意代码又通过依赖关系传播拼写仿冒typosquatting注册流行包名的“高相似变体”等开发者手误命中。这些攻击有一个共同点恶意包在仓库里是真实存在的。它的名字、版本号、发布者都能在PyPI、npm、Maven Central上查到。安全工具的检测逻辑本质上是在“已存在的包集合”里做黑名单、行为分析、信誉评分——包存在才有得查。而AI幻觉依赖不一样。很多时候AI生成的那个包名在官方源里根本不存在。SCA工具扫了个寂寞因为扫描清单里的依赖名在库里查无此项SAST工具也查不出漏洞因为“不存在”本身不在漏洞库里。传统防线建立在一个没法成立的前提上防线直接空转。3.2 构建日志里的“NameError”往往被当成临时网络抖动当幻觉依赖真的导致构建失败现象也很有欺骗性。最常见的是ModuleNotFoundError或者 npm 的404 Not Found。比如在Python项目里你装包的时候看到报错ERROR: Could not find a version that satisfies the requirement neopackage1.0.0 (from versions: none) ERROR: No matching distribution found for neopackage1.0.0在Node项目里你会看到npm ERR! 404 Not Found - GET https://registry.npmjs.org/neopackage - Not found这类报错太常见了。公司内网代理抽风、镜像源同步延迟、私有源漏配全都表现为“找不到包”。多数人第一反应是重试一次、换个镜像或者干脆把依赖名去掉改用手写实现。没人会往“AI编了个假包名”的方向想。3.3 最凶险的变体名字能用但内容被掉包更让人挠头的是第三种情况也是整个问题的“致命升级版”——AI生成的包名不光存在还被人抢注成了恶意包。这种场景下你pip install是能成功的代码能跑通测试能过安全扫描也未必告警。因为恶意包往往做了大量伪装功能上会真的实现一部分业务逻辑只是在背后多夹带点私货。安全团队查包有没有问题一般看来源、历史版本、函数行为。但一个刚注册三天、发布了一两个版本、还恰好实现了“你需要的功能”的包行为分析系统很难在第一时间判定恶意。再加上它跟AI生成的幻觉名完全一致开发者根本没有任何怀疑理由。这种“幻觉生成 抢注命中”组合风险已经不是黑天鹅而是灰犀牛。4. 一次真实的排查链路从构建报错到揪出三个幽灵依赖下面这段是上个月我带团队排的一个真实问题删去了业务细节保留完整排查思路。你也可以把它当一张检查表遇到“依赖安装失败但找不到原因”的情况直接对照。4.1 背景CI突然挂了报错指向一个“刚加的包”当晚10点多CI上跑的一个Python服务在依赖安装阶段失败报错信息是找不到某个包但团队成员都很笃定“这个包昨天还用过没问题的。”拉出提交记录一看是当天下午进来的一个AI辅助生成的PR新增了三个依赖用来处理数据清洗。其中有一个名字很眼熟但当时谁也没注意。4.2 第一步锁定“不存在但被引用”的模块我第一件事不是去查“为什么不通过”而是把构建日志里的requirements.txt解析结果和pip install的实际拉取结果做对比。在CI环境里执行pip install -r requirements.txt --dry-run --report report.json--dry-run不会真正安装但会输出依赖解析报告。然后我直接在这个报告里找有没有解析失败的依赖名。果然有一个包的解析结果是“No matching distribution”而全项目里所有import这个模块的代码都是同一个PR添加的。把代码里搜到的import语句和真实安装包名的对应关系列出来我用了一个看起来很笨但很有效的办法手写脚本遍历项目里所有被import的顶层模块名跟pip list的已安装包名做一次差集。import ast, pathlib, pkg_resources installed {p.project_name.lower() for p in pkg_resources.working_set} imported set() for path in pathlib.Path(src).rglob(*.py): tree ast.parse(path.read_text()) for node in ast.walk(tree): if isinstance(node, ast.Import): for name in node.names: imported.add(name.name.split(.)[0].lower()) elif isinstance(node, ast.ImportFrom): imported.add(node.module.split(.)[0].lower() if node.module else ) print(疑似不存在:, imported - installed)这种“import集合与已装包集合求差集”的笨办法专门用来抓“模块名直接来源不明”的引用。跑完之后差集里出现了三个名字——其中两个是项目虚拟环境里确实没装的旧模块第三个就是那个AI编出来的幻觉包。4.3 第二步逆向追溯“这个包是怎么进到项目里的”锁定目标之后第二步是搞清楚这个幻觉包是怎么混进来的。我直接把那个PR的代码改动从头到尾过了一遍。AI生成的代码里有一整段实现一个utils/cleaner.py里面import了那个不存在的包还包装了它的函数。最误导人的是AI在这个包旁边贴心地生成了一层“兼容适配层”以至于即使包不存在只要把这层代码一删主业务逻辑依然能跑。也就是说这个包的作用本来就是可替代的属于AI“顺手”引入的冗余依赖。这种“顺手引入”恰恰是AI辅助编程里最常见的毒点。它不像程序员去查官方文档后有意选择的依赖而是模型在生成代码时觉得“这里大概率要有个库”然后硬塞了一个。开发者review的时候看到整段代码结构完整、逻辑顺畅只会检查业务逻辑对不对很少有人去逐一核对“每个import背后有没有真实的包”。我把这个结论发到团队群里结果另外两个后端同事也去查了自己的代码分别又发现了一个js项目里的类似问题——其中一个包名甚至是从某个论坛帖子里“抄”来的但那个名字早被注册成了仿冒包。4.4 第三步清点污染范围锁定风险边界定位到问题后没有急着删包。我先把三个幽灵依赖的全部引用点找出来确认没有真实业务代码依赖它们然后做了三件事第一在requirements.txt里删除三个依赖名。 第二在项目里重新搜索相关import凡是引用幽灵包的代码段要么删掉要么替换成已经验证过的真实库。 第三把 AI 生成的那个utils/cleaner.py打开逐个核对里面每个import的来源避免有“间接幽灵依赖”漏网。这里补充一个排查技巧检查锁文件lockfile里所有传递依赖的“来源字段”。如果是正常安装的包来源会是某个官方索引如果一个依赖的来源指向未知仓库或者根本没有任何来源信息那就得留意了。4.5 这次排查得到的三个教训事后复盘真正让我后怕的不是“发现了一个假包”而是“假包在项目里生活了多久”。这个PR在代码仓库里合并了将近一周CI每天都正常跑过。要不是那个包恰好装不上——可能是抢注者还没上架——我们的安全团队根本不会注意到有一个“不存在的依赖”在生产代码里潜伏了这么久。第二个教训是团队里所有人都看了那个PR却没有任何一个人质疑“这个包为什么没有被lockfile锁定”。因为我们习惯性地认为“能进PR的依赖都是被AI验证过的”而恰恰是AI没有验证任何东西。第三个教训也是最重要的依赖审查不能只靠人工必须变成机器流程的一部分。我把这次排查的脚本固化了下来每次CI构建后自动执行“import集合与已装包集合差集检查”只要出现新的未注册依赖构建直接红。5. 三重防线从生成源头到依赖解析再到持续监控的落地做法为了不让你看完前面那段“惨案”只觉得焦虑我把目前团队在用的一套防护方案完整写出来。思路分三层让幻觉少发生、让假依赖装不进去、让漏网之鱼能被快速发现。5.1 第一重在代码生成阶段给AI“戴上枷锁”AI生成代码这个环节很多团队是完全放任的。开发者把需求贴给AIAI给什么就装什么。想要从源头防住幻觉依赖一定要给AI设定硬性规则。我现在的做法是在团队的AI提示词模板里加了这么几条所有的依赖名必须引用“官方文档中真实存在的包”并在注释中标注来源地址不确定的包名必须显式写出“我无法确认这个包的真实存在性”不得编造禁止生成“看起来像某流行包但其实不是”的相似包名优先推荐已经被项目使用的现有依赖而不是每次引入新包。不要小看这几行提示词。它不能100%消除幻觉但能把AI从“自信地编造”变成“谨慎地提示”。模型本身并不知道什么是对错但它知道“被要求给出来源”时生成倾向于收敛到训练数据中更常见、更真实的包名。更好的做法是在IDE插件层面拦截。现在部分AI编程插件允许设置“自定义规则”你可以配置一个依赖名黑名单/白名单检查在AI返回代码的瞬间对所有的import语句做正则匹配凡是命中“已知真实包名列表”之外的就直接标红提示。这一步相当于把“AI的幻觉输出”卡在进入编辑器之前。5.2 第二重在依赖安装阶段引入“名称合法性校验”这层是目前最有效、最容易被团队接纳的防线。思路很简单在依赖解析和安装之间加一道“名称真实性检查”。具体做法分两步。第一步锁死来源。项目必须使用锁文件requirements.txtpip-tools或者poetry.lock、package-lock.json每次新增依赖必须通过锁文件的更新流程禁止手动往requirements.txt或package.json里塞包名。第二步在CI里加一个“依赖身份”检查步骤。用脚本把锁文件里的每一个包名跟官方源做一次head请求确认能拿到真实的元数据# Python 示例 import json, urllib.request pkg_name your-dependency url fhttps://pypi.org/pypi/{pkg_name}/json try: with urllib.request.urlopen(url, timeout10) as resp: data json.load(resp) print(真实包版本:, data[info][version]) except urllib.error.HTTPError as e: print(包不存在或已下架HTTP状态码:, e.code)这个检查对标的是“新出现在锁文件里的依赖”。对项目里原本就存在的、已经被验证过的依赖可以跳过没必要每次构建都全量检查。对于新增依赖则必须通过真实源验证否则构建直接失败。同时还要给“新增依赖”设一个冷静期。我的习惯是AI建议的新包不在当天引入。先记到待办清单过了24小时如果确实还需要再由人工去官方源查一遍确认包名、作者、最近版本更新时间、star数然后才纳入锁文件。这一步其实是在用“人的慢”对冲“AI的快”。5.3 第三重持续监控“可复现构建”与“依赖血缘”前两层防线防的是引入阶段。但依赖是活的包名今天存在不代表明天还存在今天的作者可信不代表明天依然可信。所以第三层防线是持续监控目的只有一个尽快发现“以前没问题的依赖开始变得不对劲”。我目前用的办法组合构建机每天做一次全量依赖清单快照对比昨天的清单任何新增、删除、版本变更都会单独告警核心服务强制使用hash-pinned依赖锁定——不光锁版本号还锁安装包的哈希值。这样即便上游仓库被投毒拉到本地的安装包哈希对不上构建会直接拒绝定期生成SBOM软件物料清单把每个依赖名、版本、来源、许可证、哈希全部记录在案。安全团队做审计时直接拿SBOM去比对公共情报库就不用每台机器挨个问了。这里多提一句“可复现构建”。如果你的项目不能做到“同一份锁文件在全新环境里安装结果完全一致”那安全审计基本无从谈起。可复现构建是供应链安全的地基不是可选项。在npm项目里建议用npm ci代替npm install它严格按照锁文件安装不会因为环境差异悄悄改版本。Python项目建议用pip install --require-hashes -r requirements.txt或直接上uv前者强制哈希校验后者解析速度快到可以让安全检查频繁跑起来不心疼成本。5.4 给团队流程的“三道硬要求”除了技术手段流程上一定要有制度兜底。我踩过坑之后的团队规范只有三条简单但管用任何AI生成的代码进PR前必须由另一个人类开发者做一次“只审查依赖变更”的专项review不允许混在业务代码里带过锁文件的变更记录与代码变更记录挂钩凡是新依赖都要能找到对应的功能说明和引入理由每个月做一次依赖清点把“没有被任何代码import的依赖”以及“超过半年没有更新的依赖”单独列出来逐项确认去留。这三条制度不重但能逼着团队养成“对依赖敏感”的肌肉记忆。依赖不是免费午餐每一次引入都在扩大攻击面这个账必须有人算清楚。6. 写在最后——AI辅助编程不是毒药但使用的人必须长出抗体从我个人的体感来说AI辅助编程带来的效率提升是实打实的我没有任何劝退的意思。恰恰因为它的效率高我们才必须在“代码产出速度”和“依赖可信度”之间重新寻找平衡。这几个月排查下来我最深的一个体会是AI幻觉在语法层面只是小麻烦在依赖层面是生死问题。语法错了编译器会挡在门口依赖错了它直接绕过编译器住进你的构建环境跟着你的应用一起上线。所以我不建议团队因为怕幻觉就禁用AI更不建议完全信任AI的包名推荐。正确姿势是把它当成一个“有点能力但经常虚报”的下属——它给出的代码要用但给出的依赖必须先验证。最后分享一个顺手的小技巧如果你也在用AI生成代码可以在提示词里固定加一句“不要推荐任何未经我确认的第三方库如果确实需要请先列出三种可选方案让我选择”。这短短一句话能把幻觉依赖的概率压下一个量级。跟我一起排查过问题的那几个同事已经把这个习惯固化成了他们自己的提示词模板到现在也没再翻过车。