89 个写好了
但没打开的功能

餐厅后厨每天都有一些菜品已经研发好、试做过，但没有出现在菜单上。 厨师想等待合适的时机，或者还在等食材供应，或者只是还没准备好把它推向所有客人。 菜存在，只是你还不知道。

软件开发里有个类似的机制，叫 Feature Flag（功能开关）： 代码已经写好并打包发布出去，但被一个开关控制着，对外默认关闭。 工程师可以随时打开，也可以只对特定用户打开做测试， 或者等某个时间节点一键开放给所有人。

Claude Code 泄露的源码里，我们数出了 89 个这样的功能开关。 其中大约一半已经是正式功能。另外大约半数，是你还没有见过的东西。

最重要的一个：KAIROS

所有开关里出现频率最高的，是 KAIROS。

Kairos 是希腊语，有两个意思：一是"正确的时机"（与 Chronos 的线性时间相对）， 二是"机会之窗"。在修辞学里，它指演讲者捕捉到听众最开放、最准备好接受信息的那一刻。

在 Claude Code 的源码里，KAIROS 是一个"始终在线的 AI 助手模式"的代号。 它不是编程工具，而是一个持续存在的 AI 伙伴： 你不需要每次主动输入指令，它会主动观察你的工作，在合适的时机介入、提醒或提供帮助。

想象一下：你正在修一个 bug，IDE 的 AI 助手注意到你已经在这个文件里来回修改了四次， 主动说"我注意到这个问题，你想让我分析一下根本原因吗？"——你没有问它，它主动来找你了。

这是 Claude Code 从"工具"向"同事"的根本性转变。KAIROS 模式完整实现后， 你和 AI 的关系不再是"我发指令，它执行"，而是"我们共同工作，它主动参与"。

BRIDGE_MODE：一个引擎，四个前端

第二个值得深入看的是 BRIDGE_MODE（桥接模式），源码里也叫 "Remote Control"。

现在的 Claude Code 是一个 CLI（命令行）工具。你打开终端，输入 claude，在黑色窗口里工作。 BRIDGE_MODE 要解决的问题是：同一个 Claude Code 引擎，能不能同时驱动多个前端？

从源码里可以看到，BRIDGE_MODE 允许 Claude Code 以"远程控制"模式运行： 一个 Claude Code 实例在你的机器上跑着，但控制它的不是你打开的那个终端， 而是 claude.ai 网页、VS Code 插件，或者其他任何实现了桥接协议的客户端。

这背后的产品逻辑是：Anthropic 不想为每个前端（CLI/IDE/Web/移动端） 分别维护一套代码，而是想用一个核心引擎驱动所有界面， 就像 Linux 内核可以运行在服务器、桌面、手机上一样。

代码里有一个有意思的错误信息透露了它的设计边界： "Remote Control requires a claude.ai subscription"—— 这个功能只会向付费用户开放，至少在初期如此。

值得单独展开的九个开关

除了 KAIROS 和 BRIDGE_MODE，还有九个开关的名字足以让人脑补出完整的产品故事：

用产品经理的眼光做一个预测

如果按照"完成度"和"产品影响力"来给这些功能排优先级，一个大致的判断是这样的：

一个更大的问题

数完这 89 个开关，有一个问题浮现出来： Anthropic 到底想把 Claude Code 做成什么？

DAEMON（后台守护进程）+ KAIROS（主动观察介入）+ SSH_REMOTE（远程服务器控制） + COORDINATOR_MODE（多 Agent 编排）+ BRIDGE_MODE（多前端统一引擎）…… 这些加在一起，不是一个编程助手，而是一个始终在线、无处不在的 AI 操作层。

你的机器上有一个进程，连接到你的 IDE、你的浏览器、你的服务器， 主动观察你的工作，在你需要之前就准备好帮助， 在你不在线的时候继续处理队列里的任务—— 这不是工具，这是一个 AI 时代的操作系统雏形。

历史上，每一次操作系统级别的争夺，都是价值巨大的赌局： Windows 对 Mac，iOS 对 Android，每一场争夺都重新定义了谁拥有用户的计算入口。 那下一场争夺的战场，可能就是：谁的 AI 层成为你工作流程的默认基础设施。

而这 89 个开关，是 Anthropic 走向那个目标的步伐——每一个都还没有面世， 但每一个都已经写好了代码，等待着被打开的那一天。