51万行源码泄露!一个实习生的失误,让Anthropic ＂裸奔＂12小时

一个 60MB 的调试文件，让价值数十亿美元的 AI 公司，把 51 万行核心源码”免费开源”给了全世界。

这不是黑客攻击，不是内鬼泄密。

就是一个实习生，漏掉了一个文件。

事情是怎么发生的？

2026 年 3 月 31 日，AI 头部公司 Anthropic 照常发布了旗下 AI 编程工具 Claude Code 的新版本（v2.1.88）到 npm 公共仓库。

几小时后，一名来自 Web3 安全公司 Fuzzland 的实习研究员 Chaofan Shou 在 X 平台发出一条帖子：

“Anthropic 在 Claude Code 的 npm 包里，附带了完整的 source map 文件。”

这条帖子，在 AI 开发者圈子里炸开了锅。

source map 是什么？

简单说，它是一种调试辅助文件。

前端工程师在开发时，会把 TypeScript 源码编译、压缩成一个体积很小的 cli.js 文件发布出去。这个压缩后的文件人类几乎看不懂。

而 source map（.map 文件）的作用，就是把这个压缩文件还原回原始的、可读的 TypeScript 源码，方便开发者调试。

正常情况下，source map 只应该存在于开发环境，发布到 npm 时必须删除。

但这一次，Anthropic 没有删。

一个 59.8MB 的 cli.js.map 文件，就这样安安静静地躺在了公开的 npm 包里。

任何人，只需要一行命令：

npm install @anthropic-ai/claude-code

然后解析那个 .map 文件，就能还原出 Claude Code 的全部原始源码。

泄露了多少？

数字说话：

泄露的内容包括：

• 整体架构：React + Ink 构建终端 UI，Bun 运行时，支持自然语言交互的 REPL 循环
• Agent 协议系统：内部 Agent 路由与调度逻辑
• QueryEngine.ts（4000 行）：查询引擎，含用户输入与工具注册机制
• JWT 认证机制：身份验证底层实现
• Prompt 细节：对话追踪、多轮上下文管理的内部实现
• Slash 命令系统：权限控制逻辑
• 状态机：复杂的多状态转换逻辑
• 远程控制系统：后台 daemon 模式（代号 “Kairos”）
• 未发布功能：代号 “Capybara” 的实验性模块、约 108 个 feature() 特性开关

换句话说，Claude Code 这个产品的全部工程实现细节，都摆在了全世界面前。

谁的锅？

根据多方报道，这次事故的直接原因是：

一名实习生在发布时，未确认排除 .npmignore 中的 source map 文件，直接将包含 source map 的版本推送到了 npm registry。

技术上的根本原因是：

正常流程：  TypeScript 源码 → 编译压缩 → cli.js（发布到 npm）                              ↑                         删除 cli.js.map ← 这步被跳过了！实际发生：  TypeScript 源码 → 编译压缩 → cli.js + cli.js.map（一起发布！）                                              ↑                                    60MB，包含完整原始源码

.npmignore 配置文件未正确排除 source map，或构建流程中漏掉了清理步骤。

这是一个人为失误，不是系统漏洞，不是黑客攻击。

但结果，和被黑了没什么区别。

Anthropic 怎么说？

事发后，Anthropic 反应很快：

• 紧急删除了 npm 包中的 source map 文件
• Claude Code 项目负责人 Boris Cherny 在社交媒体上公开回应
• 通过 CNET 发表官方声明

官方声明原文（大意）：

“此次事件未涉及泄露任何有效的客户数据或凭证信息。我们将此定性为人为失误导致的发布事故，而非安全漏洞。我们已采取措施，防止此类事件再次发生。”

关键澄清：

• ✅ Claude 大模型权重未泄露
• ✅ 用户数据和凭证未泄露
• ✅ Haiku / Sonnet / Opus 模型未受影响
• ⚠️ 泄露的是客户端工具的实现逻辑，不是模型本身

但声明发出之前，源码已经被大量 fork 到 GitHub，部分仓库在几小时内就获得了数千 Star。

删，已经来不及了。

这件事为什么值得所有程序员关注？

1. 这不是 Anthropic 独有的问题

source map 泄露，是整个前端/Node.js 生态中极其常见的安全盲区。

很多团队在发布 npm 包时，根本没有意识到 .map 文件的存在，更没有在 CI/CD 流程中加入检测。

你的团队，有没有这个问题？

2. 实习生不是替罪羊，流程才是根本

这次事故的根本原因，不是实习生能力不足，而是发布流程缺乏安全兜底。

一个健壮的发布流程，应该做到：

• 发布前自动检测是否包含 source map
• 敏感操作（发布到公共 registry）需要 code review 或双人确认
• CI/CD 流水线强制校验敏感文件

如果流程本身有这些保障，实习生的失误就不会造成这么大的影响。

3. “调试辅助文件”也是核心资产

很多人觉得，source map 只是个调试工具，没什么大不了。

但这次事件证明：source map 里包含的，是你产品的全部工程智慧。

架构设计、模块划分、内部 API、未发布功能……全在里面。

对于一家靠技术壁垒竞争的 AI 公司来说，这些信息的价值，不亚于模型本身。

程序员的三条安全红线

这次事件，给所有开发者划出了三条清晰的红线：

红线一：发布 npm 包，必须配置 .npmignore

# .npmignore 示例*.map*.tssrc/tests/.env*

或者在 package.json 中用 files 字段白名单控制：

{"files": ["dist/", "README.md"]}

发布前用 npm pack --dry-run 预检，确认包含的文件列表。

红线二：CI/CD 流程加入 source map 检测

# 在发布脚本中加入检测if find dist/ -name "*.map" | grep -q .; thenecho"❌ 发现 source map 文件，禁止发布！"exit 1fi

红线三：敏感操作必须有二次确认机制

发布到公共 registry 这类不可逆操作，应该：

• 要求 code review 通过后才能执行
• 或者设置双人确认机制
• 或者在 CI 中加入人工审批步骤

最后

这次事件的本质，是一个 60MB 的调试文件，让一家估值数十亿美元的 AI 公司，把核心工程资产在几小时内变成了全球开发者的学习材料。

它不是黑客攻击，不是内鬼泄密。

就是一个普通的发布流程疏漏。

但造成的影响，是不可逆的。

对于我们每一个程序员来说，这件事的提醒很简单：

你的代码，比你以为的更容易暴露。你的流程，比你以为的更需要保护。

如果觉得有用，欢迎转发给你的团队。

📢 互动话题：如果你觉得这篇文章对你有启发，欢迎点赞、在看、转发给更多朋友看到。评论区说说你身边都有哪些泄露事情。