docs: 新增「揭秘:隐藏功能与内部机制」文档栏目

添加 5 篇文档揭示 Claude Code 的三层功能门禁系统:
- 构建时 88+ feature flags 分类全解
- GrowthBook 运行时 A/B 测试体系与 tengu_* 命名文化
- KAIROS/PROACTIVE/BRIDGE 等 8 大未公开功能深度分析
- Ant 身份门控下的专属工具、命令与 Beta API

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
claude-code-best 2026-04-01 11:30:27 +08:00
parent 4233ee7de6
commit 2fa91489c8
6 changed files with 619 additions and 0 deletions

View File

@ -0,0 +1,158 @@
---
title: "Ant 的特权世界"
description: "USER_TYPE === 'ant'——Anthropic 员工专属的工具、命令、API 和代号体系"
---
{/* 本章目标完整记录身份门控层——ant 构建独享的一切 */}
## 什么是 Ant
`USER_TYPE` 是一个构建时常量,通过 Bun 打包器的 `--define` 注入。在 Anthropic 的内部构建中它被设为 `'ant'`,在公开发布的版本中是 `'external'`
```typescript
// 反编译版本src/entrypoints/cli.tsx 第 16 行)
(globalThis as any).BUILD_TARGET = "external";
```
由于这是编译时常量Bun 会进行**常量折叠**——所有 `process.env.USER_TYPE === 'ant'` 在外部构建中直接变为 `false`,后续代码被 DCE 移除。但在反编译版本中,这些代码保留完整。
`USER_TYPE === 'ant'` 出现在代码库的 **60+ 个位置**控制着工具、命令、API、UI 等方方面面。
## Ant-Only 工具
以下工具仅在内部构建中被加载到工具注册表:
| 工具 | 代码位置 | 用途 |
|------|---------|------|
| **REPLTool** | `src/tools/REPLTool/` | 高级 REPL 模式——在 VM 中包装 Bash/Read/Edit/Glob/Grep/Agent 等工具 |
| **SuggestBackgroundPRTool** | `src/tools/SuggestBackgroundPRTool/` | 建议在后台创建 PR |
| **ConfigTool** | `src/tools/ConfigTool/` | 交互式配置编辑器,包含 Gates 标签页用于覆盖 GrowthBook flags |
| **TungstenTool** | `src/tools/TungstenTool/` | 基于 tmux 的终端面板工具(反编译版中已 stub |
```typescript
// src/tools.ts 第 16-24 行
const REPLTool =
process.env.USER_TYPE === 'ant'
? require('./tools/REPLTool/REPLTool.js').REPLTool
: null
const SuggestBackgroundPRTool =
process.env.USER_TYPE === 'ant'
? require('./tools/SuggestBackgroundPRTool/SuggestBackgroundPRTool.js')
.SuggestBackgroundPRTool
: null
```
## Ant-Only 命令
`src/commands.ts` 注册了 25+ 个仅在内部构建中可用的斜杠命令:
<AccordionGroup>
<Accordion title="调试类">
- `breakCache` — 清除缓存
- `ctx_viz` — 可视化上下文窗口使用情况
- `debugToolCall` — 调试工具调用
- `env` — 显示环境变量
- `mockLimits` — 模拟速率限制
- `resetLimits` — 重置速率限制
</Accordion>
<Accordion title="实验类">
- `bughunter` — Bug 猎人模式
- `goodClaude` — 质量评估工具
- `antTrace` — 追踪分析
- `perfIssue` — 性能问题诊断
</Accordion>
<Accordion title="工作流类">
- `commit` — 快速提交
- `commitPushPr` — 一键提交+推送+创建 PR
- `issue` — 创建 GitHub Issue
- `autofixPr` — 自动修复 PR 中的问题
- `share` — 分享会话
- `summary` — 生成摘要
</Accordion>
<Accordion title="基础设施类">
- `backfillSessions` — 回填会话数据
- `bridgeKick` — 重启 Bridge 连接
- `oauthRefresh` — 刷新 OAuth Token
- `teleport` — 传送到指定上下文
- `onboarding` — 新手引导
- `agentsPlatform` — Agents 平台管理
- `version` — 内部版本详情
- `initVerifiers` — 初始化验证器
</Accordion>
</AccordionGroup>
<Note>
这些命令在 `IS_DEMO` 模式下也会被隐藏,防止在演示环境中暴露内部功能。
</Note>
## Beta API Headers
Claude Code 向 API 发送的 beta headers 也分为公开和内部两类:
| Header | 功能 | 可见性 |
|--------|------|--------|
| `claude-code-20250219` | Claude Code 标识 | 公开 |
| `interleaved-thinking-2025-05-14` | 交错思考模式 | 公开 |
| `context-1m-2025-08-07` | 1M 上下文窗口 | 公开 |
| `context-management-2025-06-27` | 上下文管理 | 公开 |
| `web-search-2025-03-05` | 网页搜索 | 公开 |
| `effort-2025-11-24` | 推理强度控制 | 公开 |
| `fast-mode-2026-02-01` | 快速模式 | 公开 |
| `token-efficient-tools-2026-03-28` | Token 高效工具 | 公开 |
| `advisor-tool-2026-03-01` | 顾问工具 | 公开 |
| **`cli-internal-2026-02-09`** | 内部 CLI 功能 | **Ant-Only** |
| **`afk-mode-2026-01-31`** | AFK 模式(离开键盘自动审批) | **Feature Flag** |
| **`summarize-connector-text-2026-03-13`** | 连接器文本摘要 | **Feature Flag** |
```typescript
// src/constants/betas.ts 第 29-30 行
export const CLI_INTERNAL_BETA_HEADER =
process.env.USER_TYPE === 'ant' ? 'cli-internal-2026-02-09' : ''
```
`cli-internal` header 意味着 Anthropic 的 API 服务端也维护着一套 ant-only 的服务端行为——这不仅仅是客户端的门控。
## 内部代号体系
Anthropic 有浓厚的"动物命名"文化:
| 代号 | 身份 | 出处 |
|------|------|------|
| **Tengu**(天狗) | Claude Code 项目代号 | 所有 GrowthBook flags 的 `tengu_` 前缀、分析事件名称 |
| **Capybara**(水豚) | 模型代号 | `src/constants/prompts.ts` 中被 Undercover Mode 屏蔽的名称 |
| **Fennec**(耳廓狐) | 已退役模型别名 | `src/migrations/migrateFennecToOpus.ts`——曾用名已迁移到 Opus |
这些代号通过 Undercover Mode 在公开仓库的 commit 中被严格过滤。
## 环境变量开关
除了 `USER_TYPE`,还有一系列精细的环境变量控制各项功能:
<AccordionGroup>
<Accordion title="功能禁用开关">
- `CLAUDE_CODE_SIMPLE` — 简化模式(禁用高级功能)
- `CLAUDE_CODE_DISABLE_THINKING` — 禁用 thinking
- `DISABLE_INTERLEAVED_THINKING` — 禁用交错思考
- `DISABLE_COMPACT` — 禁用消息压缩
- `DISABLE_AUTO_COMPACT` — 禁用自动压缩
- `CLAUDE_CODE_DISABLE_AUTO_MEMORY` — 禁用自动记忆
- `CLAUDE_CODE_DISABLE_BACKGROUND_TASKS` — 禁用后台任务
</Accordion>
<Accordion title="功能启用开关">
- `CLAUDE_CODE_VERIFY_PLAN` — 启用 VerifyPlanExecutionTool
- `ENABLE_LSP_TOOL` — 启用 LSP 语言服务器工具
- `CLAUDE_CODE_UNDERCOVER` — 强制启用 Undercover Mode
- `CLAUDE_CODE_TERMINAL_RECORDING` — 启用终端录制asciicast
- `CLAUDE_CODE_ABLATION_BASELINE` — 启用基线对照模式
</Accordion>
<Accordion title="环境配置">
- `CLAUDE_CODE_REMOTE` — 远程执行模式(自动增加堆内存限制)
- `CLAUDE_CODE_COORDINATOR_MODE` — 启用 Coordinator 模式
- `CLAUDE_INTERNAL_FC_OVERRIDES` — GrowthBook flag 覆盖ant-only
- `IS_DEMO` — 演示模式(隐藏内部命令和敏感信息)
</Accordion>
</AccordionGroup>
<Note>
`ABLATION_BASELINE` 特别有趣——它同时关闭 thinking、compaction、auto-memory 和 background tasks用于测量这些高级功能对 AI 表现的**因果影响**。这是一个严肃的"科学对照实验"工具。
</Note>

View File

@ -0,0 +1,114 @@
---
title: "88 面旗帜:构建时 Feature Flags 全解"
description: "深入剖析 Claude Code 的 88+ 个构建时 feature flags揭示被编译器"删除"的功能"
---
{/* 本章目标:完整梳理构建时 feature flag 系统的机制和所有 flag 的分类 */}
## feature() 是什么
Claude Code 使用 Bun 打包器的 `bun:bundle` 模块提供编译时特性门控:
```typescript
// 源码中的用法src/tools.ts 等)
import { feature } from 'bun:bundle'
const SleepTool = feature('PROACTIVE') || feature('KAIROS')
? require('./tools/SleepTool/SleepTool.js').SleepTool
: null
```
在 Anthropic 的内部构建中,`feature()` 在打包时被求值——返回 `true` 的代码会被保留,返回 `false` 的代码会被 **Dead Code Elimination (DCE)** 彻底移除。
在我们的反编译版本中,这个函数被兜底为:
```typescript
// src/entrypoints/cli.tsx 第 3 行
const feature = (_name: string) => false;
```
这意味着所有 88+ 个 feature flag 后的代码**在运行时永远不会执行**,但代码本身完整保留,可以阅读和分析。
## Flags 分类全景
<CardGroup cols={2}>
<Card title="Agent / 自动化" icon="robot">
**15 个 flags** — 控制 AI 的自主能力边界
`KAIROS` · `KAIROS_BRIEF` · `KAIROS_CHANNELS` · `KAIROS_DREAM` · `KAIROS_GITHUB_WEBHOOKS` · `KAIROS_PUSH_NOTIFICATION` · `PROACTIVE` · `COORDINATOR_MODE` · `FORK_SUBAGENT` · `AGENT_MEMORY_SNAPSHOT` · `AGENT_TRIGGERS` · `AGENT_TRIGGERS_REMOTE` · `VERIFICATION_AGENT` · `BUILTIN_EXPLORE_PLAN_AGENTS` · `MONITOR_TOOL`
</Card>
<Card title="基础设施" icon="server">
**10 个 flags** — 控制运行环境和连接方式
`DAEMON` · `BG_SESSIONS` · `BRIDGE_MODE` · `CCR_AUTO_CONNECT` · `CCR_MIRROR` · `CCR_REMOTE_SETUP` · `DIRECT_CONNECT` · `SSH_REMOTE` · `SELF_HOSTED_RUNNER` · `BYOC_ENVIRONMENT_RUNNER`
</Card>
<Card title="安全 / 分类" icon="shield-halved">
**6 个 flags** — 增强权限判断的智能性
`TRANSCRIPT_CLASSIFIER` · `BASH_CLASSIFIER` · `TREE_SITTER_BASH` · `TREE_SITTER_BASH_SHADOW` · `NATIVE_CLIENT_ATTESTATION` · `ABLATION_BASELINE`
</Card>
<Card title="工具 / 能力" icon="toolbox">
**10 个 flags** — 新增的 AI 能力
`WEB_BROWSER_TOOL` · `TERMINAL_PANEL` · `CONTEXT_COLLAPSE` · `HISTORY_SNIP` · `OVERFLOW_TEST_TOOL` · `WORKFLOW_SCRIPTS` · `VOICE_MODE` · `MCP_RICH_OUTPUT` · `MCP_SKILLS` · `UDS_INBOX`
</Card>
<Card title="UI / 体验" icon="palette">
**8 个 flags** — 界面和交互改进
`MESSAGE_ACTIONS` · `QUICK_SEARCH` · `HISTORY_PICKER` · `AUTO_THEME` · `STREAMLINED_OUTPUT` · `COMPACTION_REMINDERS` · `TEMPLATES` · `BUDDY`
</Card>
<Card title="平台 / 实验" icon="flask-vial">
**10+ 个 flags** — 实验性和平台级功能
`DUMP_SYSTEM_PROMPT` · `UPLOAD_USER_SETTINGS` · `DOWNLOAD_USER_SETTINGS` · `EXPERIMENTAL_SKILL_SEARCH` · `ULTRAPLAN` · `ULTRATHINK` · `TORCH` · `LODESTONE` · `PERFETTO_TRACING` · `SLOW_OPERATION_LOGGING` · `HARD_FAIL` · `ALLOW_TEST_VERSIONS`
</Card>
</CardGroup>
## 代码中的典型模式
Feature flags 在代码中主要有三种使用模式:
### 模式一:条件加载工具
```typescript
// src/tools.ts — 最常见的模式
const MonitorTool = feature('MONITOR_TOOL')
? require('./tools/MonitorTool/MonitorTool.js').MonitorTool
: null
```
当 flag 为 `false` 时,`require()` 调用被 DCE 移除,工具不会出现在可用工具列表中。
### 模式二:条件注册命令
```typescript
// src/commands.ts — 注册斜杠命令
if (feature('VOICE_MODE')) {
commands.push({ name: 'voice', description: '...' })
}
```
### 模式三:条件启用 API 特性
```typescript
// src/constants/betas.ts — 控制发送给 API 的 beta header
export const AFK_MODE_BETA_HEADER = feature('TRANSCRIPT_CLASSIFIER')
? 'afk-mode-2026-01-31'
: ''
```
<Note>
由于 `feature()` 在构建时求值,被 DCE 移除的代码不会增加最终打包体积。但在反编译版本中,这些代码全部保留——这正是我们能够进行完整分析的原因。
</Note>
## 有趣的发现
- **KAIROS 家族**最庞大——6 个相关 flag 控制从核心功能到推送通知的方方面面
- **ABLATION_BASELINE** 是用于"科学对照实验"的——它会关闭 thinking、compaction、auto-memory 等高级功能,测量裸 API 调用的基线性能
- **BUDDY** 是一个 AI 吉祥物/精灵系统——在 `src/buddy/` 目录下有完整实现
- **ULTRAPLAN** 和 **ULTRATHINK** 暗示着比当前 extended thinking 更高级的推理模式

View File

@ -0,0 +1,119 @@
---
title: "千面千人GrowthBook A/B 测试体系"
description: "揭秘 Claude Code 如何通过 GrowthBook 实现运行时 A/B 测试和渐进式功能发布"
---
{/* 本章目标:深入运行时 A/B 测试层——GrowthBook 的集成架构、用户定向、tengu 命名文化 */}
## 为什么需要运行时 A/B 测试
构建时 `feature()` 是"全有或全无"的——要么所有用户都有,要么所有用户都没有。但产品团队需要更精细的控制:
- 只对 5% 的用户灰度发布新功能
- 按订阅类型Free / Pro / Team差异化体验
- 对特定组织静默开启实验性能力
- 随时远程关闭出问题的功能,无需发版
这就是 **GrowthBook** 的用武之地——一个运行时的、基于用户属性的功能门控和 A/B 测试系统。
## 集成架构
GrowthBook 的完整实现位于 `src/services/analytics/growthbook.ts`1156 行),工作流程如下:
<Steps>
<Step title="启动时获取远程配置">
CLI 启动时GrowthBook SDK 通过 `https://api.anthropic.com/` 的 API 端点获取当前的功能配置和实验分组规则。使用 `remoteEval: true` 模式——在服务端计算分组,客户端只拿结果。
</Step>
<Step title="计算用户属性">
SDK 收集当前用户的属性(设备 ID、订阅类型、组织 UUID 等),用于决定该用户属于哪些实验的哪个分组。
</Step>
<Step title="缓存到本地">
计算结果缓存到 `~/.claude.json` 的 `cachedGrowthBookFeatures` 字段。刷新间隔Anthropic 员工 20 分钟,外部用户 6 小时。
</Step>
<Step title="代码中查询 flag">
业务代码通过 `tengu_*` 前缀的 flag 名查询功能状态GrowthBook SDK 返回当前用户的分组值。
</Step>
</Steps>
## 用户定向属性
GrowthBook 根据以下用户属性决定实验分组:
| 属性 | 类型 | 来源 | 用途 |
|------|------|------|------|
| `id` | string | 会话 ID | 按会话粒度分组 |
| `deviceID` | string | 持久化设备标识 | 跨会话一致性 |
| `sessionId` | string | 当前会话 ID | 会话级实验 |
| `platform` | enum | `process.platform` | 按操作系统差异化 |
| `organizationUUID` | string | API 认证信息 | 按组织灰度 |
| `accountUUID` | string | API 认证信息 | 按个人账户灰度 |
| `subscriptionType` | string | API 认证信息 | Free / Pro / Team 差异化 |
| `rateLimitTier` | string | API 认证信息 | 按速率限制层级 |
| `email` | string | API 认证信息 | 精确定向特定用户 |
| `appVersion` | string | `MACRO.VERSION` | 按版本号灰度 |
| `github` | object | GitHub Actions 元数据 | CI 环境特殊处理 |
<Note>
这套定向系统意味着 Anthropic 可以做非常精细的实验——比如"只对 Mac 上的 Pro 订阅用户的 10% 开启新功能"。
</Note>
## 代号文化tengu_* 的世界
所有运行时 flag 都以 `tengu_` 为前缀——"Tengu"(天狗)是 Claude Code 的内部项目代号。flag 名采用**动物/植物/矿物 + 形容词**的命名约定,刻意保持不透明。
<AccordionGroup>
<Accordion title="tengu_kairos — Kairos 助手模式">
控制 KAIROS 功能的运行时开关。即使构建时 `feature('KAIROS')` 通过,仍需此 flag 命中才能激活。双重门控确保新功能可以分阶段发布。
</Accordion>
<Accordion title="tengu_amber_stoat — Explore Agent A/B 测试">
控制内置的 Explore 子 Agent 的行为变体。"amber stoat"(琥珀色白鼬)是随机生成的代号,与功能内容无关——这是为了防止通过 flag 名猜测功能。
</Accordion>
<Accordion title="tengu_auto_background_agents — 后台 Agent 自动化">
控制是否自动将某些任务分派给后台 Agent 执行,而不是在前台阻塞用户。
</Accordion>
<Accordion title="tengu_onyx_plover — Auto-Dream 后台记忆">
控制"自动做梦"功能——在空闲时后台整理和巩固 Agent 的记忆。"onyx plover"(玛瑙鸻)又是一个不透明代号。
</Accordion>
<Accordion title="tengu_glacier_2xr — 工具搜索行为">
控制 Tool Search 的行为变体,可能是搜索算法或排序策略的 A/B 测试。
</Accordion>
<Accordion title="tengu_birch_trellis — Bash 权限策略">
控制 BashTool 权限判断的策略变体——可能在测试更宽松或更严格的权限规则。
</Accordion>
<Accordion title="tengu_scratch — 草稿本功能">
控制一个实验性的"草稿本"功能,可能是让 AI 在处理复杂任务时使用中间暂存区。
</Accordion>
<Accordion title="tengu_quartz_lantern — Diff 计算策略">
控制文件写入和编辑时的 diff 计算方式。可能在 A/B 测试不同的 diff 算法对用户体验的影响。
</Accordion>
</AccordionGroup>
## Ant-Only 覆盖机制
Anthropic 员工拥有两种方式绕过 GrowthBook 的远程求值:
### 环境变量覆盖
```bash
# 仅在 USER_TYPE=ant 的构建中生效
CLAUDE_INTERNAL_FC_OVERRIDES='{"tengu_kairos": true}' claude
```
通过 `CLAUDE_INTERNAL_FC_OVERRIDES` 环境变量传入 JSON 对象,直接覆盖任意 flag 的值。
### Config 界面覆盖
在内部构建中,`/config` 命令的 Gates 标签页提供了图形化的 flag 管理界面,可以实时切换任意 GrowthBook flag。
## 实验追踪
GrowthBook 集成了完整的实验曝光追踪:
- 每次查询 flag 时记录实验曝光事件
- 通过 protobuf 格式的 `GrowthbookExperimentEvent` 上报
- 包含 `variation_id`0=对照组1+=实验组)和 `in_experiment` 标记
- 数据用于分析功能对用户行为的因果影响
<Note>
GrowthBook 正在从 Statsig 迁移而来——代码中仍保留着 `checkStatsigFeatureGate_CACHED_MAY_BE_STALE()` 这样的迁移兼容层。
</Note>

View File

@ -0,0 +1,132 @@
---
title: "未公开功能巡礼"
description: "深度解析 Claude Code 中 8 个最令人兴奋的隐藏功能——从永不下线的 AI 助手到 AI 吉祥物"
---
{/* 本章目标:逐一展示 8 个最重要的隐藏功能,分析它们背后的产品方向 */}
## 全景
从 88+ 个构建时 flags 和 500+ 个运行时 flags 中,我们挑选了 8 个最具代表性的未公开功能。它们不仅展示了 Claude Code 当前的技术深度,更勾勒出 Anthropic 对"AI 编程助手"的未来愿景。
<AccordionGroup>
<Accordion title="KAIROS永不下线的 AI 助手">
**门控**: `feature('KAIROS')` + `tengu_kairos`
KAIROS 是 Claude Code 最庞大的隐藏功能群——6 个独立 flag 控制着一个完整的"持久化 AI 助手"系统:
| Flag | 能力 |
|------|------|
| `KAIROS` | 核心助手模式——AI 不再随对话结束而"消失" |
| `KAIROS_BRIEF` | 精简输出模式 |
| `KAIROS_CHANNELS` | 基于频道的消息系统 |
| `KAIROS_DREAM` | 后台"做梦"——自主整理记忆 |
| `KAIROS_GITHUB_WEBHOOKS` | 订阅 GitHub PR 事件,自动响应 |
| `KAIROS_PUSH_NOTIFICATION` | 向移动端推送通知 |
KAIROS 的工具集包括 `SleepTool`(让 AI 主动"休眠"等待事件)、`SendUserFileTool`(向用户发送文件)、`PushNotificationTool`(推送通知)和 `SubscribePRTool`(监听 PR
**推测方向**: 一个 7x24 在线的 AI 团队成员,能自主监控代码库、响应事件、管理任务。
</Accordion>
<Accordion title="PROACTIVE自主行动模式">
**门控**: `feature('PROACTIVE')`
在标准模式中Claude Code 是被动的——等待你输入然后响应。PROACTIVE 模式颠覆了这一范式:
- AI 拥有 `SleepTool`,可以主动"打盹"一段时间
- 系统定期发送 `<tick>` 提示,触发 AI 检查是否有需要主动做的事
- AI 可以在没有用户输入的情况下自行决策和执行
**推测方向**: 从"问答式助手"进化为"自主式同事"——AI 在后台持续工作,偶尔需要你确认方向。
</Accordion>
<Accordion title="COORDINATOR_MODE多 Agent 指挥官">
**门控**: `feature('COORDINATOR_MODE')`
当前的 Claude Code 已经支持子 Agent`AgentTool`),但 Coordinator Mode 将其提升到新的层次:
- 一个"指挥官" Agent 分析任务并分解为子任务
- 多个"工人" Agent 并行执行子任务
- 指挥官协调结果、处理冲突、合并输出
完整实现位于 `src/coordinator/coordinatorMode.ts`。
**推测方向**: 大型编程任务的全自动并行处理——比如"重构整个认证系统"可以同时由多个 Agent 处理不同模块。
</Accordion>
<Accordion title="BRIDGE_MODE远程遥控">
**门控**: `feature('BRIDGE_MODE')`
Bridge Mode 让 Claude Code 可以通过 WebSocket 被远程控制:
- `src/bridge/` 目录包含完整的 WebSocket 桥接实现
- 支持 IDE 扩展作为远程前端
- 包含 ant-only 的故障注入测试(`bridgeDebug.ts`
- 配合 `DIRECT_CONNECT` flag 可通过 `cc://` URL 直连
**推测方向**: Claude Code 的 UI 前端与后端执行分离——你可以在 VS Code 中操作,但 AI 在远程服务器上执行。
</Accordion>
<Accordion title="WEB_BROWSER_TOOL内置浏览器">
**门控**: `feature('WEB_BROWSER_TOOL')`
当前的 Claude Code 只有简化的 `WebFetchTool`(获取网页内容),但代码中存在更强大的浏览器工具:
- 基于 Bun 的 WebView 实现
- 可以渲染和交互网页,而不仅仅是抓取文本
- 与 Computer Use 的 `@ant/` 包配合使用
**推测方向**: AI 能像人一样浏览网页——点击、填表、截图,用于测试 Web 应用或收集信息。
</Accordion>
<Accordion title="VOICE_MODE语音交互">
**门控**: `feature('VOICE_MODE')`
代码中存在语音输入模式的注册点,但核心实现依赖于 `audio-napi` 包(在反编译版本中已 stub
- 通过 `/voice` 命令激活
- "按住说话"hold-to-talk交互模式
- 需要系统级音频 API 支持
**推测方向**: 不用打字,直接和 AI 对话编程。
</Accordion>
<Accordion title="BUDDYAI 吉祥物">
**门控**: `feature('BUDDY')`
`src/buddy/` 目录包含一个完整的"伙伴精灵"系统:
- 终端中的小型动画角色
- 可能根据 AI 的状态(思考中、执行中、完成)展示不同动画
- 纯 UI/趣味性功能
**推测方向**: 给冷冰冰的终端增加一点温度——让等待 AI 思考的过程不那么无聊。
</Accordion>
<Accordion title="Undercover Mode隐身贡献">
**门控**: `USER_TYPE === 'ant'`(自动激活)
这不是一个功能,而是一个**安全机制**——当 Anthropic 员工向公开仓库贡献代码时自动激活:
- 剥除所有 AI 归属标记(`Co-Authored-By` 行)
- 禁止在 commit 消息中提及模型代号Capybara、Tengu 等)
- 禁止暴露内部仓库名、Slack 频道、短链接
- 通过 `CLAUDE_CODE_UNDERCOVER=1` 强制开启,无法强制关闭
- 仅在仓库匹配内部白名单(~25 个私有仓库)时自动关闭
**意义**: 证实 Anthropic 员工确实在使用 Claude Code 进行日常开发,并且会向公开项目贡献代码。
</Accordion>
</AccordionGroup>
## 这些功能告诉我们什么
纵观这 8 个隐藏功能,一个清晰的产品愿景浮现:
1. **从被动到主动** — PROACTIVE、KAIROS 让 AI 不再只是等待指令
2. **从短暂到持久** — KAIROS 的持久化模式让 AI 成为"常驻团队成员"
3. **从单一到多感官** — VOICE_MODE、WEB_BROWSER_TOOL 拓展交互维度
4. **从单兵到协同** — COORDINATOR_MODE 让多个 AI 并行协作
5. **从本地到分布式** — BRIDGE_MODE、SSH_REMOTE 解耦前后端
Claude Code 正在从一个"终端里的聊天机器人"进化为一个**自主、持久、多模态的 AI 编程同事**。

View File

@ -0,0 +1,86 @@
---
title: "三层门禁:功能是如何被藏起来的"
description: "Claude Code 用三层独立的门禁系统控制功能的可见性——构建时、运行时、身份层"
---
{/* 本章目标:建立对三层门禁系统的全局认知,为后续四篇深入文章奠定坐标系 */}
## 冰山一角
你日常使用的 Claude Code只是完整代码库的冰山一角。
逆向工程揭示了一个事实:大量功能被精心"藏"在三层独立的门禁系统之后。有些是正在 A/B 测试的实验性功能,有些是仅限 Anthropic 员工使用的内部工具,还有些是尚未对外发布的下一代能力。
> 我们在 `src/` 中发现了 88+ 个构建时 feature flags、500+ 个运行时 A/B 测试标记,以及一整套身份门控机制。
## 三层门禁全景
| 维度 | 第一层:构建时 `feature()` | 第二层:运行时 GrowthBook | 第三层:身份 `USER_TYPE` |
|------|---------------------------|--------------------------|-------------------------|
| **控制方式** | `bun:bundle` 编译时宏 | GrowthBook SDK 远程求值 | 构建时 `--define` 常量 |
| **决策时机** | 打包时(代码直接被删除) | 启动时 + 定期刷新 | 打包时(常量折叠) |
| **粒度** | 全有或全无 | 按用户/设备/组织定向 | 按构建版本ant / external |
| **标记数量** | 88+ | 500+ (`tengu_*` 前缀) | 1`ant` vs `external` |
| **逆向可见性** | 代码残留,但永远走 `false` 分支 | 完整 SDK 代码可读 | 条件分支清晰可见 |
## 决策流程
当一个功能请求进入 Claude Code它会依次经过三层门禁的检查
```
功能请求
┌─────────────────────────┐
│ 第一层feature('X') │ ──── 编译时已决定 ──→ false → 代码被 DCE 移除
│ (构建时 Feature Flag) │
└─────────┬───────────────┘
│ true (仅内部构建)
┌─────────────────────────┐
│ 第二层tengu_xxx │ ──── 运行时按用户属性 ──→ 不在实验组 → 功能关闭
│ (GrowthBook A/B 测试) │
└─────────┬───────────────┘
│ 在实验组
┌─────────────────────────┐
│ 第三层USER_TYPE │ ──── ant? external? ──→ external → 功能不可用
│ (身份门控) │
└─────────┬───────────────┘
│ ant
功能可用 ✓
```
三层门禁**相互独立**一个功能可能同时受多层控制。例如KAIROS 助手模式同时需要 `feature('KAIROS')` 构建时开启 **和** `tengu_kairos` 运行时实验命中。
## 逆向工程揭示了什么
在这个反编译版本中:
- **第一层**完全透明——`feature()` 被兜底为 `() => false`,所有 88+ 个 flag 的代码路径都可以阅读,只是永远不会执行
- **第二层**完整保留——GrowthBook SDK 的 1156 行代码完整可读,包括用户定向属性、缓存策略、覆盖机制
- **第三层**清晰可见——`process.env.USER_TYPE === 'ant'` 出现在 60+ 个位置,每一处都标记着"仅限内部"的功能边界
<Note>
这三层门禁不是安全机制——它们是产品发布策略。目的是让 Anthropic 能够在不同用户群体中渐进式地测试和发布功能,而不是阻止逆向工程。
</Note>
## 接下来
后续四篇文章将分别深入每一层门禁的细节:
<CardGroup cols={2}>
<Card title="88 面旗帜" icon="flag" href="/docs/internals/feature-flags">
构建时 Feature Flags 的完整分类与解读
</Card>
<Card title="千面千人" icon="flask" href="/docs/internals/growthbook-ab-testing">
GrowthBook A/B 测试体系的运作机制
</Card>
<Card title="未公开功能巡礼" icon="eye" href="/docs/internals/hidden-features">
KAIROS、PROACTIVE 等 8 大隐藏功能深度解析
</Card>
<Card title="Ant 的特权世界" icon="shield" href="/docs/internals/ant-only-world">
Anthropic 员工专属的工具、命令与 API
</Card>
</CardGroup>

View File

@ -76,6 +76,16 @@
"docs/extensibility/skills",
"docs/extensibility/custom-agents"
]
},
{
"group": "揭秘:隐藏功能与内部机制",
"pages": [
"docs/internals/three-tier-gating",
"docs/internals/feature-flags",
"docs/internals/growthbook-ab-testing",
"docs/internals/hidden-features",
"docs/internals/ant-only-world"
]
}
],
"footerSocials": {