Claude Code终极命令指南：从权限管理到自动化工作流全攻略

Claude Code 再度迎来重磅升级！如果你平时没有持续关注它的版本迭代，隔段时间重新打开，大概率会生出一种既熟悉又陌生的感觉：怎么又冒出新命令了？怎么之前没注意到的能力突然出现了？

Claude Code 的更新速度确实很快，但真正被用户高频调用的，往往还是最基础那几个指令，多数场景下倒也够用。因此不少人对 Claude Code 的使用，仍停留在"打开终端，发起对话"的初级阶段，最多再配合 help 查看可用功能。

至于上下文管理、权限控制、技能扩展、自动化能力，虽然有所了解的人不少，但真正系统性地运用到日常工作中的却不多。所以要用好 CC 的关键不在于记住所有指令，而在于理解每个命令在什么场景下使用、为何使用该命令。

本文将从实际应用场景出发，系统梳理 Claude Code 中那些实用高效却常被忽略的命令，构建完整的使用方法论。

命令的本质认知

许多初学者认为"命令"很简单：输入斜杠加单词，执行对应动作即可。但在 Claude Code 中，并非所有 /命令 都遵循同一套逻辑：

  1. 部分属于内置命令，专门处理会话、上下文、模型、权限等基础能力；
  2. 部分虽采用命令形式，但背后实际对应的是 skill 能力；
  3. 还有些命令更像能力入口，真正连接的是 hooks、agents、MCP、schedule 等更大的扩展机制；

这正是很多人虽知道命令名称，实际使用时仍感混乱的根源——问题往往不在于命令数量，而在于未理清这套系统的整体架构。

Claude Code 的命令若按能力形态粗略分类，大致可归为三类，后续再按实际使用场景细分讲解。

1. 基础控制指令

这类命令主要解决 Claude Code 自身如何使用的问题，涵盖会话清理、上下文压缩、模型切换、推理强度调整、状态查看、权限管理等基础操作。

这些指令最基础也最常用，属于日常高频交互的范畴。Claude Code 的使用体验是否流畅，往往取决于这些基础命令是否运用得当。

2. 场景化能力指令

这类命令已超越"执行单一动作"的范畴，更像是将某类任务封装成独立入口。例如调试、批量处理、循环执行、PR 修复等命令，背后更接近完整流程而非单点操作。

这类命令可理解为：表面是一个指令，实际调用的是一整套预设能力。

3. 扩展能力相关指令

如 memory、skills、agents、hooks、MCP、schedule 等，更适合视为通向 Claude Code 扩展能力的一组入口。

与前两类最大区别在于：前两类聚焦当前会话的高效执行，而这一类涉及能力的长期沉淀、外部工具接入、重复动作转化为可复用流程。

掌握 Claude Code 命令的关键不在于记住多少，而在于理解每个命令的功能定位及适用场景。

第一类：会话与上下文管理指令

会话与上下文管理是最核心的命令集合。

许多用户感觉 Claude Code 越用越慢、越用越乱，第一反应常归咎于模型性能或上下文过长。问题或许与此相关，但更多时候源于会话管理不当。

这类命令技术门槛不高，却直接影响日常体验。运用得当会感觉工具非常顺手，运用不当则容易出现上下文混乱、指令串味、信息臃肿等问题。

本组最值得优先掌握的命令包括：clear、compact、context、resume、rewind、recap。

1. clear：彻底清空，从零开始

官方描述：Start a new conversation with empty context. The previous conversation stays available in /resume.
简单理解：清空当前上下文，开启全新会话；历史会话仍可通过 resume 找回。

clear 操作直观明了，即清空当前会话并从零开始构建上下文。该命令人人会用，但也最容易被滥用。只要感觉对话混乱就直接 clear，确实简单粗暴，但已建立的任务背景、约束条件、上下文信息也会一并清除。

因此 clear 更适合以下场景：

  • 当前任务已完全结束，准备开启全新话题
  • 会话已严重偏离轨道，继续挽救成本过高
  • 上下文混杂过多无关信息，继续对话只会更加混乱

简言之，clear 适合"推倒重来"，不适合作为日常整理手段。

2. compact：智能压缩上下文

官方描述：Free up context by summarizing the conversation so far.
简单理解：通过总结当前会话内容释放上下文空间。

若说 clear 是推倒重来，compact 更像是"保留主线，清理冗余"。

这条命令极其重要，却常被用户忽视。长时间使用 Claude Code 时，最常见问题并非完全崩溃，而是上下文不断膨胀，其中混杂旧尝试、废弃思路、重复描述、已解决问题和失效指令。此时真正需要的不是清空，而是将当前任务压缩成更干净、更聚焦的状态继续推进。

可将其理解为"会话瘦身"：主线任务保留，必要信息留存，但那些已不重要或会干扰后续判断的内容会被最大限度压缩。

对大多数用户而言，compact 的使用频率应高于 clear。

尤其在以下场景中，优先考虑 compact 更为合适：

  • 任务尚未完成，但对话已过于冗长
  • 中间尝试过多种方案，希望保留结论、舍弃过程噪音
  • 需要继续当前任务，但明显感觉上下文开始沉重

许多用户一旦感觉会话不顺，便条件反射式地使用 clear。但更稳妥的做法是先行判断：任务是应重开，还是仅需瘦身。如果只是后者，compact 才是更优选择。

3. context：先诊断再处理

官方描述：Visualize current context usage as a colored grid. Shows optimization suggestions for context-heavy tools, memory bloat, and capacity warnings.
简单理解：以可视化方式查看上下文使用情况，并提示哪些内容可能过载。

有时会话是否"沉重"不能完全凭感觉判断，此时 context 的价值便凸显出来。它如同一个上下文状态检测仪：先了解当前所处状态，再决定是继续对话、执行 compact，还是直接 clear。

它能帮你减少拍脑袋决策。尤其在任务冗长、信息量大的情况下，先查看上下文状态再决定处理方式，通常更为稳健。

Image

4. resume：接续未竟任务

官方描述：Resume a conversation by ID or name, or open the session picker.
简单理解：通过会话 ID、名称或选择器恢复历史会话。

并非所有 Claude Code 任务都适合一次完成。有些任务本身跨度很长，中间可能暂停，过一段时间再继续。此时若完全重新描述背景，成本高昂且容易遗漏信息。resume 的意义正在于此：接续历史会话，减少重复铺垫。

该命令适合"任务主线未变，仅中途暂停"的场景。相比重新开启会话再手动补充背景，resume 效率更高。

5. rewind：不满意就回退

官方描述：Rewind the conversation and/or code to a previous point, or summarize from a selected message.
简单理解：将会话或代码状态回退到先前节点，或从指定消息重新总结。

有时问题并非整个会话不可用，而是某段对话开始偏离正轨。这种情况下 rewind 极具价值。它如同将会话或代码状态回拨一小段，让你从更合适的位置重新出发，而非全盘推翻。

可将其理解为"撤回到前一阶段"的能力。对于中途试错较多但又不希望丢弃前期成果的场景，比直接 clear 更精细。

6. recap：阶段性总结收口

官方描述：Generate a one-line summary of the current session on demand.
简单理解：按需生成当前会话的一句话摘要。

recap 的作用非常适合放在长任务的阶段性节点上。例如一个任务已讨论很久，此时你自己也开始混乱，不确定当前进度、结论或剩余工作。此时先执行 recap 将进度和关键点整理清晰，再决定下一步如何推进，通常会让思路更清爽。

其价值不在于替代思考，而在于帮你将当前会话状态整理成更易于推进的形式。

Image

本组命令使用方法论

将本组命令视为一套"会话整理工具箱"：

  • clear 负责重开
  • compact 负责瘦身
  • context 负责状态诊断
  • resume 负责接续任务
  • rewind 负责回退修正
  • recap 负责阶段性收口

其中最容易被低估的是 compact。许多用户会用 clear，也知道 resume，但真正能显著改善日常体验的，往往是学会在恰当时机使用 compact、context 和 recap。

因为这些命令解决的不是"如何开新局"，而是"如何把当前这局打得更加顺畅"。

如果你目前对 Claude Code 的使用仍偏向单条会话从头到尾，或一旦混乱就直接 clear，那么本组命令值得尽快熟练掌握。

第二类：模型、推理强度与成本管控指令

如果说上一组解决"会话如何管理"，那这一组解决的是：当前任务到底该以何种状态运行。

许多初学者使用 Claude Code 时容易形成习惯：不分任务类型统一上高配。小问题也想让它深度思考，简单修改也直接拉满，结果往往是成本上升、响应变慢，实际效果却未必更好。

问题不在于高配无价值，而在于并非所有任务都值得如此配置。

本组值得关注的核心命令包括：model、effort、status、cost、stats。

1. model：先判断任务类型

官方描述：Select or change the AI model.
简单理解：选择或切换当前使用的 AI 模型。

model 解决的是"让谁来做这件事"的问题。这看似是配置项，实则极为关键，因为不同任务对模型能力的要求本就不在同一层级。

若只是让 Claude Code 处理边界清晰的任务，如：

  • 修改明确指定的代码片段
  • 修复已精确定位的小 bug
  • 调整样式、文案或配置
  • 按既定方案补充实现细节

这类任务更接近执行题，重点在于准确完成，未必需要最强分析能力。

举例而言。你在开发 React 页面，仅想修改弹窗按钮文案并补充 loading 状态。此任务分析空间极小，Claude Code 只需按要求修改代码即可。此类场景过度追求模型配置，收益并不明显。

但若换种场景：你接手陌生项目，下单流程时好时坏，尚不确定问题在前端状态、接口参数、权限校验还是边界条件。此时让 Claude Code 先读代码、梳理链路、罗列可能原因，模型能力的重要性便显著提升。

因此更建议先自问：这是执行型任务，还是判断型任务？ 执行型优先考虑效率，判断型再优先考虑能力。判断正确后，后续体验会更加稳定。

2. effort：任务明确就调低，任务复杂再调高

官方描述：Set the model effort level. Accepts low, medium, high, xhigh, or max; available levels depend on the model.
简单理解：设置模型推理强度，可选档位随模型不同而变化。

effort 解决的是"这次要不要让它深度思考"的问题。该设置易被误用，许多人的直觉是：既然更高 effort 代表更深思考，默认开高点至少不会亏。但事实并非如此。

例如你已明确问题根源：submitOrder 调用前漏了判空，只需补充保护分支和 toast 提示。此任务目标非常明确，Claude Code 需要的是执行而非推演。此时将 effort 拉满，只会让本可几分钟解决的小问题变得缓慢。

相反，若面对以下任务，则值得调高 effort：

  • 需求本身存在歧义，需先分析
  • 多个方案需比较取舍
  • 代码链路长，需先理解
  • 问题来源不明确，需排查原因
  • 需先梳理思路，再决定落地方式

对比示例：

帮我给表单加上邮箱校验和提交按钮禁用逻辑

这是实现题，较低 effort 通常足够。

帮我判断权限系统应放在网关层、服务层，还是仅前端做展示控制，并说明取舍

这是分析题，effort 应明显上调。

因此 effort 不宜长期固定于某档位。核心原则：任务明确就调低，任务复杂再调高。

3. status：确认当前配置状态

官方描述：Open the Settings interface (Status tab) showing version, model, account, and connectivity.
简单理解：打开设置中的状态页，查看版本、模型、账号、连接状态等信息。

status 并非高频命令，但适合在"感觉哪里不对劲"时使用。比如你为分析复杂问题切换了模型并调高 effort，任务完成后开始让 Claude Code 处理小修改，却发现响应变慢、回复明显比平时沉重。

此时很多人会下意识认为 Claude Code 状态不佳，但更常见的情况是：你仍停留在之前的配置中。

此时看一眼 status，就能避免许多靠感觉判断的问题。尤其在你切换过模型、修改过配置、调整过权限后，status 如同确认当前状态的快速入口。

只要感觉表现与预期不符，先别急着改 prompt，先看当前状态。

4. cost：建立成本意识

官方描述：Alias for /usage.
简单理解：cost 是 usage 的别名，用于查看会话成本、计划用量和活动统计。

cost 命令平时鲜少被主动查看，但只要你开始高频使用 Claude Code，它就值得偶尔关注。

比如感觉最近没让 Claude Code 做什么特别大的事，花费却不低。回头一看，问题可能不是某次任务特别昂贵，而是许多本应简单的任务一直在使用偏高配置运行。

单次看来不明显，累积起来就很显著。

cost 的意义不是让你盯着数字焦虑，而是帮你建立成本感。你会逐渐明白：哪些任务值得高配，哪些任务实则"高射炮打蚊子"。

当你频繁使用 Claude Code，或尝试更高模型、更高 effort 时，可定期查看 cost。目的不是少用，而是用得更明白。

5. stats：分析使用结构

官方描述：Alias for /usage. Opens on the Stats tab.
简单理解：stats 是 usage 的别名，会直接打开 Stats 标签页。

stats 可视作使用情况面板，其真正价值不在于孤立数字，而在于帮你看清：最近的使用究竟将资源消耗在何处。

打开后我会重点关注几个维度。

第一，看总成本。 这不是制造焦虑，而是建立大致成本感。尤其连续几天高频使用时，总成本能让你快速判断近期使用是否明显偏高。

第二，看 Token 使用情况。 这比单纯看成本更有参考价值，因为成本偏高往往源于上下文过长、会话沉重、反复携带大量历史信息。比如小修改本可几句话说明，但因在长会话中硬撑，每次请求都附带大量上下文，Token 自然被持续放大。

第三，看时间维度。 关注 API 实际耗时与真实使用时长差异。若真实使用时间长但有效调用时间不多，问题可能不在模型慢，而是中间频繁打断、等待确认、来回补充上下文。反之若 API 耗时本身很长，则需回看模型、effort、上下文长度是否过重。

第四，看代码改动量。 若花费不少但代码改动很少，需判断消耗是否主要在"理解、分析、试错"上。这不一定是坏事，但能提醒你：这类任务未来是否应先让 Claude Code 做计划排查，再进入修改阶段，避免边想边改、反复返工。

第五，看活动分布。 若统计可查看命令、会话或工具使用情况，可顺手审视使用结构。比如是否大量时间花在简单修改上却沿用高 effort，是否频繁进入长会话却很少 compact，是否在同类低风险操作上被权限确认反复打断。

举例：连续一周都觉得成本偏高，却说不出原因。看一眼 stats，可能发现最近大量使用集中在不复杂的小修改上，却几乎每次都沿用分析复杂问题时的配置；同时上下文越来越长，却很少 compact。此时问题就很清晰：使用方式不当。

因此 stats 不应只看总数，而应关注几个问题：

  • 成本是否明显高于预期
  • Token 是否被长上下文持续放大
  • 时间主要花在模型调用还是等待确认上
  • 代码改动量与消耗是否匹配
  • 使用结构是否集中在低价值、高消耗任务上

如此看待，stats 就不只是统计数字，而是一次使用方式的复盘。

ImageImage

本组命令使用方法论

这组命令可帮你建立简单判断流程：先判断任务类型，再决定模型和 effort，最后通过 status、cost、stats 回看用法是否跑偏。

最常见的误区有二。

一是默认高配，无论任务大小先将模型和 effort 拉满，结果更慢更贵，效果却未明显提升。

二是从不看反馈，持续使用却从不回头看状态、成本和统计，最终只能靠感觉判断"今天好不好用"“这个工具值不值”。

更稳健的做法是：

  • 执行型任务优先考虑快和准
  • 判断型任务再考虑更强模型和更高 effort
  • 使用一段时间后定期查看 cost 和 stats
  • 感觉不对劲时先看 status，不要全靠猜测

如此，Claude Code 的使用就不再是"凭感觉调配置"，而是逐渐转变为"按任务调档位"。

第三类：权限、安全与排障指令

若说前两类解决"怎么聊得顺"和"怎么配得对"，那这一类解决的是：为何它明明看起来能做，但就是没做成。

许多用户使用 Claude Code 时，最常见的不适感并非回答不够聪明，而是：

  • 想让它继续干活，却一路弹窗确认
  • 想调用命令或工具，结果权限不足
  • 明明已安装配置，却仍无法使用
  • 报错信息虽有，却不知从何查起

这类问题看似"Claude Code 不太行"，但通常并非模型本身问题，更常见原因是：权限未配好、环境未打通、执行边界未设定、排障入口未找准。

本类中最易混淆的是权限相关能力，可用模型理解：

能力 解决的问题 可简单理解为
permissions 哪些能做、哪些要问、哪些禁止 权限规则
auto mode 哪些调用可自动放行 自动审批
sandbox 即使执行，也只在边界内执行 执行隔离
fewer-permission-prompts 找出低风险高频确认，生成 allowlist 权限优化

理清这几层关系后，再看 doctor、debug、security-review 等排障与安全命令，思路会更加清晰。

本组值得重点关注的核心命令与能力包括：permissions、auto mode、doctor、debug、sandbox、security-review、fewer-permission-prompts。

Image

1. permissions：别只会点击确认

官方描述：Manage allow, ask, and deny rules for tool permissions.
简单理解：管理工具权限中的允许、询问和拒绝规则。

许多用户首次觉得 Claude Code"有点烦"，基本都是从权限确认开始的。读取文件确认一次，运行命令确认一次，修改内容可能还要确认。单次影响不大，但连续工作时这种反复确认会严重破坏节奏。

此时不应只想着"能不能少问点"，而应打开 permissions 关注三件事：

  • 哪些操作已被 allow
  • 哪些操作仍会 ask
  • 哪些操作已被 deny

这三个关键词至关重要。allow 表示 Claude Code 可直接执行，不再每次询问；ask 表示每次都需要确认；deny 表示直接禁止。真正需要管理的是这三类规则之间的边界，而非简单全部放开。

第一类：低风险、高频、重复操作，可考虑 allow。 例如：

  • 读取项目普通源码文件
  • 搜索关键词
  • 查看目录结构
  • 执行 npm run lint
  • 执行 npm run test
  • 执行 git status、git diff 等只读检查

这些操作本身风险低且频繁出现，若每次都弹窗，效率会被切得很碎。此类命令可考虑加入允许规则：

{  
  "permissions": {  
    "allow": [  
      "Bash(npm run lint)",  
      "Bash(npm run test *)",  
      "Bash(git status)",  
      "Bash(git diff *)"  
    ]  
  }  
}

第二类：有风险但非绝对禁止的操作，建议保留 ask。 例如：

  • 修改项目文件
  • 执行构建脚本
  • 安装依赖
  • 执行迁移脚本
  • 运行会改变本地状态的命令

这些操作并非不能让 Claude Code 执行，但最好不要无脑放行。如 npm install、pnpm install、数据库 migration、脚本修复等，一旦执行可能改变本地环境或项目状态，保留确认更稳妥。

第三类：明确不希望触碰的内容，应直接 deny。 例如：

  • .env、.env.*
  • secrets/**
  • 私钥、证书、凭据文件
  • 生产配置
  • 高风险命令如 git push、rm -rf、生产发布脚本

这类内容不要依赖"到时候看弹窗再判断"，最好一开始就写入 deny：

{  
  "permissions": {  
    "deny": [  
      "Read(./.env)",  
      "Read(./.env.*)",  
      "Read(./secrets/**)",  
      "Bash(git push *)",  
      "Bash(rm -rf *)"  
    ]  
  }  
}

此处有个易被忽视的关键点：deny 优先级最高。 即使某操作在其他地方被 allow，只要命中 deny 仍会被拦截。因此真正敏感内容应优先放入 deny，而非仅依赖 ask。

此外，permissions 不仅管理 Bash，还可管理文件读取、文件编辑、WebFetch、MCP 工具、Agent 等能力。你可限制读取敏感文件，也可限制某个 MCP server 下的工具，或禁止调用某些 subagent。

因此这部分真正值得关注的，不仅是"弹窗太多怎么办"，而是能否将操作分为三层：

  • 可默认放行的低风险动作
  • 需要人工确认的中风险动作
  • 必须直接禁止的高风险动作

若准备长期使用 Claude Code，应先梳理项目权限规则，尤其是 .env、密钥目录、生产脚本、发布命令、git push 等内容，优先 deny；lint、test、git status、git diff 等高频低风险操作，再考虑 allow。

补充：auto mode 并非替代权限规则

auto mode 易被误解为"有了它就不用管 permissions"，这种理解不准确。

auto mode 本质是权限模式，目标是在后台安全检查通过的情况下，减少人工确认、自动批准更多工具调用。它解决的是"是否每一步都要问你"的问题。

但 permissions 解决的是另一件事：你提前定义哪些可做、哪些要问、哪些绝对禁止。

较稳妥的理解是：auto mode 负责运行时判断，permissions 负责静态边界。

例如你开启 auto mode，希望它能连续完成修 bug 任务。但你仍应将 .env、密钥目录、生产脚本、git push 等高风险内容放入 deny。这样即使 auto mode 倾向于减少确认，真正敏感的边界也不会被轻易越过。

若只是个人小项目，auto mode 可明显减少确认疲劳；但若是公司项目、涉及敏感配置、生产脚本、客户数据，就不要只依赖 auto mode，仍需配好 permissions，尤其是 deny 规则。

2. doctor：先体检，再排查

官方描述：Diagnose and verify your Claude Code installation and settings.
简单理解：诊断并检查 Claude Code 的安装和配置状态。

doctor 适合解决"明明装好了，但就是不好使"的问题。

这类问题很常见：命令能启动，界面也正常，但到具体功能就不对。如某个工具调不起来、某项能力不生效，或行为与预期相差甚远。

此时最怕靠猜测：你猜是模型问题，我猜是网络问题，折腾半天，最后发现只是认证状态不对、依赖未装好或某个环境项未生效。

举例：刚装完 Claude Code，能正常对话，以为环境无问题。结果接入 MCP 或调用外部工具时总是失败。此时很多人会直接搜报错、改配置，甚至怀疑版本问题。更稳妥的顺序是先跑一遍 doctor，检查基础环境、认证、配置是否有明显异常。

doctor 不一定直接给出最终答案，但能先帮你排除一批低级高频问题。

遇到"刚配置完但不好使"的情况，先跑 doctor，再深入排查细枝末节。

3. debug：别反复试错，要定位问题层级

官方描述：Enable debug logging for the current session and troubleshoot issues by reading the session debug log.
简单理解：开启当前会话调试日志，通过日志排查问题。

有些问题 doctor 可快速发现，但也有些问题它只能告诉你有异常，无法直接指出根因。

此时该轮到 debug。

许多人排障时习惯：看到报错，改一点，再试；不行，再换个方向改一点。简单问题如此处理尚可，但链路一复杂，很容易变成碰运气。

比如你接了一个 MCP 服务，配置文件看起来没问题，但 Claude Code 调用时一直失败。此时若只是反复改配置，很容易越改越乱。更有效做法是打开 debug，先看清楚问题卡在哪一层：

  • 命令根本没执行到
  • 服务没连上
  • 认证没过
  • 请求发出了但返回失败
  • 还是 Claude Code 当前状态与你的理解不一致

能否看清这一层，决定了你是真正排障还是在试手气。

只要问题已非"一眼可见"，就不要持续猜测，尽早打开 debug 查看完整链路。

4. sandbox：在边界内自由执行

官方描述：Toggle sandbox mode. Available on supported platforms only.
简单理解：在支持的平台上开启或关闭沙箱模式。

sandbox 最易被误解为"限制"，但它真正解决的是：如何让 Claude Code 在边界明确的前提下连续执行命令。

它与 permissions、auto mode 不在同一层面。

permissions 决定动作按规则能否执行；auto mode 决定本次工具调用能否自动放行；sandbox 则决定即使执行了，也只能触碰哪些文件、目录和网络资源。

举例：你让 Claude Code 排查前端项目构建失败。它可能需要读取 package.json、查看 Vite 配置、执行 npm run build、执行 npm run test、查看错误日志，甚至生成临时构建产物。

若无 sandbox，每次执行 Bash 都可能触发确认，你会被打断多次。

若只有 auto mode，它可能自动判断这些操作较安全而减少确认，但这些命令仍在真实环境中执行。

若开启 sandbox 且这些命令能在沙箱边界内运行，Claude Code 就能更顺畅地完成这些只影响当前项目范围的操作。你无需每一步都点确认，同时它也无法随意写到项目外、读取敏感文件或访问不该访问的网络资源。

这就是 sandbox 的核心优势：减少低价值确认，同时保留执行边界。

它特别适合以下场景：

  • 让 Claude Code 跑测试、跑 lint、跑 build
  • 让它在项目目录内排查和验证
  • 让它执行会产生临时文件或构建产物的命令
  • 让它自动尝试修复问题，但不希望它越过项目边界
  • 团队希望减少权限确认，但又不想完全放开 Bash 执行权限

不过 sandbox 并非万能安全开关。

有些命令需访问项目外路径，如 ~/.kube、全局缓存目录、Docker、系统级工具，可能需要额外配置写入路径或明确排除某些命令。某些环境下 sandbox 需要平台支持和依赖，若环境不支持可能不会按预期生效。

只要你开始让 Claude Code 执行命令而非仅看代码写建议，就应认真了解 sandbox。其最大好处不是"更安全"四个字，而是让 Claude Code 在边界明确的前提下，真正进入连续工作状态。

5. security-review：主动安全审查

官方描述：Analyze pending changes on the current branch for security vulnerabilities.
简单理解：分析当前分支待提交改动中的安全风险。

security-review 直译为"安全审查"，作用也很直接：让 Claude Code 从安全角度检查当前代码或改动，帮你发现明显风险点。如权限控制是否遗漏、外部输入是否校验、敏感信息是否暴露、文件处理是否有边界问题、依赖或调用链路是否存在潜在风险。

因此它不是实现功能的命令，而是为功能"补一层安全检查"的命令。

很多时候功能能跑通，并不代表足够安全。尤其 Claude Code 参与修改后，更应有意识地补充安全视角。

如下场景非常适合使用：

  • 刚完成一轮较大代码改动
  • 引入了新依赖或新执行链路
  • 修改了权限、鉴权、数据处理相关逻辑
  • 实现了文件上传、回调接口、第三方集成
  • 准备将某段流程固化为长期自动化能力

举例：你让 Claude Code 补充文件上传逻辑，功能测试正常，文件也能上传。但有没有限制文件类型？有没有控制大小？有没有处理越权访问？有没有路径穿越风险？这些问题不会因功能跑通而自动消失。

此时补充一轮 security-review，比上线前临时排查要稳妥得多。

只要改动涉及权限、数据、文件、外部输入，就顺手做一次安全审查。它不一定每次都能发现问题，但能帮你多一个安全视角，避免只盯着"功能是否跑通"。

6. fewer-permission-prompts

官方描述：Scan your transcripts for common read-only Bash and MCP tool calls, then add a prioritized allowlist to project .claude/settings.json to reduce permission prompts.
简单理解：扫描历史使用记录，将常见低风险只读调用加入项目允许列表，减少权限确认。

fewer-permission-prompts 若只看名字，可能误以为是某种"少弹窗模式"。

但它实际做的事情更具体：扫描你的使用记录，找出那些频繁出现、风险较低的只读 Bash 命令和 MCP 工具调用，然后帮你将它们加入项目级 .claude/settings.json 的 allowlist。

也就是说，它不是让 Claude Code 以后什么都少问，而是帮你把"已反复确认、基本可信的低风险操作"沉淀为权限规则。

举例：假设你这几天一直在同一前端项目里让 Claude Code 执行：

  • git status
  • git diff
  • npm run lint
  • npm run test
  • 调用某个只读 MCP 工具查询任务状态
  • 调用某个只读 MCP 工具读取文档内容

这些动作每次都要确认。刚开始你会认真看，但连续点击十几次后，大概率已非审核风险，而是机械点击。

此时 fewer-permission-prompts 的价值就显现出来。

它会基于你的历史记录，分析哪些只读命令和 MCP 工具调用反复出现，然后给出一份更适合当前项目的 allowlist。生成后，这些低风险高频操作就能减少对你的打断。

因此 fewer-permission-prompts 更像一个"权限优化助手"。

前面说的 permissions 是你手动定规则；auto mode 是运行时尽量少打断；sandbox 是限制执行环境；而 fewer-permission-prompts 是根据历史使用记录，帮你找出哪些低风险动作值得沉淀为 allowlist。

它不是替你做安全决策，也不是让你跳过权限体系，而是帮你回答一个实际问题：过去一段时间里，哪些确认其实已经重复太多次，应该沉淀为规则？

此处需注意两点。

第一，它更适合优化只读、低风险、高频操作。如 git status、git diff、测试命令、lint 命令、只读 MCP 查询等。

第二，生成 allowlist 后最好人工过一遍。不要看到推荐规则就直接接受，尤其涉及外部 MCP 工具时，要确认该工具仅读取数据，还是可能触发写入、同步、发布、删除等动作。

当你发现自己在同一类低风险操作上反复点确认，就可以跑一次 fewer-permission-prompts。它最适合解决的不是"我要完全放开权限"，而是"我想把那些已反复确认的低风险动作自动化"。

如此理解就比较清晰：permissions 是你手动定规则，fewer-permission-prompts 是 Claude Code 根据你的历史记录，帮你找出哪些规则值得加入 allowlist。

ImageImage

本组命令使用方法论

本组命令其实在帮你回答三个问题：

  • Claude Code 现在是否有权限做这件事
  • 当前环境和执行链路是否正常
  • 交给它做，边界和风险是否可控

此处最常见误区是将所有异常归因于"模型不行"。

但更多时候问题很朴素：权限没配好、环境没打通、日志没往下看、边界没设清楚。

因此这类命令真正价值不是"出问题再补救"，而是让使用方式逐步稳健：

  • 经常被打断，先看 permissions
  • 刚安装或配置完不好使，先跑 doctor
  • 问题不是一眼能看懂，打开 debug
  • 涉及命令执行、文件修改、外部工具调用，考虑 sandbox
  • 涉及权限、数据、文件、外部输入，补一轮 security-review
  • 低风险确认太多，再用 fewer-permission-prompts 优化

如此，Claude Code 才更像在可控环境中稳定工作，而非一边使用一边猜测它下一步是否会掉链子。

第四类：扩展能力指令

前面几组命令更多解决"当前这次怎么用得更顺"，而 memory、skills、agents、hooks、mcp、schedule 这一组解决的是更长远的问题：如何将经验、规则、工具和流程沉淀下来，让 Claude Code 不只是临时写几段代码，而是逐渐演变为更贴合你工作方式的开发助手。

这组命令看似分散，但可分两层理解。

第一层，将团队经验沉淀为本地工具箱。

memory 负责记住长期事实，skills 负责沉淀可复用流程，agents 负责拆分专门角色，hooks 负责将固定动作挂载到关键节点。它们解决的是：Claude Code 如何更懂你的项目、更贴合团队习惯。

第二层，向外连接系统，将重复任务延伸为自动化流程。

mcp 负责连接外部工具和数据源，schedule 负责将重复任务变为 routine。它们解决的是：Claude Code 如何走出当前会话和目录，融入更完整的研发工作流。

如此看，这组命令其实在回答几个关键问题：

  • 哪些信息应该长期记忆
  • 哪些流程应沉淀为可复用能力
  • 哪些任务适合拆给专门 agent
  • 哪些动作可自动触发
  • 哪些外部系统可接入
  • 哪些事情可定时、重复、自动执行

这也是 Claude Code 真正拉开差距之处。

Image

1. memory：长期记忆的取舍

官方描述：Edit CLAUDE.md memory files, enable or disable auto-memory, and view auto-memory entries.
简单理解：编辑 CLAUDE.md 记忆文件，开启或关闭自动记忆，并查看自动记忆内容。

memory 解决的是"哪些信息值得长期保留"的问题。

许多初学者会将项目中所有规则、说明、约束、流程都塞进 CLAUDE.md。看起来很认真，但时间一长易变问题：记忆文件越来越臃肿，真正重要信息反而被淹没。

因此 memory 的关键不是"能不能记"，而是"什么值得记"。

我会将适合放入 memory 的内容大致分为：

  • 项目长期稳定的技术栈
  • 常用启动、测试、构建命令
  • 代码风格和目录约定
  • 团队明确要求遵守的规则
  • 项目中长期有效的注意事项

例如前端项目长期使用 React、Vite、Ant Design、Biome，测试用 Vitest，这些信息适合写入 memory。Claude Code 后续改动时就无需每次都询问技术栈和测试命令。

但以下内容不太适合长期记忆：

  • 某次临时排查结论
  • 一次性需求背景
  • 已废弃方案
  • 当前会话中的中间尝试
  • 仅对短期任务有效的约束

若这些内容都写入 memory，反而可能干扰后续判断。

举例：今天让 Claude Code 临时绕过某个接口，因后端尚未联调完成。此信息今天有用，但一周后可能过期。若被长期记住，后续 Claude Code 可能继续沿用此临时假设，导致新实现方向跑偏。

因此 memory 只放长期稳定、跨任务复用的信息，不要当成会话垃圾桶。

若开启 auto-memory，也要定期查看自动记住了什么。自动记忆不是坏事，但自动记住的内容不一定都适合长期保留。项目越大，这件事越重要。

2. skills：将重复流程定制为专属命令

官方描述：List available skills. Press t to sort by token count.
简单理解：查看当前可用 skills，也可按 token 占用排序。

skills 解决的是"重复流程如何沉淀"的问题。

许多用户将 Claude Code 用成这样：每次做代码审查都复制一大段审查要求，每次做故障复盘都复制一套模板，每次做接口联调都重新描述检查清单。这样虽能用，但很累且容易不一致。更好方式是将这些反复出现的流程沉淀为 skill。

你可以创建这些 skill：

  • code-review：按团队规范审查代码
  • api-review：检查 OpenAPI、字段命名、错误码、权限点是否一致
  • incident-review：按固定模板整理故障复盘
  • release-check：上线前检查分支、配置、测试、风险项
  • spec-check：检查需求文档、接口契约、验收标准是否一致

这样后续使用时，无需每次重写 prompt，直接调用对应 skill 即可。

此处有个关键区别：CLAUDE.md 更适合放事实和规则，skills 更适合放流程和方法。

例如"项目使用 pnpm"是事实，适合放 memory；“每次发布前按 10 步检查"是流程，更适合做成 skill。

另一好处是，skill 正文并非每次会话一开始就全部塞入上下文，而是在需要时才加载。对于很长的检查清单、SOP、方法论文档，这点非常重要。

举例：你有一套内部代码审查规则，包含命名规范、异常处理、权限校验、日志规范、测试要求。若全部塞进 CLAUDE.md，每次会话都带着会很沉重；但若做成 code-review skill，只在真正审查代码时才加载，成本和干扰都会小很多。

只要发现自己连续三次以上复制同一套提示词或检查清单，就应考虑将其做成 skill。

3. agents：将任务委派给专业角色

官方描述：Manage agent configurations.
简单理解：管理 subagent 配置。

agents 解决的是"复杂任务如何分工"的问题。

若说 skill 更像一套可复用流程，那 agent 更像一个专门负责某类任务的角色。

例如你可以创建这些 agent：

  • code-reviewer：专门审查代码质量和风险
  • test-writer：专门补充测试
  • debugger：专门排查错误和失败用例
  • architecture-reviewer：专门看架构、边界和依赖关系
  • docs-writer：专门整理文档和说明

这类 agent 的价值不在名字好听，而在于它可以拥有独立的提示词、工具权限、模型、记忆和工作边界。

举例：你让主会话里的 Claude Code 同时完成"读代码、改实现、补测试、审风险、写说明”，它虽能做到，但上下文会很重，关注点也易频繁切换。

若任务复杂，可让主会话负责协调，将部分工作交给专门 agent。如让 debugger 先排查失败原因，test-writer 补测试，code-reviewer 最后审查改动。此时主会话无需事事亲为，更像协调者。

但 agent 并非越多越好。

若只是改按钮文案、补简单判断、修明确小 bug，没必要专门拉 agent。agent 更适合：

  • 任务需要明显分工
  • 子任务相对独立
  • 需要不同视角检查同一批代码
  • 希望某类能力长期稳定复用
  • 希望给不同角色配置不同工具和权限

不要急于创建大量 agent。可从最常用的两个开始：一个 code-reviewer，一个 debugger。前者负责质量把关，后者负责问题排查。用顺后再扩展到测试、文档、架构等方向。

4. hooks：将重复动作自动挂载

官方描述：View hook configurations for tool events.
简单理解：查看工具事件相关的 hook 配置。

hooks 解决的是"哪些动作不应每次都靠人提醒"的问题。

许多团队使用 AI 写代码时，最大问题不是 Claude Code 不会写，而是写完后有些固定动作总容易遗漏。

例如：

  • 改完代码忘了格式化
  • 改完接口忘了跑类型检查
  • 改完关键文件忘了跑测试
  • 执行危险命令前没有二次提醒
  • 修改配置后未记录日志或通知

若每次都靠你在 prompt 里提醒，效率很低，因为它们本质上不是"智能判断"，而是"固定流程"。

这正是 hooks 的价值。

hooks 可在 Claude Code 的工具事件前后触发命令。可理解为：当 Claude Code 准备做某事或刚做完某事时，自动执行你预配置的脚本。

举例：可配置 hook，只要 Claude Code 修改前端代码，就自动跑 formatter 或 lint；若它准备执行高风险 Bash 命令，就先拦截或给出提示；若它修改关键目录，就自动跑对应测试。

这类事情不一定需要 Claude Code 每次都"想起来"，而应交给 hooks 固化。

注意：hooks 与 skills 不同。skills 是给 Claude Code 的一套工作方法，偏"怎么做"；hooks 是工具事件触发的自动动作，偏"何时自动执行"。

例如：

  • “代码审查要检查哪些内容"适合做 skill
  • “每次修改后自动跑 lint"适合做 hook

凡是在 prompt 里反复提醒 Claude Code 做的固定动作，都可思考是否更适合放进 hooks。尤其是格式化、测试、校验、通知、危险命令拦截等，非常适合自动化。

5. mcp

官方描述：Manage MCP server connections and OAuth authentication.
简单理解：管理 MCP 服务连接和 OAuth 认证。

mcp 解决的是"Claude Code 如何连接外部系统和工具"的问题。

我现在更愿意用一句话概括其定位：CLI 是工具本身的操作入口，skill 是 Claude Code 的使用说明书，MCP 是 AI 客户端之间的标准连接层。

现在评估外部工具接入，不应一上来就默认选 MCP。许多工具已有成熟官方 CLI，且配套对应 skill。如 Playwright 可通过 CLI 跑测试、生成用例、调试和查看报告；飞书也可通过 lark-cli 完成文档、多维表、消息等操作。

这种情况下，优先考虑 CLI + 配套 skill 往往更合适：CLI 负责执行，skill 负责流程说明。这样既贴近工具本身用法，也更容易控制输入输出。

如 Playwright 场景，若只是跑 E2E 测试、调试失败用例、查看测试报告，直接走 Playwright CLI 就很自然。配套 skill 负责告诉 Claude Code 测试怎么跑、报告怎么看、失败后如何处理。若团队还有自己的约定，如默认浏览器、测试目录、失败重试策略、报告输出格式，再基于现有 skill 做二次封装即可。

飞书场景也类似。若只是读取文档、更新多维表、拼接字段后写回，用 lark-cli 这类官方或团队维护的 CLI 会更轻。真正需要封装的通常不是"怎么调用飞书”，而是你们自己的业务流程，如更新前先 dry-run、输出必须是 JSON、批量更新前先校验记录、失败后保留原始响应等。

这也是 CLI + skill 的优势：CLI 负责把事情做了，skill 负责把事情按正确姿势做。

此外，在许多命令式、可脚本化的任务中，CLI + skill 通常也更省上下文。因为 Claude Code 只需知道命令怎么用、参数怎么传、输出怎么读；skill 正文也只有在使用时才加载。而 MCP 往往需要暴露工具列表、参数 schema、工具说明和返回结构，当工具多、说明长、返回内容大时，Token 消耗会更明显。

当然，这并非说 MCP 没有价值。

MCP 更适合以下场景：

  • 没有好用的官方 CLI，但有 API 可封装
  • 需要跨 Claude Code、Claude Desktop 或其他 AI 客户端复用
  • 希望将一组工具以统一 schema 暴露给模型
  • 需要统一 OAuth、权限边界和工具描述
  • 工具能力复杂，不适合每次都靠 shell 拼参数
  • 需要团队级统一接入和治理

因此我的简单判断标准是：

  • 一次性、命令式、可脚本化的任务，优先 CLI + skill；
  • 已有配套 skill 的工具，先用现成能力，再按团队流程二次封装；
  • 需要标准化、长期化、跨客户端复用的能力，再考虑 MCP。

6. schedule：将重复任务变成例行程序

官方描述：Create, update, list, or run routines. Claude walks you through the setup conversationally.
简单理解：创建、更新、查看或运行 routine，通过对话方式完成配置。

schedule 解决的是"哪些事不需要你每次手动启动"的问题。

它对应 routines，可理解为一类定时或可重复运行的 Claude Code 任务。

这类能力与 loop 有些相似，但使用场景不完全相同。

loop 更像在当前会话里反复跑某个提示，如每 5 分钟检查部署结果；schedule 更像是将某个任务变成可管理、可重复运行的 routine，如每天早上检查仓库状态，或每周生成项目摘要。

举几个可能例子：

  • 每天早上汇总当前仓库未合并 PR
  • 每天下班前检查 CI 失败情况
  • 每周生成一次项目进展摘要
  • 定期检查依赖升级风险
  • 定期扫描文档和代码是否存在明显不一致
  • 定期整理某项目最近变更

schedule 的价值不是让 Claude Code"自动写代码”，而是让那些原本需手动发起的固定检查，变成可持续运行的流程。

例如你负责长期项目，每周都要看 PR、CI、近期改动和潜在风险。以前你可能每周手动打开多个系统查看，再让 Claude Code 总结；若这件事非常固定，可考虑做成 routine，让它按固定节奏运行。

但这类能力也需谨慎。

一旦任务变成定时运行，就不再只是"你当前盯着的一次会话"。若 routine 会访问仓库、外部系统、敏感信息，就更应提前配好权限、MCP、sandbox 和相关边界。

我的建议是：schedule 适合低风险、重复性强、输出以总结提醒为主的任务。不要一上来就让它定时做高风险写操作。先从读、查、汇总、提醒开始，会更稳妥。

本组命令使用方法论

这组命令帮你将 Claude Code 从"临时问答工具"转变为"可复用工作流工具"。

可简单理解为：

  • memory 负责记住长期事实
  • skills 负责沉淀可复用流程
  • agents 负责拆分专门角色
  • hooks 负责自动触发固定动作
  • mcp 负责接入外部工具和数据源
  • schedule 负责将重复任务变成 routine

其中最容易混淆的是 memory 和 skills。判断标准很简单：

  • 若是长期事实，放 memory
  • 若是一套操作流程，做成 skill
  • 若需专门角色长期处理某类问题，做 agent
  • 若是固定时机自动执行的动作，配 hook
  • 若需连接外部系统，走 MCP
  • 若需定期重复执行，考虑 schedule

这组命令不一定是新手第一天就要全部掌握的，但它们决定了你能否将 Claude Code 真正用深。

如果只是临时问问题，前面几组命令足够；但若希望 Claude Code 长期适配你的项目、团队、流程，这组能力迟早绕不开。

第五类：高阶效率与工作流指令

前面几组更多解决 Claude Code 的基础使用体验。

batch、simplify、loop、autofix-pr、team-onboarding、powerup、release-notes 这些命令平时不一定每天使用，但一旦遇到合适场景，效率提升会非常明显。

它们的共同点是：不再只是执行小动作，而是更接近完整工作流。

如批量改造代码、循环检查状态、自动修复 PR、生成团队上手指南、学习新功能，这些都不是"问一句答一句"的传统交互，而是让 Claude Code 承担更长链路的任务。

这组命令可视为 Claude Code 的"效率放大器"。

Image

1. batch：大规模代码改造的利器

官方描述：Orchestrate large-scale changes across a codebase in parallel.
简单理解：将大规模代码改造拆分为多个独立任务，并行推进。

batch 不是用来修小 bug 的。

它更适合范围大、重复性强、可拆分为多个独立子任务的代码改造。

例如：

  • 将某目录下旧组件迁移到新组件体系
  • 批量替换过时 API
  • 将多个模块从旧状态管理方案迁移到新方案
  • 批量调整一类接口调用方式
  • 在多个相对独立模块中补充同类能力

这类任务若只靠单会话慢慢改，易出现两个问题：上下文越来越重，任务边界越来越乱。

batch 的思路更像是：先研究代码库，再将任务拆分为多个独立单元，然后并行交给后台 agent 处理。每个 agent 在自己的 git worktree 中实现、测试，最后提交 PR。

举例：假设你要将 src/legacy 下的一批旧页面逐步迁移到新组件体系。此事不适合一次性塞给 Claude Code 让它在单会话里全改完，因为文件多、范围大、上下文易乱。

但若这些页面相对独立，就比较适合 batch：先让它分析哪些页面可拆分迁移，再生成拆分计划，确认后并行推进。

但 batch 也非越用越好。

若任务本身没想明白，或多个模块强耦合，直接批量拆分反而制造更多返工。

只有当任务满足三个条件时才考虑 batch：

  • 范围足够大
  • 子任务相对独立
  • 验收标准清晰

如果只是局部修改，没必要上 batch。

2. simplify：功能完成后做质量收口

官方描述：Review your recently changed files for code reuse, quality, and efficiency issues, then fix them.
简单理解：检查最近修改的文件，发现复用、质量和效率问题，并尝试修复。

simplify 很适合放在一轮代码修改后使用。

很多时候 Claude Code 帮你实现了功能，但代码未必足够干净。可能有重复逻辑、临时实现、能跑但不简洁，或某些地方可复用却未复用。

此时 simplify 的价值就体现出来。

它不是让 Claude Code 重新实现功能，而是对最近改动的文件做一轮质量检查，并尝试修复明显问题。

举例：你让 Claude Code 连续修改表单页、接口封装和状态管理模块，功能已跑通。但回头看代码，会发现有些校验逻辑写了两遍，有些 loading 状态处理较散，有些错误提示未统一。

此时可用 simplify 让它重点检查代码复用、可读性、效率和重复逻辑。

若有特别关注方向，也可加上 focus，如：

/simplify 重点检查重复的表单校验逻辑

或：

/simplify 重点检查内存使用和性能问题

simplify 很适合放在"功能做完、提交之前"这个阶段。它解决的不是从 0 到 1，而是从"能跑"到"更干净"。

3. loop：让 Claude Code 持续监控

官方描述：Run a prompt repeatedly while the session stays open.
简单理解：在会话保持打开时，重复执行某个提示。

loop 解决的是"我不想一直手动问同一件事"的问题。

有些任务非一次性完成，而需持续观察。

例如：

  • 等待部署是否完成
  • 等待 CI 是否通过
  • 每隔一段时间检查日志是否还有错误
  • 持续观察任务队列是否清空
  • 反复检查页面或接口是否恢复正常

若每次都手动问 Claude Code，一方面麻烦，另一方面容易忘。

loop 更适合这类场景。

例如：

/loop 5m 检查部署是否已经完成

这种用法很直观：每 5 分钟检查一次部署是否结束。

若不传 interval，Claude Code 也可自己控制节奏；若不传 prompt，则可跑自主维护检查，或使用 .claude/loop.md 里的默认提示。

但 loop 也需注意边界。

它适合持续观察、持续检查，不适合无边界地自动改代码。尤其涉及生产环境、数据变更、外部系统操作时，不要让它长时间无监督执行高风险动作。

loop 优先用于"看"和"查"，谨慎用于"改"。检查部署、观察日志、确认 CI 状态都很适合；自动反复修改和发布则需非常谨慎。

4. autofix-pr：自动处理 PR 反馈

官方描述：Spawn a Claude Code on the web session that watches the current branch’s PR and pushes fixes when CI fails or reviewers leave comments.
简单理解：启动 Claude Code Web 会话，监听当前分支 PR，在 CI 失败或评审有评论时自动推送修复。

autofix-pr 很有代表性，因为它已非简单本地命令，而是将 Claude Code 接入 PR 工作流。

它适合解决这类问题：你已提交 PR，但后面还有一堆零碎反馈需处理。

例如：

  • CI 挂了，需修 lint 或类型错误
  • Reviewer 留了几个小修改意见
  • 测试失败，需根据失败日志修复
  • 代码风格不一致，需补格式化或调整命名

以前这些事都要你自己反复看 PR、看 CI、改代码、push、再等结果。

autofix-pr 的价值在于，可启动远程 Claude Code 会话，监听当前分支对应 PR。当 CI 失败或 reviewer 留评论时，自动尝试修复并 push。

举例：你提了一个 PR，核心实现已没问题，但 CI 里挂了几个类型错误，reviewer 也提了两个命名建议。此时可用 autofix-pr 处理这些明确、局部、可验证的问题，无需一直自己盯着。

但该命令有前提。

它需要 gh CLI，也需能访问 Claude Code on the web。且它默认根据当前 checkout 分支识别 PR；若要处理其他 PR，需先切到对应分支。

autofix-pr 适合处理明确反馈和 CI 失败，不适合自动处理大范围设计争议。lint、类型错误、测试失败、review 小建议都适合；涉及架构方向、产品取舍、复杂重构，应人工先判断。

5. team-onboarding：将个人经验转化为团队指南

官方描述：Generate a team onboarding guide from your Claude Code usage history.
简单理解：根据你的 Claude Code 使用历史生成团队上手指南。

team-onboarding 易被忽视却很有意思。

它不是帮你写代码，而是帮你将过去一段时间如何使用 Claude Code 的经验整理出来。

例如它会根据你最近的使用历史、命令、MCP server 等信息，生成一份 markdown 指南，方便团队其他成员快速上手。

该命令适合：

  • 团队准备统一推广 Claude Code
  • 已有人试用一段时间，希望将经验同步给他人
  • 项目已形成固定用法但尚未写成文档
  • 新成员加入项目，需快速了解如何用 Claude Code 配合当前仓库

举例：你已在项目里用 Claude Code 跑通很多流程：怎么跑测试、怎么做代码审查、怎么调用内部 CLI、哪些权限可放开、哪些目录不能碰。其他同事若从零摸索会很慢。

此时用 team-onboarding 生成初稿，再人工补充删改，比从零写团队指南快得多。

但它生成的是"基于历史使用的初稿"，非最终制度。可将其作为团队 Claude Code 使用规范的起点，但不要不审直接发给团队，尤其涉及权限、MCP、内部工具、敏感目录时，要人工过一遍。

6. powerup：快速掌握新功能

官方描述：Discover Claude Code features through quick interactive lessons with animated demos.
简单理解：通过带动画演示的交互式小课程了解 Claude Code 功能。

powerup 很适合解决现实问题：Claude Code 更新太快，很多新功能根本来不及看文档。

它不是生产力命令，而是学习命令。

例如你隔段时间没关注 Claude Code，回来发现多了新权限模式、新 Web 能力、新 routines、新 review 能力。此时直接翻 changelog 当然可以，但不一定有体感。

powerup 的作用就是通过较短的交互式课程，让你快速理解某些功能如何使用。

若觉得自己只会用最基础命令，可先跑一遍 powerup。它不一定解决当前任务，但能帮你发现原来不了解的能力。

尤其 Claude Code 最近的更新节奏，定期用它补课，比一直靠别人转发新功能截图靠谱。

7. release-notes：主动跟踪版本更新

官方描述：View the changelog in an interactive version picker. Select a specific version to see its release notes, or choose to show all versions.
简单理解：通过交互式版本选择器查看 changelog 和 release notes。

release-notes 特别适合放在本文结尾前，因为本文起点就是：Claude Code 更新太快，很多人不知道新命令怎么用。

release-notes 解决的就是这个问题：不要只等别人总结，也不要只靠别人转发的截图，自己可直接在 Claude Code 里查看版本更新。

它适合：

  • 隔段时间没用 Claude Code，想看最近更新了什么
  • 看到别人提到新命令，但不确定从哪个版本开始有
  • 某个命令行为变了，想回头看 release notes
  • 想确认最近是否有和权限、MCP、skills、routines 相关的更新

举例：若突然发现某个命令不见了，或行为和之前不一样，与其第一时间怀疑自己配置错了，不如先看一眼 release-notes。Claude Code 更新快，有些命令会新增、改名、移除，release notes 反而是最直接的确认入口。

可将 release-notes 视为 Claude Code 的"版本说明入口"。尤其当你看到新功能但自己本地没有，或命令行为与他人不同时，先查版本，再判断是环境、套餐、平台或功能开关的问题。

本组命令使用方法论

将这组命令放在一起，它们更像是处理"长链路任务"的指令：

  • batch 适合大规模、可拆分的代码改造
  • simplify 适合功能完成后的代码收口
  • loop 适合持续观察状态
  • autofix-pr 适合处理 PR 后续反馈
  • team-onboarding 适合将个人经验整理为团队指南
  • powerup 适合快速学习新能力
  • release-notes 适合跟踪版本变化

这类命令不一定是每天最高频的，但在特定节点能发挥重要作用。

我的判断是：

  • 做大规模改造，先想 batch
  • 改完代码想收质量，试试 simplify
  • 需要持续观察状态，用 loop
  • PR 后续反馈明确，用 autofix-pr
  • 团队要推广 Claude Code，用 team-onboarding
  • 自己跟不上更新，用 powerup 和 release-notes

这组命令价值不在日常小任务里多打一堆命令，而是在遇到更长、更重、更重复的任务时，让你知道 Claude Code 已提供更合适的入口。

精简版：应该从哪些命令开始

前面讲了这么多命令，可能有人觉得：看起来都有用，但一下子记不住。

这很正常。Claude Code 的命令无需一次性全学完，更合理的方式是按使用阶段选择。

刚开始用，先打顺基础体验；高频使用后，再关注权限、成本、上下文和排障；若要推广到团队，再看 skills、hooks、agents、MCP、schedule 等偏工作流的能力。

1. 新手先掌握这 6 个

若刚开始用 Claude Code，可先从这 6 个命令开始：

  • help
  • clear
  • compact
  • model
  • effort
  • permissions

help 用来了解当前环境到底有哪些命令。这很重要，因为 Claude Code 的命令会受版本、平台、套餐、配置影响，不同人看到的命令可能不完全一样。

clear 和 compact 负责处理上下文，前者重开后者瘦身。新手最易犯的错就是一乱就 clear，但很多时候更适合先 compact。

model 和 effort 负责控制任务档位。不要所有任务都默认高配，执行题和判断题应区别对待。

permissions 负责减少使用摩擦。只要开始让 Claude Code 读文件、跑命令、改代码，就一定会遇到权限确认。早点把 allow、ask、deny 的关系搞明白，后面会顺很多。

新手阶段不建议一上来研究所有高级能力。先用顺这几个，日常体验提升会非常明显。

2. 高频用户重点看这些

若每天都在用 Claude Code，就不能只停留在"会问问题"层面。

此时更应关注：

  • context
  • stats
  • cost
  • doctor
  • debug
  • sandbox
  • fewer-permission-prompts

context 帮你判断当前会话是否已太重。

stats 和 cost 帮你看使用结构和成本，不要一直凭感觉判断"今天是不是变贵了"“是不是变慢了”。

doctor 和 debug 用来排查环境和调用问题。尤其接 MCP、CLI、外部工具后，不要一出错就怀疑模型，先看是否环境、认证、配置、权限出了问题。

sandbox 和 fewer-permission-prompts 更偏向效率与安全平衡。前者让 Claude Code 在边界内连续工作，后者帮你将低风险、高频确认沉淀为 allowlist。

这个阶段重点不是"多知道几个命令"，而是让 Claude Code 更稳定、更省心、更可控。

3. 团队使用重点看这些

若已非个人使用，而是希望将 Claude Code 推广到团队，重点就要变了。

个人使用时，许多事可靠习惯解决；团队使用时，必须靠机制解决。

此时最值得关注：

  • memory
  • skills
  • agents
  • hooks
  • mcp
  • schedule
  • team-onboarding

memory 负责沉淀长期事实，如技术栈、目录结构、启动命令、测试命令、项目约定。

skills 负责沉淀团队流程，如代码审查、接口检查、发布前检查、故障复盘、需求验收。

agents 负责将复杂任务拆给更专门的角色，如 code-reviewer、debugger、test-writer。

hooks 负责将固定动作自动化，如改完代码自动 lint，执行危险命令前拦截，修改关键目录后自动测试。

mcp 和 CLI + skill 的关系前面已讲。团队场景中，更重要的不是"接得多"，而是判断哪些能力应通过 CLI + skill 落地，哪些值得做成 MCP 这类长期连接层。

schedule 适合将低风险、重复性的检查任务变成 routine，如定期检查 CI、汇总 PR、扫描文档和代码是否不一致。

team-onboarding 适合团队推广初期使用。它可根据已有使用历史生成上手指南，再由人工修订成团队规范。

团队阶段真正要解决的，不是每个人会不会用某个命令，而是能否将好的用法固化下来，让大家用得一致、可控、可复用。

4. 我的个人优先级

若按优先级排序，我会这样分：

第一优先级：compact、permissions、model、effort

这几个直接影响日常体验。上下文管不好，权限理不顺，模型和 effort 乱用，Claude Code 很容易又慢又贵，还不好控。

第二优先级：context、stats、cost、doctor、debug

这几个让你从"凭感觉使用"变成"有反馈地使用"。会话是否太重、成本是否异常、环境是否有问题，都能更快看出来。

第三优先级：skills、hooks、agents、sandbox

这几个决定你能否将 Claude Code 用深。一个人临时用可能没那么强烈，但只要长期用、团队用、稳定用，这些能力迟早要看。

第四优先级：mcp、schedule、batch、autofix-pr

这几个更看场景。用得对会很强，用得早了反而可能增加复杂度。如 MCP 不是所有工具都要接，schedule 也不适合一上来就跑高风险写操作，batch 更适合大规模、可拆分的任务。

不要看到新命令就急着都学一遍。更好方式是：先解决日常摩擦，再解决稳定性，再沉淀流程，最后再上更重的自动化。

5. 场景速查表

最后放一张速查表，方便在具体场景中快速找到入口。

场景 优先命令
会话聊乱了 context、compact、clear
想继续上次任务 resume
想回退到之前状态 rewind
想阶段性整理会话 recap
觉得 Claude Code 又慢又贵 model、effort、cost、stats
想确认当前配置状态 status
权限弹窗太多 permissions、fewer-permission-prompts
想减少确认但不想放开边界 auto mode、sandbox、permissions
刚安装或配置完不好使 doctor
工具调用失败不知卡在哪 debug
改动涉及权限、数据、文件、外部输入 security-review
想沉淀项目长期规则 memory
想沉淀重复流程 skills
想把任务拆给专门角色 agents
想把固定动作自动化 hooks
想接外部工具和系统 CLI + skill，必要时 mcp
想定期跑低风险检查 schedule
想批量推进大规模改造 batch
改完代码想做质量收口 simplify
想持续观察部署、CI、日志状态 loop
PR 后续反馈明确 autofix-pr
团队要推广 Claude Code team-onboarding
想快速补课新功能 powerup
想看最近版本更新 release-notes

此表不是让你一次性全记住，而是帮助在具体场景中快速定位命令。

总结

许多人学习 Claude Code，第一反应是研究 prompt。

这固然重要。你问得清不清楚、任务描述准不准确，都会直接影响结果。但用久了会发现，只会写 prompt 还不够。

Claude Code 是否好用，很大程度上取决于你是否将它视为完整工具来管理：上下文怎么收、模型和 effort 怎么选、权限边界怎么定、哪些流程要沉淀、哪些工具该接进来、哪些重复任务可以自动化。

因此，Claude Code 的命令不是拿来背的。更重要的是知道：什么时候该用哪个，为什么要用它，用了之后能解决什么问题。

这也是本文想表达的核心：

Claude Code 最值得学的，不只是怎么问，还有怎么用。

如果你现在还只会打开终端直接提需求，最多用一下 help，也没关系。先从几个高频命令开始，把上下文、权限、模型和成本理顺，就已经能明显改善体验。

至于 skills、hooks、agents、schedule、MCP 这些更重的能力，可以等你真有重复流程、团队协作和外部工具接入需求时，再一步步往上加。

不要为了"高级"而高级。先解决真实问题，再选择合适命令。这才是 Claude Code 更稳定、也更长久的用法。