Claude Code 源代码泄露了。一个以安全著称的 AI 公司，为什么总犯这种低级错误？AI 干活到底靠不靠谱？
先讲简单事实。2026 年 3 月 31 日，Claude Code 的源代码泄露了。它本身不是开源软件，而是闭源软件，但在打包发布时，直接把源代码一起打包进去了。发布之后很快就被人发现了。从名字上看，发现的人应该也是中国人，叫“潮饭说”。发帖披露后，这个帖子获得了 2.2 万次点赞和 1100 万次阅览，一下就爆发了。
先说结论：这不是第一次，已经是 Anthropic 第三次干出同样的事了，都是在发布时直接把源代码打包进去。这种泄露对于 Anthropic 来说损失巨大。各个层级的竞争对手都可以从中学习它的软件架构，连防蒸馏模块也一起泄露了，反而更方便竞争对手去进行蒸馏。商誉也受到了难以估量的损害。它号称最安全，结果却先干出这种事。
按 Anthropic 现在的内部工作方式来看，内部每天 60 到 100 个内测版本，对外基本日更，慢一点也是两三天更新一次，90% 的代码和流程都由 AI 控制。这种事情几乎没办法彻底避免。想继续当老大，就不能慢下来，必须越来越快。所以这绝对不会是最后一次。
这件事可以分几部分来讲：
- 技术上到底发生了什么；
- 这次泄露的内容里到底有哪些有趣的东西；
- Anthropic 这次损失到底有多惨；
- 留给 Anthropic 和它竞争对手的选择其实都不多，只能继续狂奔；
- 对于普通项目和个人来说，到底能不能安全地使用 AI。
技术上到底发生了什么
Claude Code 不是一个特别庞大的系统，一共大约 51 万行代码。对比一下：Linux 内核大约 3500 万到 4000 万行，Chrome 浏览器 3600 万到 4000 万行，VS Code 大约 300 万行，PostgreSQL 约 130 万行。所以 Claude Code 其实不算特别大。
它的代码是用 TypeScript 写的。写的时候肯定要求提高可读性，虽然大部分是 AI 写的，但人还是要进去读。发布时，它发布的是一个 npm 包。npm 有专门的打包工具，打包时会把这些代码转换成 JavaScript。
JavaScript 虽然也是解释执行的语言，但在打包过程中，会把所有细碎的小文件塞进一个完整文件里，再把变量名处理掉，做代码混淆，把注释去掉。做完这些以后，代码就非常难读了。拿到打包后的代码，一般很难直接解读。不是完全不能逆向，但极其费劲，尤其是 50 多万行代码，做逆向工程会非常困难。
但问题是，打包后还得保证代码能正确执行，还要调试。不能说在原始代码上调试完，打包之后就不管了。所以这里就需要一个东西，叫 source map，也就是源文件映射。它的作用是告诉你：打包后那份几乎人类不可读的代码，原来对应的是哪个文件、什么名字、哪几句代码。
这次 Anthropic 把这个东西也一起放进包里了。有了 source map，理论上就可以还原和处理这些代码了。但更夸张的是，source map 里还写了一句：他们把所有源码包放在 Cloudflare 的 R2 空间上。
R2 本质上是一个公开可访问的对象存储空间，类似网盘，文件上传之后可以通过 URL 获取。正常情况下这也未必有问题，因为链接本来是很长的一串乱码，外人通常找不到。但 Anthropic 把这个链接直接写进了 source map 里。
结果大家顺着这个线索一看，发现里面有个叫 src.zip 的文件。打开一看，1900 多个文件。也就是说，连根据 source map 去反编译、去还原代码这一步都省了，直接把完整源代码包抓回来了。这等于发福利发得非常狠。
正常情况下应该怎么避免
正常情况下，怎么避免 npm 把这些内容打进去？开源软件通常会把源码文件一起打包进去，这没问题，比如 OpenCode 之类的开源项目就是这样。但闭源项目在打包时，应该写一个叫 .npmignore 的文件，告诉打包工具哪些文件不要放进去。
正常流程应该是在打包前把 source map 等不该发布的文件排除掉。问题在于，这个 .npmignore 文件大概率也是 Claude Code 自己，也就是 AI 写的。而 Anthropic 的代码，包括 Claude Code 自己的代码，90% 以上都由 AI 生成。于是这个文件写错了，最终导致了这次泄露。
Anthropic 的补救措施
Anthropic 当然也做了补救，而且补得很快。泄露包发布几小时后，他们重新发了一个补丁包。原来是 v2.1.88，修补后版本号还是 v2.1.88，只是把 source map 文件删了，再发了一次。
然后又向 GitHub 提交了 DMCA 申请，也就是数字千年版权法案请求，要求删除泄露内容相关的仓库，总共删了 8100 多个仓库。
但这肯定已经晚了。像这种本来就在风口浪尖上的项目，一旦被发现出事，信息传播速度会非常快。大量分支仓库、镜像仓库肯定已经出现了。GitHub 上这类删除操作，必须找到最初的源头仓库，把它的所有分支都删掉才有效。
但只要有人把代码拉下来，稍微改几句，再传一个新仓库上去，这种就删不掉了。所以这类补救基本只能算聊胜于无，相当于“我已经努力过了”。
Anthropic 的官方 X 账号和官网都没有发出任何公开说明。这个也不难理解。一个以安全著称的公司，干出这种事，确实很难对外解释。
当然，犯这种低级错误的公司绝不止 Anthropic 一家。不要因为这个事件就简单得出“Anthropic 不安全”的结论。实际上，它可能依然是最安全的那一批。之所以这件事闹得沸沸扬扬，是因为它站在风口浪尖上，被太多人盯着。一旦出纰漏，就会快速爆发。很多没那么知名的小项目，源码一样可能满天飞，只是大家懒得看而已。
这次泄露内容里有哪些有趣的东西
1. “卧底模式” Undercover Mode
第一个是“卧底模式”，Undercover Mode。这个功能是干什么的？它会在每次向 GitHub 公开仓库提交代码时，先检查代码里有没有写“这是由 Claude 生成的代码”、有没有暴露 Claude 的版本号。
如果有，就把这些痕迹删掉，让它看起来像真人写的一样。这个机制本身未必有问题，但现在它自己也随着源码一起泄露出来了，就显得很讽刺。
2. 反蒸馏模块
第二个比较有意思的是反蒸馏模块。大家知道，很多模型会去蒸馏 Claude 模型。为了防止被蒸馏，Claude Code 里专门写了一个模块来做这件事。
这里面有几步：
- 第一步是假工具注入。大模型是可以调用工具的，它会在 API 响应里埋入虚假的工具调用，让竞争对手收集到的训练数据带毒。
- 第二步是思维链加密。Claude 的思考过程其实也会发到客户端上，但它是加密的，必须用自己的 API key 才能解开来看，这也是为了防止蒸馏。
- 第三步是输出投毒。Claude Code 的流量使用定制的 JSON 协议做隔离，让爬虫更难解析。
结果这次连整个防盗系统也一起泄露了，大家就看到了它在反蒸馏方面的这些小心思。
3. 大量表情符
第三个比较显眼的是代码里表情符特别多。因为它 90% 都是 Claude Code 自己写的，所以代码和日志里有大量表情符。这个其实不难理解。AI 写完代码以后，人还是要读的，加入一些表情符确实能提升阅读体验。
4. 泄露内容中总结出的 14 条提示词原则
还有人从泄露内容里总结出了 14 条提示词原则，认为普通人也可以借鉴。不管你是在带下属、带学徒，还是平时和 AI 对话，这些思路都挺有参考价值。
- 用禁令代替指令。与其告诉 AI“你要做这个、你要做那个”，不如明确告诉它“你不许做什么”。可做的事情很多，不可做的事情相对更少，把禁令写清楚，反而更容易把事做对。
- 专门设计一个“唱反调”的角色。它的任务不是确认一切都能用，而是尽量找出问题。
- 不要画蛇添足，不要加用户没有要求的东西。AI 特别喜欢顺手多改一点，这往往很危险。这次 .npmignore 被改错，很可能就跟这个习惯有关。
- 如实汇报，不要润色，也不要过度谦虚。AI 经常在回答完后补一句“我可能理解得还不够透，您再看看”，这种其实是一种提前甩锅。源码里也有明确约束，不让它这么干。
- 活可以分出去，但思考不行。可以开很多子任务并行处理，但最后判断必须回到主任务来做。
- 不知道就说不知道，不要猜。这是为了堵住 AI 幻觉的最大来源。
- 先看再改，不要凭空编造。AI 编程时经常不先读完整上下文，就直接生成一堆代码，结果根本跑不起来。代码约束很强，认真读完上下文再动手，出错率会低很多。
- 一次授权不等于永久授权。某件事这次可以做，不代表以后同类事情都默认可以做，每次都应该重新确认。这一点其实挺反人性的，因为大家用 Claude Code 时，常常会被频繁询问“这能不能做、那能不能做”，最后用户往往会烦，直接选择“以后别问我了”。
- 每条禁令都要写清楚为什么。不能只说“不许这样”，还要说明原因，否则 AI 会试图绕过去。
- 信息按需提供，不要一次全给。每次让 AI 干什么，就只给它和当前任务相关的信息，不要把一大堆无关内容都塞进去。
- 尤其不要每次都把完整工具手册甩给 AI。最省事的方式看起来像是给它一本“工具宝典”，让它自己查，但实际上这样效果并不好。
- 沟通规范要细致到标点符号。某些标点在 Markdown 或其他标记语言里有特殊意义，可能导致内容显示异常，所以这些都要明确说明。
- 不同场景加载不同规则。因为系统里有很多 agent 和子 agent，每个子任务都应该有自己对应的系统提示词，否则很容易串。
- 提示词不要堆成一大段，要模块化。要有缩进、有步骤、有约束、有例子，写清楚先做什么、后做什么，这样 AI 更容易理解，也更不容易出错。
5. 还没发布的隐藏彩蛋
除此之外，还有一些隐藏彩蛋，也就是功能还没发布，但代码已经埋进去了，将来只要开个开关就能启用。
- Think Back：类似回想功能，用来做年度代码总结，比如你一年里写了什么代码、花了多少时间，听起来有点像代码版的年度复盘。
- Buddy 宠物系统：有 18 种宠物，每个宠物有不同性格。未来很多 AI agent 可能会以这些宠物性格来为用户服务。一个安全公司，代码里埋了一堆宠物，也挺有意思。
- Memeing：训练数据里出现了这个词，社区猜测这是 Anthropic 专门调教 Claude 更会玩梗的一部分训练数据。
Anthropic 这次到底有多惨
这次确实是损失惨重。竞争对手拿到了什么？是 51 万行代码、1900 个文件，也就是 Claude Code 完整客户端的全部内容。
已经有人拿着这些代码，只做了很小规模的补全，就能顺利编译出 Claude Code。它所有的机制，多代理协作逻辑、状态机、客户端展示方式、上下文压缩策略，甚至客户端侧的 5 层压缩策略，全都暴露了。
服务端部分因为没有代码，只能通过客户端反推，但很多关键接口和调用方式也都能部分逆向出来。至于 Claude 模型本身的推理引擎，那个在服务端，看不到；针对 Claude 的深度优化，也看不到。但即便如此，泄露的价值已经非常高了。
而且，这不是第一次。2025 年 2 月，Claude Code v0.2.8 和 v0.2.28 的源代码也发生过同样方式的泄露，都是直接把 source code 给出去了。4 个月后，也就是 2025 年 6 月 19 日，OpenCode-AI 这样的项目就上线了，现在号称是 Claude Code 最好的开源平替。
与此同时，Google 的 Gemini CLI、OpenAI 的 Codex CLI，以及国内的千问 Code，基本都是在 6 月前后上线的。
拿到这些代码以后，大家不会明说“我参考了你”，但一定会先研究、消化、理解，然后再“致敬”一下，把自己的产品上线。某种意义上，现在这个 Harness Engineering 的时代，基本就是上一次泄露推动出来的。上一次泄露几乎像一次“生物大爆炸”，突然一下，相关物种全出来了。
而这一次，事情更进一步。因为现在泄露代码本身就可以交给 Claude Code 来读。拿到代码以后，快速解析、快速补全、快速转译，几个小时内就能完成。以前 50 多万行代码，即便不算特别大的软件，要真正读明白，往往也需要几个月。现在在 Claude Code 的帮助下，几个小时，一个人就能搞定。
GitHub 上甚至已经有人把这套代码完整转译成 Python 版本或 Rust 版本，而且已经跑起来了。
为什么 Anthropic 很难彻底封堵
那 Anthropic 能不能彻底封堵，比如把这个版本废掉，做一次大升级，连服务端也一起改，让旧代码彻底失效？不行。除了向 GitHub 发 DMCA 请求之外，它没有太多别的办法。
因为服务端需要向下兼容，你不能说为了封堵泄露，就把所有老版本客户端都废掉。前面还有那么多用户签了协议、正在使用，不可能说改就改。所以它只能眼睁睁看着竞争对手做逆向、做代码蒸馏。
更糟的是，连防蒸馏模块都泄露了。大家甚至能据此更容易仿出一个 Claude Code 客户端，再去和它后端模型通信，蒸馏起来会更顺手。
更大的损失是商誉
更大的损失其实是商誉损失。很多人用 AI 时本来就不太踏实，会倾向选择一家“更安全”的公司。Anthropic 原来在这方面的名声非常好，甚至国防部都会用它的产品。
但现在它出了这种事，而且还是同样的低级错误干了三回，这对它的品牌伤害非常大。同样的事情如果是马斯克干，可能大家觉得无所谓；但 Anthropic 干，就真的是丢不起这个人。
AI 靠不靠谱：为什么这类问题还会继续发生
那这类事情以后能不能杜绝？很多人会想，知错能改，应该总能修好吧。但现实是，留给 Anthropic 的选择并不多。
先说核心问题：AI 靠不靠谱？标准答案应该始终是，不靠谱。它从来就没真正靠谱过。这次出错，说到底就是因为太快了。
传统软件公司有一整套成熟的上线流程和开发管理系统，经过多年沉淀，方法非常完善。但那套体系有个代价，就是速度慢。你不可能高频率地一天上线一堆版本，因为根本管不过来、看不过来。
而 Anthropic 做 Claude Code 的速度有多快？内部每天几十个版本，对外基本天天更新，慢一点也就是两三天一次。传统版本控制和开发管理体系，在这种频率下根本失效。
那能不能慢下来，换安全一点的方式前进？也不行。对 Anthropic 来说，是保住“安全”的名声更重要，还是继续当行业领跑者更重要？显然，后者更重要。
它只能继续快速出下一个版本，必须快速迭代，持续在 Harness Engineering 这个赛道上保持领先。你一旦慢下来，就很可能被别人超过。所以这类事情今后还会继续发生，很难彻底避免。
它的竞争对手也是一样。OpenAI、Gemini，包括国内的公司，还有开源竞争者，都必须跟着往前冲。谁稍微慢一步，谁就可能被淘汰。所以在这件事上，做开源反而最省事。反正源代码本来就是公开的，泄露了也无所谓。
但那些做闭源的公司，比如 Gemini、OpenAI，就必须投入更多人力物力来检查。
那多加点人行不行？其实意义也不大。因为当 AI 已经解决了 90% 的代码，连编译流程、发布流程都由 AI 控制时，剩下 10% 靠人去兜底，本身就很反人性。人会天然放权。
这有点像大学教授发出来的 PPT 或文章里有错别字。不是教授水平不行，而是这些东西往往是学生做的。学生做完之后，教授为什么不检查？因为他没空，而且他已经足够信任学生了。但学生也可能又把事情交给学弟学妹，一层层转包，最后就出错。
现在 Claude Code 也是一样。既然 90% 的事情 AI 都能干，剩下那 10%，人真的会去认真逐项检查吗？大多数时候不会。只能是习惯性授权给 AI，摔一个狠的，摔完还不能停，还得继续更快地跑，等着下一次再摔。
普通项目和个人还能不能安全地使用 AI
有，但前提是你没有那么着急地高频更新版本。Claude Code 之所以泄露，不是因为 AI 天生不靠谱，也不是因为人少，而是因为更新频率实在太高。内部一天几十个版本，对外一天一个版本。几十万行代码的项目，在这种节奏下，任何人工检查都很难有实际效果。
他们一年只出一两次，或者两三次，出这种事的概率都会低很多。
更可靠的方法：用脚本检查脚本
多雇一些人意义不大。想保证安全，最简单的方式其实是多写几个脚本，让程序自动检查。比如专门写一个脚本去检查 .npmignore 是否正确，里面有没有错误，有没有被 AI 偷偷改掉。这反而是最可靠的方式。
安全规则必须和主流程彻底分离
另外，硬性的安全标准应该写死在这些脚本里。虽然这些脚本也可能是 AI 写的，但负责安全规则的 AI，必须和负责主流程的 AI 彻底分开，绝对不能混在一起。
比如你不能让同一个 AI 既负责写 .npmignore，又负责自动发布。正确做法应该是：一个 AI 负责准备发布，另一个独立的 AI agent 负责执行安全检查，确认有没有错误。这有点像东厂、西厂、锦衣卫互相监督，不能混成一锅。Anthropic 这次的问题，很可能就是这些环节混在一起了。
总结
这次泄露对 Anthropic 来说绝对是个悲剧，但对整个行业来说，反而又像一次“生物大爆发”式的利好。整个行业会在 Harness Engineering 这条赛道上继续快马加鞭地往前冲。
Anthropic 这次的损失，也给所有使用 AI 的团队敲响了警钟：要么你就彻底开源，要么你就主动慢下来。这件事必须想清楚。
背景图片
Prompt：in the style of cinematic editorial illustration, modern editorial watercolor, clean hierarchy, restrained palette, a detailed wide-open office floor of an AI tech company, densely arranged standing desks and curved partitions in varied arrangements, cables and monitors creating layered depth, cool white ambient light with soft pink cherry blossom glow streaming through large windows, a cyberpunk metropolis exterior with spring樱花 trees in bloom, foreground desk fragments, midground workstations, deep background window framing the blooming city, editorial semi-realism, material details on glass panels and brushed surfaces –no people, no text, no logo –ar 16:9 –stylize 220 –chaos 5 –v 7.0 –sref 1755819253 –p qaczhqj
