Claude Code源代码意外泄露：AI圈炸锅，反蒸馏机制与系统提示词设计曝光

昨天，AI 领域发生了一件轰动性事件：Claude Code 的源代码被「被动」开源。

由于工程失误，Anthropic 在发布 npm 包时未剔除 source map 文件，导致完整的 TypeScript 源码可被轻易还原。短短数小时内，代码已被下载、镜像，并在 GitHub 上迅速扩散。

这种泄露方式，被戏称为某种意义上的“开源”。马斯克在看到“Anthropic 现在已经比 OpenAI 更 Open”的评论时，也回复道：“绝了😂”。

关于此次事件的原因，Anthropic 虽未发布官方报告，但科技媒体 Decrypt 从一位发言人处获得了评论：“今天早些时候，一个 Claude Code 版本包含了部分内部源代码。没有涉及或暴露任何敏感的客户数据或凭证。这属于人为错误导致的发布打包问题，并未构成安全漏洞。我们正在采取措施防止此类事件再次发生。”

Claude Code 之父 Boris Cherny 也在 X 上简单表示，这“就是开发者的错误”所致。

当公众还在围观这场“被动开源”的戏剧性事件时，另一批人已经开始沉下心来逐行阅读代码，尝试还原其背后的设计逻辑。一些原本不对外公开的系统级策略也随之曝光，尤其是在模型能力保护与数据安全层面，Claude Code 显然进行了更深层次的工程设计。

对 Claude Code 源代码的多方深度解读

当吃瓜群众还在围观时，大量开发者已经开始逐行阅读代码，尝试还原顶级 AI Agent 背后的设计逻辑。

Claude Code 内置了两套反蒸馏机制

X 用户 Sahil 发现，Anthropic 在 Claude Code 中内置了两套反蒸馏机制，用于防止竞争对手利用其输出数据进行模型训练。

• 其中一套机制，会在模型输出流中注入伪造的工具调用，从而污染任何被抓取的数据，使其难以被有效用于训练。
• 另一套机制，则会将所有工具调用的具体细节抽象成模糊的摘要，使得外部很难还原 Agent 实际执行了哪些操作。

来源：https://x.com/sahilypatel/status/2039004352367689891

Claude Code 源码中可以学到并复用的东西

AlphaSignalAI 开发者 Lior Alexander 对 Claude Code 源代码进行了深度分析，并总结了多个要点，以下是其中几条比较有价值的发现：

来源：https://x.com/LiorOnAI/status/2039068248390688803

1. 系统提示词是一门行为控制的范本

完整的系统提示词位于 constants/prompts.ts，可以说是整个代码库中最有价值的文件之一。它清晰展示了 Anthropic 是如何在生产级编码 Agent 中精确控制 Claude 的行为，以及每一条指令背后的设计动机。

• 三行重复代码，也好过过早抽象：在编码指令部分，系统明确要求 Claude 不要为一次性操作创建 helper、工具函数或抽象结构，也不要为假想的未来需求做设计。
• 默认不写注释：一个带有 @[MODEL LAUNCH] 标记的注释说明，这是为了对抗内部代号为 Capybara 的模型默认过度注释的问题。指令规定，只有在 WHY is non-obvious 时才允许添加注释。
• 如实报告结果：另一个 @[MODEL LAUNCH] 标注透露，Capybara v8 的错误陈述率高达 29–30%（相比 v4 的 16.7%）。因此，提示词明确规定：
  • 不要在测试失败时声称全部通过
  • 不要隐藏失败检查来制造成功结果
  • 不要把未完成的工作描述为已完成
• 用数字约束比用模糊描述更有效：源码中的注释提到，相比使用“简洁”等模糊描述，使用明确的字数限制可降低约 1.2% 的输出 token。因此，Anthropic 直接规定：
  • 工具调用之间的文本 ≤25 个词
  • 最终回答 ≤100 个词
• 外部提示词与内部提示词分层设计：对外用户使用的提示词是简洁版（如“直奔重点，尽量简短”），而内部（Anthropic 员工使用）版本则更复杂。
• 隐藏的 Simple 模式：当设置环境变量 CLAUDE_CODE_SIMPLE=1 时，整个复杂的系统提示词会被压缩为一行：“You are Claude Code, Anthropic’s official CLI for Claude”，并附带当前工作目录与日期，不包含任何编码规则、语气控制或工具使用指令。

2. 对 Claude Code 爆粗口，会被标记为负面输入

在 utils/userPromptKeywords.ts 这个仅 26 行的小文件中，系统会在每条用户输入发送到 API 之前，用两组正则表达式检测用户是否使用了脏话粗口。

对此，Claude Code 之父 Boris Cherny 评论说：“这是我们用来判断用户体验是否良好的信号之一。”

3. Claude Code 里藏了一个电子宠物

在 src/buddy/ 目录中，系统通过对用户 ID 进行哈希（基于带种子的随机数生成器），为每个用户生成一个专属且固定的虚拟伙伴（代号 Buddy）。其物种、外观和属性均由算法决定，从而实现无需存储的个性化体验。

这个哈希值会进一步映射为一整套完整的角色配置，包括：

• 物种：鸭子、鹅、Blob、猫、龙、章鱼、猫头鹰、企鹅等
• 帽子：无、王冠、礼帽、螺旋桨帽等
• 稀有度：普通（60%）、不常见（25%）、稀有（10%）等

值得注意的是，刚刚更新的 Claude Code v2.1.89 已经上线了 Buddy 功能。用户更新后只需输入 /buddy 即可启用——即使配置了其它模型也可成功启用。

4. 内置 187 个加载动词

Claude Code 内置了 187 个随机动词，在模型思考时轮流显示（例如 Beboppin‘、Lollygagging 等），用来替代单调的 “Loading…”。这些动词古灵精怪，例如：Accomplishing、Actioning、Actualizing、Architecting、Baking…… 共计 187 个。

Cherny 表示这个词汇表最早是他整理的，并吸收了其他人的一些贡献。他还指出，用户也可以让 Claude 添加自己想要的动词。

5. 反蒸馏机制：通过注入假工具污染竞争对手训练数据

在 services/api/claude.ts 中，存在一项通过 feature flag 控制的机制：在 API 请求体中加入 anti_distillation: ['fake_tools']。

5. 反蒸馏输出格式

streamlinedTransform.ts 文件实现了一种抗蒸馏的输出格式，旨在防止通过模型输出来逆向还原其完整的推理过程。其核心机制包括：
* 剥离思考过程：去除模型内部的思考内容。
* 简化工具调用：将具体的工具调用简化为类别统计（如搜索、读取、写入、命令等）。

这使得外部攻击者难以根据捕获的输出，重建 Claude 完整的推理链路。

6. 极精细化的 Prompt 缓存管理

代码库中最复杂的非 UI 代码之一是 promptCacheBreakDetection.ts。在每次 API 调用中，系统会对以下所有参数进行哈希处理，并与上一次调用进行对比：
* system prompt
* 每个工具的 schema（逐一哈希）
* 模型名称
* beta headers
* fast mode 状态
* effort 参数
* overage 状态
* 额外的请求体参数

任何变化都会被记录，并生成统一的差异报告。

缓存结构优化：
* system prompt 被 SYSTEM_PROMPT_DYNAMIC_BOUNDARY 分为两部分：上半部分为静态可缓存内容，下半部分为随会话变化的动态内容。
* MCP 服务器相关指令被从 system prompt 中移除，改为通过消息的增量附加（delta attachments）传递。这是因为若将其置于 system prompt 中，每次服务器连接变化都会导致整个缓存失效。

缓存安全继承：子 Agent 会从父 Agent 继承 CacheSafeParams（一个包含所有影响缓存键参数的结构体）。源码注释特别警告：在 fork 出的 Agent 上设置 maxOutputTokens，可能会意外限制 budget_tokens，并在旧模型上破坏缓存兼容性。

7. 卧底模式：在开源贡献中隐藏身份

utils/undercover.ts 实现了一种卧底模式。当 Anthropic 员工（USER_TYPE === 'ant'）在非内部仓库中工作时，该模式会自动且默认开启。仅当 git 远程仓库明确匹配内部白名单时，才会关闭。

一旦激活，系统提示词中会注入一段标题为 UNDERCOVER MODE: CRITICAL 的指令，要求 Claude 在公共/开源仓库中以“卧底”身份工作，其提交信息、PR 标题和内容中绝不能包含任何 Anthropic 内部信息。

被禁止的信息包括：
* 内部模型代号（如 Capybara、Tengu 等）
* 未发布的模型版本号
* 内部仓库名称
* Slack 频道
* “Claude Code”这一表述
* 任何关于自己是 AI 的描述
* Co-Authored-By 等署名信息

源码注释明确指出：此模式没有强制关闭选项，用于防止模型代号泄露。只要系统无法确认当前仓库是内部仓库，就始终保持卧底状态。

8. 25 万次被浪费的 API 调用与熔断机制

自动压缩（auto-compaction）系统中的一段注释，揭示了引入熔断机制的直接原因：

BQ 2026-03-10：有 1,279 个会话在单个会话中出现了 50 次以上的连续失败（最多达到 3,272 次），每天在全球范围内浪费约 25 万次 API 调用。

最终的解决方案是设置 MAX_CONSECUTIVE_AUTOCOMPACT_FAILURES = 3。当连续三次压缩失败后，系统将停止继续尝试，避免资源浪费。

压缩系统关键阈值：
* 摘要预留：为摘要输出预留 20,000 tokens（基于历史观测中摘要长度的 p99.99，约为 17,387 tokens）。
* 自动压缩触发阈值：context_window - max_output_tokens - 13,000 buffer
* 强制压缩（阻塞用户）阈值：context_window - max_output_tokens - 3,000 buffer

9. 独立验证：禁止模型自我确认

Claude Code 有一个关键设计原则：编写代码的 Agent 不能自行宣布任务完成。

当任务达到一定复杂度（例如修改了 3 个以上文件、涉及后端或基础设施变更），系统会自动拉起一个独立的验证智能体来检查结果。流程如下：
1. 主 Agent 编写代码。
2. 验证 Agent 独立进行检查。
3. 主 Agent 还需对验证结果进行抽查复核。

如果验证失败，则返回修改；即使通过，也不能盲目相信，必须复核证据。

10. Auto Dream：跨会话的后台记忆整合

services/autoDream/autoDream.ts 实现了一套后台记忆整合机制。当满足条件（时间间隔足够、累计了足够多的新会话内容）时，Claude Code 会以 fork 出的 subagent 形式运行 /dream 命令，回顾历史会话并将其压缩整理为结构化的 MEMORY.md 文件。

触发流程遵循先廉价后昂贵的判断顺序：
1. 检查时间（是否距离上次整理足够久）。
2. 检查会话数量（是否积累了足够的新内容）。
3. 检查锁（是否已有进程在执行整理）。执行过程会加文件锁，若整理失败则自动回滚。

记忆模板：提取为 10 个结构化模块，每个模块限制在约 2000 tokens，总体控制在 12000 tokens 以内。
1. Session Title
2. Current State
3. Task Specification
4. Files and Functions
5. Workflow
6. Errors & Corrections
7. Codebase Documentation
8. Learnings
9. Key Results
10. Worklog

动态触发：记忆提取不仅在周期性任务中触发，也会在任务执行中动态发生。当累计上下文达到 10000 tokens 时首次触发，此后每增加 5000 tokens 或发生 3 次工具调用，就会再次触发一次整理。

11. 2592 行 Bash 安全防护

tools/BashTool/bashSecurity.ts 文件长达 2592 行，实现了 42 项 独立的安全检查机制，以保障 Bash 工具执行的安全性。

12. 构建阶段的金丝雀机制

代码库中多处引用了 excluded-strings.txt 文件。该文件列出了绝对不能出现在外部构建产物中的字符串，包括内部代号、API Key 前缀等敏感信息。构建系统会对打包后的输出进行扫描，一旦发现这些字符串，就会直接导致构建失败，防止敏感信息泄露。

Sebastian Raschka 解读

知名 AI 技术博主、《Python 机器学习》作者 Sebastian Raschka 也对泄露代码进行了梳理与解读。

博客链接：https://sebastianraschka.com/blog/2026/claude-code-secret-sauce.html

关键发现：
1. 构建实时仓库上下文：当用户开始输入提示时，Claude 会自动加载主分支、当前分支、最近的提交记录以及 CLAUDE.md 文件，作为初始上下文的一部分。
2. 激进的 Prompt 缓存复用机制：系统通过精细的哈希对比，极力复用缓存，以提升效率并降低成本。

3. 工具体系化优于文件上传聊天

系统提示词引导模型优先使用专用的 Grep 工具，而非通过 Bash 调用 grep 或 rg。这很可能是因为专用工具在权限管理上更安全，同时在结果的收集与处理上也更为高效。

此外，系统还提供了专门的 Glob 工具用于文件路径发现，并集成了 LSP（语言服务器协议） 工具，以支持调用关系分析、查找引用等高级代码理解任务。

相比之下，传统的聊天界面将代码视为静态文本进行处理，而这套结构化的工具链使模型能够以更深入、更高效的方式理解和操作代码，从而带来显著的能力提升。

4. 最小化上下文膨胀

在处理代码仓库时，核心挑战之一是有限的上下文长度。这一问题在与 Agent 进行多轮交互、反复读取文件、处理日志及冗长的 Shell 输出等场景下会被迅速放大。

Claude Code 通过一系列底层工程优化来缓解此问题：

• 文件读取去重：系统会检测文件内容是否发生变化，若未变化则避免重复处理。
• 大结果外置：当工具输出结果过大时，会将其写入磁盘，而在上下文中仅保留摘要预览和文件引用。
• 自动上下文管理：系统会自动截断过长的上下文，并在必要时进行自动压缩（总结），类似于现代 LLM 用户界面的做法。

整体而言，这些机制旨在有限的上下文窗口内，最大化保留高价值信息，同时剔除无效内容以节省空间。

5. 结构化会话记忆

Claude Code 会为当前对话维护一份结构化的 Markdown 记忆文件，其内容组织包括：

• 会话标题
• 当前状态
• 任务描述
• 涉及的文件与函数
• 工作流程
• 错误与修正记录
• 代码库与系统文档
• 学习与总结
• 关键结果
• 工作日志

从某种程度上看，这模仿了人类开发者处理复杂任务时的习惯：持续记录笔记、总结过程，以保持清晰的上下文与思路。

6. 使用 Fork 与子代理（Subagents）

Claude Code 能够通过创建 子代理（Subagents） 来并行处理任务，这一直是其相较于早期 Codex 模型的一个优势（直到后者近期也开始支持类似功能）。

被 fork 出来的子代理会复用父代理的缓存，同时能够感知可变状态。这使得系统可以在后台执行摘要生成、记忆提取、背景分析等旁路任务，而不会干扰主代理的执行流程。

Sebastian 最后总结道，Claude Code 的优越性并非源于提示词工程，甚至不完全取决于模型本身，而在于上述围绕性能与上下文管理的一系列细节优化。

当然，一个非常现实的优势是：所有工作内容都可以在本地环境中被有序组织和管理，无需反复将文件上传至聊天界面，这种工作流本身也极大地提升了整体使用体验。

此外，有网友整理了一份关于 Claude Code 源码的深度研究报告，涵盖了整体架构、系统提示词、Agent 提示词、Skills、Plugins、Hooks、MCP、权限与工具调用机制，以及新增的全量 Prompt 提取框架分析与 Agent 调度链深度挖掘等内容。

改写与改进版正在涌现

由于直接发布 Anthropic 泄露的源代码可能涉及法律风险，一些研究者和工程师已开始着手改写甚至改进这 50 多万行代码，而这项工作本身也离不开 AI 的辅助。有趣的是，其中一个衍生项目甚至创造了 GitHub 历史上星标数增长速度最快的纪录！

时间回溯到 Claude Code 源代码泄露后约 6 小时，此时该代码在 GitHub 上已被 fork 超过 4 万次。Anthropic 开始反应，试图依据美国的《数字千年版权法》（DMCA）要求 GitHub 删除这些源代码。

然而，众所周知：为时已晚。

除了已被成千上万开发者下载到本地的副本，这些源代码还被上传到了去中心化平台上——意味着它们“永远不会被删除”。

一位名叫 Sigrid Jin 的韩国开发者另辟蹊径，决定着手改写一个版本。

据悉，他在凌晨 4 点醒来时看到了 Claude Code 源代码泄露的消息，随即决定使用一个名为 oh-my-codex 的 AI 编排工具，将核心架构移植到 Python，并在日出前推送了 claw-code 项目。该仓库的星标数如火箭般飙升，仅用 2 小时 就超过了 5 万，打破了 GitHub 星标增长速度的历史纪录。

如今，这个上线仅十余小时的仓库，星标数已突破 6.6 万 并仍在持续增长。

值得注意的是，从该仓库的简介中可以看到，Sigrid Jin 目前正与开源社区（以及他们的 AI）一同用 Rust 重写该项目！

对此，《The Pragmatic Engineer》的创始人 Gergely Orosz 在 X 上评论道：“这要么很绝妙，要么很可怕：Anthropic 意外泄露了 Claude Code 的 TS 源代码。分享源代码的仓库被 DMCA 下架。但是这个仓库用 Python 重写了代码，因此它没有侵犯版权，并且无法被下架，让 DMCA 有力也无处使！”

考虑到 Claude Code 本身有很大一部分是由 AI 编写的，其背后的法律问题可能变得更加复杂——毕竟，AI 生成内容（AIGC）是否应享有版权一直存在争议。

此外，开源社区对 Claude Code 的改进也已开始。

毕竟，一个 51 万行代码的项目难免存在问题。正如 X 用户 Rohan 在其技术博客中所分析的，Anthropic 在设计 Claude Code 时存在一些“错误之处”。

我们让 Gemini 对其分析进行了简要总结：

• 上帝组件与 Hook 滥用：核心交互组件 REPL.tsx 长度超过 5000 行，包含 227 个 Hook 调用，逻辑高度耦合且难以进行单元测试。
• 特性标志与环境变量泛滥：存在 89 个特性标志和 472 个环境变量，反映出产品方向不够明确，且缺乏对陈旧试验代码的清理。
• 架构设计缺失导致循环引用：61 个文件存在循环依赖补丁，核心类型 Tool.ts 过于沉重，导致模块边界模糊，严重依赖 lazy require 来规避问题。
• 防御性编程沦为形式主义：为防止泄露代码而强制使用的超长类型名（53 字符）被调用上千次，已失去警示作用，演变为无意义的“代码仪式”。
• 性能优化的极端折衷：为了在 Bun 环境下节省 135 毫秒的启动时间，将近 4700 行的 CLI 逻辑堆积在单一入口文件中，牺牲了代码的可读性与可维护性。
• 快速扩张的技术债：底层模式显示，功能迭代速度远超架构演进。即便拥有巨额融资，顶尖AI产品的工程实践依然充满了临时的局部规避与妥协。

然而，社区的改进正在进行。X用户 idoubi 利用Claude Code分析了泄露的源码，将其核心逻辑抽离并重构，发布了 open-agent-sdk，旨在解决原版claude-agent-sdk不适合云端规模化调用的问题。

与此同时，另一位X用户则开发了一个兼容层（shim），将Claude Code的接口开放给了多种第三方模型和服务，极大地扩展了其适用性。

受此启发，诸如 OpenClaude、Free Code、claw-code 等一批衍生项目也如雨后春笋般涌现。

结语

Claude Code源码泄露事件，为我们提供了一个极具观察价值的行业切片。

一方面，它揭示了即便估值百亿的顶尖AI企业，其底层工程实现也难免充满妥协、技术债与“草台班子”式的局部修补。那些看似高深莫测的Agent能力，背后往往是由极其细致甚至略显繁琐的工程校验规则堆砌而成。

另一方面，开源社区在短短24小时内的反应速度令人惊叹。借助AI工具，开发者能够瞬间解构、翻译并重构一个51万行的复杂系统。当代码重构的时间成本被压缩到极致，传统的软件著作权边界正变得日益模糊。

这场由失误引发的代码狂欢，或许正预示着AI将以我们未曾设想的方式，重塑软件工程的迭代速度与开源生态的底层逻辑。

关注“鲸栖”小程序，掌握最新AI资讯