Claude Code CLI 最新指令集：别再只会 /clear 了

很多人第一次用 Claude Code，停留在两个动作：提问，然后 /clear。

这当然能用，但你会把它当成一个会写代码的聊天框，而不是一个正在成型的终端工作台。

如果你最近看到 Claude Code 的命令越来越多，甚至开始出现 /agents、/hooks、/plugin、/chrome、/channels、/schedule 这些入口，最容易产生的误解是：它只是把功能越堆越厚。

我看下来不是这样。更准确的判断是：Claude Code 正在从“终端里的 AI 助手”变成一个可配置、可协作、可自动化的 agent runtime。

这篇文章不打算把 80 多个命令逐条翻译一遍。那样没有阅读价值。我的目标更简单：帮你建立一张能用的地图——现在这套 Claude Code CLI 指令集，应该怎么理解、怎么分层、哪些真的值得先学。

Claude Code 的命令，已经不是“快捷键手册”了

Anthropic 官方命令页现在列出了 80+ 条命令，覆盖会话管理、模型切换、权限、MCP、插件、子 Agent、远程控制、计划审查、自动排程等多个层面。官方文档里对 Claude Code 的定位也越来越清楚：它不是单纯在 terminal 里补全代码，而是一个可以跑在终端、IDE、桌面端、浏览器和 Slack里的 agentic coding 工具。

这件事很重要，因为它解释了为什么命令会突然变多。

命令变多，不一定意味着复杂度失控。很多时候只是产品边界变了。

以前你只需要问它“改这个函数”。现在你开始希望它：

• 管理上下文
• 切换模型和推理强度
• 复用项目规则
• 接第三方工具
• 调子 Agent 并行干活
• 审查 PR
• 定时跑 routine
• 从浏览器或 Web 会话把任务拉回本地终端

一旦目标从“问答”变成“工作流”，命令层就一定会膨胀。

最值得先理解的，不是某条命令，而是五层结构

如果把 Claude Code 最新指令集摊开看，你会被信息量压住。更有效的方式是先按功能层来分。

我建议把它拆成五层。

第一层：会话控制层

这是最基础也最容易立刻提效的一层。核心不是“和 Claude 聊天”，而是管理上下文寿命。

最常用的一组：

• /clear：清空当前对话上下文，别名 /reset、/new
• /compact [instructions]：压缩历史上下文，保留重点但释放窗口
• /context：看当前上下文占用，找出哪些东西在吃 token
• /branch [name]：从当前节点分叉会话，别名 /fork
• /btw <question>：插播侧问题，不并入主对话
• /resume [session]：恢复旧会话
• /rename [name]：重命名当前会话
• /export [filename]：导出当前对话
• /recap：生成本次会话的一行回顾
• /copy [N]：复制最近第 N 条回复，支持把代码块写入文件
• /rewind：把对话或代码回退到之前的点

这一层最容易被低估的，其实是 /compact 和 /context。

很多人上下文快满了，第一反应还是 /clear。这样很干脆，但也会把任务状态、约束、之前已经验证过的东西一起丢掉。/compact 的价值在于：你不需要把会话推倒重来，只需要把它压缩成一个还能继续工作的摘要。

而 /context 解决的是另一个问题：你经常感觉“怎么突然变笨了”，其实不是模型退化，而是上下文里混进了太多无关信息、长日志、低价值对话和重复规则。

如果你平时已经在做长链路任务，这两个命令的收益，远高于再背三十条新命令。

第二层：模型与成本控制层

Claude Code 现在已经不是“单模型固定体验”了。你可以切模型，也可以切推理强度，还能看成本和额外用量。

这层的核心命令有：

• /model [model]
• /effort [low|medium|high|xhigh|max|auto]
• /fast [on|off]
• /usage、/cost、/stats
• /extra-usage
• /status

这里最关键的变化有两个。

第一，/model 不再只是选型号。根据官方文档，它已经和 effort 绑定在一起，支持会话内即时切换，部分模型还可以直接用左右键调 effort。对于长任务和复杂重构，这比单纯换模型更实用。

第二，Claude Code 把“速度”和“思考强度”拆开了。

你可以这么理解：

• /model 决定你找谁干活
• /effort 决定它肯花多少脑力
• /fast 决定你是否愿意拿更高成本换低延迟

这个拆分是成熟产品的信号。因为真实开发场景里，不同任务对这三件事的偏好完全不同。

比如：

• 查一个配置项，sonnet + low effort 就够了
• 审一段复杂架构改动，可能要 opus + high/xhigh
• 临时交互频繁、你只想快点试几轮，/fast on 可能更舒服

很多人觉得 Claude Code 贵，往往不是它真的不可控，而是你没有建立“任务类型 → 模型/effort 档位”的习惯。

第三层：代码工作流层

这一层才是大多数开发者最先接触 Claude Code 的地方，但现在它已经比早期“读代码、改代码、写 diff”复杂多了。

高频命令包括：

• /init
• /diff
• /review [PR]
• /security-review
• /autofix-pr [prompt]
• /batch <instruction>
• /plan [description]
• /ultraplan <prompt>
• /ultrareview [PR]
• /install-github-app

如果只看表面，会以为它们都是“辅助写代码”。其实可以再细分成三种能力。

1）项目启动和约束注入

/init 的作用不是生成一个装饰性的 CLAUDE.md，而是把项目约束、命令、目录、规范，变成 Claude 后续执行时能读到的运行时上下文。

如果你已经在团队里稳定使用 Claude Code，这个文件的重要性远高于一堆临时 prompt。

2）审查与验证

/diff、/review、/security-review、/ultrareview 这一组，说明 Claude Code 正在往“先验证再提交”的方向走。

这点我很认同。真正拖慢团队的，从来不是代码写得慢，而是写完之后没人认真看、没人系统查风险。

尤其 /security-review 这种命令的价值，不在于它能发现所有漏洞，而在于它把“安全扫描”变成了一个显式动作，而不是一句口头上说的“顺便看看有没有问题”。

3）并行化交付

/batch、/autofix-pr、/ultraplan 这几个命令，代表的是另一个方向：Claude Code 不再只服务单轮编辑，而是在试图接管一段完整交付链。

其中 /batch 很值得单独提一下。官方描述已经很明确：它会把任务拆成 5 到 30 个独立单元，在隔离的 git worktree 里并行跑，每个单元一个 background agent，最后各自开 PR。

这不是“写得更快”那么简单。这是在把 Claude Code 往团队级改动编排工具推。

问题当然也在这：一旦你把改动拆给多个 agent，真正的难点就不再是代码生成，而是任务切分质量、测试边界和 PR 收敛。也就是说，命令本身很强，但只有在代码库足够模块化时，它才会显得聪明。

第四层：扩展与自动化层

这是这波指令集最像“平台化”信号的一层。

核心命令有：

• /mcp
• /agents
• /hooks
• /plugin
• /skills
• /claude-api
• /chrome
• /schedule
• /remote-control
• /remote-env
• /web-setup
• /channels

先说一个结论：如果你只把 Claude Code 当本地代码助手，这一层你可以先不碰；但如果你想把它接进自己的工具链，这一层才是未来。

MCP：外接能力总线

/mcp 还是整个生态的基础入口。你可以把它理解成 Claude Code 对外接工具、服务和数据源的统一总线。

今天很多人谈 Claude Code 的能力，实际说的不是模型本身，而是它接上了什么：GitHub、数据库、浏览器、内部 API、文档系统、监控系统。

没有 MCP，它只是会写代码。有了 MCP，它才开始接近一个能执行任务的 agent。

Agents / Hooks / Plugin：运行时三件套

• /agents：管理子 Agent
• /hooks：在工具事件前后挂自动动作
• /plugin：安装和管理插件

这三者组合起来，已经很像一个轻量 agent platform 了。

其中我最看重的是 hooks。因为很多团队真正想要的，不是再多一个聊天入口，而是把某些动作自动化：

• 写完文件自动格式化
• 改完代码自动跑测试
• 某类命令前后注入检查
• 某些上下文出现时自动加载规则

官方文档也强调了，配置没生效时，先看 /context、/memory、/skills、/hooks、/mcp、/permissions、/doctor、/status 这些检查命令，而不是猜。

这件事很关键。因为一旦产品进入“可编程配置”阶段，调试配置本身就成了日常工作的一部分。

/chrome、/schedule、/channels：Claude Code 已经开始出 terminal 了

这一组命令最值得注意。

• /chrome：连浏览器自动化
• /schedule：把 routine 定时跑起来
• /channels：管理通知频道和消息入口
• /remote-control：让会话可被远程接管
• /teleport：把 web 上的会话拉回本地 terminal

这说明 Claude Code 的边界已经明显外扩。

它不再满足于“我在 shell 里等你打一行 prompt”。它开始尝试接浏览器、接远程环境、接消息流、接外部触发器。

说白了，命令的膨胀，本质上是执行面在扩张。

第五层：环境与权限治理层

当 Claude Code 开始能调工具、写文件、开子 Agent、接浏览器、跑自动任务，权限治理就不再是配角。

这层的关键命令包括：

• /permissions
• /sandbox
• /add-dir <path>
• /memory
• /config
• /doctor
• /status
• /keybindings
• /ide
• /theme
• /tui

很多人觉得这些命令“没生产力”，其实恰恰相反。

当工具能力弱时，权限设计不重要；因为它本来也做不了多少事。只有当它真的开始能做事，权限和隔离才会决定你敢不敢把活交给它。

比如 /permissions 和 /sandbox，本质上是在回答一个更底层的问题：

你希望 Claude Code 是一个建议者，还是一个可执行代理？

如果只是建议者，你可以容忍它每一步都问。

如果你想让它真干活，那你迟早要设计一套：哪些能直接做，哪些要批准，哪些一律不能碰。

这也是为什么官方现在会把 managed / user / project / local 这些 settings scope 讲得很细。因为一旦进入团队使用阶段，“谁能改什么、配置在哪一层生效、能不能覆盖”都会变成真实问题。

你给我的那份“命令更新时间表”，有价值，但不能原样照抄成文章

你整理的那份命令表已经很好了，信息密度也够，适合做资料底稿。

但如果直接把“命令 + 说明 + 分类 + 新增时间”排成一个大表发出去，读者大概率只会得到两个感受：

• 命令好多
• 我还是不知道先学什么

技术普及文最怕这个。信息很全，读完没地图。

所以这篇文章更适合走“地图型写法”，而不是“词典型写法”。

具体来说，发布版我建议保留两层结构：

1. 正文讲结构和判断：Claude Code 为什么会长出这么多命令，这些命令各自服务哪个层级，普通用户先学哪几组。
2. 附录给指令速查表：把你整理的高价值命令做成分组清单，而不是平铺成一张全表。

这样读者先获得认知，再拿工具表查细节。

如果是我来写这篇技术普及文，我会突出三件事

第一，不把它写成“命令大全”

命令大全很容易过期，也很难读。

真正稳定的，不是某一条命令的参数，而是这套产品正在往哪走。

这篇文章最有价值的主线，应该是：Claude Code 的命令系统，正在暴露它的产品架构。

第二，强调“从聊天到工作流”的跃迁

这是普通开发者最值得理解的地方。

如果读者看完之后意识到：

• /clear、/compact、/context 是在管上下文
• /model、/effort、/fast 是在管推理预算
• /review、/security-review、/batch 是在管交付链
• /mcp、/hooks、/plugin、/schedule 是在管扩展和自动化
• /permissions、/sandbox、/doctor 是在管治理

那这篇文章就已经有用了。

第三，别把每个新增命令都写成“重大升级”

有些命令很重要，比如 /batch、/agents、/hooks、/plugin、/chrome、/schedule。

也有些命令更像体验补全，比如 /rename、/copy、/recap、/color、/mobile。

它们当然都值得知道，但文章里要分主次。否则读者会误以为所有新增项都同等关键。

不是的。

真正构成平台分水岭的，是那些让 Claude Code 从“单人交互”走向“可编排执行”的命令。

我建议的发布结构

如果要发成一篇适合站内传播的文章，我建议用下面这个结构：

• 开头：指出大多数人只会 /clear，但真正重要的是命令层暴露的产品方向
• 第一部分：Claude Code 为什么突然多了这么多命令
• 第二部分：五层命令地图
• 第三部分：普通开发者最该先学的 10 个命令
• 第四部分：哪些命令代表它正在平台化
• 附录：按类别整理的最新常用指令速查

其中“最该先学的 10 个命令”，我会选这组：

• /compact
• /context
• /resume
• /model
• /effort
• /diff
• /review
• /mcp
• /permissions
• /doctor

这 10 个命令不一定最酷，但最能改变实际使用质量。

附录：Claude Code CLI 最新常用指令速查

下面这份不是完整 80+ 全表，而是面向普通开发者更值得先掌握的一版。

会话与上下文

• /clear：清空当前上下文，重新开聊
• /compact [instructions]：压缩历史对话，保留关键上下文
• /context：查看上下文占用和优化建议
• /branch [name]：从当前会话分叉一条新支线
• /btw <question>：提一个不进入主线历史的侧问题
• /resume [session]：恢复历史会话
• /rename [name]：给当前会话改名
• /export [filename]：导出当前会话
• /recap：生成当前会话摘要
• /copy [N]：复制最近第 N 条回复
• /rewind：回退到先前检查点或对话节点

模型、速度与成本

• /model [model]：切换模型
• /effort [level|auto]：设置推理强度
• /fast [on|off]：开关快速模式
• /usage /cost /stats：看成本、配额和用量
• /extra-usage：设置超限后的额外用量
• /status：查看当前模型、账户、连通状态和设置来源

代码工作流

• /init：初始化 CLAUDE.md
• /diff：交互式查看代码变更和各轮 diff
• /review [PR]：本地审查 PR 或当前改动
• /security-review：做安全审查
• /autofix-pr [prompt]：监控 PR 的 CI 和评论，自动推修复
• /batch <instruction>：拆分大型任务并行执行
• /plan [description]：直接进入 plan mode
• /ultraplan <prompt>：生成更重型的远程计划会话
• /ultrareview [PR]：深度多 Agent 审查

扩展、自动化与平台能力

• /mcp：管理 MCP 连接和认证
• /agents：管理子 Agent
• /hooks：查看和管理 hook
• /plugin：管理插件
• /skills：查看可用 skills
• /claude-api：加载 Claude API 参考 skill
• /chrome：配置 Claude in Chrome
• /schedule：配置 routines / 定时任务
• /remote-control：开放远程控制
• /teleport：把 web 会话拉回 terminal
• /web-setup：连接 GitHub 等 Web 侧能力

权限与环境治理

• /permissions：管理工具权限
• /sandbox：切换沙箱模式
• /add-dir <path>：临时增加可访问目录
• /memory：查看和管理 CLAUDE.md / auto-memory
• /config：打开设置界面
• /doctor：诊断安装和配置问题
• /ide：查看 IDE 集成状态
• /keybindings：编辑快捷键配置
• /theme：切换主题
• /tui [default|fullscreen]：切换 TUI 渲染器

最后一句判断

如果你今天还把 Claude Code 当“会写代码的聊天机器人”，那这套命令看起来一定很乱。

但如果你把它看成一个正在形成中的 agent runtime，这些命令就突然有逻辑了：它们分别在管上下文、模型、执行、扩展和治理。

真正值得跟踪的，不是又新增了哪条小命令，而是 Claude Code 正在把“提问”升级成“工作流编排”。

这才是这套 CLI 指令集背后的主线。

信息来源：Anthropic Claude Code 官方命令页、Overview、Settings、Model configuration、Interactive mode、Hooks、Subagents、Permissions、Plugins 和 Debug your configuration 文档；另参考 Anthropic 官方 Claude Code 产品页。