576,000个代码撕裂了AI编程的神话，还有20％的“幽

Xin Zhiyuan报告编辑：KingHz [Xin Zhiyuan介绍] AI编程梦是撕裂了！最新的研究使用576,000个代码样本来宣布，超过20％的代码取决于未存在的软件包。捕获的苹果和微软都被抓住了，而元和微软仍在大喊“将来，AI将写95％的代码”。 AI写作代码的神话变成了安全灾难。扎克伯格（Zuckerberg）最近说，该元人士正在开发专门用于编程和研究AI的代理商，而不是通用工具，而是定制的专用代理，以增强自己的AI Meta项目（例如Llama）。他预测，在接下来的12到18个月中，用于开发AI的大多数代码将不再由人类撰写，而是会发展AI代理。扩展全文 微软的预测凯文·斯科特（Kevin Scott）更长，但更勇敢。 在最近的播客中，他估计AI生成的代码将在未来五年中占主导地位，并说： 95％of代码将开发AI，人们几乎没有完全编写Manu -Mano的代码行。 左：微软首席技术官凯文·斯科特（Kevin Scott）；右：播客主持人哈里·斯宾斯（Harry Stebbings） 斯科特（Scott）拥有41年的编程经验，足以让他见证该行业的许多变化。 在1980年代，会议的编程编程开始改变高水平的语言编程。 目前，一些旧程序员会说：“如果您不知道如何编写会议语言，那么您不是真正的程序员，那就是编程的正确方法。” 现在，什么都没有提及。 他认为，AI的兴起与当年的变化没有什么不同。 SC认为，“最好的程序员”迅速适应了AI工具： 起初，开发人员对这些工具持怀疑态度，但是现在他们的态度已成为“除非我死了，否则我不想放弃这些工具。” AI已成为其工具箱不可或缺的一部分。 但是在软件引擎中Ering，“无银弹”：如果开发的次要部分小于整个工作的9/10，那么即使不需要任何时间，也不会带来提高生产率的范围。 正如斯科特所说，“创造力和基本代码设计仍然完全取决于人。” 纸质链接：https：//www.cs.cs.edu/techreports/86-020.pdf 拥有超过25年经验的记者Dan Goodin报道说，AI生成的代码无法替代人类开发人员，但可能有一场灾难性的灾难，可以使软件供应链产生效率。 AI的有害影响 在2025年，美国计算机安全协会安全安全（USENIX SECurity 2025），研究人员计划发表一篇论文，报告“软件包guni -guni”的现象。 USENIX SECURINTTITY 2025将于今年8月13日至8月15日举行 研究表明，AI生成的计算机代码中有对不存在的第三方库的引用，为供应C创造了绝佳的机会海因攻击。 攻击可以使用恶意软件包来毒化合法的程序，从而窃取数据，播种并制造其他恶意行为。 纸张链接：https：//arxiv.org/abs/2406.10279v3 该研究使用16种主要语言模型（LLM）开发了576,000个代码样本。 知道这些示例中包含的44万包依赖项是“幻觉产品”，这意味着它们不存在。 开放资源模型的虚构依赖性比例最高，而生成的代码中包含的依赖项中不存在21％。 新软件攻击：软件包混淆 不存在的依赖关系加剧了所谓的“依赖性混淆攻击”，并对软件供应链构成威胁。 这种攻击的原则是允许包裹访问服装的错误依赖关系。 例如，攻击已发布了恶意软件包，其名称与合法软件包相同，但具有更新的版本号。我在某些情况下，依赖软件的软件包将选择恶意版本而不是法律版本，因为Malisyos版本似乎已更新。 这种攻击方法，也称为“包裹混淆”，首先在2021年的概念证明中提出，成功地在苹果和微软等巨型公司的网络上成功地进行了假代码。 这是一种软件链攻击，目的是污染软件资源并向流的所有用户传染。 软件链攻击的一般步骤 “当攻击使用一个虚构的软件包名称发布包含恶意代码的软件包，并依靠该模型向毫无疑问的用户推荐名称，如果用户在没有仔细验证的情况下安装软件包，则隐藏在用户系统中的恶性代码将保存在用户系统中，”研究。” 软件包幻觉有多严重？ 为了评估包装问题的严重性，研究人员测试了16代AI CODE（包括GPT-4，Claude，Codellama，DeepSeek Coder，Mistral等），并使用两个唯一的提示形成了576,000 Python和Java代码样本。 结果表明，几乎有20％的推荐软件包不存在。 研究发现，虚构软件包的比例在不同的LLM和编程语言之间差异很大。 开放资源模型的平均虚构比例接近22％，而业务模型略高于5％。平均小说 - Python代码比例为16％，小于2乘Java1％。 这种差异可能与模型和培训数据的复杂性有关。 商业模型（例如ChatGpt系列）通常比开放资源模型多10倍以上，并且大量参数可以减少幻觉。此外，培训数据，微调和安全优化也会影响虚构的比例。 至于Java的小说与Python的比例，研究认为这是Asso与Java生态系统中的软件包数量（约10倍）和命名空间复杂性介入。 较大的软件包生态系统和复杂的命名增加了模型准确召回软件包名称的难度，从而增加了小说比例的增加。 Python和Java代码中不同语言模型的幻觉率 如果LLM重复重复幻觉，则培养了同一包装，研究人员通过500个幻觉 - GM随机选择，可以激发线索并重复每个提示的查询10次。 转动： 在10个查询中反复提到了43％的幻觉套餐-Guni； 39％的幻觉包装在10个查询中完全未指定； 在10次迭代中，有58％的幻觉 - 枪中重复一次不止一次提及。 在10个查询中反复提到了43％的幻觉套餐-Guni； 39％的幻觉包装在10个查询中完全未指定； 幻觉的58％ - 在10次迭代中，冈尼（Guni）被重复地提到了一次以上。 “这表明大多数幻觉不是随机错误，而是反复的持续现象。这种持久性对于恶意攻击更为重要，使其更加现实。 尽管许多模型在某些情况下可能会看到自己的幻想，但问题在于，许多开发人员依靠AI来生成代码并盲目信任AI输出。 “炼金术”很难消除 在AI字段中，当大语模型产生的输出结果不正确，毫无意义或与分配给其的任务完全无关时，就会发生“幻觉”的现象。 长期以来，“幻觉”已经发生了大型语言模型，因为它降低了模型的实用性和信誉。事实证明，LLM“幻觉”很难预测和解决。 幻觉软件包是否可能是从删除软件包到假装数据的？ 研究人员发现DeleTED软件包为幻觉贡献了“非常小”。 他们还发现了“跨语言幻觉”：以编程语言的幻觉的幻觉名称，以另一种语言的包裹的名称相同。 幻觉效果在Java中更为常见。 此外，大多数幻觉的幻觉与现有包装名称“大不相同”，但是这些名称通常令人信服并且对上下文高度敏感。 对于使用LLM的开发人员，研究人员的建议是：在使用AI推荐的代码以避免陷入供应链攻击的陷阱之前，请仔细检查建议的软件包是否存在。 开发人员保持警惕和经过验证，可以有效地降低软件包幻觉引起的安全风险，并确保Codelahat可靠的安全性。 参考： https://arstechnica.com/security/2025/04/ai-generated-tode-can-be-be-a-disaster-for-the-software-toupsly-toupsly-chain-hes-为什么/ https://www.helpnetsecurity.com/2025/04/14/package-hallucination-lopsquatting-malicious-code/ https://x.com/wesrothmoney/status/1917370974032519547 https://www.youtube.com/watch？