跳到主要内容

这次 Claude Code 到底泄露了什么?

· 阅读需 6 分钟
Claude Dev
Claude Dev

“Claude Code 源代码泄露了” 这句话,一开始听起来像是社交媒体的夸张标题。

但把社区证据看得更细以后,这种怀疑需要更新。

这次事情不只是 prompt 被提取,也不只是一个模糊传闻。更可信的说法是:Claude Code 的 npm 包里发布了一个 source map,这个 source map 暴露了通往内部源码文件的路径,而社区据此重建出了远比公开仓库所展示更大的代码树。

这已经比常见的社交媒体夸张说法更接近真正的源码泄露。

核心指控是什么​

社区给出的说法很直接:

  1. Claude Code 发布到 npm 的包中包含一个 JavaScript source map。
  2. 这个 source map 指向了内部 TypeScript 源码位置。
  3. 这些源码可以被抓取并重建。
  4. 最终结果又以反编译或重建后的形式被重新发布到了 GitHub。

如果这条链条成立,那这次事情就不只是“prompt 泄露”或“有人猜出了 system prompt”。

它是一场带有源码层后果的打包失误。

为什么社区认为这次是真的​

这里有三个公开证据值得看。

1. Reddit 线程​

在 2026 年 3 月 30 日,r/ClaudeAI 上的一则帖子称 Claude Code 的源码是“通过 NPM 上的 .map 文件泄露的”。

这个机制本身就很关键,因为 source map 一直都是常见失误点:

  • 它可能暴露原始文件结构
  • 它可能暴露未混淆的标识符
  • 在某些构建和托管方式下,它甚至可能反向指向原始源码载荷

这已经比常见的“有人泄露了内部代码”传言具体得多。

2. Fried Rice 的 X 帖子​

社区持续引用的那条 X 线程,给出了更细一层的版本:

  • Claude Code 的 npm 包据称带出了 source map
  • 这个 map 据称引用了 Anthropic 托管存储上的一个 zip 归档
  • 那个归档据称包含了远比之前公开可见范围更大的内部源码树

即使社区现在还在继续复原细节,这个机制本身是自洽的。

3. instructkr/claude-code 仓库​

目前最强的公开证据就是这个 GitHub 仓库:

  • https://github.com/instructkr/claude-code

这个仓库明确把自己描述为基于泄露 source map 对 Claude Code 的重建版本,并声称:

  • 原始 npm 包只暴露了很小一部分打包文件
  • 恢复出来的源码树大得多
  • 社区重建了数千个文件
  • 泄露内容覆盖了内部实现细节、prompts 和功能开发痕迹

这并不自动意味着仓库里的每一行都完全准确、完全完整。但它已经远远超出“松散传言”的级别。

这和之前的 prompt 泄露故事有什么不同​

更早一轮围绕 Claude Code 的争议,更多是这些内容:

  • system prompts 被提取
  • tool schemas 被整理
  • 行为指令被公开
  • agent 逻辑被社区逆向

这些本身已经有价值,但它们并不等于源码泄露。

而这一次,失效机制明显不同:

  • 不只是 prompt 提取
  • 不只是公开仓库被深挖
  • 不只是 CMS 草稿暴露
  • 而是一个随构建产物发布出去的 source map,看起来真的让代码重建成为可能

这才是关键区别。

如果社区重建结果大体可信,那么这次就不只是“大家更了解 Claude Code 怎么表现”,而是“大家获得了更多 Claude Code 实际是怎么实现的内容”。

最可能发生了什么​

基于当前公开的社区证据,最 plausible 的链路更像这样:

  1. Anthropic 把 Claude Code 的一个包发布到了 npm。
  2. 这个包里包含了本不该以这种形式公开的 source map。
  3. 这个 map 暴露了原始源码信息,或指向了相关源码载荷。
  4. 社区研究者顺着这条线重建出了内部代码。
  5. 重建后的代码随后扩散到 GitHub 和社交媒体。

这让它更像一次打包和发布流水线失误,而不只是“有人把 prompt 发到了网上”。

这对开发者为什么重要​

实践层面的教训非常直接,而且也非常传统:

source map 本身就是发布面的一部分。

很多团队把它当成无害的调试残留,但当它具备下面这些属性时,它绝不无害:

  • 保留原始路径元数据
  • 保留可读的符号名
  • 引用私有制品存储
  • 或暴露足够多的结构来重建内部源码

而在 AI 产品里,这种风险会被进一步放大,因为一次泄露可能同时暴露多层信息:

  • 代码
  • prompts
  • tool contracts
  • feature flags
  • safety controls
  • 未发布功能工作

这就是为什么这次事情比普通的“assistant prompt 泄露”更值得重视。

这并不意味着什么​

即便这次源码泄露说法大体成立,也不应该过度延伸。

它并不自动意味着:

  • Anthropic 的模型权重泄露了
  • 每个内部服务都泄露了
  • 所有 Claude 产品都泄露了
  • 或者社区重建仓库一定是 100% 精确、100% 正版的源码树

但它确实很可能意味着一件严重的事:

  • 一个分发到生产环境的构建产物暴露了足够多的信息,让外部人员得以重建 Claude Code 的大部分内容

按照正常的软件安全标准,这已经是一次相当严重的失误。

更好的安全结论​

真正的教训不是“AI 公司天生脆弱”。

更朴素的结论是:

  1. 构建流水线会泄露。
  2. 只要你把调试产物发出去,它就是生产产物。
  3. 一旦包元数据暴露了内部存储引用,私有制品就可能不再私有。
  4. 在 AI 工具里,prompts 和代码已经足够接近,一次打包失误就可能同时暴露实现逻辑和行为逻辑。

这也是为什么发布工程应该和模型安全宣传获得同等重视。

最后结论​

在看完 Reddit 线程、X 上的讨论,以及 GitHub 上的重建仓库之后,更强的结论是:

Claude Code “源码泄露” 这件事,这次看起来大体是真实的,而 source map 正是最核心的泄露路径。

这件事不是简单的 prompt 被猜中,也不只是大家过度解读公开仓库。

更关键的指控是:Anthropic 看起来通过 npm 分发了一个构建产物,而这个产物暴露了足够多的源码级信息,使得社区得以重建 Claude Code 的重要部分。

如果这条链条属实,那么这就不只是 AI 圈的一次热闹事件。

它是一场起因非常传统、但后果一点也不普通的发布工程事故。

Sources (checked March 31, 2026)​