快速摘要： 2026年3月31日，Anthropic 旗下的 AI 编程工具 Claude Code 的完整源代码因 npm 包中误带 Source Map 文件而意外泄露，超过 1900 个文件、51.2万行 TypeScript 代码被公之于众。泄露内容涵盖了工具系统、查询引擎、多智能体协调器、IDE 桥接层等核心模块，还曝光了多个未发布的隐藏功能——包括代号为"Kairos"的常驻智能体模式、"Buddy"电子宠物系统、以及专门防止内部信息外泄的"Undercover Mode"。本文将从泄露原因、技术架构、隐藏功能、安全启示四个维度进行详细拆解，往下看有更详细的技术分析和操作要点。本文由 莫潇羽@源码七号站 原创撰写，转载请注明出处。
一、事件始末：一个 .map 文件引发的"开源"风暴
2026年3月31日，安全研究员 Chaofan Shou 在检查 npm 注册表中 @anthropic-ai/claude-code 这个公开包时，发现了一个异常文件。除了常规的可执行文件 cli.js 之外，包里赫然多出了一个体积高达 59.8 MB 的 cli.js.map 文件。
对于不熟悉前端工程化的朋友，这里需要解释一下 Source Map 的概念。在现代 JavaScript/TypeScript 项目中，源代码在发布前通常会经过编译、打包、压缩等处理步骤，最终输出的是高度混淆的生产代码。Source Map 文件（扩展名为 .map）是一种映射文件，它能将压缩后的代码精确地映射回原始源代码，方便开发者在出现问题时进行调试。换句话说，只要拿到了 .map 文件，就可以近乎完整地还原出原始代码。
正常情况下，Source Map 文件绝不应该出现在生产环境或公开的 npm 包中——它只应存在于开发环境中用于调试。但这次，Anthropic 在构建发布流程中出现了配置疏漏，导致这个 .map 文件被一并打包到了公开的 npm 注册表中。更关键的是，这个 Source Map 文件引用了存储在 Anthropic R2 存储桶中的未混淆 TypeScript 源代码，使得任何人都可以通过该映射直接下载到完整的 src/ 目录。
消息一出，开发者社区瞬间炸锅。短短数小时内，就有人将处理好的源代码上传到了 GitHub 上的公开仓库。仓库地址为 https://github.com/instructkr/claude-code（莫潇羽@源码七号站 已验证该地址有效），星标数迅速飙升。Reddit、Hacker News 等技术社区的讨论热度也急速攀升，全球开发者纷纷下载、分析、讨论这份意外曝光的代码。
Anthropic 方面在发现泄露后迅速做出了补救措施——推送了新的 npm 更新以移除 Source Map 文件，并从注册表中删除了早期版本。但正如技术圈那句老话所说："互联网没有删除键"，GitHub 上的备份已经被永久保存下来了。事实上，在 Anthropic 做出响应之前，已经有多个独立的备份仓库被创建，代码在社区中的传播速度远超官方的删除速度。
这个事件的时间线梳理起来大致如下：泄露最初被 Chaofan Shou 发现并在社交媒体上公开，随后消息迅速在开发者社区中扩散。有技术爱好者通过解析 .map 文件还原了完整的源代码目录结构，并将其上传到 GitHub 供公众查看和研究。与此同时，也有人直接通过 Source Map 中引用的 R2 存储桶地址下载了原始 TypeScript 文件的压缩包。在消息公开后的极短时间内，相关 GitHub 仓库的星标数就突破了数千，多个技术媒体和博客也跟进报道了这一事件。
值得一提的是，这并非 Anthropic 在短期内的首次信息泄露。就在五天前的3月26日，一个 CMS 配置错误导致了未发布的"Claude Mythos"模型相关细节、博客文章草稿等大量内部资产被公开访问。Anthropic 官方对此回应称这是"外部 CMS 工具的人为配置错误"，并强调这些材料只是"早期草稿内容"，不涉及核心基础设施、AI 系统或客户数据。连续两次安全事件，无疑给这家以安全和负责任著称的 AI 公司带来了不小的尴尬，也引发了业界对于 AI 公司整体安全管理能力的讨论。
二、泄露的技术根因：npm 发布流程中那些容易踩的坑
理解这次泄露的根因，对于所有从事 Node.js 开发的工程师来说都是一堂宝贵的安全课。下面 莫潇羽@源码七号站 带大家从技术层面详细剖析这次事故是如何发生的。
2.1 Bun 构建工具的默认行为
Claude Code 使用 Bun 作为运行时和构建工具。Bun 的打包器（bundler）在默认配置下会自动生成 Source Map 文件，除非开发者显式地关闭这一选项。这意味着如果你在使用 Bun 进行项目构建时没有特别注意，.map 文件会默认存在于构建产物中。
对于使用 TypeScript 编译器（tsc）的项目，相关配置项是 tsconfig.json 中的 sourceMap 和 declarationMap 字段：
// tsconfig.json 中关闭 Source Map 生成
{
"compilerOptions": {
"sourceMap": false,
"declarationMap": false
}
}而对于 Bun 的 bundler，则需要在构建脚本中明确指定不生成 Source Map。这个看似简单的配置项，就是这次事故的技术根因。
2.2 npm 发布机制的"陷阱"
npm 在决定哪些文件会被打包发布时，遵循一套特定的优先级规则。简单来说，有三种方式控制发布内容：
第一种是依赖 .gitignore 文件。如果项目中没有 .npmignore 文件，npm 会读取 .gitignore 的内容来决定排除哪些文件。但问题在于，构建产物（如 .map 文件）通常不会出现在 .gitignore 中——因为它们本来就不存在于源码仓库里，是在 CI/CD 构建过程中动态生成的。
第二种是使用 .npmignore 文件。这个文件专门用于告诉 npm 哪些文件不应被打包。但需要注意一个重要细节：如果项目中同时存在 .npmignore 和 .gitignore，npm 只会读取 .npmignore 而完全忽略 .gitignore。这是一个非常容易出错的地方。开发者可能更新了 .gitignore 却忘记同步更新 .npmignore，导致敏感文件被泄露。
第三种是在 package.json 中使用 files 字段做白名单。这是最安全的做法——只有明确列在 files 数组中的文件才会被发布。采用白名单策略（而非黑名单策略）可以从根本上防止意外文件被包含进 npm 包中。
// package.json 中使用 files 字段做白名单
{
"name": "@your-org/your-package",
"files": [
"dist/cli.js",
"README.md"
]
}在 Anthropic 的这次事故中，.map 文件应该是在构建阶段被生成后，由于发布配置（.npmignore 或 files 字段）不够严谨，被一同打包进了 npm 包中。
2.3 Source Map 文件的内部结构
为了帮助大家更好地理解为什么一个 .map 文件就能还原出全部源代码，莫潇羽@源码七号站 在这里补充解释一下 Source Map 文件的内部结构。一个典型的 Source Map 文件是一个 JSON 格式的文件，其核心结构大致如下：
{
"version": 3,
"file": "cli.js",
"sourceRoot": "",
"sources": [
"src/main.tsx",
"src/QueryEngine.ts",
"src/tools.ts"
],
"sourcesContent": [
"// main.tsx 的完整源代码内容...",
"// QueryEngine.ts 的完整源代码内容...",
"// tools.ts 的完整源代码内容..."
],
"names": ["startApp", "QueryEngine", "..."],
"mappings": "AAAA,SAAS,QAAQ,..."
}其中最关键的是 sources 和 sourcesContent 这两个字段。sources 列出了所有原始源文件的路径，而 sourcesContent 则直接包含了每个源文件的完整代码文本。也就是说，这个 59.8 MB 的 .map 文件中，已经嵌入了 Claude Code 全部 1900 多个 TypeScript 源文件的完整内容。任何人只需要写一个简单的脚本解析这个 JSON 文件，就能将所有源代码按照原始目录结构完整还原出来。
此外，在 Claude Code 的这个案例中，Source Map 文件还引用了存储在 Anthropic R2 云存储中的源代码文件。这意味着不仅 .map 文件本身包含了代码映射信息，通过它还能直接定位到存放原始源码的云端地址，进一步降低了还原代码的门槛。
这也是为什么安全专家反复强调：Source Map 文件绝对不能出现在任何面向公众的发布产物中。它本质上就等同于源代码本身。
2.4 发布前自检的最佳实践
为了避免类似问题，每位 npm 包维护者在执行 npm publish 之前，都应该养成使用 npm pack --dry-run 命令进行预检查的习惯：
# 在正式发布前，先查看将要包含的所有文件
npm pack --dry-run
# 检查是否有 .map 文件混入
npm pack --dry-run 2>&1 | grep "\.map$"这条命令会列出所有将要被打包的文件，让你在正式发布之前有机会发现并排除不应公开的内容。如果你在输出中看到了任何 .map 文件或其他敏感文件，就应该立即修正配置后再发布。
此外，在 CI/CD 流程中也应当加入自动化检查步骤，确保每次自动发布时不会携带调试文件或其他敏感资料。比如可以在发布脚本中增加一个校验环节：
#!/bin/bash
# 发布前自动检查是否包含 .map 文件
MAP_COUNT=$(npm pack --dry-run 2>&1 | grep -c "\.map$")
if [ "$MAP_COUNT" -gt 0 ]; then
echo "错误：检测到 $MAP_COUNT 个 .map 文件将被发布，请检查构建配置！"
exit 1
fi
echo "检查通过，准备发布..."
npm publish三、Claude Code 技术架构全景解读
泄露的代码让外界第一次有机会窥探到 Claude Code 的内部架构。莫潇羽@源码七号站 在仔细研读了多个技术分析资料后，为大家梳理出以下核心架构信息。从外部看，Claude Code 只是一个终端里的 AI 编程助手；从内部看，它是一个高度模块化、精心设计的大型工程系统。
3.1 整体技术栈
Claude Code 的技术选型非常有意思。根据泄露的代码结构和此前 Anthropic 工程师的公开分享，这个项目选择了以下核心技术栈：
开发语言选用 TypeScript，这是整个项目的主力语言，总代码量约 51.2 万行，分布在超过 1900 个文件中。运行时选用 Bun，而非更常见的 Node.js。Bun 提供了更快的启动速度和原生的 TypeScript 支持，对于一个需要频繁启动的 CLI 工具来说，这是一个务实的选择。终端 UI 框架选用 React + Ink，Ink 是一个让你能够用 React 组件来构建命令行界面的库，底层使用 Yoga 布局引擎进行终端内的弹性布局。CLI 解析框架选用 Commander.js，这是 Node.js 生态中最成熟的命令行参数解析库之一。
为什么要用 React 来写终端界面？这在很多人看来可能有些"大材小用"，但 Anthropic 的工程团队对此有明确的解释。他们提出了一个叫做"On Distribution"（在分布内）的概念——选择 AI 模型本身已经非常擅长的技术栈。TypeScript 和 React 是大语言模型训练数据中覆盖率非常高的技术，因此 Claude 模型对这些技术的理解和生成能力都很强。Anthropic 的工程师曾公开表示，Claude Code 中大约 90% 的代码是由 Claude 自己编写的。选择模型"擅长"的技术栈，使得 AI 能够更高效地参与甚至主导自身代码的迭代开发。
3.2 源码目录结构详解
泄露的源码展示了一个层次分明的目录结构，下面是核心部分的梳理：
src/
├── main.tsx # 入口文件，Commander.js CLI 解析 + React/Ink 渲染初始化
├── commands.ts # 命令注册表
├── tools.ts # 工具注册表
├── Tool.ts # 工具类型定义（约 29,000 行）
├── QueryEngine.ts # LLM 查询引擎（约 46,000 行）
├── context.ts # 系统/用户上下文收集
├── cost-tracker.ts # Token 消耗与成本追踪
│
├── commands/ # 斜杠命令实现（约 50 个）
├── tools/ # 智能体工具实现（约 40 个）
├── components/ # Ink UI 组件（约 140 个）
├── hooks/ # React Hooks
├── services/ # 外部服务集成
├── screens/ # 全屏 UI 界面（Doctor 诊断、REPL 交互等）
├── types/ # TypeScript 类型定义
├── utils/ # 工具函数
│
├── bridge/ # IDE 桥接层（连接 VS Code / JetBrains）
├── coordinator/ # 多智能体协调器
├── plugins/ # 插件系统
├── skills/ # 技能系统
├── keybindings/ # 快捷键配置
├── vim/ # Vim 模式支持
├── voice/ # 语音输入
├── remote/ # 远程会话
├── server/ # 服务器模式
├── memdir/ # 持久化记忆目录
├── tasks/ # 任务管理
├── assistant/ # 助手模式（含 Kairos 相关功能）
└── buddy/ # 电子宠物系统这个目录结构透露出的信息量非常大。首先可以看到，这不仅仅是一个简单的"AI 聊天套壳"，而是一个具备完整工具链、多智能体协同能力、IDE 深度集成、以及多种交互模式的综合性开发平台。
3.3 核心模块深度剖析
接下来，让我们逐一深入了解 Claude Code 最核心的几个模块。
（一）查询引擎 QueryEngine.ts —— 整个系统的"大脑"
QueryEngine.ts 是整个代码库中最庞大的单一模块，代码量达到了惊人的约 46,000 行。它承担了 Claude Code 与大语言模型（LLM）交互的所有核心逻辑，可以说是整个系统的"大脑"。
这个模块负责的核心功能包括：管理所有与 Anthropic API 的通信，包括请求构建、响应解析和流式传输处理；精确追踪每次交互中的 Token 消耗，这对于成本控制至关重要；实现复杂的"工具调用循环"——当模型判断需要使用某个工具时，QueryEngine 会执行该工具、收集结果，然后将结果反馈给模型进行下一轮推理，如此循环直到任务完成；处理"思维链"（Chain of Thought）模式，支持模型的扩展思考能力；以及全面的重试逻辑和错误处理机制，确保在网络波动或 API 限流等场景下的稳健运行。
从泄露的代码中可以看到，QueryEngine 还支持多种 API Beta 特性的协商。在 constants/betas.ts 文件中，列出了 Claude Code 与 API 协商使用的所有 Beta 功能标识：
// constants/betas.ts 中的 Beta 功能标识（部分）
'interleaved-thinking-2025-05-14' // 交错思考模式
'context-1m-2025-08-07' // 百万 Token 上下文窗口
'structured-outputs-2025-12-15' // 结构化输出
'web-search-2025-03-05' // 网页搜索
'advanced-tool-use-2025-11-20' // 高级工具使用
'effort-2025-11-24' // 推理力度控制
'task-budgets-2026-03-13' // 任务预算管理
'prompt-caching-scope-2026-01-05' // 提示词缓存范围控制
'fast-mode-2026-02-01' // 快速模式这些标识揭示了 Anthropic 在 API 层面正在开发和测试的诸多前沿特性，比如百万 Token 的超长上下文窗口、任务预算管理机制等。
从这些 Beta 标识中，我们可以推测出 Claude Code 的推理流程大致如下：用户输入一个自然语言指令后，QueryEngine 首先将指令连同当前的系统上下文、对话历史一起打包成一个 API 请求；API 返回的响应可能包含纯文本回复，也可能包含工具调用请求（Tool Use）；如果是工具调用请求，QueryEngine 会解析出工具名称和参数，通过权限系统进行校验后执行对应的工具；工具执行的结果被收集起来，作为新的上下文追加到下一轮 API 请求中；这个循环会持续进行，直到模型判断任务完成并输出最终结果。整个过程中，QueryEngine 还会实时追踪 Token 消耗，当接近预算限制时采取相应的策略（如启用上下文压缩或提示用户）。
这种"工具调用循环"的设计是当前 AI Agent 架构中最核心的模式之一，而 Claude Code 的 QueryEngine 无疑是这一模式的工业级实现。46,000 行代码的体量也说明了一个事实：看似简单的"AI 调用工具"背后，需要处理大量的边界情况、错误恢复、并发控制和性能优化问题。
（二）工具系统 Tools —— 40 多个能力模块的"万能工具箱"
Claude Code 的工具系统采用了类似插件的架构设计。每一个独立的能力——无论是读写文件、执行 Bash 命令、搜索代码库还是进行网页抓取——都被封装成一个独立的、具有权限控制的工具模块。整个工具基础类型定义（Tool.ts）就有约 29,000 行代码，可见其复杂程度。
根据泄露的代码和公开的 SDK 文档，Claude Code 内置的工具大致涵盖以下几个大类：
文件操作类工具包括文件读取（Read）、文件写入（Write）、文件搜索（Grep，基于 ripgrep 实现，支持正则表达式）、目录列表（ListDir）等。这些工具让 Claude 能够像人类开发者一样浏览和修改项目文件。
命令执行类工具以 Bash 工具为核心，允许 Claude 在终端中执行各种系统命令。通过 Bash 这个"万能适配器"，Claude 可以调用任何人类开发者常用的命令行工具——git、npm、docker、make 等等。这种设计哲学的精妙之处在于：与其为每个外部工具编写专门的集成插件，不如直接赋予 AI 使用终端的能力，就像给它一双可以操作键盘的手。
代码智能类工具中最值得关注的是 LSP（Language Server Protocol）集成。LSP 是一种用于编辑器和语言服务器之间通信的开放协议，Claude Code 通过集成 LSP 可以获得实时的代码分析能力——包括类型检查、引用查找、符号重命名等。这让 AI 的代码理解能力远超简单的文本模式匹配。
网络相关工具包括网页获取（WebFetch）和网页搜索（WebSearch），让 Claude 能够在编码过程中查阅在线文档和搜索技术资料。
子智能体工具（AgentTool）允许 Claude 在需要时生成子智能体来处理特定子任务。这个设计实现了任务的分治策略——当面对一个复杂的大型任务时，主智能体可以将其分解为多个子任务，分别委派给子智能体处理，最后汇总结果。
此外还有笔记本编辑（NotebookEdit，用于操作 Jupyter Notebook）、任务列表管理（TodoWrite）、后台任务管理等工具。
每个工具都配有权限控制机制。 这是 Claude Code 安全架构中极其重要的一环。系统在每次工具调用之前都会进行权限检查——根据当前配置的权限模式（default、plan、bypassPermissions、auto 等），决定是直接执行、请求用户确认，还是拒绝操作。更有意思的是，代码中还发现了一个"权限解释器"（Permission Explainer）功能：当 Claude 需要请求用户批准某个操作时，它会调用一个单独的 LLM 请求来生成一段通俗易懂的风险说明。也就是说，Claude 用来解释"我为什么需要这个权限"的那段文字，本身也是由 AI 生成的。
安全防护方面同样考虑周到。受保护文件列表中包括 .gitconfig、.bashrc、.zshrc、.mcp.json、.claude.json 等敏感配置文件，这些文件被禁止自动编辑。路径遍历防护覆盖了 URL 编码绕过、Unicode 标准化攻击、反斜杠注入、大小写敏感路径操作等多种已知攻击向量。
（三）IDE 桥接系统 Bridge —— 连接编辑器的"神经通道"
bridge/ 目录下的代码实现了一个双向通信层，用于将 IDE 扩展（如 VS Code 和 JetBrains 系列 IDE）与 Claude Code CLI 连接起来。这意味着 Claude Code 不仅可以作为独立的终端工具使用，还能深度嵌入到开发者最常用的集成开发环境中。
这个桥接层支持实时的双向消息传递，IDE 可以向 Claude Code 发送请求（比如"解释选中的代码"、"重构这个函数"），Claude Code 也可以主动向 IDE 推送信息（比如代码修改建议、执行状态更新等）。这种双向通信的设计，为未来更深层次的 IDE 集成奠定了技术基础。
从工程实现的角度来看，Bridge 模块需要处理多种复杂的通信场景。比如当用户在 VS Code 中选中一段代码并右键选择"用 Claude 解释"时，IDE 扩展需要将选中的代码文本、文件路径、光标位置等上下文信息通过 Bridge 发送给 Claude Code CLI；Claude 处理完成后，结果又要通过 Bridge 回传到 IDE 中，可能是在编辑器中直接插入新代码，也可能是在侧边面板中显示解释文本。这整个流程要求通信层具备低延迟、高可靠性、以及良好的状态同步能力。
Bridge 的存在还暗示着 Claude Code 的产品形态正在从"独立终端工具"向"编辑器原生能力"演进。未来用户可能不再需要在终端和编辑器之间来回切换——Claude Code 的所有能力都可以直接在 IDE 中调用，就像使用内置的代码补全功能一样自然。
（四）多智能体协调系统 Coordinator —— 多个 AI "同时干活"
coordinator/ 目录揭示了 Claude Code 已经具备了多智能体协同工作的能力。这个协调器允许一个主智能体（Coordinator）调度多个从属智能体并行处理不同的子任务。
从技术实现上看，这个系统包含以下关键组件：TeamCreateTool 用于创建团队级别的并行工作流，多个子智能体可以同时处理不同模块的代码；协调器负责任务分配、进度追踪和结果汇总；子智能体之间通过共享任务列表进行协同，实现跨模块的并行实现。
想象一下这样的工作场景：你告诉 Claude"重构这个微服务的三个模块"，协调器可以同时启动三个子智能体分别处理各自的模块，最后统一汇总和整合，而不是串行地一个接一个处理。这将大幅提升大型项目中的开发效率。
（五）记忆与上下文管理 —— 让 AI "记住"你的项目
泄露代码中出现了多个与记忆相关的模块，展示了 Claude Code 在上下文管理方面的精细设计。
memdir/（持久化记忆目录）提供了跨会话的记忆存储能力。Claude Code 可以将对项目的理解、用户的偏好等信息持久化存储，在后续的会话中直接加载，避免每次都从零开始理解代码库。这个功能在实际使用中体现为 MEMORY.md 文件——Claude 会在使用过程中自动学习你的代码风格、项目规范、常用命令等，并将这些"记忆"写入 MEMORY.md 供后续会话参考。
context.ts 负责在每次会话启动时收集全面的系统和用户上下文信息，包括组织层面的策略配置、项目级别的 CLAUDE.md 指令文件、用户个人偏好等。这些上下文信息会被注入到 LLM 的系统提示词中，确保 Claude 从一开始就了解当前的工作环境。
更引人注目的是 services/autoDream/ 目录下的"自动梦境"系统——一个后台运行的记忆整合引擎。这个系统会作为一个后台子智能体运行，在 Claude Code 空闲时对积累的上下文信息进行整理和提炼，类似于人类在睡眠中进行记忆整合的过程。虽然命名颇具浪漫色彩，但其本质是一个务实的工程方案：通过异步处理来优化长期记忆的质量，而不影响主交互流程的响应速度。
（六）启动优化与性能策略
Claude Code 作为一个 CLI 工具，启动速度直接影响用户体验。泄露的代码展示了 Anthropic 在启动优化方面下了不少功夫。
在 main.tsx 中，多个初始化任务被设计为并行预取，在其他模块加载之前就开始执行：
// main.tsx —— 在其他 import 之前以副作用方式触发
startMdmRawRead() // 预读取 MDM（移动设备管理）配置
startKeychainPrefetch() // 预取密钥链信息那些体积较大或使用频率较低的模块——如 OpenTelemetry（遥测）、gRPC、分析服务、以及部分功能门控的子系统——则通过动态 import() 延迟加载，仅在实际需要时才加载到内存中。这种策略有效地减少了冷启动时间，让用户在输入 claude 命令后能更快地进入交互状态。
四、隐藏功能大揭秘：那些尚未发布的"彩蛋"
除了核心架构之外，泄露代码中最引人注目的莫过于多个尚未对外发布的隐藏功能。这些功能都被置于编译时特性标志（Feature Flag）之后，在对外发布的版本中被完全剔除。
4.1 Kairos 模式：永不离线的 AI 守护进程
在 assistant/ 目录下，隐藏着一个代号为"Kairos"的功能模块——这可能是整个泄露代码中最具前瞻性的发现。
Kairos 不是一个普通的命令行交互模式，而是一个具备"持久生命"的自主守护进程。它被设计为一个常驻后台运行的 Claude 智能体，不需要等待用户输入指令就能主动观察、记录甚至执行操作。从代码分析来看，Kairos 模式有以下几个关键特征：
它维护追加式的每日日志文件，在一天中持续记录观察、决策和操作。系统以固定间隔接收 <tick> 提示，在每次"心跳"中决定是否需要主动采取某种行动，还是保持静默。为了避免影响用户正常工作，系统设定了 15 秒的阻塞预算——任何可能阻塞用户工作流超过 15 秒的主动操作都会被延后处理。
Kairos 还拥有普通 Claude Code 所没有的特殊工具集，虽然具体工具列表尚未完全公开，但可以推测包括文件系统监控、项目变更检测等能力。
这个功能被 PROACTIVE 和 KAIROS 两个编译时特性标志门控，在当前的公开版本中完全不可见。如果未来正式发布，它将把 Claude Code 从一个"被动响应的编程助手"升级为一个"主动协作的编程伙伴"。
想象这样的使用场景：你在编写代码的过程中，Kairos 在后台默默观察你的文件修改和 Git 活动。当它发现你引入了一个可能导致类型错误的修改时，它会主动提醒你；当它检测到你的测试覆盖率下降时，它可能会建议你补充相应的测试用例；当它注意到你重复执行某个繁琐的操作时，它可能会主动提出创建一个自动化脚本来简化流程。这种"不说话但一直在关注"的工作方式，某种意义上比传统的问答式交互更贴近真实的结对编程体验——你的编程搭档不需要你每次都开口提问，他会在看到问题时主动提醒你。
4.2 ULTRAPLAN：远程深度规划模式
代码中还揭示了一个名为 ULTRAPLAN 的功能，它的设计理念相当大胆。当面对特别复杂的规划任务时，Claude Code 会将任务卸载到一个远程云容器运行时（CCR）中，使用更强大的模型（如 Opus 4.6）进行长达 30 分钟的深度思考。
整个流程是这样的：用户提出一个复杂任务，Claude Code 判断需要深度规划后启动 ULTRAPLAN 模式，任务被发送到远程 CCR 环境中运行。用户可以在浏览器中查看规划进度，完成后进行审批。一旦用户批准，系统会通过一个特殊的标记值 __ULTRAPLAN_TELEPORT_LOCAL__ 将规划结果"传送"回本地终端执行。
这个设计实现了本地工具轻量化与云端算力弹性化的结合，对于需要全局架构设计、大规模重构规划等重度任务来说，是一个很有想象力的解决方案。
4.3 Buddy System：工程师的电子宠物
这个发现大概是整个泄露代码中最让人会心一笑的部分了。在 buddy/ 目录下，Claude Code 的工程师们竟然内置了一套完整的电子宠物系统，设计风格类似于经典的拓麻歌子（Tamagotchi）。
这套系统的完整度令人惊讶：它包含 18 个不同的物种；每个物种都有稀有度等级划分；存在"闪光变体"（类似宝可梦中的异色个体）；每只宠物都有详细的属性统计数据；最特别的是，每只宠物在第一次"孵化"时，会由 Claude 生成一段独特的灵魂描述。
这个功能通过 BUDDY 编译时特性标志门控，系统还被设计为具有确定性的扭蛋机制——也就是说物种的随机分配是可以被验证和复现的，而非完全随机。
虽然这看起来像是工程师在工作之余的趣味创作，但它也反映了 Anthropic 工程团队的文化氛围——在构建严肃的 AI 工具的同时，也不忘在代码中埋下一些轻松有趣的元素。
4.4 Undercover Mode：颇具争议的"卧底"模式
泄露代码中还暴露了一个叫做"Undercover Mode"（卧底模式）的功能，这个功能的存在引发了社区中不小的讨论。
根据 utils/undercover.ts 中的代码逻辑，当 Anthropic 内部员工（通过 USER_TYPE === 'ant' 标识识别）在公共或开源仓库中使用 Claude Code 时，Undercover Mode 会自动激活。该模式的核心功能是在系统提示词中注入一段严格的指令，要求 Claude 在生成的提交信息、PR 标题和 PR 描述中不得包含任何 Anthropic 内部信息。
被禁止出现的内容包括：内部模型代号（如 Capybara、Tengu 等动物名称）、未发布的模型版本号（如 opus-4-7、sonnet-4-8 等）、内部仓库或项目名称、内部工具名、Slack 频道名或内部短链接、"Claude Code"字样或任何表明操作者是 AI 的信息、以及 Co-Authored-By 等归属标记。
系统提示词中甚至包含了一句颇为生动的指令："Do not blow your cover"（不要暴露你的身份）。
这个功能的存在说明 Anthropic 的员工在日常开发工作中确实大量使用 Claude Code 来参与开源项目的维护和开发。然而，这也引发了关于 AI 辅助编程透明度的讨论——当一个 AI 被刻意设计为隐藏自己的存在时，这是否影响了开源社区的信任基础？
当然，从 Anthropic 的角度来看，这个功能更多是出于商业保密的考虑——防止通过公开的 git 提交记录反推出内部正在开发的模型名称或项目细节。这是一个可以理解的安全需求，但其实现方式确实值得斟酌。
而最具讽刺意味的是：一个专门为防止信息泄露而设计的系统，最终却随着整个源代码一起被泄露了。
4.5 编译时特性标志机制
Claude Code 使用 Bun 的 bun:bundle 特性标志来管理这些隐藏功能。其工作原理是在编译阶段对代码进行静态分析，未激活的功能分支会被完全剔除（Dead Code Elimination），不会出现在最终的构建产物中。
import { feature } from 'bun:bundle'
// 未激活的代码在构建时被完全剔除
const voiceCommand = feature('VOICE_MODE')
? require('./commands/voice/index.js').default
: null泄露代码中发现的主要特性标志包括：PROACTIVE（主动模式）、KAIROS（常驻智能体）、BRIDGE_MODE（IDE 桥接）、DAEMON（守护进程模式）、VOICE_MODE（语音输入）、AGENT_TRIGGERS（智能体触发器）、MONITOR_TOOL（监控工具）、以及前面提到的 BUDDY（电子宠物）等。
这意味着当前公开版本的 Claude Code 只是完整系统的"冰山一角"——大量功能已经在代码库中实现并经过了一
