Claude Code 源码泄露刷屏了，但真正值得警惕的，可能不是“泄露”两个字

(Updated: )
, , ,

Claude Code 源码泄露刷屏了，但真正值得警惕的，可能不是“泄露”两个字

今天，Claude Code 因为“源码泄露”冲上了技术圈热议。

这种消息一出来，大家的第一反应通常都很直接：

是不是 Anthropic 被黑了？
是不是整个内部代码库都被端走了？
是不是连产品底牌都被扒光了？

但如果你把情绪先放一放，再把今天公开流传的信息和我实际核到的 npm 包证据放在一起看，会发现这件事真正值得警惕的，可能不是“泄露”这两个字本身，而是它背后暴露出的另一层问题：

AI 产品正在越来越强，但很多团队的发布链路，可能还没有强到和产品本身匹配。

先说结论：这件事更像“发布产物暴露争议”，不太像“内网源码库被黑”

截至 2026 年 3 月 31 日，我更倾向于这样定义这次事件：

它更像是一场围绕 Claude Code 发布产物的源码暴露争议，而不是已经被可靠证实的 Anthropic 内部源码仓库失陷。

这两者听起来都像“源码泄露”，但其实完全不是一个层级的问题。

如果是后者，那是内部开发系统出事，是私有仓库级别的安全事故。
如果是前者，那更像是软件供应链和构建发布流程出了纰漏。

对外行来说，这两件事都可以被简化成一句“源码泄露了”。
但对真正做工程的人来说，这两个结论的责任边界、严重程度和后续补救方式，差别很大。

为什么大家会一下子炸锅

因为这次传闻抓住了一个非常容易让人上头的点：source map。

很多人平时对这个文件没概念，但它在打包产物里，往往比 cli.js 本身更敏感。

原理很简单。

像 Claude Code 这种 CLI 工具，通常会把大量源码打包成一个大的 cli.js 文件。
如果发布时又顺手把 cli.js.map 一起带上去了，而且这个 map 文件里还包含 sourcesContent，那就等于你给外界留了一份“反向导航图”。

别人不一定需要进你的私有仓库，也不一定需要真的拿到你内部 Git 历史，单靠这个 map 文件，就可能把原始源码结构和大量实现内容重新还原出来。

所以从大众语言来说，把这种事叫成“源码泄露”，并不奇怪。

真正的问题在于：

它听起来像黑客故事，但本质上很可能是一次工程发布事故。

我今天专门去核了 npm 包

为了不只做二手转述，我直接去看了 Claude Code 的公开 npm 包。

先查的是当前最新元数据：

1
npm view @anthropic-ai/claude-code version dist.tarball repository.url

我看到的结果是：

  • 当前最新版本是 2.1.87
  • 包仍然通过公开 npm 分发
  • repository.url 指向的是一个名为 claude-cli-internal.git 的内部仓库地址

这个信息本身值得注意，但也不能过度解读。
因为 npm 元数据里保留内部仓库地址，不等于源码已经外泄。它更多只是说明这个项目的构建来源。

接着我做了更关键的一步：

1
npm pack @anthropic-ai/claude-code@latest

这条命令会把 tarball 拉下来，并打印包内容清单。

我实际看到的 2.1.87 包里，有：

  • cli.js
  • package.json
  • sdk-tools.d.ts
  • 一批平台相关二进制文件

但没有看到 cli.js.map。

考虑到今天很多讨论还点名了旧版本，我又拉了一个被频繁提到的版本：

1
npm pack @anthropic-ai/claude-code@1.0.117

结果也一样。

这个旧版本包里，我同样看到了 cli.js 和其他依赖文件，但没有看到 cli.js.map。

这意味着什么？

意味着截至我写这篇文章这一刻，至少我能从公开 npm registry 直接复现到的包证据，还不足以支撑“某个公开版本明确带着完整 map 文件发出去了”这个最硬的说法。

那今天这波消息，是不是假的

我不会这么写。

因为今天这件事，并不是简单一句“假的”就能打发掉。

更稳妥的判断是：传闻并非完全空穴来风，但目前被广泛传播的版本，很可能把不同来源、不同时间点、不同层级的内容混在了一起。

我认为现在大概有三种可能。

第一种，是方向没错，但传播链条错了。
也就是说，某个历史构建产物、镜像缓存、CDN 节点或者其他分发路径，确实曾暴露过不该暴露的内容，只是今天社交媒体在转述时，把版本号、来源和复现方式讲乱了。

第二种，是有人做了逆向、清理和结构还原，但最后传播成了“官方源码直接泄露”。
这在 CLI 工具上并不罕见。一个大型 bundle 即便没有 map，也不等于完全不可分析。

第三种，是部分截图或片段确实对应过某个时间窗口，但现在公开包已经被处理过了。
这一点我今天没法完全排除，但至少在我能直接拿到的 tarball 里，我还没复现到。

所以如果非要给一句最准确的话，我会这么说：

Claude Code 今天确实爆出了一轮“源码暴露”级别的争议，但到目前为止，最夸张的那种说法，还没有被我独立复现坐实。

真正值得行业警惕的，不是热搜，而是这类事故的性质

因为哪怕它不是“内网被黑”，问题也一点都不轻。

今天很多人会把注意力放在“Claude Code 有没有被扒光”。
但从工程安全视角看，更值得警惕的是：

AI 产品的攻击面，已经越来越不只在模型，而在产品外围那整套工程系统。

一个 CLI 产品如果在发布产物里放出了不该放出的内容，泄露出来的就不只是几段代码，而可能包括：

  • 系统提示词
  • 工具调用接口
  • feature flag
  • 隐藏命令
  • 插件机制
  • 鉴权、更新、遥测和本地执行逻辑

这些东西虽然不是模型权重，但对竞争对手、逆向研究者、安全研究员甚至攻击者来说，都非常有价值。

而 AI Agent 类产品又天然比普通网页更“厚”。

它们往往同时连着：

  • 文件系统
  • 命令执行
  • 编辑器集成
  • 插件机制
  • 终端桥接
  • 本地索引和上下文管理

也就是说，一旦发布链路出问题，被外界看见的，不会只是一个 UI，而是一整套产品内部工作方式。

这件事最扎心的地方在于：很多团队可能都中枪

别把这件事只当 Anthropic 的瓜。

因为只要你做过：

  • npm CLI
  • Electron 客户端
  • 浏览器扩展
  • Python 打包工具
  • Docker 镜像分发

那你就该知道，真正被用户安装的，从来不是你的 monorepo，而是你的 artifact。

很多团队会认真审 GitHub 仓库、审 PR、审 release note，
但到了 npm、PyPI、Docker 镜像这一步，往往就变成一句“构建好了，发出去吧”。

这才是最危险的地方。

因为对研究者、竞争对手和攻击者来说，真正有价值的入口，往往就是你发出去的那个包。

所以，这件事真正该带来的教训是什么

如果用一句话总结，那就是：

source map 不该再被当成“无伤大雅的调试文件”，而应该被当成正式安全审计对象。

闭源分发产品至少应该在 CI 里多问自己几件事：

  • 发布包里有没有 *.map
  • map 文件里有没有 sourcesContent
  • 有没有内部路径、内部仓库名、调试开关被一起打进去
  • 最终公开分发的 artifact，到底和你以为发出去的是不是同一份东西

这不是小题大做。

因为在今天这个阶段，AI 产品卷到最后，卷的已经不只是模型能力，而是整条工程链路的成熟度。

模型再强，如果发布链路经不起推敲，产品就迟早会在别的地方露底。

最后

Claude Code 今天这波“源码泄露”讨论，表面上看是在吃 Anthropic 的瓜。

但如果你把视角抬高一点，会发现它真正刺到行业神经的地方是：

当 AI 产品越来越像基础设施，工程发布链路本身，也必须按基础设施的标准去治理。

到目前为止，我不愿意把这件事轻率地写成“Anthropic 内部源码仓库被黑”。
但我同样不会把它看成一个可以被一句“只是传闻”轻轻带过的小插曲。

因为哪怕最后证明它只是一次发布产物层面的暴露争议，它也已经足够说明一件事：

今天 AI 行业真正危险的地方，很多时候不是模型不够聪明，而是工程系统还不够严密。

参考链接