1. 为什么需要一份自己的 Claude Code 命令速查表刚接触 Claude Code 的人十有八九会经历同一个阶段装完之后对着终端发呆知道这东西能改代码、能跑命令但真到用的时候脑子里只剩一个回车键。官方文档当然全可它按功能模块组织你干活时想的是我要让它把刚才那个报错修了而不是我要调用哪个子命令。这两套思维之间的翻译成本就是大多数人用了一周还停留在聊天式提问的根本原因。我自己的转折点是有一次改一个跨了七个文件的接口重构。手动描述需求、等它逐个文件确认、再手动跑测试来回折腾了快四十分钟。后来我把常用指令和快捷键整理成一张贴在副屏上的速查表同样的活儿压到了十分钟以内。差别不在于模型变聪明了而在于我不再花时间回忆下一步该敲什么。这份速查手册面向三类人刚装好 Claude Code 还没形成肌肉记忆的新手、用了一阵但总觉得效率卡在某个瓶颈的中级用户、以及想把 Claude Code 嵌进团队工作流的技术负责人。核心关键词就几个——命令速查、快捷键、工作流、CLAUDE.md。我会把高频指令按使用场景重新归类把快捷键按手不离键盘的原则整理最后给几套可以直接抄的工作流配置。所有内容基于常见实践整理具体版本行为可能有差异以你本地实际表现为准。先说一个反直觉的结论Claude Code 的效率瓶颈从来不是模型能力而是你的输入带宽。你打字描述需求的速度、你切换上下文的次数、你确认每一步的频次这些才是决定你一天能推进多少活儿的真正变量。速查表的价值就在于把这些变量压到最低。2. 高频指令按场景重新归类官方把命令按字母序排那是给查阅用的。真正干活时你需要的是按我现在想干什么来索引。下面这套分类是我用了几个月之后固定下来的覆盖了日常九成以上的操作。2.1 会话启动与上下文加载类这一类命令决定了你这次会话知道多少东西用好了能省掉大量重复解释。claude直接启动交互式会话这是最基础的入口。但很多人不知道的是在项目根目录启动和在子目录启动它自动加载的上下文范围是不一样的。我习惯永远在项目根目录启动这样它能一次性看到完整的目录结构。claude 你的任务描述这种带参数的启动方式适合一次性的小任务。比如claude 把 utils/date.js 里的 moment 换成 dayjs它会直接执行完给你结果不进入交互循环。这种用法我主要用在明确、边界清晰的重构上。/init是新手最该先跑的命令。它会在项目里生成一个CLAUDE.md文件把项目的技术栈、目录约定、常用命令这些信息固化下来。这个文件是后面所有工作流的地基具体怎么写我在第 4 节展开。/clear清空当前会话的上下文。这里有个经验当你切换到一个完全不相关的任务时一定要先/clear。否则旧任务的上下文会污染新任务的判断模型可能会莫名其妙地引用上一个任务的变量名或文件路径。我踩过这个坑改 A 模块的时候它突然去动 B 模块的文件就是因为上下文没清干净。/compact压缩当前上下文。长会话跑到后面 token 快满了它会开始遗忘早期内容。/compact会把之前的对话总结成摘要腾出空间继续干活。我的习惯是每完成一个阶段性目标就 compact 一次而不是等到报错才想起来。2.2 文件与代码操作类这一类是你和代码库交互的主要手段用熟了基本可以告别鼠标。/add 文件路径把指定文件加入当前上下文。这里的关键是精准。很多人图省事直接/add .把整个项目塞进去结果 token 瞬间爆掉而且模型注意力被大量无关文件稀释回答质量反而下降。正确做法是只加你这次任务真正涉及的文件通常三到五个。/drop 文件路径从上下文移除文件。任务推进过程中有些文件已经改完不再需要了及时 drop 掉能保持上下文干净。直接说文件路径加需求比如读一下src/api/client.ts把超时时间从 5 秒改成 30 秒它会自动读取并修改。这比先/add再描述要快适合单文件的小改动。/diff查看当前所有未提交的改动。这个命令我几乎每次提交前都会跑一遍确认它改的东西和我预期的一致。Claude Code 有时候会顺手改一些你没让它改的地方/diff是最后一道防线。/undo撤销上一次改动。注意它撤销的是 Claude Code 自己的改动不是 git 层面的。如果你已经手动改过文件undo 的行为可能不符合预期这种时候还是老老实实用 git。2.3 执行与验证类写完代码不验证等于没写这一类命令负责闭环。!命令前缀直接在会话里执行 shell 命令。比如!npm test、!git status。这个设计很妙你不需要切出终端执行结果还会自动进入上下文模型能直接看到测试输出并据此调整。/run让 Claude Code 自己执行命令并观察结果。和!的区别在于!是你主动执行给它看/run是它自己决定要跑什么。修 bug 的时候我常用这个让它自己跑测试、看报错、改代码、再跑形成一个自动循环。/test触发测试流程。它会尝试识别项目的测试框架并运行相关测试。不过实测下来对于非标准配置的项目它识别得不一定准这种时候还是用!手动指定测试命令更可靠。2.4 会话管理类/help列出所有可用命令。忘了什么的时候敲一下比翻文档快。/cost查看当前会话的 token 消耗和费用。这个命令建议养成定期查看的习惯尤其是长会话能帮你建立对一次任务大概花多少钱的直觉。/model切换模型。不同任务对模型能力的要求不一样简单的格式化、重命名用轻量模型就够复杂的架构设计再上重模型这个切换能显著影响成本。/exit或CtrlC退出会话。下面这张表把上面这些命令按使用频率和学习优先级做了个对照方便你决定先记哪些命令使用频率学习优先级典型场景/init一次性最高新项目初始化/add/drop极高最高精准控制上下文/clear/compact高高任务切换、长会话/diff高高提交前检查!前缀极高最高执行任意命令/run中中自动修复循环/cost中中成本监控/model中中按任务选模型3. 快捷键把手从鼠标上解放出来Claude Code 的快捷键设计遵循一个原则——高频操作必须单手可达。但很多人装完就用默认配置完全没意识到这些键的存在。下面按输入编辑和会话控制两类整理。3.1 输入编辑类快捷键在输入框里编辑长文本时这些键能救命。CtrlA跳到行首CtrlE跳到行尾。这两个是 readline 的标准键位在绝大多数终端里都通用。写长需求描述的时候改开头改结尾全靠它们。CtrlU删除光标到行首的内容CtrlK删除光标到行尾的内容。比狂按退格快得多。CtrlW删除光标前的一个单词。英文需求描述里特别有用。CtrlR反向搜索历史输入。你之前敲过的长需求不用重新打搜关键词就能调出来。这个键我用得最多很多需求描述是重复的搜出来改几个字就能复用。OptionEnterMac或AltEnterWindows/Linux插入换行而不提交。写多行需求的时候必须用这个否则一回车就发出去了。CtrlL清屏但保留当前输入。终端被输出刷屏了敲一下这个输入框里的内容还在。3.2 会话控制类快捷键Esc中断当前正在执行的操作。模型跑偏了、或者你突然发现需求描述错了按 Esc 立刻停。这个键要形成条件反射别等它把整个项目改乱了才想起来。Esc连按两次可以回退到历史消息重新编辑。这个功能很多人不知道它相当于给你一个时光倒流的机会回到某条消息重新提问。CtrlC退出当前会话。注意它和 Esc 的区别Esc 是中断当前操作但保留会话CtrlC 是直接结束。CtrlD在空输入时退出效果类似 CtrlC。ShiftTab切换权限模式。Claude Code 有几种权限模式比如每次操作都要确认、或者自动执行。切换模式能显著影响你的操作节奏具体怎么选我在第 5 节讲。CtrlO展开或折叠详细输出。默认输出可能被截断想看完整内容的时候用这个。3.3 关于自定义快捷键Claude Code 本身的自定义快捷键能力有限但你可以通过终端模拟器的配置来补足。比如在 iTerm2 或 Windows Terminal 里把常用的命令序列绑定到功能键上。我自己的配置是把F2绑成运行测试F3绑成查看 diff这样连命令都不用敲了。这里有个坑要提醒不同终端对Option键的处理不一样。Mac 上默认Option是输入特殊字符需要在终端设置里勾选将 Option 作为 Meta 键OptionEnter才能正常工作。我第一次用的时候死活换不了行折腾了半天才发现是这个设置的问题。4. CLAUDE.md把项目知识固化下来如果说命令和快捷键是操作层的效率那CLAUDE.md就是认知层的效率。它决定了 Claude Code 每次启动时对你的项目了解多少是整套工作流里投入产出比最高的一环。4.1 CLAUDE.md 到底解决什么问题没有CLAUDE.md的时候每次新会话你都要重新解释这个项目用什么框架、代码风格是什么、测试怎么跑、哪些目录不能动。这些信息重复输入既费 token 又费时间而且每次描述可能还不一致。CLAUDE.md就是把这些项目常识写成一个文件放在项目根目录Claude Code 每次启动自动读取。相当于给新来的同事发了一份项目手册不用每次口头交代。4.2 一份实用的 CLAUDE.md 该写什么我见过很多人把CLAUDE.md写成 README 的复制粘贴那是浪费。它应该只写对 Claude Code 干活有直接影响的信息。我的模板大致包含这几块技术栈和版本。明确写清楚框架、语言版本、包管理器。比如Node 20 TypeScript 5.3 pnpm不要用 npm 或 yarn。这样它就不会给你生成npm install的指令。目录约定。哪些目录放什么哪些是自动生成的不要改。比如src/generated/下的文件由代码生成禁止手动编辑。代码风格。缩进、引号、命名规范。如果项目有 ESLint 或 Prettier 配置直接写遵循.eslintrc和.prettierrc就行不用重复规则。常用命令。测试、构建、lint 分别怎么跑。这块特别重要写清楚了它就能自己跑测试验证改动。禁区。哪些操作绝对不能做。比如不要修改package.json里的依赖版本、不要提交.env文件。下面是一个精简版的示例结构# 项目说明 ## 技术栈 - Node 20, TypeScript 5.3, pnpm - 测试用 Vitest构建用 tsup ## 目录约定 - src/components/ 组件 - src/generated/ 自动生成禁止手改 - tests/ 测试文件 ## 代码风格 - 遵循 .eslintrc 和 .prettierrc - 组件用函数式不用 class ## 常用命令 - 测试: pnpm test - 构建: pnpm build - lint: pnpm lint ## 禁区 - 不改 package.json 依赖版本 - 不提交 .env4.3 分层管理全局与项目级CLAUDE.md支持分层。用户主目录下的~/.claude/CLAUDE.md是全局配置对所有项目生效项目根目录的是项目级配置只对当前项目生效。我的做法是全局文件里放个人偏好比如回答用中文、代码注释用英文、提交信息遵循 Conventional Commits。项目文件里放项目特定信息。这样切换项目时个人偏好不用重复写。4.4 维护 CLAUDE.md 的时机CLAUDE.md不是写完就不管了。我的习惯是每次发现 Claude Code 犯了一个本可以避免的错误就回头往CLAUDE.md里补一条规则。比如它某次用了npm而不是pnpm我就在文件里加粗强调包管理器。这样文件会随着使用越来越贴合你的项目效率提升是复利的。注意CLAUDE.md里的信息要精炼。写得太长会占用上下文预算反而挤占了真正干活的空间。我的经验是控制在 100 行以内只写不说就会出错的信息。5. 高效工作流的搭建与权限模式选择命令和快捷键是零件工作流是把零件组装成流水线。这一节讲三套我实际在用的工作流以及权限模式这个容易被忽略但影响巨大的设置。5.1 权限模式决定你的操作节奏Claude Code 有几种权限模式核心区别在于它执行操作前要不要问你。默认模式下每次文件修改、每次命令执行都要你确认。安全但节奏很慢一个稍大的任务你要按几十次确认。自动接受模式下它自己执行不问你。快但风险高万一它理解错了可能一次改一堆文件。我的选择是按任务类型切换。探索性任务、涉及关键文件的任务用默认模式每一步都看清楚。明确的重构、格式化、批量重命名这类低风险任务切到自动接受模式让它一口气干完。ShiftTab就是用来切换这个的。养成任务开始前先想一下这个活儿风险高不高的习惯比无脑用一个模式要高效得多。5.2 工作流一TDD 循环这是我最常用的工作流适合有测试覆盖的项目。流程是先让它写测试红再让它写实现让测试通过绿最后让它重构重构。每一步都用!跑测试验证。具体操作/add相关文件然后说为calculateDiscount函数写测试覆盖边界情况。它写完测试你!pnpm test确认测试失败。然后说实现这个函数让测试通过它写完你再跑测试确认通过。最后说重构这个实现保持测试通过。这个流程的好处是每一步都有客观验证不依赖你肉眼检查代码。而且测试先行的约束会让它写出的实现更聚焦。5.3 工作流二大重构的分步推进大重构最怕的是一次改太多出了问题不知道是哪一步引入的。我的做法是拆成小步每步都提交。先让它分析读一下这几个文件列出把回调风格改成 async/await 需要改哪些地方按依赖顺序排个序。拿到清单后一次只改一个文件或一组紧密相关的文件改完/diff检查!pnpm test验证git commit提交。然后再进行下一步。这样即使某一步出问题回滚成本也很低。而且分步提交的 git 历史清晰review 的时候也好看。5.4 工作流三陌生代码库的快速上手接手一个不熟悉的项目时Claude Code 能当你的向导。先/init生成初始的CLAUDE.md然后问它这个项目的入口在哪主要模块怎么划分。它会读目录结构和关键文件给你讲。接着针对你想改的功能问实现 X 功能的代码分布在哪些文件。定位到文件后/add进来深入看。这个流程比你自己一个个文件翻要快得多尤其是大型项目。不过要注意它对代码的理解可能有偏差关键结论还是要自己验证。5.5 把工作流固化成脚本如果你有一套反复用的流程可以把它写成 shell 脚本或 Makefile。比如我有个review.sh内容是启动 Claude Code 并让它对当前 diff 做 code review。这样一条命令就能触发整套流程连需求描述都省了。6. 那些文档里不会写的踩坑经验前面讲的都是应该怎么做这一节讲实际做的时候会出什么幺蛾子。这些是我和身边同行踩出来的官方文档基本不会提。6.1 上下文污染最隐蔽的效率杀手前面提过/clear的重要性这里展开说。上下文污染的表现很隐蔽模型不是报错而是给出看起来合理但方向不对的回答。比如你刚改完一个 React 组件接着问一个 Node 脚本的问题它可能会用 React 的思维来回答建议你用 hooks 组织脚本逻辑。判断是否被污染的方法如果你发现它的回答里出现了当前任务不该有的概念立刻/clear重来。不要试图纠正它纠正的成本比重新开始高。6.2 自动更新失败与权限问题有段时间我遇到auto-update failed: no write permission to npm prefix这个报错。原因是 npm 的全局目录权限不对Claude Code 想自动更新但写不进去。解决办法是修正 npm 全局目录的权限或者用版本管理工具如 nvm来管理 Node这样全局目录在用户空间下不会有权限问题。这个坑在新机器上特别常见装完先检查一下 npm 的 prefix 配置能省很多事。6.3 它改了你没让它改的地方这是/diff存在的意义。Claude Code 有时候会顺手做一些你没要求的改动比如格式化了你没提到的文件、调整了 import 顺序。大多数时候无害但偶尔会引入问题。我的习惯是任何提交前必跑/diff逐块确认。发现不想要的改动用/undo或者手动 git checkout 掉。别嫌麻烦这个习惯能帮你避免很多莫名其妙的 bug。6.4 长会话的遗忘问题会话跑到后面模型会开始忘记早期的约定。表现是它突然不遵守CLAUDE.md里的规则了或者引用了已经改掉的旧代码。对策是定期/compact把早期对话压缩成摘要。但 compact 本身也有信息损失所以关键约定最好写在CLAUDE.md里而不是只靠对话记忆。文件是持久的对话是易失的。6.5 关于模型选择的成本直觉/model能切模型但很多人不知道该什么时候切。我的经验法则需要理解的任务用强模型需要执行的任务用轻模型。架构设计、复杂 bug 定位、跨文件重构这些用强模型格式化、重命名、写简单测试、生成样板代码用轻模型就够。养成看/cost的习惯你会慢慢建立起对这类任务大概花多少的直觉然后就能做出更经济的模型选择。6.6 中文需求的表达技巧用中文描述需求完全没问题但有几个技巧能让它理解得更准。一是文件路径和代码标识符保持原样不要翻译比如就说src/api/client.ts而不是那个 api 客户端文件。二是需求要具体到可验证优化一下这个函数不如把这个函数的嵌套 if 改成早返回。三是一次说一件事把多个需求堆在一句话里它容易漏掉后面的。7. 把速查表变成你自己的写到这里命令、快捷键、工作流、踩坑都覆盖了。但我想强调一点这份速查表最大的价值不是让你照抄而是给你一个起点去长出自己的版本。每个人的项目类型、技术栈、工作习惯都不一样。我贴满副屏的那张表是我自己用出来的。你需要的命令可能和我完全不同。建议你从这份内容里挑出最常用的十条打印出来贴在显示器边上用一周形成肌肉记忆然后再往里加。CLAUDE.md也是同理。别指望一次写完美它是长出来的。每次它犯错你就补一条规则。三个月后回头看那个文件就是你项目的最佳实践沉淀。最后分享一个我最近才养成的习惯每周花十分钟回顾一下这周用 Claude Code 的过程想想哪些操作是重复的、哪些确认是多余的、哪些报错是可以提前避免的。把这些整理进CLAUDE.md或者写成脚本。工具的效率提升不是一次性的是持续微调出来的。