Claude Code源码炸了,但炸出来的东西比泄漏本身有意思多了

昨天发生了一件事，我刷到的时候愣了好几秒。

Claude Code，就是Anthropic做的那个AI编程命令行工具，目前可能是最强的AI编程Agent之一——它的完整源码，泄漏了。

不是那种”疑似泄漏”、”部分片段流出”。 是完完整整的，1900个文件，51万行TypeScript代码，全部暴露在互联网上。

一个安全研究员Chaofan Shou发现了这件事，然后GitHub上瞬间出现了好几个仓库，把这些代码整理好了，几个小时内就拿到了数千Star。

我看了一下泄漏的内容。

说实话，源码泄漏这件事本身，其实没那么让我震惊。

真正让我震惊的，是看到这些代码之后，你会发现——

原来这就是”最强AI编程工具”的底层长相。

原来这个东西，没有你想象中那么神秘。

但同时，又比你想象中精密得多。

这种感觉怎么描述呢，就像你一直觉得某个魔术特别牛逼，然后有一天你看到了魔术师的全套道具和操作手册。你发现，哦，原来不是什么超自然力量，就是极其精巧的工程设计。

但这个工程设计本身的精巧程度，反而让你更加敬佩了。

今天这篇文章，我不想只聊”泄漏了什么”这种新闻层面的东西。

我想聊聊，从这次泄漏中，我们能看到什么更深层的东西。

关于AI工具是怎么被造出来的，关于”Agent”到底意味着什么，以及关于我们作为开发者，应该从中学到什么。

一、先说泄漏本身：一个低级错误，犯了两次

这个泄漏是怎么发生的呢？

原因简单到让人想笑——Anthropic在发布npm包的时候，把Source Map文件一起发出去了。

如果你不太熟悉前端工程化，我简单解释一下。 Source Map就是一个”藏宝图”。

当你把TypeScript代码编译、打包、压缩成一个巨大的JavaScript文件之后，这个文件人类是读不懂的，全是乱七八糟的变量名和压缩后的代码。

但Source Map文件里记录了一份映射关系：压缩后的第几行第几列，对应原始代码的第几行第几列。

它本来是给开发者自己调试用的。 但如果你把它跟npm包一起发出去了——那恭喜，任何人都可以用这个藏宝图，把你的原始代码100%还原出来。

你想想这个画面。

Anthropic花了无数人力物力写出来的核心产品代码，精心打包、混淆、压缩。然后在发布的最后一步，把解密钥匙一起塞进了快递包裹里寄出去了。

我靠，这也太离谱了。

更离谱的是，这不是第一次了。

2025年2月，Claude Code早期版本就因为同样的原因泄漏过一次。

当时Anthropic从npm上撤掉了旧版本，删掉了Source Map。

然后，一年后，同样的错误又犯了一遍。

这就像——你知道《父亲的葬礼》那个经典sketch吗？

每一轮都比上一轮更离谱，观众以为不可能再出事了，结果棺材又掉了。

Anthropic这是给全世界开发者上演了一出真实版的升番喜剧。

但说实话，我倒不觉得这是因为Anthropic的工程师菜。

恰恰相反，这暴露的是一个很多团队都有的系统性问题：CI/CD流水线里的”最后一公里”安全盲区。

代码写得再好，架构设计得再精妙，如果发布流程里少了一个.npmignore规则，或者package.json的files字段没配对，一切白搭。

具体建议（今天就可以做的）：

如果你也在维护npm包，现在，立刻，去做两件事：

1. 运行一次npm pack --dry-run，看看你的包里到底包含了哪些文件。特别注意有没有.map文件、.env文件、或者任何你不想公开的东西。
2. 检查你的.npmignore或package.json的files字段。明确列出你想发布的文件，而不是依赖默认行为。

就这两步。 5分钟的事。 但能避免一场灾难。

二、掀开盖子：Claude Code的”内脏”长什么样

好，泄漏的原因聊完了，接下来聊点真正有意思的。

51万行代码被摊开在阳光下，这对于我们研究AI Agent的工程化实现来说，简直是一个天赐的学习机会。

我花了一些时间看了各路分析，有几个发现让我觉得特别值得说说。

第一个让我意外的事：它用的是Bun，不是Node.js。

这个选择其实很大胆。Bun到现在都还算是一个相对年轻的运行时，很多公司在生产环境中不敢用。

但Anthropic选它是有道理的——一方面，Bun的启动速度比Node.js快得多；另一方面，Bun的构建工具原生支持死代码消除（dead code elimination）和条件编译，Claude Code用feature()标记来做功能开关，在构建阶段就把不需要的代码路径整个剥离掉，最终产物更小更精简。

对于一个CLI工具来说，启动速度就是生命。 你想想，你在终端里敲一个命令，如果等两三秒才出响应，你会疯的。

而Node.js冷启动的那点延迟，对于一个追求极致体验的产品来说，是不可接受的。

第二个让我意外的事：终端界面是用React写的。

是的，你没看错。React。在终端里。

他们基于一个叫Ink的库做了深度定制，直接将Ink的源码fork并内置到了项目中，在此基础上构建了一套自己的终端React渲染引擎。

整个Claude Code的终端界面有数百个React组件（仅components目录下就有近400个文件）。

这听起来有点杀鸡用牛刀，对吧？一个命令行工具，有必要用React吗？

但你仔细想想Claude Code的界面——它有实时的流式输出、有代码高亮、有文件diff展示、有权限确认弹窗、有多任务状态显示——这些交互复杂度，用传统的终端渲染方式（比如直接console.log），根本搞不定。

这就像打游戏。你看《城市天际线》这种游戏，表面上就是摆摆建筑、画画马路。

但底下的交通模拟系统、供水供电网络、居民AI行为系统，复杂得一塌糊涂。

看起来简单的东西，背后往往需要一个重型的引擎来支撑。

Claude Code的终端界面就是这样。 你看到的是一个”简洁的命令行”。 底下是一个完整的React渲染引擎。

第三个，也是最重要的发现：它有大约40个内置工具。

这个数字本身就很说明问题。

当我们说Claude Code是一个”AI编程Agent”的时候，它到底”Agent”在哪里？ 答案就在这40个工具里。

它不是单纯地跟模型聊天然后把回复贴出来。

它能读文件、写文件、执行Bash命令、搜索代码库（用的ripgrep）、调用LSP获取代码补全和诊断、跟IDE双向通信、甚至能生成子Agent来并行处理任务。

每一个工具都是一个独立的模块，有自己的输入校验（用Zod v4做的）、权限控制、执行逻辑。 光是这些工具的核心类型定义文件（Tool.ts）就有近800行、29KB的代码。

这让我想到了一个类比。

你知道《塞尔达旷野之息》为什么那么牛逼吗？ 不是因为它有一个厉害的主角。是因为它有一个物理引擎。火能产生热气流，热气流能让滑翔伞上升，金属能被雷劈，木头能在水上漂。

这些基础规则组合起来，就能产生无穷无尽的玩法。

Claude Code也是一样的。这40个工具就是它的”物理引擎”。模型本身（Claude Opus/Sonnet）是那个”玩家”。

当”玩家”拿到这40个工具之后，它就可以像塞尔达玩家一样，把各种工具组合起来，完成你给它的任务。

读文件 → 理解代码 → 搜索相关函数 → 修改代码 → 执行测试 → 读取测试结果 → 修复bug → 再次测试。

这个循环不是硬编码的流程。是模型自己根据当前状态，决定下一步用哪个工具。

这才是”Agent”的真正含义。

三、最硬核的发现：那个46KB的”大脑”

在所有泄漏的代码中，有一个文件特别引人注目。

QueryEngine.ts，约1300行、46KB的代码。它是整个系统里最核心的单一模块之一。

这个文件干的事情，用一句话概括就是：管理Claude Code和底层大模型之间的所有交互。

API调用、流式响应处理、工具调用循环、思考模式控制、重试逻辑、token计数——全在这里面。

约1300行，46KB。就这一个文件，承载了整个AI交互的核心逻辑。

你可能觉得1300行听起来不多，但这是高度浓缩的核心代码——每一行都在处理关键逻辑。而且这只是冰山一角，围绕它的工具链、类型系统、错误处理散布在整个代码库的51万行中。

因为如果你自己试过做一个AI Agent，你就会知道，跟大模型的交互，远远不是”调一个API拿到回复”这么简单。

你要处理流式输出，一个字一个字地把模型的回复实时展示给用户。

你要处理工具调用，模型说”我想读取某个文件”，你要把这个请求拦截下来、执行、然后把结果喂回去。

你要处理多轮对话，上下文的累积、截断、压缩。

你要处理各种边界情况：网络超时、API限流、模型返回格式错误、工具执行失败…

每一个细节，写出来可能就是几十上百行代码。 而这些复杂度分散在整个51万行的代码库中，QueryEngine只是其中最核心的枢纽。

这件事给我最大的感触是：做一个好的AI产品，模型能力只是冰山水面上的一角。水面下的工程复杂度，才是真正的战场。

很多人觉得，AI产品不就是套个壳、调个API吗？

看完这个代码库你就知道了。

不是的。 差远了。

如果你正在做AI相关的项目，一个具体建议：

不要把所有精力都放在”prompt怎么写”上。 花至少同等甚至更多的精力在工程层面：

• 你的工具调用链路是否稳定？
• 异常处理是否完善？
• 流式输出的体验是否流畅？
• token使用是否有监控和优化？

这些”不性感”的工程问题，决定了你的产品是一个Demo还是一个真正能用的东西。

四、Source Map这件事，其实藏着一个更大的行业问题

聊到这里，我想拔高一层，聊一个我一直在想的问题。

这次泄漏的根本原因是Source Map被意外发布。 但你有没有想过一个问题——为什么Claude Code要混淆代码？

答案很明显：因为它是闭源的商业产品，需要保护知识产权。

但这就引出了一个有意思的矛盾：一个建立在开源社区生态之上的产品，自己却是闭源的。

Claude Code的技术栈——Bun、React、Ink、Zod、ripgrep、Commander.js——全部是开源项目。 它发布在npm上，用的是开源社区建立的包管理基础设施。 它的用户是开发者，这群人本身就是开源文化的核心参与者。

然后它自己是闭源的。

我不是说这有什么”不对”。 商业公司保护自己的代码，这完全合理。 但这种张力是真实存在的。

而且这次泄漏还暴露了另一个问题：JavaScript/TypeScript生态的代码保护，本质上是极其脆弱的。

不像C/C++编译成二进制，你拿到也逆向不回去（至少非常困难）。 JS/TS的”编译”本质上只是打包和压缩，原始逻辑完全保留在里面。 Source Map一旦泄漏，就是100%还原。 即使没有Source Map，用AST分析工具也能还原出大部分可读代码。

这就像——你把一封信装进了一个透明的信封里，然后在信封外面贴了一张磨砂膜。 磨砂膜掉了（Source Map泄漏），信的内容一览无余。 但即使磨砂膜没掉，拿个吹风机吹一吹（AST分析），也能看个大概。

所以，如果你的商业模式依赖于”代码不被看到”，而你又在用JS/TS—— 说实话，你可能需要重新想想这个策略。

真正的护城河不是代码的隐蔽性。 是你的工程执行力、迭代速度、数据飞轮、和用户生态。 代码被看到了，你的竞争对手就能超过你了吗？ 如果是的话，那你的护城河本来就不存在。

Claude Code的代码全世界都看到了。 但我打赌，短期内不会有人能复制出一个同等水平的产品。 因为51万行代码只是冰山一角，背后的模型能力、数据积累、工程团队的默契，这些才是真正的壁垒。

五、你该从这件事里学到什么

前面聊了这么多，最后我想回到”对普通开发者有什么用”这个问题上。

说实话，我自己看完这些分析之后，最大的感触不是技术层面的，而是一种——怎么说呢——认知上的松绑。

我之前总觉得，像Claude Code、Cursor这种产品，背后一定有什么神秘的、我完全理解不了的技术。 就好像它们是用某种黑魔法造出来的。

但现在源码就摆在那里，你看到的是什么？ React、TypeScript、Zod、Commander.js。 这些东西你都知道，你可能天天在用。

区别在哪里？

区别在于他们把这些普通的积木，搭成了一个极其精密的系统。

40个工具，每个都有清晰的输入输出定义和权限控制。

一个约1300行、46KB的查询引擎，处理了所有你能想到和想不到的边界情况。

一个双向通信的IDE桥接层，让CLI和编辑器无缝协作。

一个多Agent协调器，让多个子Agent并行工作。

没有黑魔法。 全是工程。 大量的、扎实的、不性感的工程。

我觉得这对我们所有做技术的人来说，是一个很重要的提醒：

不要迷信”天才灵感”。要相信”系统性工程”的力量。

你不需要发明新的框架、新的语言、新的范式。 你需要的是：把已有的工具用到极致，把每一个细节做到位，把系统的复杂度控制住。

具体的行动建议：

如果你对AI Agent开发感兴趣，今天就可以做一件事：

去GitHub上搜一下这次泄漏的代码仓库（搜”claude-code source”就行）。

不是让你去抄代码，那有法律风险。

而是去看看它的目录结构。看看它怎么组织40个工具的，看看它怎么设计权限系统的，看看它的命令和工具是怎么分层的。

光是这个目录结构，就能让你学到很多关于”如何设计一个复杂CLI系统”的东西。

然后，试着自己搭一个最小版本。不需要40个工具，先做3个：读文件、写文件、执行命令。

不需要1300行的查询引擎，先做一个最简单的API调用+流式输出。

不需要React终端界面，先用console.log。

从最小的东西开始。 然后一点一点加。

这就是Claude Code的造法。 也是所有好产品的造法。

写在最后

写到这里，我想起宫本茂说过的一句话。

就是那个创造了马里奥和塞尔达的男人。 他说：**”A delayed game is eventually good, but a rushed game is forever bad.”**

一个延期的游戏最终会变好，但一个赶工的游戏永远是烂的。

我觉得这句话反过来理解也成立：一个好的产品，不是因为用了什么魔法技术，而是因为在每一个细节上都没有赶工。

Claude Code的51万行代码里，藏着的不是什么惊天秘密。

藏着的是无数个”这个边界情况也要处理”的工程决策。

藏着的是无数个”这样写更稳定”的技术选型。 藏着的是一个团队的耐心和执行力。

而今天，这些东西因为一个Source Map文件，意外地被全世界看见了。

你看，魔术揭秘了。 但这个魔术师，依然值得尊敬。

因为真正牛逼的不是秘密本身。 是把每一个不起眼的细节都做对的那份耐心。

去做吧。 从你手头那个项目开始。 不需要黑魔法。 把每个细节做对就好。

—- 全文完—-