vault backup: 2026-06-09 23:15:17

claude-code-best/docs/internals/three-tier-gating.md

@@ -1,20 +1,26 @@
 ---
-title: "三层门禁系统 - 功能可见性控制架构"
-description: "详解 Claude Code 三层门禁系统：构建时 feature()、运行时 GrowthBook 和身份层 USER_TYPE，如何控制功能的可见性和灰度发布。"
-keywords: ["门禁系统", "功能门控", "feature flag", "灰度发布", "可见性控制"]
+tags: [门禁系统, feature-flags, claude-code, 灰度发布, 可见性控制]
+create time: 2026-06-09 22:30
 ---
 
-{/* 本章目标：建立对三层门禁系统的全局认知，为后续四篇深入文章奠定坐标系 */}
+# 三层门禁系统 - 功能可见性控制架构
 
-## 冰山一角
+## 概述
+
+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` |
 |------|---------------------------|--------------------------|-------------------------|
@@ -24,38 +30,29 @@ keywords: ["门禁系统", "功能门控", "feature flag", "灰度发布", "可
 | **标记数量** | 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
-          ▼
-      功能可用 ✓
+```mermaid
+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` 运行时实验命中。
 
-## 逆向工程揭示了什么
+### 逆向工程揭示了什么
 
 在这个反编译版本中：
 
@@ -63,25 +60,21 @@ keywords: ["门禁系统", "功能门控", "feature flag", "灰度发布", "可
 - **第二层**完整保留——GrowthBook SDK 的 1156 行代码完整可读，包括用户定向属性、缓存策略、覆盖机制
 - **第三层**清晰可见——`process.env.USER_TYPE === 'ant'` 出现在 60+ 个位置，每一处都标记着"仅限内部"的功能边界
 
-<Note>
-这三层门禁不是安全机制——它们是产品发布策略。目的是让 Anthropic 能够在不同用户群体中渐进式地测试和发布功能，而不是阻止逆向工程。
-</Note>
+> [!warning]
+> 这三层门禁不是安全机制——它们是产品发布策略。目的是让 Anthropic 能够在不同用户群体中渐进式地测试和发布功能，而不是阻止逆向工程。
 
-## 接下来
+### 接下来
 
-后续四篇文章将分别深入每一层门禁的细节：
+后续文章将分别深入每一层门禁的细节：
 
-<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>
+- [[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 特权世界