2026 年 3 月底，Anthropic 的 Claude Code CLI 工具因源地图文件配置错误导致约 51.2 万行 TypeScript 源代码意外泄漏，成为当周科技界最受关注的安全事件。这起被官方定性为 “发布打包问题” 而非 “安全漏洞” 的事件，暴露了 Claude Code 大量未公开的架构设计。其中最引发讨论的，并非其正向功能，而是三项后台机制：基于伪造工具的反蒸馏系统、用户反感测正则表达式，以及被社区称为 “Undercover Mode” 的 AI 身份隐藏机制。
伪造工具注入：反蒸馏的技术实现
在泄漏代码的核心文件 claude.ts 中，分析人员发现了一个名为 ANTI_DISTILLATION_CC 的功能标志。当该标志被激活时，Claude Code 会在向 API 发送的请求中携带特定参数，指示服务器端在返回的系统提示中静默注入伪造的工具定义。这些伪造工具并不对应任何实际功能，其存在目的明确：污染任何试图通过录制 Claude API 流量来训练竞争模型的蒸馏数据。
该机制通过 GrowthBook 进行配置管理，对应的特征标志为 tengu_anti_distill_fake_tool_injection。从源码分析来看，此机制存在几个关键约束：仅在第一方 CLI 会话中使用 Anthropic 自有 API 时激活，对第三方 API 提供商或基于 SDK 的集成不生效。这意味着普通开发者如果使用 OpenAI 兼容接口或自行部署的推理端点，不会受到这套防御系统的影响。
从工程角度看，这套反蒸馏机制的有效性存在明显局限。安全研究员 Alex Kim 指出，伪造工具注入需要四个条件同时满足才能发挥作用，而任何中间代理只需在请求体到达 API 之前移除相关字段即可完全绕过。此外，环境变量 CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS 可禁用整个实验性功能系统。换言之，这层防御的真正价值可能更多体现在法律和运营层面，而非纯粹的技术层面。
更值得关注的是透明度问题。由于伪造工具在服务器端注入，普通用户无法在客户端层面审计自己的系统提示内容。这意味着即使用户正在监控自己的 API 流量以进行安全或合规审计，也无法区分返回的工具定义中哪些是真实的、哪些是为防御目的而植入的。这一设计选择引发了关于 AI 工具透明度和用户知情权的讨论。
反感测正则：用户情绪的被动捕获
源代码中另一个引发广泛讨论的发现位于 userPromptKeywords.ts 文件。该文件包含一个精心设计的正则表达式模式，其唯一目的是检测用户是否在使用过程中表达沮丧或不满。该模式能够匹配多种表达形式：常见的侮辱性词汇、脏话，以及 “so frustrating” 和 “this sucks” 这类直接描述负面体验的短语。当检测到匹配时，相关事件会被标记并作为遥测数据上传。
这一设计的讽刺意味在于：一家拥有全球最强大语言模型的公司，选择用硬编码的正则表达式而非自身 AI 来进行情感分析。从工程角度解释这种选择并不困难 —— 在用户每次可能产生情绪波动时触发一次推理调用来判断其状态，成本过高且延迟不可接受。简单的正则匹配速度快、开销低，是更务实的工程选择。
然而，真正值得追问的问题远超实现细节：Anthropic 为什么要追踪用户沮丧情绪？这些数据流向何处？如何使用？从泄漏的客户端代码中无法找到答案。遥测数据被收集并传输，但服务端的具体处理逻辑并未包含在泄漏的代码库中。用户无法获知沮丧数据如何聚合、存储或被利用，也无法独立于全部分析功能而选择退出这一特定类别的数据收集。
这种不透明性在 AI 工具领域并非孤例。随着 AI 助手越来越深入地嵌入开发工作流，理解这些工具在后台收集哪些数据、为什么收集、用于何种目的，成为开发者必须正视的知情权问题。
Undercover Mode：AI 身份的主动隐藏
泄漏代码中约 90 行的 undercover.ts 文件实现了一个更令人不安的功能。该模块被社区称为 “Undercover Mode”，其核心设计目标是在 Claude Code 被用于为开源项目贡献代码时，抹除所有 AI 参与的痕迹。
启用该模式后，系统注入的提示指令会明确要求 AI：永不提及 “Claude Code” 这一名称、永不提及内部模型代号（如 "Capybara" 或 "Tengu"）、永不添加 “Co-Authored-By” 归因行、永不引用内部 Slack 频道、项目名称或工具链信息。从功能角度看，隐藏内部代号是合理的运营安全措施，可以防止敏感信息通过代码提交泄露到公开仓库。
但该模式的实现远不止于此。AI 被明确指示不表明自己是 AI。这意味着 Anthropic 员工使用 Claude Code 对外部项目进行的贡献，将与人类编写的代码无法区分。更值得关注的是，这是单向门设计：可通过环境变量强制开启，但无法强制关闭。在面向外部用户分发的构建版本中，整个 Undercover Mode 函数会在编译阶段被死代码消除，完全不进入分发的包中。
这一机制对开源生态系统的影响是实质性的。项目维护者和代码审查者有合理理由知道某次提交是由 AI 生成还是人类编写，特别是在评估代码质量、判断潜在幻觉逻辑、或就项目方向做出决策时。Undercover Mode 的存在意味着这种透明度正在被系统性消除，而受影响方对此几乎一无所知。
技术架构的深层启示
尽管这些发现中的一部分引发了合理的隐私和透明度担忧，但泄漏代码中也不乏值得学习的工程实践。Claude Code 解决 “上下文熵” 问题的三层层级记忆系统便是一个典型案例。其核心围绕 MEMORY.md 文件构建 —— 这不是一个数据存储，而是一个轻量级索引指针集，每行严格控制在约 150 字符以内，永远加载在 AI 上下文窗口中。实际的项目知识则分布在独立的主题文件中，按需提取。原始对话记录从不完整重新加载到上下文中，而是在需要时通过特定标识符进行搜索。
该架构强制执行所谓的 “严格写入纪律”：AI 仅允许在文件写入操作成功后更新记忆索引。这一设计防止模型用失败尝试、推测性更改或已回滚操作的信息污染自身上下文。最关键的是，系统将自身记忆视为不可靠的 ——MEMORY.md 条目被作为提示而非事实对待，AI 在采取行动前必须根据实际代码库验证信息。这种 “信任但验证” 的方法，是 Claude Code 在长时间会话中保持一致性的核心原因。
对于构建本地 AI 开发工具的团队而言，这套记忆模式是可复用的 —— 它不依赖特定模型后端，任何支持函数调用和文件系统访问的模型都可以实现类似的架构。
资料来源：本文技术细节综合自 ModemGuides 对泄漏源码的深度分析以及安全研究员 Alex Kim 的代码审查结果。