夜雨聆风很多人第一次打开Claude Code，操作方式都差不多,在终端里输入claude，然后像聊天一样告诉它“帮我改这个 bug”“解释一下这个项目”“重构一下这段代码”。
这当然能用。
但如果你一直只用自然语言和它对话，就像买了一辆性能车，却全程只挂一档。Claude Code 真正厉害的地方，不只是“能听懂你说话”，而是它在交互会话里藏了一整套控制面板,上下文怎么压缩、模型怎么切换、任务怎么规划、代码怎么审查、问题怎么回滚、自动化怎么跑，都可以用斜杠命令精确触发。
官方文档对命令的定位很直接,Commands 是在 Claude Code 会话内部控制行为的入口，可以用来切换模型、管理权限、清理上下文、运行工作流等；输入 / 就能看到当前可用命令，继续输入字母还能过滤命令。命令只有出现在消息开头时才会被识别，后面的文本会作为参数传给命令。
你可以把 Claude Code 的操作方式理解成三层：
CLI Flags，是“发车前设定导航”。比如启动时用 claude --effort high、claude --permission-mode plan、claude --add-dir ../lib，这些是在进入会话前就决定运行方式。官方 CLI 参考里列出了 claude、claude -p、claude -c、claude -r以及大量启动参数。
Slash Commands，是“行车途中换挡”。你已经在一个 Claude Code session 里了，突然发现上下文快满了，用 /compact；要先看方案再动工，用 /plan；要切模型，用 /model；要看本轮改了什么，用 /diff。
Keyboard Shortcuts，是“方向盘和刹车”。比如 Ctrl+C 中断当前生成，Shift+Tab 切换权限模式，Alt/Option+P 打开模型切换，Ctrl+R 搜索历史命令。官方交互模式文档把这些快捷键、shell mode、/btw 侧边问题等都归在 interactive mode 里。
所以，斜杠命令不是“高级用户的炫技”，而是 Claude Code 日常使用里的核心控制面板。它让你少解释、少等待、少返工。
到 2026 年春季，Claude Code 的命令体系已经进入“70+ 命令”的量级；而且官方也特别提醒：不是每个命令都会对所有用户显示，可见性会受平台、套餐和运行环境影响，例如某些桌面、云端或订阅相关命令只在特定条件下出现。最稳妥的做法是：进入项目后先输入 /或 /help，以你当前环境显示的列表为准。
真正会用 Claude Code 的人，第一件事不是让它写代码，而是先管理好会话。
你可以把一个 Claude Code session 想象成一个项目作战室。刚开始墙上很干净，只有需求、目录结构、几条关键规则。聊着聊着，墙上贴满了代码片段、错误日志、测试输出、被否掉的方案、临时想法。信息越来越多，Claude 的回答就可能越来越慢，甚至开始抓不住重点。
这时候最常见的两个命令是 /compact 和 /clear。
/compact 是给对话历史做一次“脱水浓缩”。它不会把作战室清空，而是把墙上的便签整理成一份会议纪要：关键决策保留，重要文件保留，当前进度保留，冗余聊天和中间过程丢掉。官方说明里，/compact [instructions] 的作用就是通过总结当前对话来释放上下文空间，还可以传入聚焦指令，让摘要保留你指定的重点。
比如你刚完成登录模块改造，接下来还要继续写测试，可以这样用：
/compact 保留认证流程、修改过的文件、待补测试点和未解决问题
这比单纯输入 /compact 更稳，因为你告诉了 Claude：接下来最重要的不是全部细节，而是“认证流程、改动文件、测试点、遗留问题”。
一个实战经验是：不要等上下文爆了才 /compact。等到 Claude 已经明显变慢、开始遗忘、或者系统提示上下文吃紧时再压缩，质量往往不如你在 70%—80% 使用率时主动整理。更好的节奏是：一个阶段完成就压缩一次，比如“需求理解完成”“方案确定完成”“第一批代码改完”“测试修完”这些节点。
/clear 则完全不同。它不是浓缩，而是清场。官方定义里，/clear [name] 会开启一个空上下文的新对话，旧对话仍然可以通过 /resume 找回；如果只是想释放上下文但继续当前任务，应该用 /compact。
选择策略很简单：
任务还没结束，只是上下文太重，用 /compact。
任务已经结束，要切到完全不相关的新任务，用 /clear。
Claude 被错误信息带偏，越改越乱，用 /clear 重新开局。
需要找回之前的会话，用 /resume。官方文档中 /resume [session] 可以按 ID 或名称恢复对话，也可以打开 session picker。
还有一个“后悔药”叫 /rewind。它适合 Claude 走错方向之后，把对话和代码回到之前的检查点。官方命令表里，/rewind 可以回退 conversation 或 code 到之前某个点，也可以从选定消息重新摘要；它还有 /checkpoint、/undo 这样的别名。
不过要注意：回滚类命令再好用，也不要替代 Git。做高风险操作前，最好先保证工作区干净，或者手动 commit/stash 一下。Claude Code 的回退是“会话级安全带”，Git 才是“项目级保险箱”。
如果说 /compact、/clear、/resume、/rewind 负责会话生命线，那么 /init 和 /memory 负责让 Claude 真正理解你的项目。
很多人抱怨 AI 写代码不贴合项目风格，本质上不是模型不会写，而是它不知道你们团队的“潜规则”：目录怎么分、接口怎么命名、哪些库不能引入、测试怎么跑、提交信息怎么写。
/init 就像给 AI 写一份项目说明书。官方文档里，/init 用来初始化项目并生成 CLAUDE.md 指南；还可以通过 CLAUDE_CODE_NEW_INIT=1 进入更完整的交互流程，引导配置 skills、hooks 和个人 memory 文件。
新项目第一次打开 Claude Code，建议先跑：
/init
然后人工检查生成的 CLAUDE.md。不要把它当成越长越好的“项目百科”。更好的写法是短、硬、可执行：
## 开发规则- 使用 TypeScript strict mode- 禁止使用 any，除非有注释说明原因- React 组件超过 200 行需要拆分- API 请求统一走 src/lib/request.ts- 提交前运行 pnpm lint && pnpm test
/memory则更像你的“长期偏好”。官方命令表说明，/memory 可以编辑 CLAUDE.md memory files，启用或禁用 auto-memory，并查看自动记忆条目。
一个简单区分是：
/init 更偏项目级，让 Claude 理解“这个仓库怎么工作”。
/memory 更偏个人或长期偏好，让 Claude 记住“你通常希望它怎么工作”。
比如你可以把这些写进 memory：
- 回答代码问题时，优先给可运行示例- 修改复杂逻辑前，先解释风险点- 默认用中文解释，但代码注释保持英文- 遇到不确定的库版本，不要猜，先让我确认或查文档
CLAUDE.md 不要写成公司制度汇编。它的目标不是“存档”，而是“约束行为”。一句“代码要优雅”几乎没用；一句“新增工具函数必须放在 src/utils，并补充单元测试”才有用。
接下来是模型与配置。
很多人使用 Claude Code 的默认模型一路跑到底，这当然省心，但不一定划算。Claude Code 里 /model、/effort、/config 这三个命令，就像一台车的发动机模式、油门深度和中控设置。
/model [model] 用来选择或切换模型。官方说明提到，直接运行 /model 会打开模型选择器；对支持 effort 的模型，还可以用左右键调整 effort level。需要注意的是，如果当前会话已经有历史输出，切换模型后下一次响应会重新读取完整历史，可能不再享受原来的缓存上下文。
实战里可以用“梯度切换”：
用便宜快的模型扫目录、找文件、解释简单代码。
用均衡模型做日常开发、重构、测试修复。
遇到架构取舍、疑难 bug、大规模迁移，再切到更强模型。
/effort [low|medium|high|xhigh|max|auto] 控制推理强度。官方命令表里列出可用值包括 low、medium、high、xhigh、max，具体可用等级取决于模型，max 只在当前 session 生效。
这很好理解：不是每个任务都需要“深度思考”。改一个 typo，用 high effort 是浪费；设计插件架构，用 low effort 又容易浅尝辄止。
典型用法：
/effort high/plan 重构订单模块，把支付、库存、通知逻辑拆成独立 service
/config 则是设置入口。官方说明中，/config可以打开 Settings 界面，用来调整主题、模型、输出风格和其他偏好，也有 /settings 别名。
如果你发现 Claude Code 的表现“不像上次那样”，先别急着怀疑模型。跑一下 /status 或 /config 看看：当前模型、权限模式、MCP、插件、输出风格是否变了。很多问题不是 Claude 变笨了，而是环境变了。
真正进入写代码阶段，最有用的是 /review、/security-review、/simplify 和 /diff。
/diff 是你每次收工前都应该跑的命令。它打开一个交互式 diff viewer，可以查看当前未提交变更，也可以按 Claude 的每一轮修改来浏览。官方文档说明，/diff 支持在当前 git diff 和每个 Claude turn 的变更之间切换。
这解决了一个非常现实的问题：你让 Claude 改 A 文件，它可能顺手改了 B 文件；你让它补测试，它可能顺手调整了配置。自然语言回复里它未必说全，/diff 才是事实。
/review [PR] 适合做提交前的常规代码审查。官方命令表里，它用于在当前 session 本地 review 一个 PR；如果要更深的云端审查，可以看 /ultrareview。
使用场景：
/review
让它先当一个不带情绪的 reviewer，帮你找逻辑漏洞、边界条件、可读性问题。它不能替代人类 review，但很适合作为“第一道筛网”。
/security-review 更聚焦安全。官方说明它会分析当前分支 pending changes，识别注入、认证问题、数据泄露等风险。
适合这些场景：
登录、鉴权、权限控制相关改动。
支付、订单、用户隐私相关改动。
新增外部输入、文件上传、Webhook、SQL 查询。
比如：
/security-review
如果它指出“用户输入直接拼进 SQL”“token 打到日志里”“权限判断只在前端做”，这些都值得你停下来认真看。
/simplify 很容易被低估。它不是简单的“帮我优化一下”，而是一个 bundled skill。官方说明里，/simplify [focus] 会审查最近改过的文件，关注代码复用、质量和效率问题，然后修复；它会并行启动三个 review agents，聚合发现并应用修改。
它适合在功能完成后做“收尾清洁”：
/simplify focus on duplicate logic and readability
这里要特别区分 /batch 和 /simplify。它们看起来都和多 Agent 有关，但场景完全不同。
/batch 是面向“大规模并行施工”的。官方说明中，/batch <instruction> 会研究代码库，把工作拆成 5 到 30 个独立单元，确认计划后在隔离的 git worktree 中为每个单元启动一个 background subagent，每个 subagent 实现自己的部分、跑测试并开 PR。它要求项目是 git repository。
适合：
/batch 给 src/api 下所有 endpoint 增加输入校验
这类任务的特点是：范围大、模块多、可以拆分、互不强依赖。
/simplify 则是“完工后的质检小组”。它关注最近改过的文件，找重复、低效、可读性差的问题，然后统一清理。一个是多工位施工，一个是多视角质检。千万不要把 /batch 用在一个小函数优化上，也不要指望 /simplify 帮你完成跨项目迁移。
高风险操作之前，最推荐的命令是 /plan。
/plan 的价值在于：AI 先动脑，不动手。官方说明中，/plan [description] 可以直接从 prompt 进入 plan mode，并可带上任务描述，例如 /plan fix the auth bug。
这非常适合高风险修改：
/plan 将用户权限系统从 role-based 改成 permission-based，先给迁移方案，不要改代码
你会先看到它准备改哪些文件、每一步怎么做、可能影响什么、如何验证。你审核完再说“按这个计划执行”。这比直接让它开改安全得多。
一个黄金工作流可以这样走：
/effort high/plan 重构 UserService，把数据库访问抽到 Repository 层# 人工审查方案# 确认执行/diff/review/security-review
这套流程的核心不是“让 AI 更自主”，而是“让人类更容易把关”。AI 负责展开细节，人负责控制方向。
再往上就是自动化和高级能力。
/autofix-pr [prompt] 适合处理 PR 后续维护。官方命令表说明，它会启动一个 Claude Code on the web session，监控当前分支对应的 PR，在 CI 失败或 reviewer 留评论时推送修复；它依赖 gh CLI，并需要 Claude Code on the web 权限。
比如：
/autofix-pr only fix lint and type errors
这个命令适合团队里那些机械但烦人的 PR 返工：lint 挂了、类型错了、reviewer 提了几个小问题。注意，不要把“业务设计争议”交给它自动修，除非你非常清楚自动修复边界。
/schedule [description] 则用于例行任务。官方说明里，它可以创建、更新、列出或运行 routines，这些任务运行在 Anthropic 管理的云基础设施上，并且 Claude 会通过对话引导你完成设置。
适合：
/schedule 每周一上午扫描项目依赖风险并生成报告
或者：
/schedule 每天检查主分支 CI 状态，总结失败原因
如果说 /schedule 是“定时闹钟”，那/loop 更像“当前会话里的循环观察”。官方文档把 /loop列为 bundled skill，可以在当前 session 保持打开时重复运行一个 prompt，比如每 5 分钟检查部署是否完成。
用法上可以记住：
当前会话里短期轮询，用 /loop。
长期、持久、例行任务，用 /schedule。
出了问题，不要第一反应重装。Claude Code 给了你两把排障工具：/doctor 和 /debug。
/doctor 是环境体检。官方命令表里，它用于诊断和验证 Claude Code 安装与设置，结果会用状态图标展示；还可以按 f 让 Claude 修复报告出来的问题。
适合这些情况：
登录状态异常。
MCP 连接不正常。
权限规则不符合预期。
终端显示或快捷键异常。
某些命令突然不可用。
直接跑：
/doctor
/debug [description] 则更像打开黑匣子。官方说明中，它会为当前 session 启用 debug logging，并通过读取 session debug log 来排查问题；如果你不是用 claude --debug 启动的，运行 /debug 会从当前时刻开始捕获日志。
比如：
/debug MCP server keeps disconnecting after tool call
这样比“Claude 怎么又坏了”有效得多，因为你给了它明确的故障现象，它可以沿着日志去查。
最后，一定要讲自定义斜杠命令。
内置命令解决的是通用问题，自定义命令解决的是“你们团队反复做的事”。比如你每次 review 都要贴一长串标准：
检查边界条件。
检查日志是否泄露隐私。
检查是否补测试。
检查接口是否兼容旧版本。
检查有没有违反团队目录规范。
这不应该每次复制粘贴。它应该变成一个命令。
官方文档说明，自定义 slash commands 本质上就是 Markdown 文件，放在指定目录里；文件名去掉 .md 后就是命令名，文件内容定义命令行为，还可以用 YAML frontmatter 提供配置。项目级命令可以放在 .claude/commands/，个人级命令可以放在 ~/.claude/commands/。不过官方也说明，.claude/commands/ 现在属于 legacy 格式，推荐的新格式是 .claude/skills/<name>/SKILL.md，但 CLI 仍然支持两种格式。
一个最简单的项目级命令：
mkdir -p .claude/commandstouch .claude/commands/review-api.md
写入：
---description: Review API changes before mergeallowed-tools: Read, Grep, Glob, Bash(git diff *)---请审查本次 API 相关变更，重点检查：1. 是否破坏向后兼容2. 是否缺少参数校验3. 是否存在权限绕过风险4. 是否泄露敏感日志5. 是否补充必要测试当前 diff：!`git diff HEAD`
之后你就可以直接输入：
/review-api
更进一步，自定义命令还支持参数。官方文档展示了 $1、$2 这类占位符，用来接收命令后的参数；例如 /fix-issue 123 high 可以让 $1 等于 123，$2 等于 high。
社区常用的 $ARGUMENTS 也是同一类思路：把命令后面的整段文本传进去。比如：
---description: Generate migration planargument-hint: [module-name]---请为以下模块生成迁移计划：$ARGUMENTS要求：- 先列出影响范围- 再列出迁移步骤- 最后列出验证方式- 不要直接修改代码
调用：
/migration-plan user-auth module from JWT to session cookie
自定义命令真正的价值不是少打几个字，而是消除“提示词漂移”。同一件事，每个人口头描述都不一样，Claude 的执行也会飘；沉淀成 Markdown 命令后，团队标准就从“口口相传”变成了“可版本化、可审查、可复用”的工程资产。
官方现在更推荐使用 Skill 形态来扩展 Claude Code：一个 Skill 由 SKILL.md 组成，包含 YAML frontmatter 和 Markdown 指令；目录名会变成你调用的命令名，description 会帮助 Claude 判断什么时候自动加载。Skills 还支持辅助文件、动态上下文注入，并且只有在使用时才加载正文，避免长期占用上下文。
所以，如果只是一个轻量快捷命令，用 .claude/commands/*.md 很快。
如果你要做成团队长期复用的能力包，带模板、脚本、示例、参考文档，那就用 .claude/skills/<name>/SKILL.md。
写到这里，你会发现 Claude Code 的斜杠命令并不是一张“背诵表”，而是一套工作流语言。
刚进项目，用 /init 和 /memory 让 Claude 先理解规则。
开始复杂任务，用 /plan 先看方案。
执行过程中，用 /model 和 /effort 控制推理成本。
上下文变重，用 /context、/cost、/stats 观察油量，用 /compact 主动续航。
代码写完，用 /diff 看事实，用 /review 和 /security-review做提交前过滤。
大规模任务，用 /batch 拆给多个 Agent；收尾优化，用 /simplify 做质量清洁。
出了问题，用 /rewind 回退，用 /doctor 和 /debug 排障。
重复流程，用自定义命令或 Skill 固化下来。
这就是 Claude Code 从“聊天式编程助手”变成“可控工程协作系统”的关键。
自然语言负责表达意图，斜杠命令负责精确控制。你不需要一次记住所有命令，只需要先掌握最常用的那十几个。等你习惯了/compact、/plan、/diff、/review、/model、/memory，再回到纯聊天式使用，会明显感觉少了方向盘。
