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

就在前天，一场堪称AI行业“核弹级”的乌龙事件，彻底打破了硅谷大模型圈的平静

明星AI独角兽Anthropic旗下的核心产品——Claude Code（AI编程助手），竟然因为一次极低级的打包错误，将其最核心的51万行源代码直接“开源”到了公共网络上。

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

科技圈常说“技术无罪”，但当顶级的AI公司也开始频频翻车时，一个严肃的问题就摆在了面前：在这个越发依赖AI的时代，我们是否应该将整个系统的安全，完全寄托在少数几个人或者企业的身上？

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

起初，外界猜测Claude Code源代码泄露，或许是某个神通广大的黑客攻破了Anthropic的服务器。但深入了解后才发现，这纯粹是一次“低级错误”酿成的闹剧。

根据Anthropic最新的公告，此次泄露事件发生在2026年3月31日。当时，团队在npm代码库中推送Claude Code的 v2.1.88 版本更新。在此过程中，他们使用了此前收购的Oven公司开发的Bun工具。问题就出在这里：该工具在运行时，错误地将一个完整的Ja vaScript source map 文件（通常用于内部调试，包含了完整的原始未混淆代码映射）一同打包发布了出去。

图源：Claude

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

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

这种为了绕过开源社区人类开发者审查而设计的隐蔽机制，直接引发了开发者社区关于顶级AI公司隐藏身份参与项目维护的伦理争论。毕竟，技术再强也不应无视社区规则，更何况从泄露的代码来看，这一过程还是“全自动执行”的。

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

简单来说，这个BUG会让Claude Code把你之前已经花费Token执行和推理过的问题，全部重新计算一遍。要知道，全量推理和缓存命中之间的Token成本可能相差十倍。这意味着，你原本计划使用十天的Token余额，很可能在一天内就消耗殆尽。

图源：网络

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

那么，Anthropic到底是否知晓这个BUG的存在呢？这就成了一个耐人寻味的问题。因为后续开发者们还发现了另一个细节：Claude Code 会在系统提示词的第一块中，强行插入一个名为 x-anthropic-billing-header 的字符串。

这个字符串会导致每一个新开启的对话，其系统提示词前缀都是唯一且不同的。也就是说，即使你的提示词内容完全一致，Claude Code也会进行一次全量写入，从而消耗更多的Token。这一发现让不少开发者心生疑虑：这会不会是在变相增加计费？

可以说，这次代码泄露对开发者社区而言，某种程度上揭开了黑箱，甚至算得上是“好事”。只是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翻车不是第一次，也不是最后一次

Anthropic这次大翻车，根源在于对自动化工具和AI脚本的盲目信任（当然，人类操作失误也“功不可没”）。事实上，在整个科技与商业领域，因为过度迷信AI和自动化系统、减少甚至完全取消人工复核而导致企业损失惨重的事件，早已屡见不鲜。

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

于是，OpenClaw最引以为傲的一万多个Skill就这么全部失效了。如果想继续使用，就必须基于新的API重新进行调用和优化。由于其以全自动化运行著称，许多部署了OpenClaw的企业一觉醒来，就发现自己的工具全部罢工，只因系统自动更新了版本并执行了相关操作。

图源：网络

不止如此，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来解决吗？从现实角度看，答案既是肯定的，也是否定的。

首先，引入AI审查是必然趋势。“AI监督AI”也是目前大多数头部科技企业正在实践的方法：通过多个AI智能体的交叉验证后，再把疑似有问题的代码提交给人类工程师进行最终复核，以此降低因AI“幻觉”导致误判的概率。

图源：网络

不过，仅有这一步是远远不够的。Anthropic、亚马逊等企业的教训表明，即使存在人工复核环节，问题一样可能出现。因此，更重要的是构建多道防火墙。例如，严格遵守“最小特权原则”，绝不能对AI开放过多的系统权限，避免它在无人干预的情况下自行修改核心数据库和生产环境。

此外，最好能引入由独立系统负责的“熔断机制”。当系统监测到异常且大量的高危指令时，直接暂停所有指令的执行，并立即通知人类工程师进行复核。试想，如果Anthropic在大规模投诉GitHub仓库时设有类似的机制（比如请求投诉超过50个仓库后需要人工确认），后续的误伤风波或许就能避免。

最后，责任必须落实到人。作为AI的使用者与管理者，不能用一句“都是AI干的”来撇清责任。明确的问责机制，至少能让人类工程师在使用AI时，保持必要的谨慎和警惕，避免因过度信任而翻车。

归根结底，AI虽然以碘伏性的方式重塑了生产力，但人类才是这场变革中真正的主导者与责任主体，这一点永远不会改变。