claude code 最常用的几个指令

开场个人观察

前面已经写过一篇比较完整的 Claude Code 常用指令整理，那篇更像一张命令地图；这篇我想写得更贴近日常项目使用：如果只记几个最常用的指令，应该先记哪些？每个指令到底在项目里怎么用？

Claude Code 的指令很多。官方命令页也提醒，输入 / 可以看到当前环境可用的命令，命令必须放在消息开头才会被识别；并且不是每个命令都会出现在每个人的环境里，平台、计划、版本和登录状态都会影响可见范围。所以我不建议一上来背完整命令表。

我的做法是先掌握一条主线：项目初始化用 /init 和 /memory，复杂任务用 /plan，长会话用 /context 和 /compact，验收用 /diff 和 /code-review，方向错了用 /rewind。这几个指令能覆盖大多数日常开发场景。

核心观点

Claude Code 指令的作用，不是让你少写自然语言，而是让会话进入正确模式。一个真实开发任务通常不是“问一句、答一句”，而是要经历理解项目、制定计划、修改文件、验证结果、审查风险几个阶段。

如果没有指令，你当然也可以用自然语言表达这些意图，比如“先不要改代码，先给计划”。但指令的好处是更稳定、更明确，也更适合形成习惯。

我会把最常用指令分成四类：

第一类是项目记忆：/init、/memory。

第二类是任务控制：/plan、/model、/effort。

第三类是上下文管理：/context、/compact、/clear。

第四类是验收和恢复：/diff、/code-review、/rewind。

不用一口气全记住。先把这四类放进开发流程里，用几次之后自然就熟了。

实践方法

1. /init：新项目第一步

/init 适合在第一次进入项目时使用。它通常会帮助生成项目级说明，比如 CLAUDE.md，让 Claude Code 了解项目结构、常用命令和开发约定。

我会这样用：

/init

生成之后不要直接结束。你应该手工检查里面的内容，把真实规则补进去：

- 安装依赖使用 npm install --no-package-lock。
- 文章源文件在 source/_posts。
- 图片放在 source/images。
- public 是生成目录，不要手动写业务内容。
- 修改文章后要生成静态站并检查 archives 页面。

/init 的价值不在生成那一刻，而在后面每次任务都能复用这些项目规则。

2. /memory：把重复提醒沉淀下来

如果你发现自己反复对 Claude Code 说同一句话，比如“不要升级依赖”“先看 diff”“生成后检查归档页”，就应该考虑用 /memory 管理项目记忆。

我会在一次任务结束后补一句：

/memory

然后把稳定规则整理进去。注意，记忆文件不适合放一次性需求。比如“今天新增一篇文章”不该写进去；“新增文章必须包含 title/date/tags”才适合写进去。

3. /plan：复杂任务先停一下

/plan 是我最常用的指令之一。只要任务会改多个文件、涉及配置、可能影响线上页面，我都会先让它计划。

示例：

/plan 把博客里最近几篇文章日期从 6 月 10 日改成 5 月份随机日期，再新增一篇 6 月 1 日文章。先列出要改的源文件、图片文件、生成和部署验证步骤。

好的计划应该包含四件事：会看哪些文件、会改哪些文件、怎么验证、风险在哪里。如果计划里出现“顺便升级 Hexo”这种越界动作，就要立刻纠正。

4. /model 和 /effort：控制成本和思考深度

不是所有任务都需要最高强度。改错别字、补一段说明、生成一张简单流程图，可以用较低成本；跨模块重构、排查线上问题、做安全审查，就值得提高推理强度。

你可以在任务前调整模型或思考深度：

/model
/effort

我的习惯是：普通写作和小修用默认设置；涉及发布、权限、数据变更、复杂回归时，再提高投入。这样不会为了小任务浪费太多资源。

5. /context：看看会话被什么占满了

长会话最怕的是上下文越来越乱。你已经换了三个任务，但对话里还塞着前一个任务的日志、diff、错误输出，Claude Code 就可能开始抓错重点。

这时可以用：

/context

它的作用是让你看清上下文占用。如果当前任务已经和前面的内容关系不大，就应该压缩或清空，而不是继续往上堆。

6. /compact：把长会话压成可继续的摘要

如果任务还没完，但上下文太长，我会用 /compact。关键是不要只输入一个裸命令，而是告诉它保留哪些东西：

/compact 请保留当前目标、已经修改的文件、尚未完成的验证、遇到的错误和下一步计划。

这样压缩后继续工作，方向更不容易丢。它适合长任务，不适合完全换题。如果你要做一个全新的任务，/clear 往往更合适。

7. /diff：验收前先看真实改动

/diff 是防止 AI 编程失控的核心指令。Claude Code 的总结可能写得很漂亮，但真正要 review 的是文件改动。

我一般会在实现后说：

/diff

然后重点看这几类问题：

是否改了无关文件；

是否误动配置、锁文件、部署脚本；

是否把临时路径、token、内部地址写进代码；

是否只改了正文但忘了生成资源；

是否删除了历史页面。

不要把 /diff 当成形式。它是开发者重新拿回控制权的地方。

8. /code-review：提交前再过一遍

/code-review 适合在提交前使用。官方命令说明里提到，它会检查 diff 中的正确性问题和可清理点。我的理解是，它像一次额外 review，但不能替代你自己看关键逻辑。

可以这样用：

/code-review

如果是高风险改动，可以补充要求：

/code-review 请重点看权限、数据删除、异常分支、测试缺口和是否改到无关文件。

对于博客项目，我会让它重点看 front matter、图片路径、生成页面、归档链接和中文编码。

9. /rewind：方向错了及时回退

很多人用 AI 工具时会有一个坏习惯：发现方向错了，还继续让它“修一下”。补丁叠补丁之后，diff 会越来越难看。

这时应该考虑：

/rewind

它的意义是回到一个更干净的检查点。特别是当 Claude Code 改了太多无关文件、误解了需求、或者尝试升级依赖导致项目乱掉时，及时回退比继续修补更稳。

10. /clear 和 /resume：切换任务与找回会话

如果当前任务已经结束，准备开始另一个独立任务，可以用：

/clear

它会开启更干净的上下文。之后如果需要找回旧会话，可以用：

/resume

我的习惯是：同一任务用 /compact 延续，不同任务用 /clear 切开。这样不容易把两个任务的上下文混在一起。

踩坑提醒

第一个坑，是把命令当成魔法。比如用了 /plan，不代表计划一定正确；用了 /code-review，不代表没有 bug。命令只是让流程更清楚，最终判断还在开发者手上。

第二个坑，是不看本机可用命令。Claude Code 文档明确说，不是每个命令都会在每个环境出现。最稳的方法是在自己的会话里输入 /，看当前真实可用列表。

第三个坑，是在长会话里不断换任务。AI 会尽量利用已有上下文，但旧上下文不一定对新任务有帮助。任务之间要么压缩，要么清空。

第四个坑，是把项目规则只写在聊天里。只在当前会话里说过的规则，很容易下一次就忘。长期规则应该进入 CLAUDE.md、memory、项目文档或 skill。

第五个坑，是跳过验证。无论用什么指令，最后都要落到测试、构建、页面检查、人工 review 上。没有验证的“完成”，只是文字上的完成。

总结

如果只记 Claude Code 的几个常用指令，我会按这个顺序记：/init、/memory、/plan、/context、/compact、/diff、/code-review、/rewind。

它们对应的不是孤立功能，而是一条项目开发主线：建立记忆，计划任务，管理上下文，检查改动，必要时回退。把这条主线用熟，比背完整命令表更有价值。

参考资料

• Claude Code commands reference
• Claude Code CLI reference
• Claude Code interactive mode