[CC解构] 一个 .map 文件的蝴蝶效应

2026 年 3 月 31 日，一个普通的周二。

朝圣之旅要开始了。世人皆停足注目——"耶路撒冷"。

Twitter 上一条推文炸开了锅。安全研究员 Chaofan Shou (@Fried_rice) 发了一条简短的消息：

"Claude Code source code has been leaked via a map file in their npm registry!"

一个 .map 文件。就是那种大家发 NPM 包时经常忘记删掉的东西——source map，用来把混淆后的代码映射回原始源码。这次，它指向了 Anthropic 的 R2 存储桶，里面躺着完整的、未混淆的 TypeScript 源码。

几小时后，这条消息登上了 Hacker News 首页。538 points，297 条评论。

我当晚 clone 了一份。

为什么值得写一个系列

让我先说几个数字：

380K 行。这不是一个 side project。这是一个经过深思熟虑的、面向大规模部署的产品。它的架构决策、安全设计、性能优化，代表了 2026 年 AI 工程的最高水平之一。

而现在，源码就在那里。

我决定做一件事：通过写博文来逐层拆解它，最终理解到能自己造一个的程度。

不是为了真的造一个 Claude Code 竞品——而是因为我相信，解构一个好产品是最快的学习方式。就像学画画的人临摹大师作品，学写作的人拆解经典小说。读源码，提炼设计，写成文字，这个过程本身就是最好的教育。

第一印象：这不是你想象的 CLI 工具

打开 src/ 的第一秒，我的认知就被刷新了。

先看入口文件 main.tsx——是的，.tsx。一个命令行工具，用的是 React。4,683 行的入口文件，在第一行代码执行之前，就已经开始了三个并行任务：

// main.tsx — 在其他 import 之前就触发的副作用
profileCheckpoint('main_tsx_entry');
startMdmRawRead();      // MDM 配置读取
startKeychainPrefetch(); // macOS 钥匙串预读

还没开始解析命令行参数，后台已经在读钥匙串、拉配置了。启动时间，是这个团队在意的事。

然后看目录结构：

src/
├── tools/          # ~40 个 Agent 工具（Bash/文件/搜索/MCP/...）
├── commands/       # ~50 个 slash 命令
├── components/     # ~140 个 Ink UI 组件
├── hooks/          # React hooks（权限/状态/UI）
├── services/       # API/MCP/OAuth/LSP/压缩/分析...
├── bridge/         # IDE 双向通信
├── coordinator/    # 多 Agent 编排器
├── memdir/         # 持久记忆系统
├── skills/         # 内置技能系统
├── buddy/          # ……电子宠物？
├── voice/          # 语音输入
├── vim/            # Vim 模式
└── QueryEngine.ts  # 46K 行的 LLM 核心引擎

这不是一个"调 API 然后打印结果"的 CLI。这是一个完整的 Agent 操作系统——有自己的权限系统、记忆系统、多进程编排、IDE 集成、甚至还有电子宠物。

系列路线图

我计划用十余篇博文，从外到内、从架构到细节，完整拆解 Claude Code 的设计：

第一阶段：全局视野

• 第 1 篇：架构全景 — 从 main.tsx 到 QueryEngine，理清 380K 行代码的骨架
• 第 2 篇：灵魂工程 — System Prompt 的七层设计，这是整个产品的行为定义

第二阶段：核心引擎

• 第 3 篇：工具系统 — 40 个 Tool 如何统一在一个抽象下
• 第 4 篇：权限与安全 — yoloClassifier 的两阶段分类器
• 第 5 篇：Agent 编排 — Fork、Coordinator、Swarm 三种并行模式
• 第 6 篇：QueryEngine — 核心引擎的流式响应和 tool-call 循环

第三阶段：智能层

• 第 7 篇：记忆与遗忘 — Memory 四类分类法 + Compact 结构化压缩
• 第 8 篇：Skill 与 MCP — 可扩展的能力系统 + 外部工具标准协议

第四阶段：工程细节与隐藏层

• 第 9 篇：Terminal UI + IDE Bridge — React 渲染到终端 + 双向通信协议
• 第 10 篇：隐藏彩蛋 — Buddy 电子宠物、Undercover 卧底、Feature Flags
• 终章：设计蓝图 — 如果要自己造一个，怎么造

每篇的结构都是：它是什么 → 为什么这样设计 → 关键代码 → 我们能学到什么。

一些预告

在通读源码的过程中，有几个发现让我特别兴奋，先剧透一些：

系统提示词的深度超出想象。 不是一段"你是 helpful assistant"的文本——而是一本完整的行为手册。包含代码风格哲学（"三行重复好过一个过早的抽象"）、行动安全原则（"measure twice, cut once"）、甚至有专门的"不要做什么"章节。

Auto Mode 的权限分类器叫 yoloClassifier。 名字很 meme，但实现极其认真——两阶段 XML 分类器，Stage 1 快速判断 allow/block，Stage 2 chain-of-thought 复核减少误报。这是一个用 LLM 来审查 LLM 的安全架构。

Anthropic 员工给开源项目贡献代码时，Claude Code 会自动进入"卧底模式"。 隐藏模型名称、禁止在 commit message 中提及内部代号、去掉所有 AI 归属标记。代码里甚至专门列了"禁止出现的词"：Capybara、Tengu、claude-cli-internal……

有一个完整的电子宠物系统。 18 种物种（duck, goose, blob, cat, dragon, octopus, capybara...），5 级稀有度（common 60% → legendary 1%），5 种属性（DEBUGGING, PATIENCE, CHAOS, WISDOM, SNARK），基于用户 ID 的确定性哈希。这个团队是认真在做有趣的事。

模型代号泄露： Claude Opus 4.6（knowledge cutoff: May 2025）、Claude Sonnet 4.6（cutoff: August 2025）。内部代号 Capybara、Tengu、Numbat 出现在注释中。

写在开始之前

这个系列不是"看看别人的代码然后点评两句"。

我想做的是：理解每一个设计决策背后的 why。为什么用 Bun 不用 Node？为什么系统提示要分静态和动态两部分？为什么权限分类器要两阶段而不是一步到位？为什么电子宠物的物种名要用 String.fromCharCode 编码？

每一个 why 背后都是一个工程决策，一个 trade-off，一个对"什么是好的 AI 产品"的回答。

把这些 why 想明白、写明白，就是这个系列的意义。

明天，从架构全景开始。

📚 CC解构系列