核心机制
命令系统解析：Slash Commands 是怎么工作的
命令系统和工具系统不是一回事
Claude Code 里有两套很容易混淆的机制：
- 工具系统：给模型调用
- 命令系统：给用户显式输入
比如 /config、/mcp、/review、/plugin 这类东西，不是让模型在主循环里随便调用的，而是用户主动触发的控制入口。
加载图表中...
commands.ts 是聚合中心
commands.ts 的体量很大，原因很简单：
它把系统内的各类命令都汇总起来了。
从导入列表就能看出 Claude Code 的命令能力非常丰富，覆盖：
- 配置和环境
- 登录和会话
- 审查和 diff
- MCP 和插件
- model、usage、status、cost
- plan、permissions、hooks、files
- 远程模式、mobile、chrome、branch、skills
这说明命令系统不是边角料，而是 Claude Code 的控制面。
对应源码片段
import config from './commands/config/index.js'
import { context, contextNonInteractive } from './commands/context/index.js'
import diff from './commands/diff/index.js'
import mcp from './commands/mcp/index.js'
import review, { ultrareview } from './commands/review.js'
import skills from './commands/skills/index.js'
import status from './commands/status/index.js'
import tasks from './commands/tasks/index.js'
import plugin from './commands/plugin/index.js'
import plan from './commands/plan/index.js'
import files from './commands/files/index.js'
这里最直观的信息就是：
Claude Code 的命令系统已经形成了非常完整的产品控制面，而不是零散几个辅助命令。
命令系统在整体架构里的位置
加载图表中...
用户为什么需要命令系统
如果一切都交给模型自动决定，系统会很强，但也会失去明确控制。
命令系统的价值就在这里：
- 有些操作适合人显式触发
- 有些配置不应该靠自然语言猜
- 有些管理动作需要确定性流程
例如：
- 我想切模型
- 我想看状态
- 我想管理插件
- 我想进入某个特殊模式
这些都更适合用命令表达。
为什么成熟产品一定会保留命令面
因为很多动作的目标不是“让模型推理”，而是“让系统进入明确状态”。
例如：
- 开启某个模式
- 查看某类统计
- 管理插件市场
- 配置权限或 hooks
这些事情本来就是控制面任务，不适合交给自然语言去猜。
命令层其实也是一种“能力组织方式”
从架构上看，命令系统做了两件事：
- 给用户提供显式控制接口
- 帮助系统把庞杂能力按主题归类组织
这也是为什么你会看到 commands.ts 里既有基础命令，也有大量 feature-gated 的高级命令。
换句话说，命令系统不只是执行器，还是整个产品功能地图的一部分。
和工具系统的关系怎么理解
一个很实用的理解方式是：
- 命令是“人直接操作系统”的入口
- 工具是“模型代替人操作系统”的入口
两者共享同一个底层世界：
- 同样受配置影响
- 同样受 feature gate 影响
- 同样可能读写状态
- 同样会和 AppState、services、外部集成发生交互
只是使用者不同。
小结
Claude Code 不是只有“智能自动化”，它同时保留了强大的显式控制面。
commands.ts 的存在说明这套系统非常清楚一件事：
好的工程助手，不应该只会自动干活，还要让用户能明确地接管、切换和管理整个运行环境。