很多人第一次打开 Claude Code会下意识把它当成一个能聊天的终端框敲一句需求等结果再敲一句再等结果。这么用当然也能跑通但你很快就会撞上几堵墙——对话一长上下文迅速爆满Claude 开始忘记项目结构和前面说好的约定任务只是改一个函数它却把整个目录都扫描了一遍token 烧得飞快遇到要连续改十几个文件的重构做到一半状态就乱套了。原因很简单Claude Code 不是一个聊天框它是一个以对话为驱动、能读写文件、能执行命令的 Agent 工作台。而在终端里唯一能主动控制它的方向盘就是那几十条斜杠命令。用好这些命令工作流会从能跑变成高效且可控用不好就会陷入上下文爆炸、成本失控、权限过宽的三重陷阱。这篇我会基于自己每天在终端里的实际使用经验挑出 14 个最值得记住的命令逐个说清楚它们干什么、什么时候用、以及边界在哪里。适合两类人看一类是刚装好 Claude Code、还停留在提问—回答阶段的入门用户另一类是已经在用、但总觉得上下文和成本控制不住的进阶用户。文末我还放了三套可以直接抄的组合工作流供你对照自己的场景调整。1. Claude Code 的命令体系会话、上下文、权限三类控制面1.1 会话线对话状态由你决定而不是 AIClaude Code 每次启动都会形成一段会话这段会话里保留着历史消息、临时约定、上下文窗口占用等状态。很多新手会默认模型自己知道什么时候该压缩、什么时候该清理实际上它非常被动——上下文窗口不爆它就继续往里塞窗口满了它才开始丢记忆而且丢得毫无章法。所以会话线的核心操作必须由人主动完成。/status告诉你当前占用多少/compact帮你压缩历史/clear直接重置。这三条命令拼在一起就是一条完整的会话生命周期管理链路。你要做的不是等 Claude 提示上下文快满了而是养成固定节奏开工前查状态、任务过半做压缩、任务切换就清理。我见过不少人的做法是等系统提示或者感觉回答开始变差才去处理这个时机其实已经偏晚了。因为上下文接近极限时模型的注意力会被大量旧内容稀释回答质量早就开始悄悄下滑只是你没对比过所以察觉不到。提前干预比事后补救省心得多。1.2 上下文线模型能看到什么边界就在哪里上下文窗口是 Claude Code 最宝贵的资源之一。模型要完成任务就必须把相关文件内容、git diff、工具输出、历史对话都塞进这个窗口里。你会发现它经常主动去读文件这不是啰嗦是它在构建理解。高效工作流的本质就是控制上下文里的材料配比该进的信息进不该进的别进。/init和/memory管的是一类长期上下文——CLAUDE.md 记忆文件。/permissions管的是模型能读取哪些路径、执行哪些操作。这两条线合起来就划定了模型的视线范围。1.3 权限线能力越大越要明确不能做什么Claude Code 不仅能回答问题还能执行 bash 命令、修改文件、运行测试。这些能力用好了是效率用不好就是风险。权限线要解决的就是模型可以在哪里动手、动手到什么程度、哪些操作必须经过确认。/permissions和/config是这条线上的两个主要控制点。它们决定了 Claude 是只读地分析代码还是直接改完代码再跑测试给你看。不同场景需要不同的权限粒度这个后面我会展开讲。2. 日常会话不翻车的 5 个命令/init、/memory、/status、/compact、/clear2.1 /init用 CLAUDE.md 给项目立规矩/init会扫描当前项目的结构、代码风格、依赖工具链然后生成一份 CLAUDE.md 文件。这份文件是项目的长期记忆以后每次启动会话模型都会自动加载它。你可以把技术栈、构建命令、代码风格约定、禁止事项、部署注意事项等等都写进去。我第一次用/init的体感是它生成的模板很完整但和我项目的实际情况还是有偏差。所以我强烈建议/init执行完之后一定要手工过一遍这份文件把里面的错误描述改掉把你真正在意的约定加进去。比如我有个项目里明确约定了不允许用any类型测试命令必须走 pnpm test:unit这些一旦写进 CLAUDE.md后面所有会话都会遵守省去了每次重复交代的功夫。但要画一条边界不要在项目已经跑起来之后反复执行/init。它每次生成都会尝试重写这份文件而你手工优化的内容很可能在重写中被覆盖掉。我自己踩过这个坑——项目进入重构期后我在 CLAUDE.md 里手工维护了一整套重构约定某次手滑在根目录又执行了一次/init它直接把文件重置成了模板结构我那条最关键的先迁移 utils 再迁移 services的约束没了导致下一个会话开始后 Cloude 又按自己的理解乱动代码。现在的做法是/init只在项目初始化时用一次之后全部手工维护每次改动都走 git diff 审查。2.2 /memory先确认 AI 记住了什么/memory会显示当前会话加载了哪些记忆文件——包括项目层的 CLAUDE.md、用户层的全局记忆、以及可能挂载的其他记忆来源。这个命令的价值在于确认不是设置。它让你在开工前就知道模型现在看到了哪些长期材料有没有你想让它记住但实际没加载进去的东西。我习惯在每个任务开始前先敲一次/memory尤其是换新机器、克隆了新仓库、或者团队里有人改了 CLAUDE.md 之后。有一个很典型的场景同事更新了项目的 CLAUDE.md加入了新的代码生成规范但我这边的会话还是旧的加载状态用/memory一看才发现加载的还是旧版本。这时候重启会话或者确认加载路径就非常关键。边界也要说清楚记忆文件不等于强制规则。模型有可能在长对话的后期忽略记忆里的某条约束尤其是在上下文占用很高的情况下。所以重要的、不可妥协的约束我除了写进 CLAUDE.md还会在当次对话开头再明确说一遍。双保险才是真保险。2.3 /status上下文占用是一块实时仪表盘/status显示当前对话的上下文占用情况包括 token 使用量、窗口占比等信息。这个命令看起来不起眼但它是控制工作流节奏的核心仪表盘。我的习惯是在开始一个大任务之前先看一次任务进行中每隔一段时间再看一次。如果上下文占比到了 70% 左右我就会主动考虑是压缩还是清理。有些朋友会觉得Claude Code 不是会自动处理吗其实自动处理只是极限情况下的兜底那时候模型已经在丢三落四地工作了你后面说的话它可能只记住了最后几句。/status的边界在于它反映的是上下文窗口占用不是实时的磁盘状态也不是费用消耗。而且不同版本的统计口径可能略有差异有些版本只统计主模型的 token不含工具输出和系统提示。所以你用它做相对判断就好看到比例高就准备干预看到比例低就可以安心继续不用纠结具体数字的精确性。2.4 /compact 与 /clear压缩还是重来关键看任务连续性/compact会把当前对话的历史压缩成一份摘要释放上下文空间同时保留任务的核心脉络。/clear则是清空整个会话历史一切归零。两者最核心的区别就是任务还要不要延续。任务还在同一方向上推进就用/compact。比如你在做一个大模块的开发已经讨论了十几个文件上下文快满了但需求还没做完这时候压缩历史是最优解。压缩完之后模型会带着一份摘要继续工作之前的关键决策不会完全丢失但细节肯定会被抹掉一部分。任务已经完成或者当前对话已经跑偏到没法救就用/clear。清理之后是一个全新的会话所有临时约定都会消失但 CLAUDE.md 里的长期记忆还在。所以/clear之前我有个固定动作如果当前会话里产生了值得保留的约定先把它写进 CLAUDE.md再执行清理。不然下次会话模型又得从头摸索。关于/compact我也要说一个真实教训。有一次修一个线上 bug已经定位到是一个缓存目录把配置文件写坏了。我用/compact压缩了上下文之后模型把之前确认过的错误文件路径记串了后续改动全部指向了另一个相似命名的目录导致我的修复方案全部白做。从那以后我形成了一条经验压缩之后如果任务里有关键的绝对路径、关键文件名、关键约束最好在压缩后的第一条消息里重新强调一遍。宁可多花几十个 token也不要让模型凭模糊记忆瞎猜。维度/compact/clear上下文压缩为摘要释放空间全部清空任务延续性适合任务继续推进适合任务收尾或重开临时约定可能丢失细节全部丢失CLAUDE.md不受影响不受影响推荐时机上下文占用过高但任务未完成上下文混乱或任务切换3. 成本和模型的控制权/model、/cost、/help3.1 换模型的时机比模型本身更重要/model可以在会话中直接切换模型。Claude Code 生态里有不同能力梯度的模型可选能力强的更适合复杂推理和架构设计轻量模型则更便宜、响应更快。我的选择逻辑一般是这样做方案设计、代码重构、复杂 bug 定位用能力强的模型做格式化、改文案、解释报错、重命名变量这类琐碎工作切到轻量模型足够。但这里要强调一个被很多人忽略的边界——不要在任务中途随便切到低成本模型。有一次我让 Claude 用强模型梳理完了整个微服务的依赖关系并制定了重构步骤然后为了省 token我把模型切到了轻量档位让它按刚才的方案继续改。结果它读到的上下文是一样的但推理能力跟不上做出了一个和原方案完全不同的实现而且它在压缩后的摘要里遗漏了两个关键模块的耦合关系。正确切模型的时机是任务阶段切换点。比如架构设计阶段结束进入实现文件阶段或者问题定位结束进入批量修改阶段。在这些节点切换模型面对的任务复杂度相对稳定切换带来的质量波动会小很多。3.2 用 /cost 把 token 消耗变成可观测数据/cost会显示当前会话的 token 消耗和估算费用。很多人对这个命令不以为意觉得反正有配额看它干嘛。但我的经验是不看/cost的人往往对 token 消耗毫无体感看了之后才会慢慢建立起这个改动大概值多少钱的直觉。我会在每个子任务完成后瞄一眼/cost把它当成一次体感校准。比如你让 Claude 重构一个模块做完发现消耗了 2 万 token你就会记住这种规模的模块重构大概就是这个量级。下次规划预算时心里就有谱了。/cost的边界在于它是会话粒度的统计不代表历史所有会话的累计花费它也不具备实时拦截能力不能帮你阻止超支。它只是一个复盘工具控制预算还是要靠任务拆分、模型选择和权限限制。3.3 /help最快的命令是帮助本身/help会列出当前版本所有可用的命令以及快捷键、操作说明。这看起来基础得不像需要推荐但恰恰是很多人容易忽略的。Claude Code 的迭代速度很快命令和参数经常变化。与其背死记硬背不如在需要时直接/help看一眼。特别是当你发现某个斜杠命令行为和你预期不一致时先help确认一下最新定义比去网上搜一个过时的教程靠谱得多。它的边界在于帮助信息只覆盖当前版本内置命令不包含自定义命令的使用说明。另外帮助文档更新频率未必跟得上代码迭代个别新功能可能在文档里找不到这时候需要去官方更新日志或者社区里翻一下。4. 安全护栏与配置/permissions、/config、/mcp、/doctor4.1 /permissions权限粒度是安全底线/permissions用来查看和调整 Claude Code 的权限设置。你可以控制哪些操作需要弹窗确认、哪些操作自动放行还可以按路径、按命令类型做精细化的授权。它本质上是你和 Agent 之间的安全协商机制。我的默认配置是这样项目目录内的文件编辑自动允许bash 命令执行需要确认特别是删除、覆盖、推送这类高影响操作网络请求和外部调用逐次确认。这套配置平衡了效率和安全日常开发中不会频繁打断我但也不会让模型在没人盯着的情况下搞出大动静。边界必须画清楚权限太宽Agent 可能会顺手执行你不想执行的操作权限太窄每步都要弹确认框完全打断心流。我有一次为了省事把 bash 权限调到了自动放行结果 Claude 在重构时直接执行了删除旧版本目录的命令虽然它删的是正确的目录但我盯着终端看了好几秒冷汗直冒——删除范围覆盖了目标目录的父级再差一层就误删了。从那以后高危命令永远保持手动确认这个底线性原则我不建议任何人破例。4.2 /config自定义斜杠命令和别名的正确姿势/config可以打开配置管理界面用来调整全局设置、管理 MCP、编辑自定义斜杠命令。自定义命令的原理很简单把一段固定的 prompt 和参数组合存成一个斜杠命令之后敲一下就能复用。比如你团队有一套固定的代码审查模板就可以在项目的.claude/commands/目录下建一个codereview.md把审查流程、关注点、输出格式写进去。之后直接敲/codereviewClaude 就会按这个模板执行。同样如果你经常要执行一个固定的 Linux 命令组合也可以做成自定义命令省去每次输入一大串参数的麻烦。这里有个容易踩坑的地方配置修改之后不一定立即生效有时候需要重启会话或者重新加载配置。而且自定义命令只是 prompt 模板不是运行环境模板里写了错误的路径或者过时的命令Claude 照样会照着错的方向执行而且不会报错。我每次新建自定义命令都会先用最简单的项目试跑一遍确认它能按预期工作再放到常用项目里使用。4.3 /mcp扩展能力时先画好边界/mcp用来管理 MCP 服务器连接可以查看当前挂了哪些 MCP、状态是否正常、以及断开或连接指定服务器。MCP 协议是 Claude Code 扩展能力的重要通道通过它可以接数据库、接内部 API、接各种外部工具。但我要提醒一句接入 MCP 服务器等于把 Agent 的手伸进了外部系统。MCP 服务器本身会有自己的权限声明接入之前务必看清楚它请求了哪些权限。特别是那些要求全局文件访问或者任意路径读写的第三方 MCP风险非常高。我见过有人为了方便给某个 MCP 服务器配置了项目根目录的全读写权限结果这个 MCP 在一次同步操作里误改了配置文件。虽然最后通过 git 恢复了但那次经历之后我的原则是MCP 服务器的权限尽量按项目隔离能用只读模式就用只读模式能限定在单个目录就限定在单个目录。能力扩展和安全之间永远是先安全再扩展。4.4 /doctor环境问题定位的最后一张牌/doctor会收集当前系统的诊断信息用来排查安装、网络、身份认证、环境变量之类的问题。很多朋友遇到安装完成后启动报错或者API 请求一直失败的情况第一反应是上网搜教程但与其盲猜不如先跑一次/doctor看看到底是路径问题、密钥问题还是代理配置问题。它的边界在于/doctor只负责收集诊断信息不负责自动修复。而且它的输出里可能包含系统路径、用户名、配置地址等信息如果你截图或者复制到社区求助记得先对敏感信息做脱敏处理。我见过有人直接把/doctor输出整个贴出来结果把自己的家目录结构暴露得清清楚楚。5. 让代码场景更顺手的 2 个命令/review、/vim5.1 /review适合扫雷不适合替代人审/review会让 Claude 对当前代码做一次审查生成一份问题报告。它擅长发现明显 bug、未处理的边界条件、安全隐患、写法不一致这类问题。实测下来它对空指针风险、未初始化变量、危险的网络请求处理这些点非常敏锐能在你提交 PR 之前先做一轮自动化扫雷。不过它的边界也相当明确/review是静态分析视角它看到的是代码本身不是业务上下文。你代码里一个看似不合理的 return在业务逻辑里可能是正确写法一个变量名起得随意但背后有团队历史原因。/review会给它标记成问题这时需要你人工判断哪些是真正的问题哪些是误报。另外在大仓库里直接执行/review会消耗大量 token因为它要扫描大量文件。我的做法是先限定范围比如只审查src/services/目录下最近改动的文件或者只审查这几个函数。5.2 /vim 与终端里的 bash 执行给命令行老手的加速器/vim可以切换到 Vim 键位模式。如果你平时用终端工具就习惯 vim 键位这个模式会让你在编辑 prompt 时非常顺滑——不用鼠标纯键盘操作。但它的边界也很清楚只对 Vim 用户有正向收益。如果你不熟悉 Vim 模式打开之后反而会被insert 模式normal 模式搞晕连最基本的输入都变得别扭。所以我建议 vim 基础不牢的朋友不要开这个功能等哪天你开始主动想用 h、j、k、l 移动光标了再打开不迟。在终端里还有一个和/vim无关但同样提升效率的隐藏能力直接以!开头来执行 shell 命令。比如我经常敲!git status、!git diff、!ls src来快速查看当前状态这些命令直接在 shell 中执行不会占用给模型的主要上下文。热词榜单里大家常搜的 git 命令、Linux 命令其实都可以这样直接在 Claude Code 里用。你在让 Claude 分析之前可以先自己看一遍现场然后再把精准的问题抛给它。6. 实战组合三套工作流把命令串成闭环6.1 新项目冷启动/init /model /status 的组合新项目开工时我一般这样走第一在项目根目录启动 Claude Code先执行/init生成 CLAUDE.md。生成之后立刻手工编辑这份文件把技术栈、包管理器、测试命令、构建命令写清楚。这一步是整条工作流的基石后面所有会话都会受益。第二用/model选好主力模型。新项目通常涉及大量架构决策我会选能力强的模型来跑便宜的模型留到琐碎任务再用。第三任务进行中定期/status关注上下文占比。新项目上下文增长特别快因为 Claude 会频繁读取项目结构和新增文件。一旦发现占比偏高就用/compact保持会话延续性。这套组合的核心逻辑是先用/init建立稳定的项目记忆基底再通过模型选择控制成本上限最后用/status和/compact保持上下文始终处于健康区间。6.2 存量代码修复/memory /compact /review 的配合修存量代码最怕的是模型对项目已有的隐性约定一无所知。所以我的固定顺序是第一步先/memory看当前加载了哪些项目记忆。如果发现 CLAUDE.md 没加载或者内容过旧我会先处理记忆文件再开始诊断问题。第二步让 Claude 定位问题。这个过程通常会产生大量读写操作上下文消耗很快。我会在它定位到根因、准备动手修改之前先做一次/compact并且在下一条消息里重新强调关键路径和约束。第三步修改完成后用/review扫一遍改动重点看有没有引入新的边界问题。然后再自己过一遍改动因为/review只能发现代码层面的问题业务逻辑是否合理还得靠人。这套组合里最关键的一环是定位完成后、动手修改前的压缩节点。选在这个点做/compact既不会丢失定位过程中积累的关键信息又给后续修改腾出了充足的上下文空间。6.3 超长任务会话用边界防止上下文和时间双失控处理跨几天的超长任务时我最推荐的方式不是保持一个长会话而是拆成多个短会话接力。这是从多次翻车里总结出来的每个阶段结束前把该阶段的关键决策、未完成事项、下一阶段的入口条件全部写进 CLAUDE.md。哪怕只是临时加几条也值得因为这是不同会话之间传递信息的唯一可靠通道。然后新开一个会话继续。新会话上下文干净模型不会有旧内容的干扰记忆从 CLAUDE.md 加载信息密度反而更高。我做过一个连续五天的重构就是每天一个新会话每天晚上把当天进度和下一步计划写进 CLAUDE.md第二天早上开工直接继续。整个过程非常顺滑跟之前一个会话撑三天、最后两天 Claude 完全胡言乱语的体验是天壤之别。每个会话结束前我会用/cost看一下当天的 token 消耗记录到一个本地文件里。这不仅能复盘成本还能帮你判断任务的哪些环节特别烧 token下次可以针对性地优化。7. 命令使用边界与常见误区我把踩过的坑替你圈出来最后集中说一下使用边界。这 14 个命令没有一个能覆盖所有场景理解它们的边界比记住功能更重要。第一所有上下文管理命令/status、/compact、/clear都不是让模型思考得更好的工具它们只是让模型的记忆不冗余。压缩会丢细节清理会丢约定这是必然的代价。所以在任何上下文操作之后都要检查一遍关键信息是否还在。第二模型切换和权限调整这类命令影响的只是执行层不会改变任务的本质。换一个更强的模型不代表之前分析错的架构就能自动变对放开了权限也不代表 Claude 就更聪明。它们只是在成本—能力—安全这个三角里挪动位置。第三不要神话/review和自定义命令。/review是静态检查不是代码评审自定义命令只是 prompt 模板不是自动化流水线。真正让工作流高效的不是某一条命令而是你对命令时机的把握。第四关于省 token真正有效的手段不是频繁切模型而是减少无效上下文。权限收窄一点让 Claude 只读它该读的文件记忆写好一点让它不用反复问项目背景任务拆细一点让它每次聚焦一个小目标。这些做法比任何单个命令都更省 token。还有个很多新手容易犯的误区把/clear当成清理现场的工具遇到对话稍微变差就清。其实对话变差的根源往往是上下文里塞了太多无关内容或者任务本身就定义不清。前者可以/compact解决后者应该重新描述需求而不是简单清空。盲目的/clear会让你反复从零开始反而更浪费时间。Claude Code 的命令设计本质上就是把对话型 Agent变成可操控的生产力工具。这些命令单独看都很简单但组合起来就成了控制上下文、成本、权限和效率的整套方法论。希望这 14 个命令和它们的边界能让你在终端里干活时少一些失控多一些从容。
