很多人第一次用 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 讲得很细。因为一旦进入团队使用阶段，“谁能改什么、配置在哪一层生效、能不能覆盖”都会变成真实问题。
你给我的那份“命令更新时间表”，有价值，但不能原样照抄成文章
你整理的那份命令表已经很好了，信息密度也够，适合做资料底稿。
但如果直接把“命令 + 说明 + 分类 + 新增时间”排成一个大表发出去，读者大概率只会得到两个感受：
- 命令好多
- 我还是不知道先学什么
技术普及文最怕这个。信息很全，读完没地图。
所以这篇文章更适合走“地图型写法”，而不是“词典型写法”。
具体来说，发布版我建议保留两层结构：
- 正文讲结构和判断：Claude Code 为什么会长出这么多命令，这些命令各自服务哪个层级，普通用户先学哪几组。
- 附录给指令速查表：把你整理的高价值命令做成分组清单，而不是平铺成一张全表。
这样读者先获得认知，再拿工具表查细节。
如果是我来写这篇技术普及文，我会突出三件事
第一，不把它写成“命令大全”
命令大全很容易过期，也很难读。
真正稳定的，不是某一条命令的参数，而是这套产品正在往哪走。
这篇文章最有价值的主线，应该是：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 产品页。