打开APP

Anthropic源码泄露后续:爆破数千个代码仓库,开发者集体怒了

2026年3月31日,Anthropic旗下Claude Code因打包错误致51万行源代码泄露,维权时误删数千合法仓库,此前OpenClaw、亚马逊也因AI出问题,引发对AI管理使用的思考。

就在前天,一场堪称AI行业“核弹级”的乌龙事件,彻底打破了硅谷大模型圈的平静。明星AI独角兽Anthropic旗下的核心产品——Claude Code(AI编程助手),竟然因为一次极低级的打包错误,将其最核心的51万行源代码直接“开源”到了公共网络上。

不过,这还仅仅是开始,更搞笑的是Anthropic在事发后的“抢救”措施:为了能够将自己的源代码从Github上下架,他们启动了DMCA(数字千年版权法)投诉工具,结果变成了“无差别攻击”,直接导致数千个合法的、无辜的GitHub开发者仓库被连坐误删。

科技圈常说“技术无罪”,但当*的AI公司也开始频频翻车时,我们不得不重新思考一个问题:在这个越发依赖AI的时代,我们是否应该将整个AI系统的安全,寄托在少数几个人或者企业的身上?

不止源代码泄露!多个BUG被曝光

说实话,在一开始知道Claude Code源代码泄露后,雷科技(ID:leitech)以为是哪个神通广大的黑客把Anthropic的服务器攻破了,结果在详细了解后才发现,这纯粹就是一次“低级错误”。

根据Anthropic官方的公告,此次泄露事件发生在2026年3月31日。当时,Anthropic在npm代码库中推送了Claude-code 的 v2.1.88 版本更新。在此次更新中,Anthropic使用了前段时间收购的Oven公司开发的Bun工具,该工具在运行时错误地将一个完整的JavaScript source map 文件(通常用于内部调试,包含了完整的原始未混淆代码映射)一同打包发布了出去。

0_XOOO4k6O8i00OO0e.jpg

图源:Claude

这一“手滑”,直接导致Claude Code内部近2000个源代码文件、超过51.2万行的专有 TypeScript 源代码直接暴露,所有人都可以查看、复制和使用。

更尴尬的是,泄露的代码中还暴露了Anthropic的一些“小心思”。比如,代码中包含了一个名为“Undercover Mode(卧底模式)”的系统设定,该设定的内部指令要求AI在参与开源社区代码贡献时,必须“隐藏自己是AI的身份”,并禁止使用常规的“Co-Authored-By: AI”标签。

这种为了绕过开源社区人类开发者审查而设计的隐蔽机制,直接引发了开发者社区关于*AI公司隐藏身份参与项目维护的争论。毕竟真要说的话这多少有些不道德,你技术再强也不应该无视别人的社区规定,更何况从泄露的代码来看还是“全自动执行”的。

除此之外,还有一个更让开发者恼火的BUG,该BUG是开发者对泄露代码检查时发现的,它会导致Claude Code在恢复会话时错误地出现“缓存未命中”的问题。

简单来说,这个BUG会导致Claude Code把你之前已经花Token执行和推理过的问题,全部再计算一遍。要知道,全量推理和缓存命中之间的Token价格可是差了10倍,你原本打算在接下来10天使用的Token余额,可能会在1天内就消耗殆尽。

这个BUG被曝光后,不少开发者就马上吐槽说:“怪不得我觉得客户端的Token消耗比网页版快得多,原来真有问题”。而且在对BUG进行回溯后,开发者发现这个BUG早在v2.1.69版本中就存在,直到因为源码泄露被查证后,Anthropic才在后续发布的2.1.90版本上修复。

那么问题来了,Anthropic到底知不知道BUG的存在呢?这就是个耐人寻味的问题了。因为后续开发者们还发现一个问题,那就是Claude Code 会在系统提示词的*块中强行插入一个名为 x-anthropic-billing-header 的字符串。

这个字符串会导致每一个新开启的对话,系统提示词前缀都是*且不同的。也就是说,即使你的提示词都是一样的,Claude Code也会进行一次全量写入,消耗更多的Token,以至于现在不少开发者都对Anthropic产生了怀疑:这货不会在偷偷地坑我们钱吧?

只能说,这次代码泄露对于开发者来说基本没啥坏事,甚至可以说都是“好事”。只是Anthropic就头疼了,当然,让他们更头疼的事情还在后面。

Anthropic维权“无差别轰炸”惹怒开发者

面对这种战略级知识产权的“大出血”,Anthropic的反应可谓是“病急乱投医”的典范。

在代码泄露的数小时内,不少开发者和安全研究人员已经将其下载并镜像到了GitHub等平台。部分泄露仓库的Star数在极短时间内突破数万,甚至催生了去除官方安全限制、解锁实验性功能的所谓“破解版”。

为了遏制代码的进一步扩散,Anthropic向GitHub发起了大规模的DMCA(数字千年版权法)下架要求,然后一场悲剧就这么发生了。

据海外网站的知情者透露,Anthropic在执行代码清理时,极度依赖于自动化的代码比对与举报脚本。这些自动化工具的识别逻辑过于简单粗暴:只要在代码库或README说明文件中检测到包含泄露代码的片段或特定关键词,该仓库就会被直接判定为“侵权”。

这种缺乏人工“合理性检查”的自动化维权,直接演变成了一场大规模的GitHub仓库爆破行动。GitHub方面的初期报告显示,在短短一小时内他们就处理了涵盖超过8000个仓库网络的DMCA通知。

数千个合法开源项目,就因为撞上了自动化脚本的“枪口”而被封禁或强制删除。其中大多数都是基于 Anthropic 官方公开 API 开发的开源项目,甚至还有 Anthropic 官方自己的部分公共示例库派生版也被意外屏蔽,属于是大水冲了龙王庙。

面对这样的无差别轰炸,众多受害者在社交媒体和论坛上发起了强烈的抗议,指责Anthropic这种“先斩后奏”的粗暴手段是滥用版权法,不仅给无辜开发者带来了严重的代码丢失风险和业务停滞,更是严重损害了开源生态的基石。

面对汹涌的舆情和大规模的误伤,Anthropic不得不再次做出紧急回应,与GitHub沟通并撤回了大部分的DMCA通知(缩减至几十个确切的镜像分支),并承认自己的做法有欠妥当,后续将加强对相关流程的审核与管理。

不过,此次事件的影响还远不止于此。网络安全机构Zscaler ThreatLabz的报告显示,黑客组织已经开始利用开发者的好奇心,在GitHub上发布伪装成“Claude Code泄露版”的恶意仓库,实则内置了Vidar和Ghostsocks等窃密软件。善后处理估计还要不少时间。

AI翻车不是*次,也不是最后一次

在雷科技(ID:leitech)看来,Anthropic这次大翻车,说白了还是“对自动化工具和AI脚本的盲目信任”(虽然人类闯的祸也不少)。事实上,在整个科技与商业领域,因为过度迷信AI和自动化系统、减少甚至完全取消人工复核而导致企业损失惨重的事件,早已屡见不鲜。

举个最近的例子,年初爆火的OpenClaw在3月22日上线了一个号称“史上最强”的版本更新,并且自豪地宣布该版本的核心引擎95%以上的代码由AI完成。然后,AI在干活时觉得之前的AI与人类合作写的代码过于低效,于是自行决定废弃旧有的Skill API标准,重新编写了一套它认为更高效的新API。

于是,OpenClaw最引以为傲的一万多个Skill就这么全部被废弃了,如果想继续使用就要基于新的API做新的调用和优化。由于其本就以全自动化运行著称,很多部署了OpenClaw的企业一觉醒来,就发现自己的工具全部罢工,只因OpenClaw自动更新了版本并执行了相关操作,导致所有Skill直接失效。

不止如此,OpenClaw的AI在编程时还为了“高效”,私自关闭了多个关键的沙箱隔离权限,导致新版本存在更严重的安全问题。看到这里你可能会想,那我们回滚到上个版本不就好了?问题就在这里,AI重构后的数据库与旧版本不兼容,用户想回滚的话就要面临数据损坏的风险。

虽然后续OpenClaw发布了一个新的兼容层,但也只能挽回部分损失,以至于不少用户都跑路到了以“更严格的人工审核”著称的Claude Code(没错,就是今天这篇文章的主角)。结果没过多久Claude Code也暴雷了。好在这次与生产力无关,亏的只是Anthropic。

这次事件后,多数主流开源社区都发布了关于AI生成代码的相关准则与规定,强制要求所有基于AI的提交都必须经过人工审核,并且配备自动化回归测试模块。

还有亚马逊,从去年12月开始到今年的3月就已经爆了两次大雷。一次是AWS工程师在使用其自研的Kiro AI编程智能体时,“不小心”直接删除并重建了整个生产环境,导致AWS成本管理服务在部分区域遭遇13小时的中断。

第二次则是工程师在处理紧急部署需求时,由于过分相信AI助手给出的建议,导致亚马逊主站的核心结账逻辑与物流预测系统发生冲突。据后续统计,有12.5万个订单直接丢失,还有超过600万个订单因此延误或出错。

事后亚马逊查明,问题根源在于AI错误引用了一份过时的内部文档,导致部署代码与现有系统产生严重冲突,最终引发系统宕机。事实证明,即使有人类在一旁监督管理,如果其本身过分相信AI的话,结果并不会因此有所改变。

一连串的问题最终也让不少人开始思考:我们到底该如何管理和使用AI的这份能力呢?

解铃还须系铃人,AI问题AI治?

面对这一连串因为“盲信AI”而导致的史诗级灾难,一个悖论就摆在了整个科技圈面前:随着AI的代码生成能力越来越强、逻辑推演越来越复杂,人类开发者审查AI操作的成本正在呈指数级上升。

既然人类已经快要看不懂、也审不过来AI生成的海量代码与指令了,那么AI惹出的麻烦,最后难道只能靠更强大的AI来解决吗?在雷科技(ID:leitech)看来,答案既是肯定的,也是否定的。

首先从现实工作的角度来看,引入AI审查是必然的。“AI监督AI”也是目前大多数头部科技企业的做法之一:通过多个AI智能体的交叉验证后,再把疑似有问题的代码提交给人类工程师进行最后的复核,这样就能降低AI幻觉导致的误判问题出现的概率。

不过,只有这个还是不够的,因为Anthropic、亚马逊等企业的教训告诉我们,即使有人工复核,问题一样可能出现。所以更重要的是加入多道防火墙,比如严格遵守“最小特权原则”,对AI绝不能开放过多的权限,避免它在无人干预的情况下自行修改核心数据库和生产环境。

此外,*是加入由独立系统负责的“熔断机制”,当系统监测到异常且大量的高危指令时,直接暂停所有指令的执行,并立即通知人类工程师对指令进行复核。如果Anthropic在大范围投诉GitHub仓库侵权时有类似的机制(比如请求投诉超50个仓库后需要人工确认),估计后续的问题也就不会出现了。

最后,还是需要把责任落实到人的身上。作为AI的使用者与管理者,不能用一句“都是AI干的”来撇清责任,这样至少能让人类工程师在使用AI的时候,保持谨慎且小心的态度,避免因为过于信任AI而翻车的情况出现。

雷科技(ID:leitech)认为,AI虽然以颠覆性的方式重塑了我们的生产力,但是人类才是真正的主导者,这一点是不会变的。

【本文由投资界合作伙伴雷科技授权发布,本平台仅提供信息存储服务。】如有任何疑问题,请联系(editor@zero2ipo.com.cn)投资界处理。

相关资讯

相关企业

AI数据总览

帷幄杭州帷幄未来科技有限公司
融资时间2026-07-15 当前轮次C+++轮 融资金额4000万美元
AI
涉及机构: 招银国际(CMB International CMBI) 旗下专注于 AI 及前沿科技的基金日本三井住友银行 (Sumitomo Mitsui Banking Corporation SMBC) 旗下企业风险投资基金 SARF (SMBC Asia Rising Fund)三菱 UFG (MUFG) 旗下泰国大城银行 (Bank of Ayudhya) 企业创投 (CVC) 平台 Krungsri Finnovate弘章投资 (Charisma Partners)韩国现代汽车集团 (Hyundai Motor Group) 新加坡电信 (Singtel Innov8)
面壁智能北京面壁智能科技有限责任公司
融资时间2026-07-15 当前轮次战略融资轮 融资金额未披露
AI
涉及机构: 国家级基金央企汽车制造商等各类产业方知名财务投资人
知有无界知有无界(深圳)智能科技有限公司
融资时间2026-07-15 当前轮次天使+轮 融资金额数千万人民币
AI
涉及机构: 元禾璞华深圳新产投
幻码跃迁上海幻码跃迁量子科技有限公司
融资时间2026-07-14 当前轮次种子轮 融资金额数千万元
AI
涉及机构: 光源成长基金云启资本小苗朗程
爱诗科技北京爱诗科技有限公司
融资时间2026-07-14 当前轮次C轮 融资金额29.8 亿元人民币
AI
涉及机构: 阿里巴巴领投Lollapalooza Capital(王慧文家办)常春藤资本惠远资本钟鼎资本韩国未来资产OCBC 生态下 Lion X 基金蓝色光标CloudAlphaiGlobe Partners 等参与

最新资讯

热门TOP5热门机构 | VC情报局

去投资界看更多精彩内容
【声明:本页面数据来源于公开收集,未经核实,仅供展示和参考。本页面展示的数据信息不代表投资界观点,本页面数据不构成任何对于投资的建议。特别提示:投资有风险,决策请谨慎。】