第23章：未发布功能管线 – 89 个 Feature Flag 背后的路线图

为什么这很重要

在前面的 22 章中，我们分析的是 Claude Code 已发布的公开功能。但源码中还隐藏着另一个维度：89 个 Feature Flag 门控着尚未向所有用户开放的功能。这些 flag 通过 Bun 的构建时 feature() 函数实现——编译器在不同构建配置下将 feature('FLAG_NAME') 求值为 true 或 false，配合 dead code elimination 将未启用的代码分支完整移除。

这意味着源码中 feature('KAIROS') 门控的代码在公开构建中根本不存在——它只出现在内部构建（USER_TYPE === 'ant'）或实验分支中。但在我们还原的源码里，所有 flag 的两个分支都被保留了下来，为我们提供了一个独特的视角来审视 Claude Code 的功能演进方向。

本章将这 89 个 flag 按功能域分为五大类，分析核心未发布功能的实现深度和相互关系。需要强调的是：本章的分析基于源码中可观测的实现状态，不猜测商业策略，不预测发布时间。 flag 的存在不等同于功能即将发布——许多 flag 可能是实验性的原型、A/B 测试配置、或已废弃的探索方向。

23.1 Feature Flag 机制

构建时求值

Claude Code 使用 Bun 的 bun:bundle 模块提供的 feature() 函数：

import { feature } from 'bun:bundle'

if (feature('KAIROS')) {
  const { registerDreamSkill } = require('./dream.js')
  registerDreamSkill()
}

feature() 在构建时被替换为字面量 true 或 false。当结果为 false 时，整个 if 块在 tree-shaking 阶段被移除。这解释了为什么门控代码使用 require() 而非 import()——require() 是表达式，可以出现在 if 块内部，从而被 dead code elimination 连同其模块依赖一起消除。

引用计数与成熟度推断

通过统计每个 flag 在源码中的引用次数，可以粗略推断其实现深度：

表 23-1：Feature Flag 引用次数与成熟度推断

引用次数高不一定意味着“即将发布“——KAIROS 的 154 处引用可能恰恰说明它是一个长期演进的复杂系统，需要大量的渐进式集成。

23.2 全部 89 个 Flag 分类表

根据功能域，89 个 flag 可以分为五大类：

graph TD
    ROOT["89 个 Feature Flag"] --> A["自主 Agent 与后台运行\n18 个 flag"]
    ROOT --> B["远程控制与分布式执行\n14 个 flag"]
    ROOT --> C["上下文管理与性能优化\n17 个 flag"]
    ROOT --> D["记忆与知识管理\n9 个 flag"]
    ROOT --> E["UI/UX 与平台能力\n31 个 flag"]

    A --> A1["KAIROS (154)"]
    A --> A2["COORDINATOR_MODE (32)"]
    A --> A3["PROACTIVE (37)"]

    B --> B1["BRIDGE_MODE (28)"]
    B --> B2["UDS_INBOX (17)"]

    C --> C1["TRANSCRIPT_CLASSIFIER (107)"]
    C --> C2["BASH_CLASSIFIER (45)"]

    D --> D1["TEAMMEM (51)"]
    D --> D2["EXPERIMENTAL_SKILL_SEARCH (21)"]

    E --> E1["VOICE_MODE (46)"]
    E --> E2["CHICAGO_MCP (16)"]

    style ROOT fill:#f9f,stroke:#333,stroke-width:2px
    style A fill:#e3f2fd
    style B fill:#e8f5e9
    style C fill:#fff3e0
    style D fill:#fce4ec
    style E fill:#f3e5f5

表 23-2：自主 Agent 与后台运行（18 个）

表 23-3：远程控制与分布式执行（14 个）

表 23-4：上下文管理与性能优化（17 个）

表 23-5：记忆与知识管理（9 个）

表 23-6：UI/UX 与平台能力（31 个）

23.3 核心未发布功能深度分析

KAIROS：后台自主助手

KAIROS 是引用次数最多的 flag（154 处），其代码痕迹触及了 Claude Code 几乎所有核心子系统。从源码分析可以还原出以下架构：

graph TD
    AM["Assistant Module"] --> GATE["Gate Module\n(kairosGate)"]
    GATE --> ACTIVATE["Activation Path"]

    AM --> MODE["Assistant Mode\n独立会话模式"]
    AM --> TICK["Tick Wakeup\n定时唤醒"]
    AM --> BRIEF["Brief Tool\n简报/进度标记"]
    AM --> CH["Channels\n多通道通信"]
    AM --> DREAM["Dream\n空闲记忆整理"]
    AM --> PUSH["Push Notification\n状态推送"]
    AM --> GH["GitHub Webhooks\nPR 事件订阅"]

    TICK --> PRO["Proactive Module"]
    PRO --> CHECK{"terminalFocus?"}
    CHECK -->|"用户不在看终端"| AUTO["Agent 自主执行"]
    CHECK -->|"用户在看终端"| WAIT["等待用户输入"]

    style AM fill:#e1f5fe,stroke:#333,stroke-width:2px
    style PRO fill:#fff3e0
    style AUTO fill:#c8e6c9

图 23-1：KAIROS 助手模式架构图

KAIROS 的核心理念可以从以下代码模式中推断：

入口点（main.tsx:80-81）：

const assistantModule = feature('KAIROS')
  ? require('./assistant/index.js') as typeof import('./assistant/index.js')
  : null
const kairosGate = feature('KAIROS')
  ? require('./assistant/gate.js') as typeof import('./assistant/gate.js')
  : null

Tick 唤醒机制（REPL.tsx:2115, 2605, 2634, 2738）：KAIROS 在多个 REPL 生命周期点检查是否应该“唤醒“——包括消息处理后、输入空闲时、以及终端焦点变化时。当用户离开终端时（!terminalFocusRef.current），系统可以自主执行等待中的任务。

Brief Tool 集成（main.tsx:2201）：

const briefVisibility = feature('KAIROS') || feature('KAIROS_BRIEF')
  ? isBriefEnabled()
    ? 'Call SendUserMessage at checkpoints to mark where things stand.'
    : 'The user will see any text you output.'
  : 'The user will see any text you output.'

当 Brief 模式启用时，系统提示词指导模型使用 SendUserMessage 在关键检查点向用户报告进度——而不是输出所有中间文本。这是为后台自主执行设计的通信模式。

Team Context（main.tsx:3035）：

teamContext: feature('KAIROS')
  ? assistantTeamContext ?? computeInitialTeamContext?.()
  : computeInitialTeamContext?.()

KAIROS 引入了“团队上下文“概念——当 agent 作为助手模式运行时，它需要理解自己在更大协作图中的位置。

PROACTIVE 模式

PROACTIVE（37 处引用）与 KAIROS 高度耦合——在源码中，两者几乎总是以 feature('PROACTIVE') || feature('KAIROS') 的形式出现（REPL.tsx:194, 2115, 2605 等）。这暗示 PROACTIVE 是 KAIROS 的一个子功能或前身——当 KAIROS 的完整助手模式不可用时，PROACTIVE 提供了一个较轻量的“主动工作“能力。

关键行为差异在 REPL.tsx:2776：

...((feature('PROACTIVE') || feature('KAIROS'))
  && proactiveModule?.isProactiveActive()
  && !terminalFocusRef.current
  ? { /* 自主执行配置 */ }
  : {})

条件组合 isProactiveActive() && !terminalFocusRef.current 揭示了核心机制：当用户不在看终端，且 proactive 模式已激活时，agent 获得自主执行权限。这是一个基于物理注意力信号的权限升级——用户的终端焦点状态成为了 agent 自主性的门控条件。

VOICE_MODE：流式语音转文字

VOICE_MODE（46 处引用）的实现触及了输入、配置、快捷键和服务层：

语音 STT 服务（services/voiceStreamSTT.ts:3）：

// Only reachable in ant builds (gated by feature('VOICE_MODE') in useVoice.ts import).

快捷键绑定（keybindings/defaultBindings.ts:96）：

...(feature('VOICE_MODE') ? { space: 'voice:pushToTalk' } : {})

空格键被绑定为 push-to-talk——这是语音输入的标准交互模式。语音集成涉及 useVoiceIntegration.tsx 中的多个 hook：useVoiceEnabled, useVoiceState, useVoiceInterimTranscript，以及 startVoice/stopVoice/toggleVoice 控制函数。

配置集成（tools/ConfigTool/supportedSettings.ts:144）：voice 作为可配置的设置项注册，支持通过 /config set voiceEnabled true 启用。

WEB_BROWSER_TOOL：Bun WebView

WEB_BROWSER_TOOL（4 处引用）的实现痕迹虽少但关键：

// main.tsx:1571
const hint = feature('WEB_BROWSER_TOOL')
  && typeof Bun !== 'undefined' && 'WebView' in Bun
  ? CLAUDE_IN_CHROME_SKILL_HINT_WITH_WEBBROWSER
  : CLAUDE_IN_CHROME_SKILL_HINT

这行代码揭示了技术选型：web 浏览器工具基于 Bun 内置的 WebView，而非 Playwright 或 Puppeteer 这样的外部浏览器自动化工具。typeof Bun !== 'undefined' && 'WebView' in Bun 的运行时检测说明这依赖于 Bun 尚未稳定的 WebView API。

在 REPL 中（REPL.tsx:272, 4585），WebBrowserTool 有自己的面板组件 WebBrowserPanel，可以在全屏模式下与主对话并排显示。

BRIDGE_MODE + DAEMON：远程控制

BRIDGE_MODE（28 处引用）和 DAEMON（3 处引用）构成了远程控制的基础设施：

入口点（entrypoints/cli.tsx:100-165）：

if (feature('DAEMON') && args[0] === '--daemon-worker') {
  // 启动守护进程 worker
}
if (feature('BRIDGE_MODE') && (args[0] === 'remote-control' || args[0] === 'rc'
    || args[0] === 'remote' || args[0] === 'sync' || args[0] === 'bridge')) {
  // 启动远程控制/桥接
}
if (feature('DAEMON') && args[0] === 'daemon') {
  // 启动 daemon 进程
}

DAEMON 提供了 --daemon-worker 后台工作进程和 daemon 管理命令。BRIDGE_MODE 提供了多个子命令别名（remote-control、rc、remote、sync、bridge）——这种别名丰富度暗示团队仍在探索最佳的用户界面命名。

桥接核心在 bridge/bridgeEnabled.ts 中，提供了多个检查函数：

// bridge/bridgeEnabled.ts:32
return feature('BRIDGE_MODE')  // isBridgeEnabled

// bridge/bridgeEnabled.ts:51
return feature('BRIDGE_MODE')  // isBridgeOutboundEnabled

// bridge/bridgeEnabled.ts:127
return feature('BRIDGE_MODE')  // isRemoteControlEnabled

CCR_MIRROR（4 处引用）是 BRIDGE_MODE 的一个子模式——只读镜像，允许远程观察而不控制。

TRANSCRIPT_CLASSIFIER：auto 模式

TRANSCRIPT_CLASSIFIER（107 处引用）是引用数第二多的 flag，它实现了一个全新的权限模式——auto：

// types/permissions.ts:35
...(feature('TRANSCRIPT_CLASSIFIER') ? (['auto'] as const) : ([] as const))

在现有的 plan（需确认每个工具调用）和 auto-accept（自动接受所有）之间，auto 模式引入了一个基于会话记录分类的中间地带。系统使用分类器分析会话内容来动态决定是否需要用户确认。

checkAndDisableAutoModeIfNeeded（REPL.tsx:2772）暗示 auto 模式有安全降级机制——当分类器检测到风险操作时，可以自动退出 auto 模式回到需要确认的状态。

BASH_CLASSIFIER（45 处引用）是 TRANSCRIPT_CLASSIFIER 的一个相关组件，专门用于 Bash 命令的分类和安全评估。

CONTEXT_COLLAPSE：精细化上下文管理

CONTEXT_COLLAPSE（20 处引用）深度集成在 compact 子系统中：

// services/compact/autoCompact.ts:179
if (feature('CONTEXT_COLLAPSE')) { ... }

// services/compact/autoCompact.ts:215
if (feature('CONTEXT_COLLAPSE')) { ... }

从集成点来看，CONTEXT_COLLAPSE 在 autoCompact、postCompactCleanup、sessionRestore 和 query 引擎中都有存在。它引入了一个 CtxInspectTool（tools.ts:110），允许模型主动检查和管理上下文窗口的状态。与当前的全量压缩不同，CONTEXT_COLLAPSE 可能实现了更精细的“折叠“语义——可以选择性地折叠某些工具调用的结果，而保留其他关键上下文。

REACTIVE_COMPACT（4 处引用）是另一个压缩实验——响应式触发，而非基于 token 阈值的定时触发。

TEAMMEM：团队记忆同步

TEAMMEM（51 处引用）实现了跨会话的团队知识同步：

// services/teamMemorySync/watcher.ts:253
if (!feature('TEAMMEM')) { return }

团队记忆系统包含三个核心组件：

1. watcher（teamMemorySync/watcher.ts）：监视团队记忆文件的变化
2. secretGuard（teamMemSecretGuard.ts）：防止敏感信息泄漏到团队记忆中
3. memdir 集成（memdir/memdir.ts）：将团队记忆层纳入 memdir 路径系统

从引用模式来看，TEAMMEM 的实现相当成熟——51 处引用覆盖了记忆读写、提示词构建、secret 扫描和文件同步等完整流程。

23.4 从 Flag 集群推断系统演进方向

集群一：自主 Agent 生态

KAIROS + PROACTIVE + KAIROS_BRIEF + KAIROS_CHANNELS + KAIROS_DREAM + KAIROS_PUSH_NOTIFICATION + KAIROS_GITHUB_WEBHOOKS + AGENT_TRIGGERS + AGENT_TRIGGERS_REMOTE + BG_SESSIONS + COORDINATOR_MODE + BUDDY + ULTRAPLAN + VERIFICATION_AGENT + MONITOR_TOOL

这是最大的 flag 集群（15+ 个），其逻辑关系可以还原为：

                    KAIROS (核心)
                        │
          ┌─────────────┼──────────────┐
          │             │              │
     PROACTIVE      KAIROS_BRIEF   KAIROS_DREAM
   (自主执行权)    (简报通信)     (空闲记忆整理)
          │             │
          │        ┌────┴────┐
          │        │         │
          │   CHANNELS  PUSH_NOTIFICATION
          │   (多通道)     (状态推送)
          │
     ┌────┴────┐
     │         │
  BG_SESSIONS  AGENT_TRIGGERS
  (后台会话)    (定时触发)
     │              │
     │         AGENT_TRIGGERS_REMOTE
     │            (远程触发)
     │
COORDINATOR_MODE ── ULTRAPLAN
  (跨 agent 协调)   (结构化计划)
          │
          │
     BUDDY          VERIFICATION_AGENT
   (伴侣 UI)         (自动验证)
          │
     MONITOR_TOOL
    (进程监控)

图 23-2：自主 Agent Flag 集群关系图

这个集群描绘了一个从“被动响应用户输入“到“主动在后台持续工作“的演进路径。KAIROS 是核心引擎，PROACTIVE 提供焦点感知的自主权，AGENT_TRIGGERS 提供定时唤醒，BG_SESSIONS 提供后台持久化，COORDINATOR_MODE 提供多 agent 编排。

集群二：远程/分布式能力

BRIDGE_MODE + DAEMON + SSH_REMOTE + DIRECT_CONNECT + CCR_AUTO_CONNECT + CCR_MIRROR + CCR_REMOTE_SETUP + SELF_HOSTED_RUNNER + BYOC_ENVIRONMENT_RUNNER + LODESTONE

这个集群围绕“在用户之外的环境中运行 Claude Code“展开：

表 23-7：远程/分布式能力分层

集群三：上下文智能

CONTEXT_COLLAPSE + REACTIVE_COMPACT + CACHED_MICROCOMPACT + COMPACTION_REMINDERS + TOKEN_BUDGET + PROMPT_CACHE_BREAK_DETECTION + HISTORY_SNIP

这些 flag 描述了对上下文管理的持续优化。与第9-12章分析的现有 compact 机制相比，这些 flag 代表了下一代上下文管理：

• 从定时压缩到响应式压缩（REACTIVE_COMPACT）
• 从全量压缩到选择性折叠（CONTEXT_COLLAPSE）
• 从被动到主动的缓存管理（PROMPT_CACHE_BREAK_DETECTION）
• 从隐式到显式的预算控制（TOKEN_BUDGET）

集群四：安全分类与权限

TRANSCRIPT_CLASSIFIER + BASH_CLASSIFIER + ANTI_DISTILLATION_CC + NATIVE_CLIENT_ATTESTATION + HARD_FAIL

这个集群围绕“更精细的安全控制“展开。TRANSCRIPT_CLASSIFIER 的 auto 模式是一个重要的方向——它代表了从“二元权限“（全部确认或全部接受）到“智能权限“（基于内容分析动态决策）的转变。ANTI_DISTILLATION_CC 则暗示了对模型输出的知识产权保护机制。

23.5 Flag 成熟度光谱

将 89 个 flag 按引用次数绘制成光谱，可以观察到几个有趣的分布特征：

引用数  Flag 数量  成熟度阶段
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
100+       2     深度集成期  ██
 30-99     6     全面织入期  ██████
 10-29    12     模块集成期  ████████████
  3-9     27     初步实现期  ███████████████████████████
  1-2     42     原型探索期  ██████████████████████████████████████████

图 23-3：89 个 Flag 的成熟度分布

分布呈现明显的长尾特征：47% 的 flag（42 个）只有 1-2 处引用，处于原型或纯开关阶段。只有 2 个 flag 达到了 100+ 引用的深度集成状态。这符合软件产品的典型功能漏斗——大量探索性实验中，只有少数最终成为核心功能。

值得注意的是引用数与跨模块分布之间的区别。KAIROS 的 154 处引用分布在 main.tsx、REPL.tsx、commands.ts、prompts.ts、print.ts、sessionStorage.ts 等至少 15 个文件中——这种广泛的集成意味着启用 KAIROS 需要触及系统的多个切面。相比之下，TEAMMEM 虽然有 51 处引用，但主要集中在 memdir/、teamMemorySync/ 和 services/mcp/ 中——这种局部化的集成更容易被独立启用和测试。

23.6 构建配置推断

从 flag 的门控模式，可以推断出至少三种构建配置：

公开构建（Public Build）

绝大多数 flag 为 false。已知公开启用的功能（如基础技能系统、工具链）不需要 flag 门控——它们是源码的“默认路径“。

内部构建（Ant Build）

USER_TYPE === 'ant' 检查出现在多个技能的注册逻辑中（verify.ts:13、remember.ts:5、stuck.ts 等）。内部构建启用了更多的实验性功能，包括 EXPERIMENTAL_SKILL_SEARCH、SKILL_IMPROVEMENT 等。

实验构建（Experiment Build）

某些 flag 组合可能代表 A/B 测试配置——TREE_SITTER_BASH 和 TREE_SITTER_BASH_SHADOW 的命名模式暗示了一个“影子模式“实验：新的 Bash 解析器在后台运行并比较结果，但不影响用户可见的行为。类似地，ABLATION_BASELINE 明确标识了消融实验的基线配置。

23.7 未发布功能间的依赖关系

某些 flag 之间存在隐式依赖，可以从代码中的 && 组合推断：

// commands.ts:77
feature('DAEMON') && feature('BRIDGE_MODE')  // daemon 依赖 bridge

// skills/bundled/index.ts:35
feature('KAIROS') || feature('KAIROS_DREAM')  // dream 可独立于完整 KAIROS

// main.tsx:1728
(feature('KAIROS') || feature('KAIROS_BRIEF')) && baseTools.length > 0

// main.tsx:2184
(feature('KAIROS') || feature('KAIROS_BRIEF'))
  && !getIsNonInteractiveSession()
  && !getUserMsgOptIn()
  && getInitialSettings().defaultView === 'chat'

关键依赖关系：

表 23-8：Flag 间主要依赖关系

23.8 对现有架构的影响

这 89 个 flag 对现有架构的影响可以从几个层面理解：

上下文管理层

CONTEXT_COLLAPSE 和 REACTIVE_COMPACT 将改变我们在第9-11章分析的压缩机制。当前的 autoCompact 基于 token 阈值的定时检查可能被替换为更精细的响应式策略——在工具调用返回大量结果时立即触发局部折叠，而不是等到整体 token 数超过阈值。

权限层

TRANSCRIPT_CLASSIFIER 的 auto 模式代表了权限系统的一次范式转变。当前的二元模型（plan vs auto-accept）可能演进为三元模型，其中 auto 模式使用 ML 分类器实时评估每个操作的风险等级。

工具层

WEB_BROWSER_TOOL、TERMINAL_PANEL、MONITOR_TOOL 等新工具扩展了 agent 的感知和行动能力。特别是 WEB_BROWSER_TOOL 对 Bun WebView 的依赖，意味着浏览器能力将是原生集成的，而非通过外部进程（如 Playwright）实现。

执行模型层

KAIROS + DAEMON + BRIDGE_MODE 共同指向一个“后台持续运行“的执行模型——Claude Code 不再仅仅是一个交互式 REPL，而是可以作为守护进程在后台持续工作，通过 Bridge 远程控制，通过 Push Notification 报告进度。

模式提炼

从 Feature Flag 系统的设计中，可以提取以下可复用的模式：

模式一：构建时 Dead Code Elimination

• 解决的问题：实验性代码不应出现在生产构建中
• 模式：feature('FLAG') 在编译期被替换为字面量 true/false，if (false) { require(...) } 整个分支及其依赖被 tree-shaking 移除
• 前置条件：构建工具支持编译期常量替换和 dead code elimination

模式二：引用计数推断成熟度

• 解决的问题：在大型代码库中评估实验性功能的集成深度
• 模式：统计 flag 在源码中的引用次数和跨模块分布——100+ 引用意味着深度集成，1-2 引用意味着原型阶段
• 前置条件：flag 命名一致且通过统一 API 访问

模式三：Flag 集群依赖管理

• 解决的问题：相关功能之间的启用顺序和依赖关系
• 模式：通过 feature('A') && feature('B') 表达硬依赖，通过 feature('A') || feature('B') 表达软关联；子功能可独立于父功能启用（如 KAIROS_DREAM 可独立于完整 KAIROS）
• 前置条件：功能之间存在层次化的依赖关系

用户能做什么

理解 Feature Flag 以更好地使用 Claude Code：

1. 检查可用的实验性功能。部分 flag 通过环境变量暴露给用户——如 CLAUDE_CODE_COORDINATOR_MODE 控制协调者模式。查阅官方文档了解哪些实验性功能可以通过环境变量启用。

2. 理解构建版本的差异。公开构建、内部构建（USER_TYPE=ant）和实验构建有不同的功能集。如果你在使用企业版或内部版本，可能有更多功能可用（如 verify、remember、stuck 等技能）。

3. 关注 KAIROS 相关的助手模式。KAIROS 是引用最多的 flag（154 处），代表了 Claude Code 向“后台自主 agent“演进的方向。当这些功能逐步公开时，理解其终端焦点感知、定时唤醒、简报通信等机制有助于更好地利用它们。

4. 注意 auto 权限模式的出现。TRANSCRIPT_CLASSIFIER 引入的 auto 权限模式是介于 plan（全部确认）和 auto-accept（全部接受）之间的智能中间地带。当它公开可用时，它可能是大多数用户的最佳默认选择。

5. 理解 Flag 的存在不等于功能承诺。89 个 flag 中 47% 只有 1-2 处引用，处于原型阶段。不要基于源码中的 flag 存在来预期功能发布——flag 的本质是让团队安全地探索和实验。

23.9 小结

89 个 Feature Flag 揭示了 Claude Code 远超当前公开功能的工程深度。按功能域分类：

• 自主 Agent 生态（18 个 flag）：以 KAIROS 为核心，构建后台自主执行、定时触发、多 agent 协调的完整能力栈
• 远程/分布式执行（14 个 flag）：Bridge + Daemon + SSH/Direct Connect，实现跨机器的远程控制和分布式运行
• 上下文管理优化（17 个 flag）：从定时全量压缩到响应式选择性折叠的演进
• 记忆与知识管理（9 个 flag）：团队记忆同步、自动记忆提取、技能自我改进
• UI/UX 与平台能力（31 个 flag）：语音输入、浏览器集成、终端面板等新交互模态

从成熟度分布来看，KAIROS（154 引用）和 TRANSCRIPT_CLASSIFIER（107 引用）是最深度集成的两个系统——它们的代码痕迹已经深入 Claude Code 的核心架构。而 42 个只有 1-2 处引用的 flag 则代表了大量的探索性实验，其中大部分可能永远不会成为公开功能。

这些 flag 共同描绘了 Claude Code 从“交互式编码助手“向“后台自主开发 agent“演进的工程准备。不过，源码中的存在不等同于产品计划——feature flag 的本质是让团队能够安全地探索和实验，而不必承诺每个实验都将成为产品。