Claude Code 必知必会的 14 个命令
云朵君约 9 分钟很多人已经把 Claude Code 用进日常开发了，但用法其实还停在一个很朴素的循环里：
丢进去一个需求，让它改代码；报错了，再补一段说明；上下文乱了，就继续往后聊；实在不行，重新开一个会话。
看起来已经在“用 Agent 写代码”，实际还是把 Claude Code 当成了一个更聪明的终端聊天框。
问题不在于少背了几个斜杠命令。
真正拉开差距的，是有没有把 Claude Code 里的这些入口，放到合适的开发阶段里：什么时候该先交代项目背景，什么时候该整理上下文，什么时候只是想顺手问个问题，什么时候该让它单独做一次代码审查，环境出问题以后又该从哪里恢复。
把这些事情理顺之后，14 个命令其实没那么难记。它们大致只是在解决 5 类问题：
项目上下文、会话上下文、执行方式、代码审查，以及故障恢复。
所以这篇不准备做一张“Claude Code 命令大全”。下面还是 14 个入口，但重点是把它们放回真实工作流里：你到底什么时候该用，什么时候没必要用，以及哪些命令最容易被误用。
还有一个前提要先说明：Claude Code 更新很快，命令会调整，旧入口也会被移除。比如原稿里的 /pr_comments，已经在 Claude Code 2.1.91 的变更记录中被移除。实际使用前，最稳妥的习惯仍然是先跑一次 /help，看当前版本到底提供了什么。
01先把项目交代清楚
1. /init：第一次进仓库，先别急着改代码
进入一个陌生仓库，很多人的第一反应是直接说：
帮我看看这个项目，然后修一下这个问题。
Claude Code 当然也能开始读，但如果项目后面还要持续开发，先跑一次：
/init
通常更划算。
它会读取项目结构，并生成或补充项目级 CLAUDE.md。目录怎么分、常用命令是什么、用了哪些技术栈、有哪些固定约定，都可以从一次性的聊天背景里搬出来，变成后续任务都能复用的项目上下文。
它比较适合三种情况：第一次接手仓库、项目结构刚发生明显变化，或者现有 CLAUDE.md 已经严重过时。
但别把 /init 理解成“Claude 已经彻底看懂整个仓库”。它只是帮你建立项目入口。生成后的测试命令、部署命令、安全边界，仍然值得人工扫一遍。
2. /memory：真正需要跨任务记住的东西，再放进去
/memory
有些规则不是这一次任务才需要，而是这个项目以后每次都要遵守。
比如：
- Always suggest tests first
- Prefer composition over inheritance
- Explain complex logic with comments
- Never use any without explicit permission
这种内容就更适合放进长期记忆，而不是每次开新会话重新说一遍。
判断标准也很简单：
这条规则过两周以后，大概率还成立吗？
如果答案是“只跟今天这个需求有关”，就别塞进长期记忆。记忆不是越多越好。临时信息堆进去以后，后面的每个任务都要带着它一起走，最后反而会变成上下文负担。
02长任务最先失控的，往往不是代码，而是上下文
3. /btw：临时想到的问题，别硬塞进主任务
写代码时很容易中途冒出一个问题：
/btw refresh token 和 session cookie 的取舍是什么？
这类问题很常见，又确实想马上确认，但它和当前改代码这件事不一定有直接关系。
/btw 的意义就在这里：把这种旁路问题单独处理，不要让主任务一路长成一棵岔出去十几条支线的树。
它适合查术语、确认语法、快速比较两个方案。
但它不是后台并行任务。复杂问题如果真要展开，还是应该单独开任务或新会话，不要指望主任务自动继续跑、旁边的问题也一起完成。
4. /context：感觉 Claude 开始“变笨”时，先看看发生了什么
很多长会话都会经历一个阶段：
回答开始重复，前面说过的约束被漏掉，模型似乎越来越抓不住重点。
这时候很多人第一反应是直接 /compact。
更稳一点的做法，是先看：
/context
先确认上下文到底被什么占满了：是聊天太长、工具输出太多，还是某段指令本身就很重。
这一步看起来没什么技术含量，但很重要。因为如果根因没变，压缩完以后，用不了多久还会回到同样的状态。
5. /compact：该留的留下，该扔的就别继续背着
/compact
长任务跑久以后，真正需要保留的往往没那么多：
当前目标是什么，已经确认了哪些决策，哪些文件最重要，还有什么问题没解决。
前面那些试错过程、失败猜测、已经被推翻的路线，未必还需要完整留在上下文里。
/compact 做的就是这件事：把长对话压成更短、更能继续工作的上下文。
但要注意，压缩不是无损归档。
重要命令、接口约束、失败原因、后续必须保留的决定，最好先写进项目文件、issue 或任务记录，再做 compact。否则某些你以为“模型肯定会记住”的细节，压缩以后可能就没了。
6. /cost：长任务跑起来以后，成本最好别靠感觉
/cost
任务一旦进入多轮 Agent 操作、长文件阅读、反复重试，成本很容易在不知不觉里抬上去。
/cost 能让你看到当前会话的用量情况，适合在准备继续扩任务之前看一眼。
它不是预测器，只告诉你这次用了多少，不代表下一次一定还是这个数字。模型、账户、缓存命中、上下文长度都会影响结果。
所以更适合把它当成一次“账单检查”，而不是拿某次结果去总结一条普遍的省钱公式。
7. ! command：会话里直接跑 shell，少做一次复制粘贴
如果当前问题本来就需要看 Git 状态、跑测试、查版本，没必要每次都切到终端执行，再把输出复制回来。
可以直接写：
! git status
! npm test
! npm install
原稿里还有：
! npm install
! npm run test
! git add .
前两条都比较自然，最后一条则要谨慎一点。
git add . 会直接改暂存区，不应该和“看状态”“跑测试”放在同一个风险级别。真要暂存，至少先：
! git status
再明确指定文件，最后用：
! git diff --cached
检查暂存内容。
! 很适合短测试、读版本、看状态、执行明确脚本，但它不是权限绕过器。删除、网络访问、凭据、生产环境相关命令，该确认的仍然要确认。
8. /model：不是所有任务都值得一直开最重的模型
/model
复杂架构分析、跨文件排障、代码审查，通常更在乎推理质量。
但如果只是改个名字、调整格式、补几行重复代码，一直用最重的配置也未必有必要。
/model 更适合在任务性质发生变化时切换，而不是回答稍微慢一点就换模型。
而且模型换得再好，也救不了一个定义模糊的任务。该写清楚的输入、该跑的测试，一样不能少。
9. /effort：模型没变，但可以决定它“想多深”
在支持的版本和模型里，/effort 更像一个推理投入旋钮。
复杂问题需要多想几层，可以往上调；局部、明确、机械的任务，就没必要一直维持高投入。
它和 /model 很容易混：
/model是换模型；/effort是在当前支持范围内调整响应策略。
具体有哪些档位、当前模型是否支持，还是以本机 /help 和当前文档为准。
10. /fast：适合低风险迭代，不适合拿来硬扛复杂排障
/fast
原型探索、快速试几个方案、小范围局部修改，这类场景通常比较适合速度优先。
但到了复杂排障、关键代码审查，或者需要仔细解释因果链的时候，再一味追求快就没什么意义了。
尤其不要把 /fast 写成“固定快几倍”。
没有同一任务、同一账户、同一环境的对照测试，速度倍数和质量变化都很难下定论。
04代码写完以后，最好别马上相信它
11. /review：生成是一件事，审查最好再单独做一次
/review
Claude Code 刚刚写完代码以后，最危险的一步其实是直接默认“它应该没问题”。
/review 的价值，就是刻意把“生成”和“审查”拆开。
一个更顺手的顺序是：
! git diff
/review
! npm test
先看看到底改了什么，再让 Claude Code 用审查视角找问题，最后跑项目自己的测试。
这和一句“顺便看看有没有问题”还是不太一样。真正进入 review 流程以后，注意力更集中在 diff、边界条件、逻辑风险和维护成本上。
原稿里给出的审查示例：
Line 42: potential null reference — handle missing key
Line 87: inefficient loop — consider using map instead
Line 103: security risk — sanitize user input
这类输出更适合当待核对清单，不是缺陷判决书。
/review 也替代不了测试、安全检查和人工验收。它只是多加一层独立视角，价值已经很大。
05真出问题了，别第一反应就是重装
12. /clear：有时候坏的不是项目，是这段对话
当会话已经陷入循环，或者一个很早的错误假设一直影响后面的判断，继续补 prompt 往往只会越来越乱。
这时候可以：
/clear
把当前会话上下文清掉，重新从项目文件和明确任务开始。
不过在清空之前，先确认关键决策有没有写回 CLAUDE.md、issue、代码注释或任务记录。
否则清空是清爽了，重要信息也一起没了。
13. /doctor：命令突然不好使，先体检环境
/doctor
命令失效、权限表现异常、安装状态不明、终端集成看起来不对时，先跑一次 /doctor，通常比直接重装更合理。
它适合排查 Claude Code 自身配置和环境里的明显问题。
但也别把它当万能诊断器。网络、代理、组织策略、第三方 MCP、项目自己的构建错误，还是得分别查。
/doctor 更像先帮你缩小范围，而不是一键修好所有故障。
14. /terminal-setup：先分清到底是终端问题，还是代码问题
如果 Claude Code 和当前终端的交互没配置好，可以用：
/terminal-setup
它解决的是终端集成，不是项目本身。
运行之后，仍然要看当前 shell、操作系统和权限是不是在支持范围内。
如果你只是忘了某个命令叫什么，反而不用折腾这么多，直接：
/help
更快。
实际上，/help 可能才是这整篇里最值得长期记住的那个入口。
Claude Code 是持续更新的软件。今天的命令列表，不一定就是半年后的命令列表。比起死记一张表，更可靠的习惯是知道：忘了就去哪里查。
06真正值得记住的，其实只有这 5 类工作流
14 个入口看着不少，但把它们放回日常开发以后，其实很好归类。
第一次进项目，重点是 /init 和 /memory，把项目背景和长期规则交代清楚。
长任务跑起来以后，真正高频的是 /btw、/context 和 /compact，避免旁路问题和上下文膨胀把主任务拖乱；必要时再用 /cost 看一下用量。
到了执行阶段，! command 负责直接调用 shell，/model、/effort 和 /fast 则负责调整模型和响应方式。
代码准备交付时，至少跑一次 diff，再用 /review 做独立审查，最后回到项目自己的测试和人工验收。
真遇到环境异常，再考虑 /doctor、/terminal-setup 和 /clear。命令记不清，就回 /help。
如果只保留一套最小流程，可以压成下面这样：
第一次进项目： /init，检查CLAUDE.md；真正长期成立的规则再交给/memory长任务开始变重：旁路问题用 /btw；先/context，确认后再/compact需要项目命令：用 ! git status、! git diff和测试命令，涉及写操作时先确认风险任务难度变化：再考虑 /model、/effort，低风险速度优先阶段才用/fast准备交付：看 diff → /review→ 跑测试 → 人工验收环境异常：先 /doctor，终端有问题再看/terminal-setup，会话本身污染严重再/clear
这样看，真正需要记住的不是 14 个命令，而是它们分别在工作流里负责什么。
Claude Code 能不能真正帮上忙，最后也不取决于你会不会背这些入口。
项目说明准不准确、上下文有没有失控、权限有没有边界、模型是不是用在合适的任务上，以及代码最后有没有经过测试，这些才决定了工作流能不能跑稳。
命令只是入口，工程约束才是工作流。
07参考材料
Claude Code Commands — code.claude.com Claude Code Interactive Mode — code.claude.com Claude Code Memory — code.claude.com Claude Code Costs — code.claude.com Claude Code Model Configuration — code.claude.com Claude Code Code Review — code.claude.com Claude Code Changelog — code.claude.com