Claude Code 源码泄了,我盯着它想了很久

 不是技术扒皮贴。是我读完那些分析之后，真正觉得有意思、值得停下来想一想的几件事。

先把这件事本身说清楚。

2026 年 3 月底，Claude Code 发新版本，顺手把一个 60MB 的调试文件一起打包发到了全球 npm 仓库。这个文件叫 source map，它的作用是”把压缩混淆过的代码还原成原始状态”。换句话说，任何人只要下载了这个版本，就能看到 51 万行完整的 TypeScript 源代码。

然后全网就疯了。

但更让人哭笑不得的是：这是 Anthropic 第二次犯同一个错误。2025 年 2 月，同款问题发生过一次。

我不打算复述技术分析文章的结论。
我想说的是，读完这些之后，我自己真正在想的那几个问题。

一、第二次犯同一个错误，问题出在哪

表面上看是技术疏漏：没在 .npmignore 里排除 *.map 文件，或者 CI 流程里没有一个发布前的包内容检查。很低级，确实。

但我更想问的是：为什么第一次发生之后，修的只是那一次，而没有变成一条永久生效的团队规则？

这种模式我在工作里见过太多——出了问题，把问题本身修掉，但没有把”怎么不让这类问题再发生”这件事真正解决掉。换个人、换个场景、换个包名，同一类错误又来了。

一次事故，两种处理方式的区别：

🩹 补丁思维：把这次的 .map 文件删掉，下次发布再说。
🔧 系统思维：加一条 CI 规则——每次发布前自动检查打包内容，发现 .map 文件就卡住流程，人工确认才能继续。

前者修的是”这次的结果”，后者修的是”让这类错误再也不能发生”的机制。

这跟做测试是一回事。你发现一个 bug，修了它，但如果没同时写一个回归测试，这个 bug 理论上随时可能以不同面目重新出现。真正的质量保障，靠的不是”小心点”，靠的是让人不可能不小心的流程。

一个命令 npm pack --dry-run 就能检测出这个问题。把它加进发布 checklist，两分钟的事。Anthropic 在产品核心能力上的工程投入，和发布流程上的疏漏之间，形成了一种很奇怪的反差——这个反差本身，才是真正值得想的东西。

二、安全不是”列禁止清单”，这件事比我想的复杂很多

读这份源码之前，我以为给 AI 做安全限制，主要就是写一份危险命令的黑名单：rm -rf 禁掉，危险的 git 操作禁掉，差不多了。

读完之后，我发现这个思路从根上就错了。

真正的问题不是”哪些命令危险”，而是更基础的一层：你的安全检查系统看到的命令，和 bash 真正会执行的命令，是不是同一个东西？

举一个很具体的例子：

// bash 的花括号展开

{rm,-rf,/}# bash 会把这展开成: rm -rf /

// 一个只检查命令字符串的系统，看到的是一堆花括号

// bash 执行的，是删除根目录

类似的陷阱还有很多：Unicode 空白字符可以让两个看起来一模一样的命令实际上不同，回车符可以让终端显示的内容和真正执行的内容错位……

所以 Claude Code 的核心策略不是”列清单”，而是先回答一个更基础的问题：

我能不能完全理解这条命令要做什么？
如果能，才继续判断它安不安全；
如果不能，就直接让用户确认。

这叫 fail-closed 原则——不是”看起来没问题就放行”，而是”能证明它安全才放行，否则一律拦截”。不理解，不猜，直接问。

我觉得这个思路放到产品设计上一样成立。很多系统的问题不是因为”坏人太聪明”，而是因为设计者对自己系统的边界情况有一种没有依据的自信——大概能处理，应该没问题，放行。这种”差不多”的判断积累起来，就是最终出问题的地方。

还有一个细节，我觉得特别值得单独说：

当系统检测到危险的路径操作（比如要删某个关键文件），弹出确认框——但不提供”记住这个选择”的按钮。

普通操作可以选择记住，危险操作永远需要每次手动确认。

这不是技术问题，是行为设计问题。你让人确认一次，他认真看了；你让人确认一百次，第一百零一次他已经在自动点了。高危操作的设计原则不是”多提示”，而是永远不能让确认变成一个习惯性动作。这个道理在做任何需要用户”慎重操作”的功能时都成立。

三、提示词，才是这次泄露里真正值钱的东西

技术栈没有什么神秘的——TypeScript、Bun、React/Ink，都是现成的工具。架构分层也是正常的系统工程。

真正有价值的，是每个工具目录里的 prompt.ts——Anthropic 工程师写给模型看的约束规则。这不是文档，是他们踩过无数坑之后留下来的东西。

我印象最深的是 BashTool 里关于 Git 操作的一段——

他们不是写”禁止使用 git amend”，而是写：

// 出自 BashTool/prompt.ts

CRITICAL: When a pre-commit hook fails,

the commit did NOT happen.

So –amend would modify the PREVIOUS commit,

which may result in destroying work.

Therefore, always create NEW commits.

他们把因果链写出来了。不是命令”不要做什么”，而是说清楚”为什么这样做是错的”，以及”错了会导致什么”。

这对高能力模型来说格外关键。强模型不会因为你写了”禁止 amend”就永远遵守——遇到边界情况，它会做自己的推理。但如果它真的理解了”pre-commit hook 失败 = 这次 commit 没发生 = amend 会改掉上一次已经提交的东西”，那在任何类似的边界情况下，它都能推出正确的做法。

这让我想到写需求和规则时的两个层次：

第一层：告诉对方做什么 / 不做什么（靠记忆执行）
第二层：告诉对方为什么，以及出错了后果是什么（靠理解执行）

第一层容易被遗忘，也容易在新情况面前失效。
第二层更稳，因为执行者真的懂了，遇到没见过的情况也能自己判断。

AgentTool 的 prompt 里有一句话我觉得说得非常好，大意是：

给子 Agent 下任务，就像跟一个刚走进会议室的聪明同事说话——它不知道你们之前讨论了什么，不知道你踩过哪些坑，不理解这件事的来龙去脉。你必须把足够的上下文给到它，让它能自己做判断，而不是机械执行一个缩略版的指令。

然后是一个更重要的补充：理解这件事本身，不能外包。你得先自己想清楚，才有资格去委托。这句话对 AI 成立，对人也成立。

四、三层内存：上下文管理，靠结构不靠堆量

用过 AI 工具的人几乎都踩过同一个坑：对话开始还好，越聊越乱，到后面它开始忘事，或者把不同任务的上下文搅在一起。

大多数工具的应对思路是”把 context window 做大”——给更多空间，问题就解决了。Claude Code 源码里有一套不一样的设计，我认为更有参考价值。

它把记忆分成三层：

📍 第一层：索引（始终在线）

只存”我记过什么”的目录，不存内容本身。每行最多 150 个字符，几乎不消耗 token。需要某段历史时，先查目录，再取内容——而不是把所有历史都塞进 prompt。

类比：你大脑里知道”那件事的记录在那个本子的第三页”，而不是把那个本子全背下来

📦 第二层：项目上下文（按需调取）

CLAUDE.md 和各种项目记忆文件。不是每次对话都全部加载，而是由 Agent 根据当前任务判断”我现在需要哪部分”，再去取。

类比：做项目 A 的时候，只翻项目 A 的资料，不把所有项目的文档全摊开

💭 第三层：当前会话（实时压缩）

对话内容超出阈值时，自动压缩——保留最重要的逻辑链条，剔除冗余细节。不是丢掉，是精炼。

类比：人类的工作记忆，脑子里的细节会自然模糊，但关键判断留下来了

背后的核心洞察是：大多数任务需要的上下文，不是”所有历史”，而是”当下最相关的那部分”。把所有东西塞进 prompt，不是在帮 AI，相关信息反而会被大量无关信息淹没，判断质量下降。

这让我想到一个工作里的普遍问题：会议记录、需求文档、消息记录混在一起，到最后什么都找不到——不是因为信息太少，而是因为没有一套”索引→按需取用”的机制。AI 工具在解决这个问题，但人类自己的信息管理，其实一直也没做好这件事。

五、KAIROS：那个还没上线的功能，比上线的更让我好奇

源码里还藏了很多没发布的功能。最让我感兴趣的是一个叫 KAIROS 的东西。

KAIROS 是古希腊语，意思是”恰当的时机”。在 Claude Code 里，它是一个后台守护进程——当你不用 Claude Code 的时候，它会在后台自动运行，把你之前对话里的零散信息整理成结构化的长期记忆，源码里把这个过程叫做 autoDream（自动做梦）。

如果这个功能真的上线，意味着什么？

现在所有的 AI 编程工具，本质上还是”你问我答”的模式，只是执行力更强了。KAIROS 落地之后，会是：AI 在你下班之后，整理今天干了什么、卡在哪、有什么没解决——然后第二天你上班的时候，它已经”想了一夜”了。

这是从”工具”到”搭档”的分水岭。
工具在你用它的时候工作，搭档在你不在的时候也在转。

但这也带出了一个更难回答的问题：一个会在后台持续记录和整理你工作习惯的 AI，和一个你可以随时关掉的工具，在”你对它有多少控制权”这件事上，已经开始产生本质差异了。

源码里还有另一个引起争议的功能——我姑且叫它”匿名模式”：当 Claude Code 向开源项目提 PR 的时候，会自动移除所有 Anthropic 相关的标识信息，让代码看起来像普通开发者提交的。我理解 Anthropic 可能有自己的产品考量，但”让 AI 看起来像人类”这个方向，大家的不适感是合理的——不是因为技术本身，而是因为它破坏了协作关系里一个基础的东西：你知道你在跟谁打交道。

最后

读完这些材料，我最大的感受不是”Anthropic 牛”或者”Anthropic 粗心”——而是意识到，一个产品同时可以在核心能力上做得极其认真，在外围流程上留着明显漏洞。这两件事并不矛盾，而且比我们想象中更普遍。

精力总是先流向”做出来”，流程和防御机制永远排在后面。这不是 Anthropic 特有的，几乎每个团队都这样。

源码里还藏了一个没来得及发布的彩蛋：代号 BUDDY 的电子宠物系统，18 种物种，6 种稀有度，每个账号抽到的宠物唯一，原定 4 月 1 日愚人节亮相。结果源码先泄出去了，彩蛋的惊喜还没到，谜底已经人尽皆知了。

有时候就是这样——你最精心准备的东西，因为一个意料之外的地方出了问题，以一种完全没预料到的方式公开了。做产品也好，做工程也好，这件事没有人能完全避免，但可以让它发生得少一点。

读完真正记住的几件事：

• 安全不是”列清单”，是先搞清楚自己真正理解了什么，不理解的就拦截
• 高危操作的设计原则：永远不能让确认变成习惯性动作
• 规则要带逻辑——你写的是”不要做 X”，但对方需要的是”为什么不能 X”
• 出过的问题要变成流程机制，不能只是修了这一次
• 上下文管理靠的是结构，不是堆量
• 工具和搭档的区别，在于它是不是在你不在的时候也在工作

— The End —

— 去外头站着 —

累了就出来透透气，一起停止内耗 🌬️