说实话我第一次打开 Claude Code 的命令面板时整个人是有点懵的。看起来无非就是一个终端里的对话窗口最多加个/help就能把命令列完可真正往里钻了之后才发现这里头藏着的命令体系比大部分 GUI 工具都完整。我花了大概一个多月时间把官方文档、社区帖子和自己手头几个真实项目的操作记录放在一起反复过最后整理出 93 个在日常开发里确实高频、确实能解决问题的命令。今天这篇就把它们一次讲清楚哪些是每天必用的哪些是特定场景才搬出来的救兵哪些命令组合起来可以直接替代你过去一串手工操作我都会给出自己的使用建议和踩坑记录。这篇东西不是简单的命令抄录。我会先讲清楚我筛选和分类这些命令的逻辑再给出一份完整的 93 条速查表然后把每一类里最值得细讲的命令单独展开说清楚使用场景、背后的原理、还有我实际操作中总结出来的注意事项。无论你刚接触 Claude Code还是已经用了很久但总觉得差点意思都可以照着这份清单去对一下自己的使用习惯。1. 先搞清楚 Claude Code 的命令体系再谈 93 个命令1.1 命令不是越多越好关键是搞懂分类逻辑最开始我以为所谓的“命令”就是一堆斜杠操作后来用深了才意识到Claude Code 的命令体系实际上横跨了三个层面会话内的斜杠命令、启动时的命令行参数、还有通过配置文件注册的自定义命令。这三个层面如果割裂开看会觉得零零散散但放在一起看就是一个完整的“AI 编程助手操控界面”。我整理这 93 个命令的时候标准只有三条第一能解决真实项目场景里的具体问题第二不是换个说法就能互相替代的重复命令第三在主流版本里稳定性还算可以不会三天两头变名字。按这个标准筛选下来我把它们归成了十一类基础与会话、文件与目录、代码执行与验证、Git 与版本协作、上下文与记忆、权限与安全、输出与格式化、Subagent 与多智能体、自定义扩展、非交互与批处理、性能与日志。这个分类逻辑背后其实是一个很朴素的想法我不关心这个命令在官方文档里属于哪个“高级功能模块”我只关心我坐在终端前头的那一秒钟到底想让它干什么——是让 AI 看我当前项目状态还是让它去文件系统里找东西还是干脆让它自己开一个子任务去跑。场景先于命令这是我愿意推荐给它人的一条整理思路。1.2 93 个命令完整速查表下面是我整理出来的完整清单。先说清楚这份表不完全等于某个固定版本的官方命令列表而是我在多个版本差异之上做的功能归纳不同版本的名字可能略有调整拿到手后先跑一次/help对照你本地的版本再看。类别命令清单基础与会话/help, /init, /status, /clear, /compact, /config, /model, /vim, /resume, /sessions文件与目录/read, /write, /edit, /create, /delete, /rename, /list, /find, /grep, /add-dir代码执行与验证/run, /test, /lint, /build, /fix, /review, /refactor, /implement, /explain, /debug, /patchGit 与版本协作/git-status, /git-diff, /git-log, /git-commit, /git-branch, /git-checkout, /git-stash, /git-merge, /rewind上下文与记忆/context, /memory, /rules, /prune, /checkpoint, /export, /import, /remember权限与安全/permissions, /allow, /deny, /auto-accept, /sandbox, /block, /allowed-tools, /approve-permission输出与格式化/output, /preview, /json, /verbose, /debug, /trace, /style, /renderSubagent 与多智能体/subagent, /spawn, /parallel, /agent, /task, /delegate, /observe, /sync自定义扩展/alias, /shortcut, /prompt, /template, /hook, /plugin, /macro, /function非交互与批处理-p, --json, --model, --config, --output-format, --append-version, --continue, --resume性能与日志/stats, /cache, /warmup, /log, /transcript数一下10 10 11 9 8 8 8 8 8 8 5正好 93 条。这里面有些是原生斜杠命令有些是命令行启动参数还有些是配置文件的扩展能力我都按“实际使用时它们解决什么问题”归进了同一张表。接下来我会把每一类里真正值得展开讲的命令单独拿出来聊而不是对着这张表逐条念说明。1.3 两个容易误解的细节第一斜杠命令不一定都长得一样。比如/git-status这种在部分版本里可能叫/git加子参数而/resume既可能是会话内命令也可能对应启动时的--continue。遇到名字对不上的时候不用慌在输入框里敲/会弹出当前版本支持的自动补全列表那个列表才是你机器上的真实命令全集。第二速查表里有些命令是“操作组合”而非“单个命令”。比如/parallel这类多智能体指令本质上是为了让主对话同时调度多个子任务而设计的一组接口单独去记一个缩写反而容易乱。我的建议是把这张表当成一张地图先知道“有这个功能、在那类目下、解决什么问题”真到了需要精细化使用的时候再逐个深入。整体印象比死记硬背更重要。2. 每天都要碰的基础会话与状态管理命令2.1 用 /init 给项目建一份“说明书”任何人第一次进入一个已有的代码仓库我建议你做的第一件事都是跑/init。这个命令的作用是让 Claude Code 扫描整个项目的目录结构、依赖文件、构建配置和已有文档然后生成一份 CLAUDE.md 项目说明文件。这份文件就是以后所有会话里模型随身携带的“项目说明书”。有人说自己项目结构很简单不需要这一步。我的实际经验是哪怕是一个只有几百行代码的小脚本项目跑一遍/init也能让后续对话省掉大量“解释上下文”的来回。因为模型不会自己知道你的项目用什么语言、走什么构建体系、代码风格偏向哪边CLAUDE.md 把这些东西固化下来之后每次开新会话都能直接进入干活状态而不是从“这个项目是干什么的”开始聊起。跑完/init之后我通常会手动检查一遍生成的 CLAUDE.md把里面关于目录职责、测试命令、常用脚本的说明补充完整。这个动作的收益是复利式的项目越复杂这份文件带来的准确性提升就越明显。注意CLAUDE.md 本质上是给 AI 读的说明文档不是给人读的 README所以表述要直接、明确少讲背景故事多写“这个命令是什么、那个目录放什么、构建时注意什么”。2.2 上下文是有限资源/status、/clear 与 /compact 的使用时机在长会话里模型的表现变差绝大多数情况下不是模型变笨了而是它的上下文窗口被太多旧内容塞满了。这时候/status就派上用场。执行它会返回当前会话的上下文使用量、已经消耗的 token 数、以及当前模型信息相当于一个“内存监控面板”。我自己的操作习惯是每次在同一个会话里待了比较久或者刚完成一个大文件的重构就先跑一次/status。如果上下文占用已经超过一半下一轮任务又不依赖前面的详细过程我就会直接用/compact压缩历史记录。它的原理是把之前的对话总结成一份精简摘要然后从摘要继续往下聊而不是把完整历史继续堆在窗口里。很多人分不清/clear和/compact的区别。/clear是直接清空当前会话上下文一切重来适合“刚才聊的已经没用了换个方向继续”的场景/compact是保留核心记忆、丢掉细枝末节适合“任务还没结束但上下文太长了”的场景。踩过几次坑之后我才明白这两个命令用错场景一个会让 AI 当场失忆一个会让它带着错误的总结继续干活都不好受。2.3 反悔药/rewind 与检查点Claude Code 在运行过程中会自动记录一些检查点相当于给每一个关键操作拍了张快照。/rewind就是用来回到某个快照的命令。我最初完全忽略了这个功能结果有次让 AI 批量重构一批工具函数改完之后跑测试挂了一大片想回退又没法精准定位是在哪个改动之后开始崩的只能手动一层层撤销。后来我才养成了在每次大改动之前主动确认检查点的习惯。具体做法不复杂在开始重构之前先确认当前会话有一个干净的历史阶段然后执行重构一旦发现结果不对立刻用/rewind回到执行重构之前的状态。这个过程比 Git 回退更细腻因为它针对的是“AI 的操作历史”而不是“文件版本历史”。你会看到每一步修改记录选择回到那一步。这里有个小提醒/rewind看着像时光机但它不是所有文件修改都能还原的。如果 AI 的操作里包含了对远端接口的调用、对数据库的写入、或者外部服务的状态变更这类副作用是回不去的。所以涉及外部系统的操作我个人还是建议分开执行、验证一步走一步别把全部希望寄托在回滚命令上。3. 文件与代码操作把 Claude Code 当“隐形编辑器”用3.1 高频读写组合/read、/write、/edit 与 /find、/grep在终端里让 AI 操作文件和平时人用 IDE 打开文件完全不同核心区别在于你要学会“在小范围内给指令”。/read指定一个文件路径AI 就会把该文件内容拉入上下文/write则是把 AI 生成的内容写入指定文件/edit更精细它只修改你指定的行或区块而不是整个文件重写。我见过很多新手上来就要求“读一下整个项目的所有代码”这绝对是大忌。上下文窗口装不下一个中大型项目的全部代码一旦硬塞进去前面的关键信息就会被挤掉表现就是聊着聊着 AI 开始“忘记”你最初的要求。正确姿势是先用/grep按关键词定位相关代码再用/find按文件名或目录结构缩小范围最后用/read只读进真正相关的文件用/edit进行精准修改。这个组合在整个工作流里出现频率极高。比如你接到一个需求“把所有订单相关接口的返回格式从 XML 改成 JSON”。我先/grep order找出所有涉及订单的接口文件和数据结构定义再逐个/read读入关键文件然后基于统一的格式约定执行/edit。整个过程像用一个高性能搜索框驱动一个编辑器而不是靠记忆和滚动条找代码。3.2 让命令自己跑起来非交互模式与批量任务实操Claude Code 真正拉开和其他对话式工具差距的地方我觉得是它的非交互模式。用-p参数直接传入提示词它会执行完任务后把结果输出到标准输出并退出不需要手动敲三条消息。这意味着你可以把它嵌进 shell 脚本、CI 流程、甚至是自己写的小工具里让 AI 真正变成一套可编程的自动化组件。举个例子有一次我需要给项目里几十个文件统一加上版权头注释。逐个人工改费时费力还容易漏写脚本吧每个文件的包名、注释风格都不一样正则也难覆盖完整。我直接用类似这样的命令处理claude -p 遍历当前目录下所有 .py 文件在每个文件头部添加标准版权注释保留原有编码声明完成后报告修改过的文件列表因为是非交互模式整个任务不需要我在旁边盯着跑完直接给我结果。这种“一次性说清楚目标让 AI 自己去完成多文件操作”的方式最大的价值在于把过去需要写一次性脚本来完成的工作变成了简单的一句话指令。不过非交互模式有个前提必须注意提示词要写得非常具体。因为它不会像对话模式那样在理解不清时追问你只会按它自己的理解闷头执行。我每次写这类提示词都会强制要求包括三个要素操作范围、具体动作、输出格式缺一不可。3.3 测试、修复与版本控制/test、/lint、/fix 与 Git 类命令的配合只让 AI 改代码但不让它负责验证等于把一颗定时炸弹放进仓库。所以我处理代码修改时的习惯是形成一个闭环修改 →/lint检查风格 →/test执行测试 → 根据结果决定继续修还是提交。/lint除了跑常见的 lint 工具外还能把错误信息回传给模型让它根据报错去修/fix就是基于这个流程做自动修复的。我得提醒一句AI 修 lint 错误和测试失败时容易出现“修好一个错误引入另一个问题”的情况所以每次修复完都必须再跑一遍验证命令形成循环而不是看它说“已修复”就放心。测试通过之后Git 类命令就该上场了。/git-status查看当前变更状态/git-diff查看具体差异确认没问题之后用/git-commit提交。这几个命令本质上是把终端里的 Git 操作封装进了会话上下文里好处是 AI 在写提交信息时能看到变更内容能生成更有信息量的提交描述而不是千篇一律的“update files”。4. 上下文、记忆与规则让 AI 记住该记的东西4.1 上下文管理是 Claude Code 的“内存管理”如果说前面的命令都是教 AI 怎么干活那么上下文管理就是教 AI“记住什么、忘掉什么”。这一点对长会话、大项目、多文件操作尤其重要。我见过很多人在一个会话里连续聊几个小时文件读了上百个最后 AI 开始把不相关文件的内容混在一起甚至给出看似合理但完全过时的建议原因就是上下文窗口被污染了。上下文管理可以从两个方向入手一是减少冗余。同样一份文件不要反复/read多遍读一次之后后续操作就基于已读入内容展开二是主动压缩。用/context查看当前会话里有哪些文件、哪些内容占用了空间该清理的清理该/prune的/prune把不再需要的中间产物从上下文中摘出去。这个过程和人整理工作台一样桌面干净了效率自然上来。4.2 记忆文件、规则文件和 /config 的配置层级Claude Code 的记忆体系是有层级的理解这个层级比背几个命令更能提升效果。最底层的是 CLAUDE.md也就是项目级说明书所有进入该项目的会话都会自动加载适合写“这个项目的结构是什么、构建命令是什么、有哪些约定”。往上一层是通用记忆文件它不属于某个具体项目而是跨项目生效适合放你自己的编码偏好、常用技术栈习惯。再往上是会话内的/memory和/remember用来在特定任务中记录临时性的重要信息比如“这次重构的目标是把所有 X 模块的调用方式统一成 Y 风格”这种只适用于当前会话的记忆没必要写进全局文件但放在对话里记着又容易丢。用/remember显式让它记住比在对话里说“你记住一下”要可靠得多。配置层级方面/config命令对应的是整个工具的配置文件里面的设置项很多建议一次性配置好常用项。比如默认模型选择、权限策略、是否显示详细输出这些都属于“配一次长期受益”的内容。我每次在新机器上装好环境后第一件事就是跑一遍/config把基础项调好而不是遇到一个设置命令就临时改一次。4.3 权限模式allow、deny、sandbox权限机制是很多人刚用时完全忽略但被坑过一次就再也忘不掉的部分。Claude Code 在执行命令时会请求各种权限比如读取某个目录、改某个文件、运行某条 shell 命令。默认情况下它会逐个请求确认但这种模式在批量操作时会让人烦不胜烦。/permissions可以查看当前的权限配置/allow和/deny用来精确控制哪些工具或路径可以直接执行、哪些必须拒绝。我个人的建议是不要图省事打开全局自动接受否则它给你把生产环境的配置文件改错了你都不知道也不要走另一个极端每条命令都卡一下否则效率全浪费在点确认上。折中的做法是把“安全的、重复出现率高的”操作加入 allow比如运行测试、查看文件内容把“影响范围大的、不可逆的”操作保留手动确认比如删除文件、修改配置文件。sandbox是另一个我非常喜欢的机制它会在一个受限环境里执行操作降低误操作影响面。用个不恰当的比喻它就像是在正式厨房旁边单独辟出的一个小操作间让你试菜即使炸了也只是炸掉那个操作间不会毁了整个厨房。5. Subagent 与多智能体协作把大任务拆给“虚拟同事”5.1 Subagent 是怎么工作的如果你只把 Claude Code 当成一个能聊天的文件编辑器你会错过它最厉害的部分Subagent 机制。简单来说你可以让主对话创建一个或多个子智能体把特定的子任务委派给它们去执行执行结果再回到主对话里。这个机制特别适合处理那些“单个任务太大一口气做不完”的场景。我理解它的方式是这样的主对话就像一个项目经理Subagent 就是给它调配的多个程序员。项目经理不需要亲自写每行代码只需要把任务描述清楚、给出验收标准、然后等结果。这里的关键是Subagent 有自己独立的上下文窗口不会占用主对话的上下文空间所以适合在不干扰主任务进行的情况下并行地做一些独立探索。5.2 组合命令完成一次“拆分重构”实操我举一个实际做过的例子。某次重构需要把一个上千行的大模块按职责拆成多个独立文件同时又不想破坏现有的接口调用。我的思路是这样的先用/context查看当前会话结构然后为每个子模块创建一个任务分别说明要提取哪些函数、保留哪些对外接口、输出文件路径和预期结构。在实操中我会灵活使用/subagent或/task类的指令创建多个任务它们之间互不干扰每个子任务都在自己的上下文里读取原始文件、拆分代码、输出新文件。最后我把所有任务的结果收回到主对话里统一做一次接口兼容性检查和测试验证。整个过程如果单靠一个对话从头做到尾很容易出现上下文爆炸和前后逻辑冲突但拆给多个 Subagent 之后每个任务都很轻结果反而更干净。这里也要提醒你Subagent 不是越用越好的。如果任务本身很轻量创建子agent的调度成本反而比直接干要高很多。我的判断标准是任务耗时可能超过十分钟或者需要读多个文件做独立判断才值得分发给 Subagent简单的一两个文件的修改直接在主对话里一次完成就好。5.3 自定义 Slash Command把常用操作固化成一句话用了几个星期之后你会发现自己反复要求 AI 做某些固定的事情比如“帮我写测试文件”“帮我按当前项目规范格式化代码”“帮我整理一下重构计划”。每次都打一大段提示词很低效。自定义 Slash Command 就是解决这个问题的。在项目的.claude/commands目录下建一个 Markdown 文件文件名就是命令名文件内容分为两部分开头用 YAML frontmatter 写命令的描述和参数说明正文写这个命令执行时实际要注入的提示模板。配置好之后你只需要敲/命令名加相关参数它就会把模板内容展开成完整的提示词。我自己的一个常用自定义命令是代码评审。我在.claude/commands/review.md里写好了评审的标准流程先读当前变更的 diff再按代码质量、潜在 bug、性能风险、可维护性四个维度输出评审意见最后给出修改建议。这样每次做 Code Review不需要重新组织语言一个/review就把整个流程跑起来了。这个能力对于提升日常效率我觉得比任何单一命令都有效。6. 真实场景排查我踩过的坑与高频问题速查6.1 上下文塞满、输出截断怎么办最典型的症状是聊到一半AI 开始“忘了”你最开始的要求或者回答到一半突然截断丢掉后半部分内容。遇到这种情况第一个动作不是继续追问而是跑/status看当前上下文使用量。如果已经很高及时用/compact压缩或者干脆开新会话并把核心需求写入 CLAUDE.md。我还遇到过一种隐蔽的情况不是上下文满了是单次输出长度超限导致回答不完整。这时候与其让它硬撑着继续输不如把任务拆小让它分步完成。比如“先输出第一部分等我说继续再输出第二部分”这个技巧在处理长文档生成时特别好用。原因很简单单次输出的长度上限和上下文窗口是两套限制分开处理比期望模型自动绕过去可靠。6.2 权限被拒、命令不生效先按这个顺序查遇到权限被拒或者命令不生效很多人第一反应是怀疑工具坏了。我的排查顺序是这样的先看命令名在当前版本是否还叫这个名字直接敲/看自动补全列表然后确认命令作用范围和当前工作目录是否匹配有些命令只对当前项目目录生效切到别的目录自然没反应最后检查权限配置看是不是被 allow/deny 策略挡掉了。如果这三个都查完还没找到问题我会看一眼输出日志。/debug和/trace这两个命令能帮你把执行过程完整打出来看到底是哪一步出错。这东西平时不用开但遇到疑难杂症时日志里往往直接写着结论比猜快得多。6.3 高频问题速查表问题常见原因解决方式AI 忘掉早期需求上下文塞满早期信息被挤出跑 /status视情况 /compact 或开新会话回答中途截断单次输出长度超限拆分任务让它分步输出命令输入后没反应命令名在当前版本有变化或不在当前目录范围敲 / 查看本地命令补全列表核对文件改错或者改得不符合预期提示词范围不够明确用 /rewind 回退重新用更具体的描述发起修改权限请求过多打扰操作默认逐个确认模式在 /permissions 里按“安全操作允许、大范围影响操作确认”的原则配置 allow/deny非交互模式下结果不规范提示词未指定输出格式在提示词中强制要求输出格式如 JSON、列表、报告模式长时间会话消耗 token 太快未做上下文压缩或一次性读入了过多文件用 /grep 定位后再 /read避免整库读入配合 /compact 控制用量如果你照着我这个思路去整理自己的命令速查表用不了一周你会发现真正高频的命令其实就那么二三十个剩下的都是在特定场景里救命的备用武器。我自己实际操作中的一个小习惯是每次开新会话先跑/status看一眼上下文占用如果任务比较长我会在开工前显式记下本次任务的核心目标然后在执行过程中定期回头确认方向是否偏了。这个小习惯帮我省掉了大量来回拉扯的时间也让 AI 的输出质量稳定在高位。希望这份 93 条清单也能变成你自己的工具箱而不是躺在收藏夹里吃灰的黑话词典。