我用 Claude Code 写了大半年项目最想吐槽的一点是网上所谓的命令大全大多是把帮助文档里的英文说明翻译一遍翻完你依然不知道什么场景该敲哪条更别提那些“全网最全”的说法往往只是把几十个命令往那儿一堆看着热闹实际用起来一头雾水。这篇我换个讲法先用一套逻辑帮你看懂命令设计的底层思路再把我自己整理过的 93 个命令入口分成四张表全列出来最后用几个我每天都在用的组合演示一遍。新手可以从第 2 节开始直接抄作业老手可以直接跳到第 3 节看组合用法保证每一段都对得起“实操”两个字。1. 命令设计逻辑搞懂这套思路93 个命令至少能少背一半1.1 斜杠命令的本质给对话预设“工作模式”很多第一次用 Claude Code 的人会觉得斜杠命令就是快捷键省得打几个字而已。但实际不是这样。斜杠命令更像是给这个对话预设了一个工作模式你敲下/review它知道接下来要把代码审查的标准提上来你敲下/init它知道要开始分析项目结构并生成规范文件你敲下/compact它知道你嫌弃上下文太长了要执行一次压缩。我习惯把它类比成你跟一个资深工程师之间的沟通方式。你要是直接说“帮我看看代码”他可能先问你十个问题但你要是递过去一张写好的检查清单他直接照着清单逐项过就行。斜杠命令就是那张清单它绕开了“猜测你意图”这一步让模型把精力花在执行上而不是理解上。另一个容易被忽略的点是斜杠命令的定义本身就是 Markdown 文件你可以自己往里边塞说明、示例、检查步骤。这等于你能定制一个新的“工作模式”给 Claude Claude Code 用。第 4 节我会专门讲这块怎么写这里先记住一个核心结论命令不是“少打字”的偷懒工具而是“明确意图”的控制手段。1.2 符号前缀、!、#背后的杠杆效应斜杠命令之外Claude Code 的输入框里还支持几类符号前缀很多人用了很久也不知道它们能干嘛。符号用来引用文件或目录。我实测下来这是上下文管理最重要的入口。你在对话里写“看看src/utils/format.ts的导出逻辑”它会把那个文件的内容读进上下文并围绕它回答。如果你引用的是一个目录它一般会先看目录结构再按需读取内部文件。这里有个细节直接用引用单个大文件没问题但一次引用整个目录尤其是上百个文件的目录可能会把大量无关内容塞进上下文反而干扰判断。!符号用来执行终端命令比如!git status、!npm test。它会真实地在当前工作区跑一次命令再把输出回传给你。这招在排查问题时极好用尤其是“看看服务现在挂没挂”“跑一下这个测试什么结果”这类需求不需要切出对话窗口就能拿到环境里的真实反馈。#的用法在不同项目里略有差异。官方层面#常被用来引用会话里的某条消息或者配合协作脚本做任务标记我自己的项目里也会把它当成 todo 标签用例如让 Claude 把待办事项都标注成#TODO开头方便我统一搜索。符号前缀之所以威力大是因为它们把“文件系统”和“终端命令”直接拉进了对话你不再需要把内容复制粘贴给模型而是把入口交给它。1.3 快捷键让双手留在键盘上终端环境本身有一批通用快捷键它们不是 Claude Code 独有却是日常使用中绕不开的。我列出了个人使用频率最高的几个组合说一个最容易踩的坑很多人发现对话卡住了就连续按CtrlC结果把整个进程都干掉了而不是中断当前输出。正确姿势是先按一次Esc或CtrlC看是否是中断当前生成如果发现退出了交互界面再考虑是不是按键按过头了。另外↑方向键翻历史这个习惯一定要养成。Claude Code 的会话上下文很长有时候你前面那句指令写得非常好直接翻上去微调比重新打一遍更高效。CtrlL清屏也很实用输出太长的时候清一下可以让注意力回到当前的提示符上。2. 命令全景拆解四张大表凑齐 93 个命令入口我按自己的使用习惯把 93 个命令入口分成了四类官方斜杠命令 25 个、符号前缀与快捷键 18 个、内置工具调用 12 个、推荐自定义命令 38 个。这个分类不是官方文档结构是纯粹的实战角度方便你在不同场景下快速检索。2.1 官方斜杠命令25 个命令用途我的使用频率/help查看内置帮助和相关说明偶尔/init初始化项目生成或更新规范文件新项目必用/new开启一个新的对话会话高/clear清空当前会话上下文高/compact压缩会话历史节省上下文空间每天数次/resume恢复之前的对话会话高/export导出当前会话内容低/import导入会话内容低/status查看当前执行状态与任务进度中/history查看历史操作记录中/add添加文件到上下文极高/drop移除上下文中的文件极高/context查看上下文占用情况极高/memory写入长期记忆内容中/todos管理待办清单中/agents创建或进入子代理模式中/permissions调整权限模式与白名单高/mcp管理 MCP 连接中/model切换当前对话使用的模型高/config打开用户级或项目级配置中/doctor诊断环境与安装问题偶尔/login登录账号低/logout退出登录低/vim切换 Vim 键位喜欢的人爱死/repl进入交互式解释器模式偶尔这 25 个是所有命令的地基。我的建议是优先吃透/add、/drop、/context、/compact这四个因为它们直接决定了你“喂给模型什么信息”。信息喂对了后面哪怕只用对话自然语言输出质量都能上一个台阶。2.2 符号前缀与快捷键18 个符号/快捷键用途提示文件路径引用具体文件进入上下文单文件最稳目录路径引用目录先看结构再按需读取注意目录大小!终端命令在工作区执行 Shell 命令真实操作谨慎使用#任务标签标记话题、待办或消息引用团队可统一约定“引用文本”强制按字面文本理解避免歧义CtrlL清屏输出过长时用CtrlC中断当前输出或退出交互按一次观察反应Esc取消/停止工具调用比 CtrlC 温和↑ / ↓翻阅历史输入频繁使用Tab自动补全路径或命令非常实用ShiftTab切换补全建议少数终端支持CtrlA光标移到行首通用终端快捷键CtrlE光标移到行尾通用终端快捷键CtrlU清除当前输入行打错整行时用CtrlK删除光标后到行尾的内容通用终端快捷键CtrlR搜索历史命令可以搜到之前操作CtrlD结束输入部分环境退出注意别误按CtrlZ挂起当前任务需要回到 shell 时救急这里特别说明一下和!是 Claude Code 交互层面的符号其余的都是终端通用快捷键。很多人会把“快捷键”这部分也算进命令数量里我觉得合理——毕竟指望命令行工具提效双手离不开键盘。2.3 内置工具调用12 个工具名用途Read读取文件内容ReadJson读取结构化 JSON 或数据文件Write写入新文件Edit对现有文件做局部修改Bash执行 Shell 命令Grep全文检索目标内容GrepJson在 JSON 文件里检索字段Glob按通配符匹配文件路径LS列出目录内容TreeSearch按语义检索或组织目录信息WebSearch联网检索资料WebFetch抓取网页文本内容这 12 个工具并不是让你像敲命令一样手动触发而是说明 Claude Code 在对话过程中“可以调用的能力边界”。我为什么把它们列进命令表因为当你用自然语言提问时它极可能就是在背后调用这些工具。理解了这一点你发出的指令就会更精准你想让它在几十个文件里找某段逻辑直接说“用 Grep 搜一下关键字”而不是含糊地说“帮我找找那个东西”。2.4 推荐自定义命令38 个推荐命令用途/review对最近改动做代码审查/commit生成符合规范的提交信息/test运行相关测试并分析失败原因/debug输入报错信息逐步排查/refactor重构指定模块并保持行为一致/cleanup清理无用文件与死代码/doc为模块生成文档与注释/setup初始化本地环境与依赖/release执行发布检查与版本收尾/fix读取报错给出修复方案和执行建议/explain解释一段代码的运行逻辑/diagram用文字描述模块关系或流程/estimate评估开发工作量与风险点/risk检查需求中的潜在技术风险/roadmap把需求拆成分阶段任务/api生成或更新接口定义/db生成数据表结构与索引建议/deploy检查部署配置和执行发布步骤/rollback评估回滚方案并执行/audit检查依赖安全与配置问题/lint按规范检查代码风格/format自动格式化代码/plan将大任务拆成执行计划/summary总结当前会话结论/i18n补全或检查多语言文案/schema生成或校验数据结构定义/cache分析缓存策略问题/log分析日志并定位异常/monitor生成服务监控检查项/sync同步配置或数据/update升级依赖并处理变更/feature为新功能编写实现方案/bug按 Bug 模板收集信息/hotfix紧急修复流程/env查看和管理环境变量配置/seed生成测试种子数据/mock生成接口 Mock 数据/e2e生成端到端测试要点这 38 个命令并非开箱即用需要你自己在.claude/commands/目录下创建对应的 Markdown 文件它们才会出现在斜杠命令列表里。我给了推荐命名和用途你可以直接照着建。第 4 节我会演示一个完整的自定义命令写法这里先有个概念自定义命令就是把“你经常重复说的一大段话”压缩成一个斜杠指令属于收益最高、门槛最低的效率提升手段。3. 高频命令实测能立刻提效的五个组合3.1 组合一/init CLAUDE.md把项目基因写进去新接手一个项目我做的第一件事永远是/init。它会在项目根目录生成或更新一份CLAUDE.md里面记录着项目结构、技术栈、构建命令、代码规范。很多人把它当成一份给 Claude 看的说明书这理解不够。我更愿意把它理解为“项目基因”——每次新开会话Claude Code 都会自动读取这份文件相当于让每个新会话都带着同一个记忆底座。我实际测试过两个对照场景。同一个项目在没有CLAUDE.md的情况下让 Claude 写一个新的 API 接口它会给出一版中规中矩的代码但目录结构、命名风格跟现有代码总有出入。等我用/init生成了规范文件又手动补充了“本项目使用函数式组件禁止类组件”“状态管理统一走某个库”这两条后第二次让它在同一项目里写同样的接口生成的代码几乎可以直接合入。差异就是这么明显所以我每次进入项目的第一条命令永远是/init。这里有个注意事项/init生成的文件不要迷信它只能基于目录结构和已有代码推断不一定能覆盖你团队真正约定俗成的规则。正确做法是生成之后手动改一遍把最能代表这个项目风格的 10 到 20 条规则写进去越多越杂反而让模型抓不住重点。3.2 组合二路径 /add精准投喂上下文Claude Code 的上下文窗口是有限的这决定了你不能把半个项目都塞给它。我最常用的操作顺序是先src引目录让它看结构定位到相关文件后马上用/add把具体文件加进上下文再用/drop把无关内容踢出去。这套组合的核心是“够用即可”。比如我要改一个支付回调接口通常上下文里只需要路由文件、对应的控制器、相关的模型定义、以及接口文档片段。至于不相关的工具函数、配置文件别加。我踩过的坑是为了图省事把整个src目录通过丢进去结果 Claude 输出的代码看着结构挺完整但把几个无关模块的旧函数误当成依赖生成了根本不该存在的引用。那不是模型蠢是我喂错了信息。所以我现在对项目里的新人只有一个要求让 Claude 帮你之前先自己回答三个问题——它需要读哪个文件要跑哪些命令要遵循什么约束把这三点想清楚再动手、/add、!效果会比笼统一句“帮我看下这个功能”好十倍。3.3 组合三/compact压缩上下文的正确时机/compact是我用得最勤的命令之一但这并不代表我应该无脑用它。它的作用是压缩会话历史把已经聊过的内容做一次提炼留下关键结论释放上下文空间。但我实测发现压缩是有信息损耗的——对话里的某些细节、某个字段名、某个具体的报错堆栈压缩后可能只剩下模糊的概括后续执行就容易变形。我的经验是不要等项目聊到上下文快爆了才想起/compact。更好的时机是你意识到“接下来要换一个明显不同的任务”的时候。比如前半小时一直在讨论需求现在要动手写代码了此时上下文里塞满了需求讨论的来回对话直接压缩一次把需求结论保留住进入实现阶段。压缩完之后我通常会接着追问一句“刚才讨论得到的结论是什么”确认它没有把关键信息丢掉。如果发现有遗漏马上手动补一条到/memory或 CLAUDE.md 里。另一个实用技巧是在/compact之前把必须留存的要点用一句话写进当前对话里比如“记住生产环境的数据库地址配置要放在环境变量里”这样压缩工具在提炼时就会优先保留这类显式说明而不是靠它自己去猜哪些信息重要。3.4 组合四!命令与 Shell 直接互通!前缀会让我在对话里直接指挥终端做事这个能力用好了效率提升非常明显。比如我怀疑某个测试挂了直接在对话里输入!npm test -- --listTests它会返回当前测试文件清单比我手动切终端跑命令快得多。再比如查 Git 历史!git log --oneline -10一步到位让 Claude 基于真实提交记录分析问题而不是靠它凭感觉猜。但这里有一个我必须强调的安全问题!命令是真实执行在系统里的它不是模拟也不是演示。刚开始使用者最容易犯的错就是对它太信任比如让 Claude 执行一个看似无害的清理命令结果它真的把临时目录里的文件删了。所以我的原则是凡是涉及删除、覆盖、移动文件的命令先让它输出命令内容我看一眼确认没问题之后再手动执行而不是直接让模型代劳。3.5 组合五/model按任务难度切换模型很多人不知道 Claude Code 支持在对话中切换模型/model一敲就能在不同的模型之间切换。我自己的策略是“大模型想方案小模型跑执行”。需求分析、架构设计、审视复杂代码逻辑这类高难度的活儿用最强模型写格式化的代码、生成文档、补注释、整理测试数据这类重复性任务换到轻量模型就够用。这么做的直接好处是省时间和省额度。我曾经在一个大量生成数据脚本的任务里全程开着强模型结果同一个任务换成轻量模型后速度和成本都有明显改善输出质量对比下来几乎没差别。你要是不确定该用哪个模型可以先从中等模型开始跑感觉它理解需求吃力、频繁出错再切到强模型如果一切顺利就别往上升级。4. 自定义命令实战把重复劳动固化成 /xxx4.1 自定义命令的基本写法自定义命令的机制其实非常简单每个命令对应一个 Markdown 文件文件名就是命令名文件内容就是你想让 Claude 执行的那套指令。全局命令放在~/.claude/commands/目录项目级命令放在项目根目录的.claude/commands/目录。我个人遵循的原则是通用型命令放全局比如/commit、/summary和具体项目绑定强的命令放项目级比如某套特殊格式的接口生成命令。文件内容支持用双大括号做参数占位比如你想让命令接受一个输入参数在 markdown 里写{{参数名}}实际使用斜杠命令时它就会提示你输入对应内容。这让自定义命令不只是固定口号还能变成可复用的工具。4.2 一个可用的 /review 命令示例我拿团队里用得很顺的一个代码审查命令举例。它的定位不是“让 Claude 全量重写代码”而是“按团队的检查清单逐项过一遍”。在.claude/commands/review.md里我写了这样几段内容你是本项目的代码审查助手。请对 {{目标范围}} 的改动执行以下检查 1. 是否遵循项目 CLAUDE.md 中约定的目录结构与命名规范 2. 是否存在明显逻辑错误、空指针风险或未处理的异常边界 3. 是否有不必要的大文件改动、死代码或重复实现 4. 是否缺少必要的测试覆盖 输出格式 - 每个问题按「严重 / 一般 / 建议」分级 - 每行说明具体文件与行号范围 - 最后给出优先级排序的修复建议不要直接改代码实际使用的时候我输入/review src/utils/payment.ts它就会带上这个文件路径按上面这套标准逐项审查。以前我要手敲一大段审查要求现在一个斜杠命令就搞定了而且每次的审查标准保持一致——这一点对团队协作特别重要规则统一才能减少口头传达的偏差。4.3 团队规范与 CLAUDE.md 的配合自定义命令做到一定规模之后容易出现和项目规范脱节的问题。我的解决办法是把项目级规则全部沉淀在CLAUDE.md里然后自定义命令里统一留一句“请先阅读 CLAUDE.md 中的项目规范”。这样即使命令模板更新不及时只要规范文件是最新的Claude 的行为也会跟着最新规则走。举个例子某次我们团队调整了接口返回格式从下划线命名改成小驼峰。我没有去改每个命令文件里的描述只是在CLAUDE.md里补了一行“所有接口返回字段必须使用小驼峰命名”。之后凡是走了任意自定义命令的代码生成都会遵守这条新规则。这就是“规则文件 命令模板”的搭配价值命令负责流程规范负责内容互不干扰又互相支撑。5. 常见问题与避坑实录5.1 命令没反应先查这四个地方我自己遇到命令不生效的情况绝大多数不是产品出 bug而是小细节没到位。第一是检查斜杠前缀是否输入正确。有时候中文输入法会混进一个全角字符斜杠看起来像/实际不是命令自然没反应。第二是自定义命令没出现在列表里先看文件扩展名是不是.md以及是否放在正确的目录。我之前把命令文件起名带空格结果怎么都不出现去掉空格就好了。第三是新写的自定义命令往往需要重开会话或者重新加载才会被识别某些情况下要执行/help刷新一下。第四是如果你改动过权限配置注意是不是被权限拦截了——命令本身没问题但被当前权限策略挡掉了。顺序排查法比较稳先确认输入有没有隐形字符再确认文件路径和扩展名再确认是否要重启会话最后看一眼权限日志。5.2 上下文越用越笨多半是没管上下文很多人的使用体验曲线是“一开始挺聪明聊到后面越来越笨甚至前后矛盾”。这几乎都是上下文管理不到位导致的。对话越长原始信息被淹没在历史里的概率就越大模型会越来越依赖最近几轮的内容忘了你最早提到的约束。我的处理流程是这样感觉回答质量下滑先/context看当前占用率。如果占用率很高立刻执行/compact并在压缩后追问一句确认关键结论是否保留。如果压缩后还是不行就考虑开新会话把核心需求、约束、相关文件重新/add进去。但不要一卡顿就/clear有些上下文是有价值的粗暴清空会丢掉重要信息。保存关键决策靠/memory或写进CLAUDE.md这才是长期有效的办法。5.3 权限弹窗过敏怎么调出一个顺手的权限策略Claude Code 能调用的工具越多权限弹窗出现的频率就越高。有时候你只是想让它读几个文件结果弹窗连续出现好几次体验极其割裂。反过来你要是把所有权限全部放开又担心它执行了危险命令。我最后调出来的策略是阅读类工具Read、Grep、LS、Glob大量放行写入类工具保持确认危险类操作删除、移动、执行脚本每次询问。这个策略既保证了效率又守住了底线。具体在/permissions里设置默认模式为询问模式再把高频的只读命令加进白名单。调完以后日常开发顺畅度会明显提升而且你心里有数真正需要人确认的动作它不会越过你。5.4 加错文件导致幻觉怎么避免前面提到过把不相关文件加进上下文会干扰模型判断具体表现形式就是它“自信地”生成一些基于错误根据的代码看起来合理实际是幻觉。要避免这个问题最笨也最有效的方法是每次让 Claude 动手改代码之前先让它列出它认为相关的文件和改动范围你确认无误后再让它改。我在实践中还养成了一个习惯遇到生成结果奇怪的情况第一反应不是质疑模型能力而是先执行/context看看上下文里到底有哪些文件。十次里有七八次能发现某个改动请求时不小心把旧的备份文件也带进去了导致模型在旧逻辑上做推理。用/drop把无关文件移出去重新提问问题通常当场消失。5.5 自定义命令载入失败缓存与路径的坑自定义命令写好了却不生效另一个常见原因是路径歧义。全局命令和项目命令如果同名项目级优先级更高但可能有缓存残留导致新改动不生效。我的排查顺序是确认当前工作目录在项目根目录下确认命令文件放在.claude/commands而不是随便建了个同名文件夹然后重开会话再试。还有一个细节容易被忽略命令文件的文件名会直接决定命令触发词最好不要用中文和特殊字符否则在某些终端环境里补全和识别会有问题。保持英文小写加短横线是最稳妥的命名方式。结尾我整理这张表之后的真实心得把 93 个命令入口整理完的那一刻团队有人问我真的有人能用得上 90 多个命令吗我的回答是日常开发里八成时间可能就靠那十个主力命令但知道全貌的价值在于当你遇到一个从来没见过的工程问题时你会想起“好像有个东西能干这个活”而不是又回到手工复制粘贴和反复聊天试探的笨办法。我个人实际用下来的体会是不要试图一上来就背完整张表。先把/init、、!、/add、/drop、/compact、/model这七个玩到形成肌肉记忆再按你自己项目的痛点逐个添加自定义命令。随着使用时间推移你会慢慢形成一套属于自己团队的命令体系那个价值远比我给的清单大得多。最后再分享一个小建议每新增一条自定义命令顺手在CLAUDE.md里记一句它的用途三个月后你会发现这份文件才是你这个项目最值钱的数据资产。