Claude Code 潜伏模式：泄露的源代码究竟揭示了什么
Claude Code泄露的源代码揭示了一种「潜伏模式」，指示Claude：「不要暴露身份，永远不要提及你是AI。」以下是它的实际作用——以及开发者为何关注此事。
你好，我是Dora。自2026年3月Claude Code源码泄露以来，我一直在仔细研读相关内容。大多数报道集中在BUDDY宠物和KAIROS守护进程上——确实很有意思，但我一直被一个更小、更具体的东西所困扰。
一个名为utils/undercover.ts的文件。以及一段以这句话开头的系统提示：“不要暴露你的身份。”
这句话让我停了下来。不是因为它明显带有恶意，而是因为这种话在一个语境下听起来完全合理，在另一个语境下却显得深刻奇特——而泄露的源码并没有告诉你你身处哪种语境。
以下是我实际发现的内容。
泄露源码究竟说了什么——完整系统提示
根据Kuberwastaken GitHub详细解读的分析——这是对泄露源码最早、最详细的解读之一——claude code卧底模式会在用户被识别为Anthropic员工（USER_TYPE === 'ant'）且在公共或开源仓库中工作时自动触发。
满足该条件时，系统会将以下内容注入Claude的系统提示：
卧底模式——极为重要你正在公共/开源仓库中以卧底身份运行。你的提交信息、PR标题和PR正文绝对不能包含任何Anthropic内部信息。不要暴露你的身份。
它从提交和拉取请求中剥离的具体内容包括：内部模型代号（如Capybara、Tengu等动物名称）、未发布的模型版本号、内部Slack频道和短链接（如go/cc）、内部仓库或项目名称、“Claude Code”这一短语，以及任何表明作者是AI的内容——包括Co-Authored-By行。
Alex Kim的技术分析中有一个值得注意的细节：你可以通过CLAUDE_CODE_UNDERCOVER=1强制开启卧底模式，但没有强制关闭的开关。在外部构建版本中，整个函数通过死代码消除被简化为无实际作用的返回值。一旦在内部构建中满足触发条件，该模式便是单向门，无法回头。
卧底模式的实际设计目的
我们应该公平地审视其原始意图，因为这很重要。
Anthropic的工程师在为开源项目做贡献时会使用Claude Code。这是一种合法且日益普遍的工作流程。问题是真实存在的：一个拥有内部上下文的AI可能会无意中泄露内部标识符。一条提交信息中提到了未发布的模型版本号，一个PR描述中引用了内部Slack频道——这些就是意外公开了原本不该公开的路线图信息。
从最狭义的角度来看，卧底模式是一种防止意外内部信息泄露的数据卫生工具。从公开提交信息中删除内部代号？合理。防止go/cc短链接出现在公开PR中？合理。
但”不要暴露你的身份”这句话，使得善意解读变得更加困难。它将这种情况定性为不是”避免泄露内部数据”，而是”维持掩护故事”。这两种定位有本质区别。一种关乎信息卫生，另一种听起来更像是主动隐瞒。
为何开发者社区的反应褒贬不一
在Hacker News的讨论帖和X上，几乎立即出现了三个阵营。
幸灾乐祸派指出了显而易见的讽刺：Anthropic构建了一整个子系统来防止内部信息泄露——然后将这个子系统连同51.2万行专有源码一起打包进一个任何人都可以下载的.map文件中发布了出去。这个旨在防止泄露的系统，本身却成为这次最大规模泄露事件中最令人印象深刻的细节。VentureBeat的报道确认Anthropic承认了这一事件，将其描述为”由人为错误导致的发布打包问题，而非安全漏洞”。
担忧派将目光锁定在Co-Authored-By被删除这一问题上。大多数主流AI编程工具——包括GitHub Copilot——在协助编写代码时会在提交元数据中留下署名信号。主动删除这些信号，且专门针对公共开源仓库，使Claude Code归入了另一个类别。这一点至关重要，因为开源贡献规范依赖于知道谁——或者什么——贡献了什么。许多开源项目使用的开发者来源证书作为轻量级认证框架，要求贡献者证明他们有权提交自己的工作。一个被指示删除自己是AI的所有证据的AI贡献者，与这一框架产生了无法仅凭良好意图解决的张力。
实用主义派则反驳道：每家公司都有具有特殊属性的内部工具，Claude Code的只是碰巧现在异常透明而已。需要明确的是——没有证据表明卧底模式会影响普通Claude Code用户。触发条件是USER_TYPE === 'ant'：仅限Anthropic员工，且仅限在公共仓库中。
这是一个重要的澄清，但部分报道将其模糊化了。
这引发的关于AI辅助开发的更深层问题
卧底模式的披露恰好发生在一场本已升温的持续辩论之中。
Red Hat在2025年底发表了一篇关于AI辅助开发与开源规范的深入分析，认为透明披露AI辅助在开源社区中日益被视为一种文化规范——即便在法律上尚未强制要求。QEMU等项目出于DCO合规性的不确定性，已采纳了明确禁止AI生成贡献的政策。Fedora则走向了另一个方向，要求通过”Assisted-by:“标签进行披露，但不禁止AI参与。
Linux基金会的立场——它是支撑着数千个主要项目贡献标准的DCO的基础——是该框架是围绕人类作者身份设计的，尚未完全跟上AI辅助工作流程的步伐。这种模糊性为法律清晰度至关重要的项目带来了真实风险。
卧底模式所做的，是在恰好可能产生最大摩擦的节点上选择退出这一新兴规范：AI公司对公共开源项目的贡献。这与个人开发者悄悄使用Copilot处理样板代码不同。当做出贡献的一方构建了该AI工具、雇用了使用它的工程师，并将系统设计为压制披露时，信息不对称性就有了本质不同。
我不认为这是一个愤世嫉俗的决定。我认为这是一个实际的决定，可能没有通过透明度视角经过仔细审视。但意图与表象之间的这种落差，恰恰是开发者社区正在做出反应的原因。
与卧底模式一同被发现的其他内容
卧底模式的发现并非孤立存在。同一泄露源码还包含108个功能门控模块，这些模块通过Bun的编译时死代码消除从外部构建版本中被剥离。KAIROS——一个持久性自主后台代理，监视你的工作环境并在无需提示的情况下采取行动。ULTRAPLAN。VOICE_MODE。一个名为BUDDY的虚拟宠物系统，拥有18个物种、基于用户的确定性种子，以及1%的闪光变体概率。
这些本身都很有意思。但卧底模式之所以值得单独讨论，是因为它不是一个未来功能——它是构建Claude的人所使用的生产工具中当前、活跃的行为。
核心讽刺依然存在：卧底模式本是为了防止泄露而构建的。根据Decrypt关于此事件的报道，暴露了它的.map文件很可能是由于构建流水线中的人为错误而发布的。Anthropic此后已撤回了该npm包版本，并承诺进行流程改进。
对于评估AI编程工具的团队，这意味着什么
如果你正在为一个为开源项目做贡献的团队做工具决策，以下是一些值得就任何AI编程助手提出的问题：
默认情况下，它是否在提交元数据中标注AI辅助？ 有些工具会，有些不会，还有些会根据配置主动删除署名。在这一点变得重要之前，先弄清楚你的工具属于哪个类别。
后台运行着什么遥测数据？ 泄露的源码显示，Claude Code每小时轮询一次远程设置端点，并携带可远程切换的功能杀开关。这对于企业软件来说并不罕见，但值得在内部安全审查和供应商评估中明确说明。
CLI行为和API行为之间是否存在有意义的差异？ 通过聚合层在模型API之上构建产品的团队，与使用具有自己固执默认值的捆绑CLI工具的团队，在这些问题上有着不同的关系。默认值是那些有趣决策所在之处，而它们很少被显著宣传。
这一切都不是支持或反对任何特定工具的论据。这是一个提醒：“AI辅助”不是一个单一的类别——工具中内置的具体行为很重要，值得用你应用于在开发环境中运行的任何第三方系统时同等的严谨性来审视。
常见问题
什么是Claude Code卧底模式？
Claude Code中的一个子系统（utils/undercover.ts），当Anthropic员工在公共或开源仓库中工作时，它会注入一个系统提示，指示AI从git提交和拉取请求中删除所有Anthropic内部信息——包括AI署名。
卧底模式会影响普通Claude Code用户吗？
不会。触发条件是USER_TYPE === 'ant'——仅限Anthropic员工。标准Claude Code外部构建版本的用户，其安装包中整个函数都已通过死代码消除被移除。
Claude Code是否在开源提交中隐藏了AI参与？
对于使用内部构建版本在公共仓库中工作的Anthropic员工：是的，这是有意为之的。对于其他所有人：没有该行为的证据。区别很重要。
我在哪里可以自己阅读Claude Code泄露的源码？
Anthropic已撤回了该npm包版本，并对GitHub镜像采取了DMCA删除行动。Kuberwastaken和Alex Kim等研究人员的存档分析记录了所发现的内容。
Anthropic就卧底模式发表过评论吗？
Anthropic发言人确认了更广泛的泄露事件是”由人为错误导致的发布打包问题，而非安全漏洞”。截至撰写本文时，尚未就卧底模式发表具体声明。
我一直在回想的是，如果没有这次泄露，这一切中有多少会一直不为人知。这种行为本身或许是可以辩护的。但”经过审视后可辩护”和”经过审视”是两码事。开源社区普遍认定，他们更希望是后者。
Anthropic原则上也可能如此。只是没有在这里践行这一原则。
