为什么高频指令值得单独掌握
前面已经写过一篇比较完整的 Claude Code 常用指令整理，那篇更像一张命令地图；这篇我想写得更贴近日常项目使用：如果只记几个最常用的指令，应该先记哪些？每个指令到底在项目里怎么用？
Claude Code 的指令很多。官方命令页也提醒，输入 / 可以看到当前环境可用的命令，命令必须放在消息开头才会被识别；并且不是每个命令都会出现在每个人的环境里，平台、计划、版本和登录状态都会影响可见范围。所以我不建议一上来背完整命令表。
可以先掌握一条主线：项目初始化用 /init 和 /memory，复杂任务用 /plan，长会话用 /context 和 /compact，验收先看 /diff，安全敏感改动用 /security-review，方向错了用 /rewind。这些指令能覆盖大多数日常开发场景。
先按任务阶段建立使用顺序
Claude Code 指令的作用，不是让你少写自然语言，而是让会话进入正确模式。一个真实开发任务通常不是“问一句、答一句”，而是要经历理解项目、制定计划、修改文件、验证结果、审查风险几个阶段。
如果没有指令，你当然也可以用自然语言表达这些意图，比如“先不要改代码，先给计划”。但指令的好处是更稳定、更明确，也更适合形成习惯。
我会把最常用指令分成四类：
第一类是项目记忆：/init、/memory。
第二类是任务控制：/plan、/model、/effort。
第三类是上下文管理：/context、/compact、/clear。
第四类是验收和恢复：/diff、/security-review、/rewind。
不用一口气全记住。先把这四类放进开发流程里，用几次之后自然就熟了。
十个高频指令及其场景
1. /init：新项目第一步
/init 适合在第一次进入项目时使用。它通常会帮助生成项目级说明，比如 CLAUDE.md，让 Claude Code 了解项目结构、常用命令和开发约定。
我会这样用：
1 | /init |
生成之后不要直接结束。你应该手工检查里面的内容，把真实规则补进去：
1 | - 安装依赖使用 npm install --no-package-lock。 |
/init 的价值不在生成那一刻，而在后面每次任务都能复用这些项目规则。
2. /memory：把重复提醒沉淀下来
如果你发现自己反复对 Claude Code 说同一句话，比如“不要升级依赖”“先看 diff”“生成后检查归档页”，就应该考虑用 /memory 管理项目记忆。
我会在一次任务结束后补一句：
1 | /memory |
然后把稳定规则整理进去。注意，记忆文件不适合放一次性需求。比如“今天新增一篇文章”不该写进去；“新增文章必须包含 title/date/tags”才适合写进去。
3. /plan：复杂任务先停一下
/plan 是我最常用的指令之一。只要任务会改多个文件、涉及配置、可能影响线上页面，我都会先让它计划。
示例：
1 | /plan 把博客里最近几篇文章日期从 6 月 10 日改成 5 月份随机日期，再新增一篇 6 月 1 日文章。先列出要改的源文件、图片文件、生成和部署验证步骤。 |
好的计划应该包含四件事：会看哪些文件、会改哪些文件、怎么验证、风险在哪里。如果计划里出现“顺便升级 Hexo”这种越界动作，就要立刻纠正。
4. /model 和 /effort：控制成本和思考深度
不是所有任务都需要最高强度。改错别字、补一段说明、生成一张简单流程图，可以用较低成本；跨模块重构、排查线上问题、做安全审查，就值得提高推理强度。
你可以在任务前调整模型或思考深度：
1 | /model |
我的习惯是：普通写作和小修用默认设置；涉及发布、权限、数据变更、复杂回归时，再提高投入。这样不会为了小任务浪费太多资源。
5. /context：看看会话被什么占满了
长会话最怕的是上下文越来越乱。你已经换了三个任务，但对话里还塞着前一个任务的日志、diff、错误输出，Claude Code 就可能开始抓错重点。
这时可以用：
1 | /context |
它的作用是让你看清上下文占用。如果当前任务已经和前面的内容关系不大，就应该压缩或清空，而不是继续往上堆。
6. /compact：把长会话压成可继续的摘要
如果任务还没完，但上下文太长，我会用 /compact。关键是不要只输入一个裸命令，而是告诉它保留哪些东西：
1 | /compact 请保留当前目标、已经修改的文件、尚未完成的验证、遇到的错误和下一步计划。 |
这样压缩后继续工作，方向更不容易丢。它适合长任务，不适合完全换题。如果你要做一个全新的任务，/clear 往往更合适。
7. /diff：验收前先看真实改动
/diff 是防止 AI 编程失控的核心指令。Claude Code 的总结可能写得很漂亮，但真正要 review 的是文件改动。
我一般会在实现后说：
1 | /diff |
然后重点看这几类问题：
是否改了无关文件；
是否误动配置、锁文件、部署脚本；
是否把临时路径、token、内部地址写进代码；
是否只改了正文但忘了生成资源；
是否删除了历史页面。
不要把 /diff 当成形式。它是开发者重新拿回控制权的地方。
8. /security-review：检查安全敏感改动
/security-review 用于分析当前分支待提交改动中的安全风险，例如注入、认证授权缺陷和敏感数据暴露。它不等同于通用代码审查，也不能替代开发者检查业务正确性、性能、兼容性和测试覆盖率。
可以这样用：
1 | /security-review |
对于通用代码审查，应直接给出清晰的自然语言要求，例如“请只读审查当前 diff，按严重程度列出业务错误、兼容性风险和测试缺口”。对于博客项目，可以重点检查 front matter、图片路径、生成页面、归档链接和中文编码。
9. /rewind：方向错了及时回退
很多人用 AI 工具时会有一个坏习惯：发现方向错了，还继续让它“修一下”。补丁叠补丁之后，diff 会越来越难看。
这时应该考虑：
1 | /rewind |
它的意义是回到一个更干净的检查点。特别是当 Claude Code 改了太多无关文件、误解了需求、或者尝试升级依赖导致项目乱掉时，及时回退比继续修补更稳。
10. /clear 和 /resume：切换任务与找回会话
如果当前任务已经结束，准备开始另一个独立任务，可以用：
1 | /clear |
它会开启更干净的上下文。之后如果需要找回旧会话，可以用：
1 | /resume |
我的习惯是：同一任务用 /compact 延续，不同任务用 /clear 切开。这样不容易把两个任务的上下文混在一起。
指令使用中的常见误区
第一类误区是把命令当成正确性保证。使用 /plan 不代表计划一定正确，使用 /security-review 也不代表不存在业务缺陷。命令用于组织流程，最终判断仍由开发者负责。
第二个坑，是不看本机可用命令。Claude Code 文档明确说，不是每个命令都会在每个环境出现。最稳的方法是在自己的会话里输入 /，看当前真实可用列表。
第三个坑，是在长会话里不断换任务。AI 会尽量利用已有上下文，但旧上下文不一定对新任务有帮助。任务之间要么压缩，要么清空。
第四个坑，是把项目规则只写在聊天里。只在当前会话里说过的规则，很容易下一次就忘。长期规则应该进入 CLAUDE.md、memory、项目文档或 skill。
第五个坑，是跳过验证。无论用什么指令，最后都要落到测试、构建、页面检查、人工 review 上。没有验证的“完成”，只是文字上的完成。
总结
如果只记 Claude Code 的几个常用指令，可以按这个顺序掌握：/init、/memory、/plan、/context、/compact、/diff、/security-review、/rewind。
它们对应的不是孤立功能，而是一条项目开发主线：建立记忆，计划任务，管理上下文，检查改动，必要时回退。把这条主线用熟，比背完整命令表更有价值。