Claude 30+高频好用核心指令
Claude 指令是什么？
很多人刚开始用 Claude 时，对“Claude 指令”的理解其实比较简单：输入一个斜杠，加一个单词，执行一个动作。
💡
有些属于内置命令，用来处理会话、上下文、模型、权限这类基础能力；
有些虽然也是命令形式，但背后对应的其实是 skill；
还有一些命令，真正连接的是 hooks、agents、MCP、schedule 这类更大的扩展机制；
基础控制命令
这一类主要解决的是 Claude Code 自己怎么用的问题。
比如清理会话、压缩上下文、切换模型、调整推理强度、查看状态、管理权限等。
这类命令最基础，也最常用，很多时候，Claude Code 用起来顺不顺手，差别往往就在这些基础命令的用法有没有跑偏。
场景化能力命令
这一类命令已经不只是“执行一个动作”了，而是更像把某类任务封装成了一个入口。
比如调试、批量处理、循环执行、PR 修复这类命令，背后其实更接近一段完整流程，而不是单点操作。
这类命令也可以理解成：你看到的是一个命令，实际调用的可能是一整套预设好的能力。
扩展能力相关的命令
这一类指令 是Claude Code 通向扩展能力的一组入口。比如 memory、skills、agents、hooks、MCP、schedule 。
💪
它们和前面两类最大的区别是：
前两类更多是在当前会话里更高效地做事，而这一类已经开始涉及怎么把能力沉淀下来、怎么接外部工具、怎么把重复动作变成长期可复用的流程了。
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 更适合下面这几种情况：
•
当前任务已经彻底结束了，准备开始一个新话题
•
会话已经明显跑偏，继续救的价值不大
•
上下文里混进了太多无关信息，继续聊只会越来越乱
2. compact：压缩上下文
官方描述：Free up context by summarizing the conversation so far.
简单理解：通过总结当前会话内容，释放上下文空间。
如果说 clear 是彻底重开，那 compact 更像是“保留主线，清理包袱”。
💪
长时间使用 Claude Code 时，最常见的问题不是完全聊崩，而是上下文越来越长，里面混着旧尝试、废弃思路、重复描述、已解决的问题和已失效的指令。这个时候，真正需要的通常不是清空，而是把当前任务压缩成一个更干净、更聚焦的状态继续往下走。
尤其是在下面这些场景里，优先考虑 compact 通常会更合适：
•
任务还没做完，但对话已经很长了
•
中间试了很多方案，想保留结论、丢掉过程噪音
•
需要继续当前任务，但明显感觉上下文开始变重
你可以把它理解成一次“会话瘦身”：主线任务还在，必要信息还在，但那些已经不重要、或者会干扰后续判断的内容会被尽量压缩掉。所以对大多数人来说，compact 应该是比 clear 更高频的命令。
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。它能帮你少一点拍脑袋。尤其是任务比较长、信息量比较大时，先看一眼上下文状态，再决定怎么处理，通常会更稳。
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 它更像是把会话或代码状态往前拨回去一点，让你从更合适的位置重新继续，而不是全盘推倒重来。
6. recap：先收个口，再继续
官方描述：Generate a one-line summary of the current session on demand.
简单理解：按需生成当前会话的一句话摘要。
💪
recap 的作用很适合放在长任务的阶段节点上。
比如一个任务已经聊了很久，这时候你自己也开始有点乱，不确定当前已经做到哪里、结论是什么、还剩什么没做。这个时候先来一个 recap，把当前进度和关键点收一下，再决定下一步怎么继续，通常会清爽很多。
它的价值不在于替代思考，而在于帮你把当前会话的状态整理成更容易继续推进的样子。
这一组命令到底该怎么用
如果把这一组命令放到一起看，其实可以把它们理解成一套“会话整理工具”：
clear 负责重开
compact 负责瘦身
context 负责查看状态
resume 负责续上次的任务
rewind 负责往前回退
recap 负责阶段性收口
第二类：模型、推理强度与成本相关命令
这一组解决的是：这件事，到底该让 Claude Code 用什么状态来做。很多人刚开始用 Claude Code 时，容易形成一个习惯：不分任务，统一上高配。小问题也想让它多想一会儿，简单修改也直接拉满，结果往往是成本上去了、响应变慢了，体感却未必更好。问题在于不是所有任务都值得高配。
这一组里比较值得关注的，主要有这几个：model、effort、status、cost、stats。
1. model：先判断
官方描述：Select or change the AI model.
简单理解：选择或切换当前使用的 AI 模型。
💪
model 解决的是“让谁来做这件事”的问题。这件事听起来像配置项，但实际非常关键。因为不同任务对模型能力的要求，本来就不是一个级别。
如果你只是让 Claude Code 做一些边界很清楚的事情，比如：
•
改一段已经很明确的代码
•
修一个已经定位清楚的小 bug
使用之前可以先问自己一个问题：这个任务是执行型任务，还是判断型任务？
执行型任务，优先考虑效率；判断型任务，再优先考虑能力。这个判断一旦做对，后面的体验会稳定很多。
2. effort：任务明确就收低，任务复杂再往上拨
官方描述：Set the model effort level. Accepts low, medium, high, xhigh, or max; available levels depend on the model.
简单理解：设置模型的推理强度，可选档位会随模型不同而变化。
💪
effort 解决的是“这次要不要让它多想一点”的问题。任务的目标已经非常明确，Claude Code 需要的是执行，不是推演。如果你面对的是这类任务，得把 effort 往上调：
effort 最好不要长期固定在某个档位。我的理解很简单：任务明确，就收低；任务复杂，再往上拨。
3. status：确认当前状态
官方描述：Open the Settings interface (Status tab) showing version, model, account, and connectivity.
简单理解：打开设置里的状态页，查看版本、模型、账号、连接状态等信息。
status 不是很有存在感的命令，但它很适合在“感觉哪里不对”的时候用。
💪
只要你觉得它今天表现和我预期不一样，先别急着改 prompt，先看当前状态。
4. cost：成本意识
官方描述：Alias for /usage.
简单理解：cost 是 usage 的别名，用来查看会话成本、计划用量和活动统计。
cost 这个命令，很多人平时不太会主动看。
比如你觉得最近也没让 Claude Code 做什么特别大的事情，但花费就是不低。回头一看，问题可能不是某一次任务特别贵，而是很多本来很小的任务，也一直在用偏重的模型和 effort 去跑。
💪
cost 的意义不是让你盯着数字焦虑，而是帮你建立成本感。你会慢慢知道：哪些任务值得用更高配置，哪些任务其实是在用“高射炮打蚊子”。
当你开始频繁使用 Claude Code，或者尝试更高模型、更高 effort 时，可以定期看一下 cost。不是为了少用，而是为了用得更清楚。
5. stats：看结构
官方描述：Alias for /usage. Opens on the Stats tab.
简单理解：stats 是 usage 的别名，会直接打开 Stats 标签页。
stats 可以理解成一个使用情况面板。它真正有价值的地方，不是告诉你一个孤立的数字，而是帮你看清楚：最近这段使用，到底把资源花在了哪里。
打开之后，我会重点看几个方向。
第一，看总成本。这不是为了制造焦虑，而是先建立一个大概的成本感。尤其是你连续几天都在高频使用 Claude Code 时，总成本能让你快速判断最近的使用是不是已经明显偏高。
第二，看Token 使用情况。这比单纯看成本更有参考价值。因为成本高，很多时候不是某一次任务特别夸张，而是上下文太长、会话太重、反复把大量历史信息带进去。比如一个小修改，本来几句话就能说清楚，但因为你一直在一个长会话里硬撑，每次请求都带着大量上下文，Token 自然会被不断放大。
第三，看时间维度。这里可以关注 API 实际耗时和真实使用时长之间的差异。比如你发现真实使用时间很长，但有效调用时间并不多，那问题可能不是模型慢，而是中间被你频繁打断、等待确认、来回补充上下文。反过来，如果 API 耗时本身就很长，那可能就要回头看模型、effort、上下文长度是否过重。
第四，看代码改动量。如果你花了不少成本，但代码改动很少，就要判断这次使用是不是主要消耗在“理解、分析、试错”上。这不一定是坏事，但它能提醒你：这类任务以后是不是应该先让 Claude Code 做计划和排查，再进入修改阶段，避免边想边改、来回返工。
第五，看活动分布。如果统计里能看到命令、会话或工具使用情况，就可以顺手看看自己的使用结构。比如是不是大量时间花在简单修改上，却一直沿用高 effort；是不是频繁进入长会话，却很少 compact；是不是一直在同类低风险操作上被权限确认打断。
举个例子：你连续一周都觉得 Claude Code 成本偏高，但又说不出为什么。
看一眼 stats，可能会发现：最近大量使用都集中在一些并不复杂的小修改上，但你几乎每次都沿用了之前分析复杂问题时的配置；同时上下文越来越长，却很少做 compact。这时候问题就很清楚了：使用方式不对。
所以 stats 最好不要只看一个总数，而是看几个问题：
•
成本是不是明显高于预期
•
Token 是不是被长上下文持续放大
•
时间主要花在模型调用上，还是花在等待和反复确认上
•
代码改动量和消耗是否匹配
•
使用结构是不是集中在一些低价值、高消耗的任务上
这样看，stats 就不只是统计数字，而是一次使用方式的复盘。
这一组命令到底该怎么用
这一组命令可以帮你建立一套简单的判断流程：先判断任务类型，再决定模型和 effort，最后通过 status、cost、stats 回头看自己的用法有没有跑偏。
这里面最常见的误区有两个。
一个是默认高配。不管任务大小，先把模型和 effort 往高了拉，结果就是更慢、更贵，但效果并没有明显更好。
另一个是从来不看反馈。一直在用，却从来不回头看状态、成本和统计，最后只能靠感觉判断“今天好不好用”“这个工具值不值”。
更稳的做法是：
•
执行型任务，优先考虑快和准
•
判断型任务，再考虑更强模型和更高 effort
•
用一段时间之后，定期看 cost 和 stats
•
感觉不对时，先看 status，不要全靠猜
这样一来，Claude Code 的使用就不再是“凭感觉调配置”，而是逐渐变成“按任务调档位”。
第三类：权限、安全与排障相关命令
这一类命令解决的是：为什么它明明看起来该能做这件事，但就是没做成。
很多人用 Claude Code 时，最常见的不适感不是回答不够聪明，而是下面这些情况：
•
想让它继续干活，结果一路弹确认
•
想调命令、调工具，结果权限不够
•
明明装了、配了，还是用不起来
•
报错是报错了，但根本不知道该从哪里查
更常见的原因是：权限没配好、环境没打通、执行边界没设清楚、排障入口没找对。
这一类里，最容易混在一起的是权限相关能力。可以先用一个模型理解：
先把这几层分清楚，后面看 doctor、debug、security-review 这些排障和安全命令，就会顺很多。
这一组里比较值得重点关注的，主要有这些命令和能力：permissions、auto mode、doctor、debug、sandbox、security-review、fewer-permission-prompts。
1. permissions：别只点确认
官方描述：Manage allow, ask, and deny rules for tool permissions.
简单理解：管理工具权限中的允许、询问和拒绝规则。
很多人第一次觉得 Claude Code “有点烦”，基本都是从权限确认开始的。看个文件确认一次，跑个命令确认一次，改个内容可能还要再确认一次。单次不算什么，但连续做事时，这种反复确认会非常影响节奏。
💪
这个时候不要只想着“能不能少问一点”，而是应该打开 permissions 看三件事：
•
哪些操作已经被 allow
•
哪些操作仍然会 ask
•
哪些操作已经被 deny
这三个词很关键。allow 代表 Claude Code 可以直接做，不再每次问你；ask 代表每次遇到都要确认；deny 代表直接禁止。
真正要管理的是这三类规则之间的边界，而不是简单地全部放开。
3.1
第一类，低风险、高频、重复出现的操作，可以考虑 allow。
•
读取项目里的普通源码文件
•
搜索关键词
•
查看目录结构
•
执行 npm run lint
•
执行 npm run test
•
执行 git status、git diff 这类只读检查
这些操作本身风险低，而且经常出现。如果每次都弹确认，效率会被切得很碎。像这类命令，就可以考虑加入允许规则，例如：
代码块
Plain Text
3.2
第二类，有风险但不是绝对不能做的操作，建议保留 ask。
•
修改项目文件
•
执行构建脚本
•
安装依赖
•
执行迁移脚本
•
运行会改变本地状态的命令
这些操作不是不能让 Claude Code 做，但最好不要无脑放行。比如 npm install、pnpm install、数据库 migration、脚本修复这类动作，一旦执行就可能改变本地环境或项目状态，保留确认会更稳。
3.3
第三类，明确不希望它碰的东西，应该直接 deny。
•
.env、.env.*
•
secrets/**
•
私钥、证书、凭据文件
•
生产配置
•
高风险命令，比如 git push、rm -rf、生产发布脚本
这类东西不要靠“我到时候看弹窗再判断”，最好一开始就写进 deny。比如：
代码块
Plain Text
{
"permissions": {
"deny": [
"Read(./.env)",
"Read(./.env.*)",
这里还有一个很容易忽视的点：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 本质上是一个权限模式，目标是减少人工确认，让 Claude Code 在后台安全检查通过的情况下，自动批准更多工具调用。也就是说，它解决的是“要不要每一步都问你”的问题。
但 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 适合解决那种“明明装好了，但就是不好使”的问题。
这类问题很常见：命令能启动，界面也正常，但一到具体功能就不对。比如某个工具调不起来，某个能力不生效，或者行为和你预期差很多。遇到“刚配置完但不好使”的情况，先跑 doctor，再去查更细的问题。
3. sandbox：让它更自由地干活，但只能在边界内干活
官方描述：Toggle sandbox mode. Available on supported platforms only.
简单理解：在支持的平台上开启或关闭沙箱模式。
💪
sandbox 最容易被误解成“限制”，但它真正解决的是另一个问题：如何让 Claude Code 在边界明确的前提下连续执行命令。
区别：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
•
让它在项目目录内做排查和验证
•
让它执行一些会产生临时文件或构建产物的命令
•
让它自动尝试修复问题，但不希望它越过项目边界
4. security-review：让 Claude Code 帮你做一次安全审查
官方描述：Analyze pending changes on the current branch for security vulnerabilities.
简单理解：分析当前分支待提交改动中的安全风险。
💪
security-review 直译过来就是“安全审查”。它的作用也很直接：让 Claude Code 从安全角度检查当前代码或当前改动，帮你看看有没有明显的风险点。比如权限控制有没有漏、外部输入有没有校验、敏感信息有没有暴露、文件处理有没有边界问题、依赖或调用链路里有没有潜在风险。
比如下面这些场景，就很适合用一下：
•
刚做完一轮比较大的代码改动
•
引入了新的依赖或新的执行链路
只要改动碰到权限、数据、文件、外部输入，就顺手做一次安全审查。它不一定每次都能发现问题，但能帮你多一个安全视角，避免只盯着“功能有没有跑通”。
5. 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 以后什么都少问，而是帮你把“已经反复确认过、基本可以信任的低风险操作”沉淀成权限规则。
它会基于你过去的使用记录，分析哪些只读命令和 MCP 工具调用反复出现，然后给出一份更适合当前项目的 allowlist。生成之后，这些低风险高频操作就可以少打断你。
⚠️这里要注意两点。
第一，它更适合优化只读、低风险、高频的操作。
比如 git status、git diff、测试命令、lint 命令、只读 MCP 查询，这些都比较适合。因为这些动作不会直接改代码、不会修改环境，也不会触碰生产系统。
第二，它生成 allowlist 之后，最好还是人工过一眼。
不要看到它推荐了一组规则，就直接无脑接受。尤其是涉及外部 MCP 工具时，要看清楚这个工具到底只是读取数据，还是可能触发写入、同步、发布、删除这类动作。
当你发现自己总是在同一类低风险操作上反复点确认，就可以跑一次 fewer-permission-prompts。它最适合解决的不是“我要完全放开权限”，而是“我想把那些已经反复确认过的低风险动作自动化掉”。
💪
这样理解就比较清楚了：permissions 是你手动定规则，fewer-permission-prompts 是 Claude Code 根据你过去的使用记录，帮你找出哪些规则值得加入 allowlist。
这一组命令到底该怎么用
经常被打断，先看 permissions
刚装完或刚配置完不好使，先跑 doctor
问题不是一眼能看懂，打开 debug
涉及命令执行、文件修改、外部工具调用，考虑 sandbox
涉及权限、数据、文件、外部输入，补一轮 security-review
低风险确认太多，再用 fewer-permission-prompts 优化
第四类：扩展能力相关命令
这一组，解决的是更长期的问题：怎么把经验、规则、工具和流程沉淀下来，让 Claude Code 不只是临时帮你写几段代码，而是逐渐变成一个更贴合你工作方式的开发助手。
💪
第一层，是把团队经验沉淀成本地工具箱。
memory 负责记住长期事实，skills 负责沉淀可复用流程，agents 负责拆出专门角色，hooks 负责把固定动作挂到关键节点上。它们解决的是：Claude Code 如何更懂你的项目、更贴合你的团队习惯。
第二层，是向外连接系统，并把重复任务延伸成自动化流程。
mcp 负责连接外部工具和数据源，schedule 负责把重复任务变成 routine。它们解决的是：Claude Code 如何走出当前会话和当前目录，进入更完整的研发工作流。
1. memory：哪些东西应该长期记住
官方描述：Edit CLAUDE.md memory files, enable or disable auto-memory, and view auto-memory entries.
简单理解：编辑 CLAUDE.md 记忆文件，开启或关闭自动记忆，并查看自动记忆内容。
💪
memory 解决的是“哪些信息应该长期保留下来”的问题。我会把适合放进 memory 的内容，大致分成这几类：
•
项目长期稳定的技术栈
•
常用启动、测试、构建命令
•
代码风格和目录约定
•
团队明确要求遵守的规则
比如一个前端项目长期使用 React、Vite、Ant Design、Biome，测试用 Vitest，这些信息就适合写进 memory。Claude Code 后面再做改动时，就不需要每次重新问你技术栈和测试命令。
如果都写进 memory，后面反而可能干扰判断。所以 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：检查需求文档、接口契约、验收标准是否一致
只要你发现自己连续三次以上复制同一套提示词或检查清单，就应该考虑把它做成 skill。
3. agents：把任务交给专门的“角色”去做
官方描述：Manage agent configurations.
简单理解：管理 subagent 配置。
💪
agents 解决的是“复杂任务怎么分工”的问题。
如果说 skill 更像一套可复用流程，那 agent 更像一个专门负责某类任务的角色。比如你可以有这些 agent：
•
code-reviewer：专门审代码质量和风险
•
debugger：专门排查错误和失败用例
•
architecture-reviewer：专门看架构、边界和依赖关系
•
docs-writer：专门整理文档和说明
这类 agent 的价值，是它可以有自己的提示词、工具权限、模型、记忆和工作边界。
如果任务比较复杂，你可以让主会话负责协调，把一部分工作交给专门的 agent。比如让 debugger 先排查失败原因，让 test-writer 补测试，让 code-reviewer 最后审一轮改动。
不要急着创建一堆 agent。可以从最常用的两个开始：一个 code-reviewer，一个 debugger。前者负责把关质量，后者负责排查问题。用顺之后，再扩展到测试、文档、架构等方向。
4. hooks：把重复动作自动挂到关键节点上
官方描述：View hook configurations for tool events.
简单理解：查看工具事件相关的 hook 配置。
💪
hooks 解决的是“哪些动作不应该每次靠人提醒”的问题。
很多团队在用 AI 写代码时，最大的问题不是 Claude Code 不会写，而是它写完之后，有些固定动作总容易漏。比如：
•
执行危险命令前没有二次提醒
•
修改配置后没有记录日志或通知
这些动作如果每次都靠你在 prompt 里提醒，就很低效。因为它们本质上不是“智能判断”，而是“固定流程”。
hooks 可以在 Claude Code 的一些工具事件前后触发命令。你可以理解成：当 Claude Code 准备做某件事，或者刚做完某件事时，自动执行一段你预先配置好的脚本。凡是你在 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 负责流程说明。这样既贴近工具本身的用法，也更容易控制输入输出。
另外，在很多命令式、可脚本化的任务里，CLI + skill 通常也更省上下文。因为 Claude Code 只需要知道命令怎么用、参数怎么传、输出怎么读；skill 正文也只有在使用时才加载。而 MCP 往往需要暴露工具列表、参数 schema、工具说明和返回结构，工具多、说明长、返回内容大时，Token 消耗就会更明显。
用一个简单标准来判断：
一次性、命令式、可脚本化的任务，优先 CLI + skill；
已有配套 skill 的工具，先用现成能力，再按团队流程二次封装；
需要标准化、长期化、跨客户端复用的能力，再考虑 MCP。
6. schedule：把重复任务变成 routine
官方描述：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 长期适配你的项目、你的团队、你的流程，那这一组迟早都绕不开。
第五类：高阶效率和工作流命令
💪
它们的共同点是：不再只是执行一个小动作，而是更接近一个完整工作流。这类命令，平时不一定每天都会用，但一旦遇到合适场景，效率提升会非常明显。
比如批量改造代码、循环检查状态、自动修 PR、生成团队上手指南、学习新功能，这些都不是“问一句、答一句”的传统交互方式，而是在让 Claude Code 承担更长链路的任务。
1. batch：适合大规模、可拆分的代码改造
官方描述：Orchestrate large-scale changes across a codebase in parallel.
简单理解：把大规模代码改造拆成多个独立任务，并行推进。
💪
batch 不是用来修一个小 bug 的。它更适合那种范围大、重复性强、可以拆分成多个独立子任务的代码改造。
•
把某个目录下的旧组件迁移到新组件体系
•
批量替换一套过时 API
batch 的思路是：先研究代码库，再把任务拆成多个独立单元，然后并行交给后台 agent 处理。每个 agent 在自己的 git worktree 里实现、测试，最后提交 PR。
如果任务本身还没想清楚，或者多个模块之间强耦合，直接批量拆出去反而容易制造更多返工。
只有当任务满足三个条件时，再考虑 batch：
•
范围足够大；
•
子任务之间相对独立；
•
验收标准比较清楚。
2. simplify：改完之后，让它帮你收一轮
官方描述：Review your recently changed files for code reuse, quality, and efficiency issues, then fix them.
简单理解：检查最近修改过的文件，发现复用、质量和效率问题，并尝试修复。
很多时候，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 解决的是“我不想一直手动问同一件事”的问题。
有些任务不是一次性完成的，而是需要持续观察。比如：
•
持续观察某个任务队列是否清空
•
反复检查某个页面或接口是否恢复正常
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 工作流里。
autofix-pr 的价值在于，它可以启动一个远程 Claude Code 会话，监听当前分支对应的 PR。当 CI 失败或者 reviewer 留评论时，自动尝试修复并 push。
5. team-onboarding：把你的使用经验整理给团队
官方描述：Generate a team onboarding guide from your Claude Code usage history.
简单理解：根据你的 Claude Code 使用历史，生成一份团队上手指南。
💪
team-onboarding 是一个很容易被忽视，但挺有意思的命令。它不是帮你写代码，而是帮你把过去一段时间怎么用 Claude Code 的经验整理出来。、
这个命令适合下面这些场景：
•
团队准备统一推广 Claude Code
•
已经有人先试用了一段时间，希望把经验同步给其他人
•
项目里已经形成了一些固定用法，但还没写成文档
•
新成员加入项目，需要快速知道怎么用 Claude Code 配合当前仓库
6. powerup：更新太快，就让它带你补课
官方描述：Discover Claude Code features through quick interactive lessons with animated demos.
简单理解：通过带动画演示的交互式小课程，了解 Claude Code 的功能。
💪
powerup 很适合解决一个现实问题：Claude Code 更新太快，很多新功能你根本来不及一个个看文档。
尤其是 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 里看版本更新。
💪
它适合下面这些场景：
•
隔了一段时间没用 Claude Code，想看看最近更新了什么
可以把 release-notes 当成 Claude Code 的“版本说明入口”。尤其是你看到一个新功能，但自己本地没有，或者命令行为和别人不一样时，先查版本，再判断是不是环境、套餐、平台或功能开关的问题。
这一组命令到底该怎么用
如果把这一组放在一起看，它们更像是处理“长链路任务”的命令：
batch 适合大规模、可拆分的代码改造
simplify 适合功能做完后的代码收口
loop 适合持续观察状态
autofix-pr 适合处理 PR 后续反馈
team-onboarding 适合把个人经验整理成团队指南
powerup 适合快速学习新能力
release-notes 适合跟踪版本变化
💪
这一组命令的价值，不是让你在日常小任务里多打一堆命令，而是在遇到更长、更重、更重复的任务时，知道 Claude Code 其实已经提供了更合适的入口。
如果只想先记一小部分，应该从哪些命令开始
Claude Code 的命令不需要一次性全学完，更合理的方式是按使用阶段来选。
刚开始用，先把基础体验打顺；高频使用后，再关注权限、成本、上下文和排障；如果要推广到团队，再看 skills、hooks、agents、MCP、schedule 这些更偏工作流的能力。
新手先掌握这 6 个就够了
help
clear
compact
model
effort
permissions
😀
•
help 用来知道当前环境里到底有哪些命令。这个很重要，因为 Claude Code 的命令会受版本、平台、套餐、配置影响，不同人看到的命令可能不完全一样。
•
clear 和 compact 负责处理上下文。前者是重开，后者是瘦身。新手最容易犯的错误，就是一乱就 clear，但很多时候更适合先 compact。
•
model 和 effort 负责控制任务档位。不要所有任务都默认高配，也不要所有问题都用同一个思考强度。执行题和判断题，应该区别对待。
•
permissions 负责减少使用摩擦。只要开始让 Claude Code 读文件、跑命令、改代码，就一定会遇到权限确认。早点把 allow、ask、deny 的关系搞明白，后面会顺很多。
高频使用者重点看这几类
如果你已经每天都在用 Claude Code，就不能只停留在“会问问题”这个层面了。
context
stats
cost
doctor
debug
sandbox
fewer-permission-prompts
😀
•
context 帮你判断当前会话是不是已经太重。
团队使用重点看这几类
团队使用时，就必须靠机制解决。这时候最值得关注的是这些命令：
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 适合在团队推广初期使用。它可以根据已有使用历史生成上手指南，再由人修订成团队规范。
按场景快速查命令
最后放一张速查表，方便你在具体场景里快速找到入口。