跳到主要内容

这次 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)