第 16 章 Config 与 Feature Flags

不只是参数配置

Claude Code 的配置系统做两件事：控制运行时参数（超时时间、模型选择、各种开关），以及通过 feature flag 控制哪些功能对哪些用户可见。后者让同一份代码可以对外表现出不同的产品形态——外部公开版、内部开发版、实验功能版、组织定制版，功能集各不相同，但底层都是同一套代码。

Feature Flag 怎么工作

Feature flag 的判断发生在命令注册、工具初始化的时候，不是运行时的 if/else。

Flag 为 false 时，模块根本不加载，命令不出现在注册表里，Tab 补全里也看不到。工具层同理——某些工具的存在本身，受 feature flag 控制。

这种设计有一个好处：不同构建版本的包体积可以差异很大。外部版不会携带任何内部功能的代码，而不只是把它们隐藏起来。

配置的层级

配置有五个层级，从高到低：企业策略（通过管理平台下发，优先级最高）、用户级（~/.claude/settings.json）、项目共享级（.claude/settings.json，提交到仓库）、项目本地级（.claude/settings.local.json，不提交）、以及服务端 feature flag。

高层级可以覆盖低层级。企业策略还可以锁定某些配置项，让用户无法修改——比如强制禁用某些工具、限制只能连接指定组织。这对企业部署很重要：组织可以强制安全策略，同时让用户保留个性化配置的空间。

一份代码，多条产品线

如果没有 feature flag，维护多个产品版本的常见做法是拉多个 fork——外部版一个、内部版一个、实验版一个，各自维护。问题是每次改一个核心功能，所有 fork 都要同步，成本越来越高。

Feature flag 的方案是：只有一份代码，差异全部做成开关，主干统一迭代，不同产品线通过配置区分。代价是代码里会散落着各种条件判断，理解某个功能的完整行为需要知道在哪些 flag 组合下它是开着的。但对于需要同时维护多个产品版本的系统来说，这个复杂度是值得的。

从源码里能印证这一点：大约 100 个 feature flag，还有 19 个不出现在 /help 里的隐藏命令——/ultraplan、/teleport、/autofix-pr、/buddy 等，都是正在演化中的产品线留下的痕迹。