虚构包：生成代码的供应链风险

虚构包是生成代码将实际上不存在或被恶意创建的依赖项以安全可用的方式推荐的现象。 当模型以令人信服的方式在代码中插入一个从未发布过的库名时，该名称便不再只是猜测，而成为一个可达的地址。如果有人去填充那个地址，那么所建立的东西就不再是建议，而是一个正在运行的供应链漏洞。风险并非源自代码本身，而是起于对代码的反射性信任。

• 生成的代码容易以安全自信的语气建议不存在的包名。
• 同一个虚构名称在不同查询中重复出现时，会成为一个可预测的目标。
• 空置的名称会归属于第一个填充它的人的控制。
• 危险不在于安装时，而在于对安装结果的放任不查时才显现。
• 验证要求不是假定来源为真实，而是去检验它的真实度。
• 人工审查是最容易被跳过的步骤，因此也是最昂贵的缺失。

虚构包到底指的是什么？

虚构包是指生成模型将不存在的依赖项当作已存在的事实来提出。其决定性特征不是名称的拼写错误，而是以确信无疑的方式呈现错误名称。模型不会附带不确定性的提示；输出以与真实库相同的自信和相同的形式出现。

这种现象常以一种模式重复出现。对同类问题往往会反复建议同一个捏造名称，因为模型遵循语言概率而非现实。重复在此处至关重要。一次出现的错误名称只是一个错误；而在数百次输出中反复出现的相同错误名称则成为一个可预见的攻击面。

将该现象与相邻问题区分开来是有帮助的。虚构包不是拼写错误；拼写错误是对已存在名称的损坏，而虚构名称并不对应任何真实实体。也不是版本混淆；此处缺失的不是版本，而是库本身。区分看起来细微，但在防御上决定性：填充一个空名称比模仿已有名称要更为悄无声息。

需要澄清的一点是：虚构名称的危险不在于模型犯错本身，而在于该错误以一致、有形式感且令人信服的外壳出现。一个不存在的库会携带真实库通常具备的所有表面特征：合理的名称、熟悉的格式、能顺畅嵌入代码的调用。正因如此，虚构包不像代码错误那样显眼，而更像是一个有效的建议。该现象在防御价值上的要点就在这里：问题不在于输出错了，而在于错误以与正确相同的形式出现。

重复出现的虚构名称为何会成为目标？

重复会把一个虚构名称从无害的错误转变为稳定可利用的表面。当模型在特定需求场景中不断建议同一个不存在的名称时，该名称就不再是偶发的。它变得可预测，而可预测性对攻击者与防御双方都构成杠杆。

其机制基于简单观察。生成系统会选择最可能的续写，因此相似的请求会产生相似的输出。这种一致性通常是一种优点。然而，当它应用于不存在的名称时，同样的一致性会预先宣布一个地址。一个名称多次以相同形式出现，向可能去填充它的人发出邀请而不是随机提示。

这里的关键在于意图与机会之间的空档。模型本身并非恶意；它只是遵循概率。但每一个空置且重复出现的名称都会成为容纳他人意图的容器。防御的焦点因此不是捕捉单一错误，而是使得重复出现的空名称不易被悄然占有。一个需求不断产出相同解决方案看似令人宽慰；但这种宽慰正是放松审查的根源。

对生成代码的信任在哪里滑落？

信任的滑落并非在安装时发生，而是在阅读时开始。一段流畅且无瑕的输出，会被读者以与已验证输出相同的感觉来解读。形式的光滑常被误认为内容的真实性。正是这种混淆，让虚构名称未经审查便通过成为可能的唯一缺口。

起作用的是一种心理捷径。人们对自信的来源提出的问题比对谨慎的来源要少。生成的代码几乎总是显得自信，因为它很少显露不确定性。因此，读者往往在最需要质疑的地方反而最少质疑。信任转移发生在这里：从证据转向语气。

另一种滑落来自规模。单一建议易于复核，但在数百行生成代码中，单个名称并不显眼。当体量稀释了审查时，验证显得代价高昂，而看起来代价高的步骤最先被省略。这里暴露出的权衡是：随着速度提升，逐一检验每个名称的意愿下降，而风险恰恰在这被省略的检验中积累。

还有一种隐蔽的滑落来自于接力。生成的代码通常不会孤立存在；它成为下一次生成的输入、下一个请求的基础。未经验证的名称一旦进入，就会被周围的一切当作常态来承载。于是一次无审查的输入，便悄然地遗留给随后的所有步骤。信任真正滑落的地点往往不是最初的错误，而是该错误被不加质疑地接纳。

哪种验证纪律能缩小这一表面？

验证纪律是一种习惯，即不是假定来源为真实，而是明确去检验它。该原则简明：不要仅因名称看起来可信就赋予信任。每一项依赖在进入代码前，都应与真实的历史相连，而这种连接应是证据而非猜测。

该纪律在三个层面上运作。第一是来源审查：该名称是否对应存在且可追溯的历史？第二是对重复性的警觉：同一个虚构名称被反复建议时，不应让人放松，反而应提高警戒。第三是人工审查——这是最容易被跳过、因此最宝贵的层面。三层共同目标是：把信任从语气拉回到证据之上。

依赖幻觉

生成代码倾向于将不存在的库当作真实存在来推荐的现象。

来源信任

基于可追溯真实历史而非外观的信任。

悄然接管

重复出现的空名称被首个填充者在不被察觉的情况下接管。

这些层面不是障碍而是过滤器。目的不是放慢生产，而是将输出的可信语气与其真实度之间的鸿沟显化。过滤的成本很低，但被跳过的代价是延迟且巨大的。

该纪律的真正力量不在单次操作，而在成为习惯。偶尔执行的验证总比完全不做要好一点；因为危险就是藏在那唯一被忽视的名称里。检验只有在成为反射动作时才有意义：每个被建议的名称都按其能展示的历史而非其展现的自信来被默认评估。该态度一旦建立，令人信服的名称无条件通过将成为例外而非规则。捕捉例外要比每次都重建规则便宜得多。

在依赖进入代码前应遵循什么顺序？

审查顺序应在名称进入代码前启动，而非在首行编写前就滞后。错误不在于使用生成的代码；错误在于在未经任何检验的情况下把建议的名称视为真实。一个小而固定的流程，可以阻止这种悄然接管演变成昂贵的意外。

1. 将每个被建议的依赖名称从输出中分离出来，明确记录并标记。
2. 核查每个名称是否对应真实、可追溯的历史来源。
3. 有意识地检查该名称是否在先前的生成中重复出现。
4. 若某来源无法验证，将该名称提交人工审查而非直接信任。
5. 仅将通过证据检验的名称纳入代码；其余的保留为待答问题。

该顺序的重要性在于：默认情况下昂贵错误容易发生。当没有任何事物被明确检验时，令人信服的名称会自然而然地被接受。把验证从需要勇气的单次决定变成一种习惯，是缩小该表面的唯一可靠方法。

顺序之外还有一条文化层面的因素。团队往往奖励已写出的内容，而很少奖励被质疑并被拒绝的建议；因此不经审查的信任会作为常规激励的副产物累积。将被拒绝的名称视为与被接受的名称同等有价值，有助于维持纪律。没有这种文化，生成最快的代码将成为最昂贵的代码。

顺序还是一种可视化的工具。将被建议的名称从输出中分离并明确标注，会将审查与一个意图关联起来；此名称不再在上百行中隐没，而成为一个独立的决策点。这一小小的分离动作，会把验证从抽象的善意变成具体的步骤。看不见的事物无法被质疑；因此首要任务是让被质疑的事物变得可见。

由虚构包塑造的风险面向何方？

随着生成变得普及，名称是否真实这一问题将不再是边缘细节，而成为中心化的纪律课题。趋势指向一个平衡：生产变得越来越廉价，而信任的获取却变得愈发昂贵。难点不在于写出代码，而在于判断哪些名称确有其物。

有两股压力会变得尖锐。其一是卫生问题：重复出现的虚构名称群体会形成一片静候被占有的表面，而对来源的审查会变成与命名习惯一样基础的日常操作。其二是在低成本下的判断。当一切都能快速生成时，稀缺的不是生产能力，而是辨识何者经真实验证的能力。

更细微的滑落也许最关键。随着输出流畅性的提升，流畅本身不应该再被视作信任的指标。信任应基于可追溯的历史而非语气，而保持这一区别正是该领域成熟度的真正尺度。故事的价值不在于一切都能被生成，而在于信任需要被赢取、被命名并被捍卫。

这一转变还有其共有的方面。当名称的真实性不再托付于单一审查者时，脆弱性就会减弱；相同名称在多个独立点被重复验证，会让它慢慢稳固。供应链的弹性来源不是单一门的坚固，而是不同地点反复检验同一名称的共同习惯。随着领域成熟，验证会从个人美德转变为共同的态度。一个名称在越多地方被检验，悄然接管能找到的缝隙就越窄。

并不表示总是拒绝生成的代码就是一种美德。生产是一种手段，如同其它工具一样可以被误用；最常见的误用就是在没有任何检验的情况下接纳令人信服的名称。该领域的成熟体现在：当它生产得更多时，仍会诚实地回答每个被建议的名称是否真实存在的问题。