Claude Code源码泄露的来龙去脉和反思

“

一家强调”安全第一”的AI公司，在五天内泄露了两次。

开篇：史上最尴尬的”开源”

2026年3月下旬，一件技术圈的”名场面”悄悄发生了。

有人在NPM上下载 @anthropic-ai/claude-code 这个包，准备正常安装，结果打开一看：哇，这包怎么这么大？

不是因为依赖臃肿，而是因为——Anthropic不小心把Claude Code将近50万行内部源码、1000多个相关文件，全部打包进去，公开发布到了全球最大的JavaScript软件包仓库上。

任何人，只要 npm install，就能把这份”意外礼物”下载回家。

更戏剧性的是，这不是Anthropic当月的第一次泄露。

就在几天前，这家公司刚刚因为内容管理系统的默认配置问题，把接近3000份内部文档意外公开，其中包括一个神秘的新模型”Claude Mythos”的详细技术博客草稿——一个被内部描述为”迄今最强大、网络攻防能力远超所有现有模型”的产品，就这么提前”官宣”了。

五天之内，泄露了两次。一家公司，一个月内两度以这种方式登上科技媒体头条。

最妙的是，这家公司的第一原则，是”安全第一（Safety First）”。

我不是要嘲笑Anthropic。我只是觉得，这件事里藏着太多值得认真聊的东西——关于工程文化、关于开源的边界、关于AI公司在高速扩张期会面临的真实挑战。

让我们从头说起。

▲ 这不是开源，这是”意外开源”

第一章：事件经过——五天两次，怎么发生的

第一次：Mythos模型文档泄露（2026年3月27日前后）

根据The Decoder（2026年3月27日）和Fortune的报道，Anthropic的内容管理系统存在一个配置失误：默认设置将上传的文件自动公开，导致近3000份内部文档在无意间对全网可见。

被曝光的核心内容，是两篇几乎完全相同的博客草稿——标题分别是”Claude Mythos”和”Claude Capybara”（Anthropic似乎还没决定用哪个名字）。

文章里写了什么？

按照The Decoder的报道，这份草稿描述了一个全新级别的模型，”比现有的Opus系列更大、更智能”，在软件编码、学术推理和网络安全测试上”取得了远超任何此前模型的戏剧性更高分”（dramatically higher scores）。

更敏感的是，草稿还提到这个模型”在网络攻击能力上，目前远领先于任何其他AI模型”，并且”预示着一波即将到来的、能以防御者难以追赶的速度利用漏洞的模型浪潮”。

Anthropic在Fortune首发报道后向其确认：公司确实在训练和测试一个新模型，并称其为”迄今为止我们构建的最具能力的模型，在推理、编码和网络安全方面有实质性进展。”

但这些话，本来不应该是这样被公众知道的。

第二次：Claude Code源码泄露（2026年3月31日）

根据The Decoder（2026年3月31日）的报道，开发者们在NPM上发现了异常——Anthropic在发布Claude Code的NPM包时，意外将内部远超预期的大量文件打包进去：

• 50万行以上的源代码
• 1000多个相关文件
• 工具工作原理的详细信息
• 对尚未发布的模型和功能的引用

NPM是全球最主要的JavaScript/Node.js软件包仓库，完全公开。任何开发者只需执行一条标准的安装命令，就能将这批文件全部下载到本地。

Anthropic的官方声明很简短：这是”人为失误“造成的，并非安全漏洞，没有客户数据受到影响，公司正在制定措施防止类似事件再次发生。

就这些。

第二章：技术拆解——”人为失误”的背后是什么

“人为失误”是一个非常方便的说法。它听起来像是”有人按错了按钮”，但实际上，任何一次工程事故，背后都是系统性问题的显性化。

让我们拆一下这两次泄露的底层逻辑。

NPM包发布的技术背景

NPM包的发布，通常通过 .npmignore 文件或 package.json 里的 files 字段来控制”哪些文件应该被打包发布”。如果这两处配置不正确，或者根本没有配置，npm publish 会按照默认规则打包——这个默认规则会包含相当多你可能并不想公开的东西。

Claude Code在GitHub上的仓库（anthropics/claude-code，截至2026年3月Star数已达94,600+）是公开维护的，但”公开仓库”和”公开发布的npm包”应该包含哪些文件，是两回事。

问题的核心在于：内部构建产物、未发布功能的引用、工具实现细节，这些东西本不该出现在一个公开的npm包里。

这说明什么？大概率是构建与发布流程里缺少了一道”发布前检查”的关卡——比如：

• 没有强制审查 .npmignore 配置的流程
• 没有对发布包内容做自动化的白名单校验
• 没有发布前的人工二次审核

在一个高速迭代的团队里，这类”流程没跟上速度”的问题，比人们想象的更常见。

CMS配置泄露的技术背景

第一次泄露（Mythos文档）的原因更典型：默认安全设置不够保守。

内容管理系统的一个字段默认为”公开”，而不是”私有”——这是无数企业SaaS产品里反复出现的安全隐患模板。人的本能是”按默认配置用”，尤其是在赶时间的时候。

这两次事故，技术原因不同，但有一个共同点：流程的松散，让人类错误获得了显现的机会。

▲ 不是黑客入侵，是大门没锁

第三章：泄露的内容有多敏感——该怎么评估

这里要做一个冷静的区分。

什么是真正敏感的

1. 对未发布产品的引用：Claude Code的NPM包里包含对尚未发布的模型和功能的引用，这让竞争对手提前知晓了Anthropic的产品路线图。在AI军备竞赛的当下，这不是小事。

2. Mythos/Capybara的能力描述：草稿里关于这个模型”网络攻击能力远超所有现有模型”的表述，本身就具有相当的战略敏感性——不只是商业机密，某种程度上也涉及安全讨论的边界。

3. 内部工程实现细节：50万行源码里，可能包含特定的算法实现、工程架构选择等技术资产。这是Anthropic投入大量工程资源的成果。

什么没有想象中那么严重

Anthropic的声明说”没有客户数据受到影响”，这一点值得认真对待。Claude Code是一个在终端运行的编程工具，它的NPM包里不该包含客户的代码或对话数据——而从目前报道来看，确实没有证据显示用户个人数据被泄露。

另外，关于”源码泄露”：需要注意的是，Claude Code的工具层代码（Terminal agent框架、与Claude API的交互方式等）和模型权重是两码事。泄露的是工具的工程实现，而不是让Claude聪明的那部分参数。

用一个比方：这相当于泄露了一把锁的机械结构图，而不是解锁的密码本身。

但”相对没那么严重”并不等于”无所谓”。

第四章：讽刺的结构——”安全第一”公司的安全困境

这是整件事最值得深思的层面。

Anthropic是目前AI行业里在”安全”议题上最高调的公司之一。它的公司使命明确写着以”负责任的方式开发AI”为核心，它雇用了大量专门研究AI安全的研究员，它定期发布关于AI对齐、AI风险的深度研究报告。

然而，就在公司标榜安全理念的同时，基础的工程操作安全（operational security）——比如”不要把内部文档设成默认公开””发布NPM包之前检查里面有没有内部文件”——却出现了漏洞。

这不是什么致命的矛盾，但它揭示了一个现实：

AI安全（AI Safety）和工程安全（Operational Security）是两套不同的能力体系。

一家公司可以在AI对齐研究上做到世界顶尖，同时在工程流程管理上存在人手不足、流程不健全的问题。这两者不互斥，但也不自动捆绑。

更重要的是，Anthropic正处于一个极速扩张期。根据公开报道，公司在2025年完成了多轮融资，估值快速攀升，员工规模也在快速增长。在这个阶段，工程流程的补强，往往追不上人员和产品扩张的速度。

这不是Anthropic独有的问题。这是每一家快速成长的科技公司都会面临的”成长代价”。

只是，当你的名片上写着”安全第一”，代价被公开讨论的压力就会格外大。

▲ 车开得越快，安全带就越重要

第五章：横向参照——这在科技行业有多普遍

为了不让这篇文章变成对一家公司的单独批判，我想放一些背景数据。

根据Verizon发布的《2025年数据泄露调查报告》（Verizon 2025 Data Breach Investigations Report），在所有被记录的数据泄露事件中，**人为因素（Human Element）**至少参与了其中约68%的案例。这个数字连续多年居高不下。

而在具体的泄露原因中，”配置错误（Misconfiguration）”是云环境下最常见的问题类型之一——恰恰对应了Anthropic这两次事故的技术归因。

科技行业里，类似的”意外公开”并不罕见：

• 代码托管平台上，定期有开发者不小心把含有API密钥的代码推送到公开仓库
• 云存储服务的S3 Bucket因配置不当而公开，是过去十年间反复出现的新闻
• 大型科技公司的内部工具或文档意外被搜索引擎索引，也时有发生

从这个视角看，Anthropic的事故是行业共性问题在高关注度公司身上的一次显现。

区别只在于：你的知名度越高，同样的事情，引发的讨论就越多。

这不是说”因为大家都这样所以无所谓”。这是说，解决方案不在于道德批判，而在于系统性的工程文化建设。

第六章：真正的反思——我们能从中学到什么

如果你只是一个旁观者，这件事很好笑。

如果你是一个工程师、一个技术团队的 leader，或者任何一个负责”把产品发出去”的人，这件事应该让你停下来想一想。

反思一：发布流程需要独立的安全关卡

发布流程（无论是npm publish、docker push还是其他形式的软件分发）需要把”安全检查”作为一个独立的、强制性的步骤，而不是依赖工程师个人的记忆和习惯。

自动化检查可以做很多事：扫描包内文件是否超出白名单、检测是否含有内部敏感路径、比对文件大小是否异常等。这些都是可以用工具解决的问题，而不是靠人的小心来解决的问题。

反思二：默认设置应该是最保守的设置

内容管理系统的默认设置是”公开”，这是一个经典的设计反模式。

在安全领域有一个广为人知的原则：最小权限原则（Principle of Least Privilege）。它的精髓是：任何系统、用户、进程，在默认情况下只应该拥有完成其工作所必需的最小权限。

翻译成产品设计语言就是：默认应该是最安全的，而不是最方便的。

如果你今天要设计一个内容管理系统，文件的默认可见性应该是”私有”，公开需要主动操作；而不是默认公开，私有需要主动设置。

反思三：”AI安全”和”工程安全”是两张不同的票

这是最值得记住的洞察。

如果你在构建一个AI产品，或者在评估一个AI公司，不要把”他们有强大的AI安全研究团队”等同于”他们的工程操作安全也很强”。这是两种不同的能力，需要分开评估。

前者关注的是模型的对齐、可控性、有害输出的防范——这是一个研究问题。

后者关注的是代码怎么发布、数据怎么存储、权限怎么管理——这是一个工程流程问题。

一家公司可以在前者上达到顶尖水平，却在后者上出现初级失误。这不是虚伪，这是能力的不均衡分布。识别这种不均衡，是任何人在与AI公司打交道时都应该具备的判断力。

▲ 两套体系，各有短板

结尾：Anthropic之后，我们在等什么

Anthropic的官方声明说，公司正在”制定措施防止类似事件再次发生”。

这是正确的。

但”制定措施”这四个字很轻。它意味着什么？是给NPM发布流程加一道自动化检查？是修改CMS的默认设置？是增加一个发布审批的审核节点？还是重新审视整个发布体系？

目前，从公开报道来看，没有更多细节。

我不认为Anthropic会因为这两次泄露而遭受什么根本性的打击。Claude Code在GitHub上的Star数仍在快速增长（截至2026年3月，GitHub主仓库Star数已超94,000），用户基础依然坚实，Claude Mythos/Capybara如果如预期般发布，仍然会引发巨大关注。

但这件事留下了一个问题，悬在空中：

在AI能力以指数级速度扩张的今天，配套的工程规范、安全流程和组织能力，能否以同样的速度成长？

对Anthropic来说，这个问题需要用行动来回答，而不是用声明。

对整个行业来说，这个问题同样适用。

我们正在把越来越多的信任，交给这些快速奔跑的AI公司。他们在奔跑的时候，最好确保鞋带是系好的。

我是专注 AI Agent深度实践的努力撞蘑菇AI，致力于分享真实可用的 AI 使用经验与工作流探索，欢迎你和我一起把 AI 玩明白，如果内容对你有帮助，欢迎关注、点赞、转发。

我创建了「OpenClaw完全指南」知识星球，专注记录我使用OpenClaw的真实过程，从安装部署、核心能力到真实案例全面覆盖，记录的都是我的实践经验，欢迎加入、一起探索，帮助大家真正把OpenClaw用起来、用好它。