00
引言
不少开发者第一次使用 Claude Code，都会沿用聊天机器人的操作习惯：输入需求、等待回答，遇到问题再补充一段上下文。
这种方式可以完成小任务，却很容易在长时间开发中失控。对话越来越长，项目规则需要反复说明，终端输出来回复制，模型的速度、成本和上下文占用也缺少可见性。
真正高效的用法，不是背更多提示词，而是把 Claude Code 当成一个可以初始化、配置、观察、恢复和审查的工程环境。下面的 14 个命令，按照实际开发阶段重新分为五组。
01
开始编码前，先把项目环境准备好
好的会话不是从一句“帮我写代码”开始，而是先让工具理解仓库，再明确哪些规则需要长期保存。
1. /init：为仓库生成第一版说明
首次进入一个项目时，运行 /init 可以初始化 CLAUDE.md。Claude Code 会分析仓库结构，并生成一份项目指南，帮助后续会话了解常用命令、架构线索和协作约定。
这份文件不是一次生成后永久不动的“标准答案”。自动生成的内容可能过长，也可能包含能从代码直接推断的信息。正确做法是把它当作初稿，删除噪声，只保留模型无法稳定推断的约束。
2. /memory：管理真正需要长期记住的规则
/memory 用来查看和编辑 CLAUDE.md、个人记忆与自动记忆。适合保存稳定偏好，例如测试命令、包管理器、禁止修改的目录和代码审查标准。
项目事实放在仓库级文件，个人偏好放在用户级配置，本机专用信息留在本地范围。把所有内容塞进一个全局文件，会让无关规则污染其他项目。
3. /terminal-setup：改善终端输入体验
按照官方文档说明，/terminal-setup主要为 VS Code、Cursor、Alacritty、Zed 等终端安装 Shift+Enter 换行快捷键，并处理部分终端的输入设置。
它解决的是多行提示词和终端交互体验，不是权限或日志采集。需要把命令输出加入会话，应使用后面介绍的 !Shell 模式。
02
长会话的关键，是控制上下文而不是硬撑
上下文管理不是等到模型“忘事”后再补救，而是持续观察、及时压缩，并把旁支问题从主对话中隔离出去。
4. /btw：旁支问题不要污染主线程
开发过程中经常会临时想到一个问题，例如“JWT 和 Session Cookie 在这里如何取舍”。使用 /btw 问题 可以针对当前会话提问，但不会把这次问答加入主对话历史。
它适合解释概念、确认术语和快速回顾现状；如果答案会改变架构决策，仍应回到主线程明确记录，否则后续步骤不会自动继承这项决定。
5. /compact：带着重点压缩会话
当会话变长时，/compact 会总结历史并释放上下文。不要只输入一个裸命令，更好的方式是附加保留要求：
/compact 保留鉴权重构的决定、失败测试和未解决问题，删除已经放弃的 UI 讨论
官方命令支持 /compact [instructions]。指定重点能够降低关键约束被摘要成一句空泛结论的风险。
6. /context：先看上下文花在了哪里
/context 会用可视化方式展示当前上下文占用，并提示哪些工具输出、记忆文件或对话内容消耗较多。需要完整展开时可以使用 /context all。
它比凭感觉判断“模型是不是快忘了”更可靠。如果大部分空间被冗长的 CLAUDE.md 或重复工具输出占据，优先优化源头，而不是频繁压缩。
7. /usage：观察用量和成本
当前推荐命令是 /usage，/cost 与 /stats 是它的别名。它可以显示会话成本、套餐用量限制和活动统计，具体内容会因账户类型而异。需要注意，显示字段会随版本和登录方式变化。
03
执行任务时，减少切换并匹配合适的资源
上下文准备好以后，效率来自减少无意义的窗口切换，同时根据任务难度调整模型与速度。
8. !：直接进入 Shell 模式
在输入行开头使用 !，可以直接运行 Shell 命令，并把命令与输出加入会话：
! npm test
! git status
当前版本还会在输出进入记录后让 Claude 自动响应，因此测试失败可以直接得到解释。Shell 模式不会让模型替你判断命令是否安全；删除文件、发布和修改生产环境等操作仍需自己确认目标。
9. /model：根据任务切换模型
/model 可以打开模型选择器，也可以传入模型名称。它适合在同一会话中根据任务切换资源，例如架构设计使用更强的推理能力，机械修改使用更快的模型。
但切换模型不等于上下文质量自动提升。任务描述混乱、规则矛盾时，换更强模型也只是更昂贵地处理噪声。
10. /fast：速度模式不是换一个“更笨的模型”
/fast on 与 /fast off 用于切换 Fast mode。官方说明是以更快输出为目标，支持情况取决于当前模型、账户和环境。
它适合快速迭代和短反馈循环。安全审查、数据库迁移与关键发布前检查，更重要的是使用明确的审查标准和足够推理强度，而不是只看响应速度。
04
代码审查不能只问一句“有没有问题”
让模型随口看一眼代码，很容易得到泛泛建议。更有效的做法是调用明确的审查流程，并指定目标与输出方式。
11. /code-review：针对差异运行结构化审查
当前正式命令是 /code-review，/review 是别名。它可以审查当前 diff，也可以接收 PR 编号、分支或路径；--fix 可应用修改，--comment 可生成 GitHub PR 行内评论。
本地审查建议先运行不带自动修复的版本，确认问题是否真实，再决定是否应用更改。任何模型审查都不能代替测试、类型检查、静态分析和人工责任人审批。处理 PR 反馈可以结合 /code-review、GitHub App 或直接让 Claude 通过 ghCLI 读取评论。
05
走错方向时，要会清理、诊断和查帮助
当会话开始重复、安装状态异常或记不住命令时，不必立即关闭终端并从头再来。
12. /clear：开始一段干净对话
/clear 会启动空上下文的新会话，同时保留项目配置。还可以传入名称，为之前的会话加标签，之后通过 /resume 找回。
如果只是上下文接近上限，用 /compact；如果当前思路已经失控、任务目标也发生改变，再使用 /clear。两者分别解决“空间不足”和“方向需要重置”。
13. /doctor：先诊断，再考虑重装
/doctor 会检查安装健康状况，包括重复安装、PATH 问题、无法解析的设置文件、低效配置与部分集成问题，并先报告发现，再询问是否修改。
终端外也可以运行 claude doctor 获取只读诊断。不要把诊断工具描述成一个固定的五项清单，检查范围会随版本继续扩展。
14. /help：以本机实际可用命令为准
/help 会显示当前环境可用的命令。官方文档明确提醒，不是所有命令都会出现在所有账户、平台和运行环境中。
因此，当执行某条命令不存在，并不一定是安装损坏，也可能是版本、套餐、平台或功能开关不同。
06
一套更现实的采用顺序
不要一天之内强迫自己记住 14 个命令。可以按照痛点逐步引入：
-
新项目重复解释背景：先用 /init和/memory。 -
长会话容易丢重点：先学 /context与带说明的/compact。 -
终端和聊天窗口来回切换：使用 !Shell 模式。
-
想提升交付质量：把 /code-review加到测试之后。
-
会话跑偏或环境异常：分别使用 /clear与/doctor。
这些命令的共同目标不是让开发者“少思考”，而是把低价值的切换、重复说明和状态猜测交给工具，让注意力回到需求、边界和验证上。
添加个人微信，进专属粉丝群！
