这次事件根本不是高明的黑客攻击，纯粹是流程上的低级失误叠加，而且，这是第二次了！
Anthropic源码又，又，又，又泄露了...
到底发生了什么事？
简单说，Claude Code在发布npm包时，一不小心把一个调试50多M的.map文件给打包进去了。
多了个文件而已，听上去，是不是没什么？
这个.map是干嘛的？
你可以理解为：源代码原版是TypeScrip写的，但发布时会把它压缩、混淆成一堆难以阅读的JavaScript天书，而那个.map文件，就是“天书”和“原版”之间的完整对照字典。可以通过这个字典，将Claude Code源码全家桶，全部被还原曝光。
Claude Code全家桶被还原曝光了哪些？
几小时内，代码在GitHub上被疯狂备份、传播，根本拦不住。
这么低级的错误，究竟是怎么发生的？
最让人无语的来了，这根本不是高明的黑客攻击，纯粹是流程上的低级失误叠加，而且，这是第二次了！
简直是人为与流程的“双重漏洞”：
首先，最新已经承认：部署流程里有“几个手动步骤”，其中一个出了错。其次，工程师也坦白了：有人为了自己团队调试方便，主动选择了在发布版里包含.map，结果在方便自己的同时，也“方便”了全世界。最核心的问题：这个流程依赖人工检查，没有自动化防线，才导致同一个坑，踩了两次。
吃瓜归吃瓜，从技术上来说，到底应该如何根治此类问题呢？
根据我这些年的研发管理经验：指望人不犯错是不现实的，杜绝这类问题的核心思想是，用自动化的工具和强制的流程，取代不可靠的人工记忆和操作。
(1) 自动化安检：在CI/CD流水线里，集成像GitGuardian这样的代码扫描工具。每次构建发布，自动检查包里有没有.map、.env、密钥等敏感文件。有就报错，发布失败。
画外音：哪些一定不能发。
(2) 强制白名单：在package.json里明确列出只能发布这些文件，其他的一律不准带，想犯错都没机会。
画外音：只能发布哪些。
(3) 环境隔离：在构建脚本里写死，生产环境的构建命令会自动剥离source map，开发环境的则保留。从根源上隔离。
画外音：开发环境，测试环境，沙箱环境，线上环境都要隔离。
最后，问题来了：
上一次故障，你觉得他们复盘过没有?我能想到的，你觉得他们想得到吗?可是，为什么没有解决呢?世界，真是一个巨大的草台班子。
