三层门禁系统 - 功能可见性控制架构

概述

Claude Code 的功能可见性由三层独立的门禁系统控制：构建时 feature() 决定代码是否被打包，运行时 GrowthBook 按用户属性做 A/B 测试，身份层 USER_TYPE 区分内部/外部构建。88+ 个构建时 flags、500+ 个运行时标记、410+ 处身份检查，共同构成了这套精密的灰度发布体系。

正文

冰山一角

你日常使用的 Claude Code，只是完整代码库的冰山一角。

逆向工程揭示了一个事实：大量功能被精心"藏"在三层独立的门禁系统之后。有些是正在 A/B 测试的实验性功能，有些是仅限 Anthropic 员工使用的内部工具，还有些是尚未对外发布的下一代能力。

[!info] 我们在 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，它会依次经过三层门禁的检查：

flowchart TD
    REQ["功能请求"] --> L1{"第一层: feature('X')"}
    L1 -->|"编译时已决定 false"| DCE["代码被 DCE 移除"]
    L1 -->|"true (仅内部构建)"| L2{"第二层: tengu_xxx"}
    L2 -->|"不在实验组"| CLOSED["功能关闭"]
    L2 -->|"在实验组"| L3{"第三层: USER_TYPE"}
    L3 -->|"external"| UNAVAIL["功能不可用"]
    L3 -->|"ant"| AVAIL["功能可用"]

    style DCE fill:#fee,stroke:#c66
    style CLOSED fill:#fee,stroke:#c66
    style UNAVAIL fill:#fee,stroke:#c66
    style AVAIL fill:#efe,stroke:#6a6

三层门禁相互独立，一个功能可能同时受多层控制。例如，KAIROS 助手模式同时需要 feature('KAIROS') 构建时开启和 tengu_kairos 运行时实验命中。

逆向工程揭示了什么

在这个反编译版本中：

第一层完全透明——feature() 被兜底为 () => false，所有 88+ 个 flag 的代码路径都可以阅读，只是永远不会执行
第二层完整保留——GrowthBook SDK 的 1156 行代码完整可读，包括用户定向属性、缓存策略、覆盖机制
第三层清晰可见——process.env.USER_TYPE === 'ant' 出现在 60+ 个位置，每一处都标记着"仅限内部"的功能边界

Warning

这三层门禁不是安全机制——它们是产品发布策略。目的是让 Anthropic 能够在不同用户群体中渐进式地测试和发布功能，而不是阻止逆向工程。

接下来

后续文章将分别深入每一层门禁的细节：

feature-flags — 构建时 Feature Flags 的完整分类与解读
growthbook-ab-testing — GrowthBook A/B 测试体系的运作机制
hidden-features — KAIROS、PROACTIVE 等 8 大隐藏功能深度解析
ant-only-world — Anthropic 员工专属的工具、命令与 API

关联笔记

feature-flags - 88 个构建时 Feature Flags
growthbook-ab-testing - GrowthBook A/B 测试体系
hidden-features - 未公开功能巡礼
ant-only-world - Ant 特权世界

3.9 KiB Raw Permalink Blame History Unescape Escape