说实话我一开始用 Claude Code 的时候有点不以为然觉得无非是在终端里聊天。直到我花了一个下午把它的常用指令和快捷键系统过了一遍才发现自己之前一直在用“聊天”的方式用一个“命令行工具”。Claude Code 最忌讳的就是把它当成普通 AI 聊天窗你越会用指令驱动它它越像一支小队而不是答题机器。下面这份清单里的命令和快捷键我基本都实际跑过适用场景也尽量说清楚适合已经装好 Claude Code、想真正把效率拉满的人。如果你第一次听说这个工具也没关系文里保留了安装和启动的最小闭环。1. 先把认知理顺为什么我在终端里跑 AI而不是一直开 IDE 插件1.1 终端里的 AI 和 IDE 补全插件本质上是两类东西IDE 里的 AI 插件比如各种 Copilot 类工具核心能力是“补全”它跟着光标走上下文主要来自当前打开的文件和编辑器选区。它的产品形态决定了你只能在一个文件里一点点往前推。Claude Code 不一样它跑在完整的 shell 环境里能做的不只是补全而是“操作”读文件、跑命令、执行测试、查看 git 状态、批量改代码。这个差异直接决定了使用方式。我在 IDE 里更习惯问“这一行怎么写”而在 Claude Code 里一般直接指挥它“跑一下测试把失败用例和堆栈整理给我然后去改对应文件”。后者是一个可重复的操作流前者是一段对话。你越早意识这一点越不会把终端里的 AI 用成一个大号问答框。1.2 哪些人最适合把 Claude Code 放进日常工作流我自己的经验是下面几类人受益最明显后端工程师 / 全栈工程师经常要跨模块改代码、看运行日志、重构公共方法终端里的操作密度本来就高。长期用 git 命令行开发的人Claude Code 可以直接配合git diff、git log使用指令和终端快捷键是同一套肌肉记忆。需要批量处理重复任务的场景比如批量改导入路径、批量补充注释、批量修 lint 错误非交互模式配合脚本非常好用。想训练“指挥 AI”能力的开发者在终端里你能看到每一次工具调用的命令和输出比黑盒插件更有掌控感。但如果你是纯前端且重度依赖鼠标操作、平时不太碰终端那 Claude Code 的学习曲线会稍微陡一些。没关系后面快捷键部分可以直接抄作业。2. 装好、启动、登录跑通最小闭环再谈提效2.1 全局安装与更新踩过权限坑要记住安装先决条件很简单机器上有 Node.js。装法就是用 npm 全局安装npm install -g anthropic-ai/claude-code装完验证claude --version如果能看到版本号说明装好了。更新有两种路径claude update # 或者 npm update -g anthropic-ai/claude-code这里有个高频报错auto-update failed: no write permission to npm prefix。原因很好理解npm 全局安装目录通常是/usr/local/lib/node_modules或系统级目录当前用户没有写权限自动更新就失败了。解决办法不建议无脑加sudo因为 sudo 装的包归属 root以后再更新还是麻烦。更推荐把 npm 全局目录改到用户目录mkdir -p ~/.npm-global npm config set prefix ~/.npm-global然后把下面的内容加到~/.bashrc或~/.zshrcexport PATH~/.npm-global/bin:$PATH之后重新打开终端再装一次 Claude Code自动更新权限问题基本就消失了。如果你不想改全局配置也可以直接给原目录当前用户授权sudo chown -R $(whoami) $(npm config get prefix)但这个方法只在你自己用的机器上推荐公司统一管理的机器还是用用户级目录更安全。2.2 三种启动方式对应完全不同的使用场景我在项目里常用的启动方式有三种不要只记claude一个。第一种是交互式启动直接进项目目录敲claude然后一条一条对话。适合探索问题、临时改代码、看项目结构。进交互模式后你能用的斜杠指令最多。第二种是直接传一句话启动claude 检查一下这个仓库的 README帮我列出缺失的安装说明这种方式适合一次性提问跑完就退出不用维护会话。第三种是非交互模式配合脚本和 CI 场景claude -p 对 src/utils.ts 做一次代码审查输出问题列表-p的意思是 print 模式不会进入交互会话结果直接打印到终端可以接到 shell 脚本里。我喜欢用它做批量任务比如遍历几个 git 分支分别检查代码差异。三种方式对比一下一眼就知道什么时候用哪个启动方式命令示例适合场景交互模式claude探索、调试、多轮修改直接传参claude 问题或任务单次提问、快速产出非交互模式claude -p 任务脚本化、批量执行、CI 集成2.3 登录与目录选择建议进项目根目录再启动交互模式里第一次使用会提示登录一般用/login走身份验证流程。如果你平时已经在用对应平台的账号登录过程很快登录状态可以通过/logout退出。目录选择这个细节最容易被忽略。我见过有人从用户主目录直接启动 Claude Code然后让它“找一下那个项目”结果 AI 在整棵目录树里乱翻既慢又容易误改文件。正确做法是先进到具体项目根目录再启动。这样它能自动读取项目配置文件、git 信息和已有的记忆文件上下文更准确。例如cd ~/work/my-project claude如果你的项目里已经有一份项目说明书或者规范文档尽量放在明显位置告诉它或者用/add显式加到上下文后面会讲。3. 常用指令清单别死记命令要理解每个指令在“操作什么”3.1 会话控制类/status、/clear、/compact、/cost先讲会话控制因为这是保持长期使用不卡壳的关键。/status用来查看当前会话状态包括上下文使用量、已消耗的 token 情况、当前模型等。我自己的习惯是每完成一个任务片段就看一眼尤其是干了大半天之后。上下文不是无限的早发现快满了好过做到一半被截断。/clear是清空当前会话内容开启新的对话但它不会把你的记忆文件删掉。这一点很关键如果只是想让 AI“忘掉刚才聊的细节”用/clear如果你希望新会话能继续使用之前沉淀的项目规范那依赖的是/memory里的内容而不是聊天记录。/compact是压缩当前上下文。长会话聊到一半上下文快爆了又不想从头开始就可以用这个指令把历史对话归纳成精简摘要释放空间。注意压缩会损失一部分细节重要信息最好先让它写进文件。/cost可以查看本次会话花费了多少 token、多少钱。如果是自费使用这个指令几乎每天都要用防止某次大任务偷偷烧掉大量用量。3.2 代码任务类/init、/add、/review、/bug这几个是干活时最常用的指令。/init用于初始化一个项目的 AI 上下文。执行后它会在项目里生成类似CLAUDE.md的记忆文件内容通常包括项目简介、技术栈、常用命令、代码风格等。新会话启动时如果检测到这份文件会自动读取。新项目第一次使用我建议先跑/init后续所有会话的上下文质量会明显提升。/add手动把文件加入上下文。默认情况下Claude Code 会按需自己去读文件但有时你想让它重点关注某个文件或某段配置直接用/add src/utils.ts最干脆。交互里还可以用文件名的方式快速引用我经常把 config 文件和入口文件一起加进上下文连续提问都很准。/review是让 AI 审查当前代码改动。它适合在写完一段代码后执行它会主动看 git diff给出潜在问题、改进点。注意它不是 Code Review 的替代品但能帮你提前抓住低级问题。我通常在准备 commit 前跑一遍比提交后再被打回少一轮痛苦。/bug是让 AI 重点排查报错和缺陷。当测试报错或者运行出现异常时我会先说清楚现象然后执行/bug让它沿着错误信息定位并修复。它更偏向“排查动作”和直接问“哪里有问题”相比它会按 bug 分析流程走输出定位路径和修复建议。3.3 记忆与模型类/memory、/model、/agents/memory查看和编辑长期记忆文件。它会展示当前项目里的记忆内容你可以直接要求“在这个文件里补充一条代码格式化统一用 prettier”。之后新会话也能看到。第一次使用/init后再把团队或个人的常用约定写进记忆长期下来很省事。/model切换当前模型。Claude Code 在交互中可以通过/model快速切换不同档位的模型。我自己的习惯是复杂架构设计、重构、多文件改动用能力更强的旗舰模型简单的代码格式化、文本总结、翻译这类任务用更轻快的模型。切换非常灵活可以在同一会话里按需切换。/agents管理子代理。如果你版本里的 Claude Code 支持子代理可以在这里查看任务拆分情况。适合的场景是主对话负责整体进度子代理单独去调查某个模块或某个日志问题再把结果汇报回来。注意子代理会增加用量小任务不用开。3.4 模式与维护类/help、/vim、/config、/update/help永远是第一指令。版本更新后快捷键和指令可能微调直接看内置帮助最可靠。/vim开启 vim 模式。如果你习惯 vim 键位在终端里编辑代码时会更顺手。不习惯的可以忽略。/config查看或修改配置项包括权限、默认行为、模型偏好等。/update手动检查更新。配合前面说的 npm 权限问题如果报错先看看是不是全局目录写权限问题。我用一个表格把指令按用途归类平时忘了可以回来查用途指令初始化项目上下文/init查看当前会话状态/status清空会话但保留记忆/clear压缩长会话摘要/compact查看 token 花费/cost审查最近代码改动/review排查修复 bug/bug管理长期记忆/memory切换模型档位/model查看帮助/help切换 vim 编辑模式/vim手动更新/update4. 快捷键清单把常用操作变成肌肉记忆4.1 基础键位输入、中断、历史、清屏Claude Code 跑在终端里所以很多快捷键继承了终端本身的键位。Enter发送当前指令。Shift Enter在多数终端模拟器里是软换行用来写多行指令。↑/↓在输入框里翻历史指令和 shell 的 history 一样。Ctrl L清屏。会话内容还在只是画面干净了。Ctrl C中断当前正在进行的 AI 响应或工具调用。Ctrl D退出交互会话相当于发 EOF。Tab终端里的路径和命令补全在输入指令时也能帮上忙。这里有个容易踩的坑不同终端模拟器对某些按键的拦截不太一样。比如在部分 IDE 的内置终端里Ctrl D可能被绑定成“关闭面板”那你就得去快捷键设置里改掉冲突。所以拿到一份快捷键清单之后第一件事是测试不是背诵。4.2 双按 Esc撤销最近一次操作这个一定要练如果说只能记住一个快捷键那我会选连按两次Esc。Claude Code 在修改文件或执行工具调用后如果你觉得改坏了立即连按两次Esc通常能撤销刚才的操作。这个动作比“赶紧去 git checkout”快得多尤其 AI 一次动了多个文件时它能更精准地回退一部分操作。我自己的习惯是让它改完代码后先不着急继续对话直接打开 git diff 看一遍。如果不对立刻双按 Esc 撤销然后重新组织指令。第一次用的时候可能会犹豫“要不要撤销”别犹豫宁可撤销重来也不要让它带着错误继续往下扩。注意双按 Esc 不是万能的。如果 AI 已经执行了多条命令、提交了 commit 或拉了远端分支撤销操作不一定能覆盖所以关键改动前最好先git stash或新建分支。4.3 ShiftTab专注模式与多行输入的开关另一个高频操作是Shift Tab。在 Claude Code 的输入框和展示区域之间切换时它能帮你把正在写的长指令“锁定”在一个更专注的编辑状态里避免误按 Enter 直接发送。当你要写一段包含多个步骤的复杂指令时就按Shift Tab切到多行编辑状态写好了再发。这个动作能极大减少“指令只写了一半就发出去”的情况。我写长 prompt 的时候基本一直是这个状态写完再退出。需要强调一下如果你之前用惯了聊天软件可能习惯一句一句聊。但在终端里一条结构完整的指令比十条零散的话效率高一个量级。Shift Tab就是帮你把话一次性说完的工具。4.4 常用快捷键速查表我把自己日常用得上的键位整理成一张表省得每次翻文档快捷键作用备注Enter发送指令基本键位Shift Enter多行输入换行受终端模拟器影响Shift Tab切换多行/专注编辑状态高频使用↑/↓浏览历史指令终端通用Esc中断当前输出/操作轻量中断EscEsc撤销最近一次工具操作保命键位Ctrl C强制中断当前任务终端通用Ctrl D退出交互会话也可能绑定 IDE 面板Ctrl L清屏终端通用Tab命令/路径补全终端通用这个表不追求覆盖所有功能只求覆盖一天工作里 80% 的操作。快捷键这东西贪多嚼不烂先把撤销、多行输入、中断这三个练熟收益就非常明显了。5. 从“会用”到“好用”我常用的指令快捷键组合工作流5.1 排查 Bug 的固定节奏先跑、再断、后修、终审我处理一个陌生 bug 的时候流程基本是固化的。先在项目目录启动claude然后给一条非常具体的指令“先运行项目的测试命令把失败用例和堆栈输出给我不要改代码。” 这一步的关键是让它先做信息收集不要直接开修。很多问题定位不准就是因为 AI 在没看到完整报错的情况下猜原因。等它跑完命令输出结果后如果输出太长或者它已经自说自话开始分析我会按一次Esc中断追问一句“只保留失败的三个用例每个给出完整堆栈”。中断不是结束对话而是控制节奏。信息足够后再执行/bug让它定位并修复。修完后不是直接信任而是立刻让它/review审查自己的改动然后我打开 git diff 再人工过一遍。如果改得不对双按Esc撤销重新描述约束条件。这套流程看起来多了一步但实际比“让它随便修”稳定得多。核心原则是信息收集、修复、审查三个阶段分开不要让 AI 一口气包办。5.2 用 /init 和 /memory 把项目规范一次定下来新项目第一次跑通之后我会马上执行/init生成项目记忆文件。然后做的事可能比你想象的更“琐碎”把项目的启动命令、测试命令、代码风格约定、禁止改动的目录全部写进记忆。比如前端项目我会让 AI 记住“本地 mock 启动用pnpm dev:mock单元测试用pnpm test -- --run样式统一用 tailwind不要修改dist/目录下的内容。”以后新会话启动AI 自动读这些约定就不用每次重复交代。平时新总结出什么约定直接说“补充到 /memory”它就会更新记忆文件。这套动作做上几次我明显感觉 AI 的第一次回答准确率高很多少很多来回试探。5.3 长会话维护压缩、清理、切换模型如果你和我一样会开着会话干一整天那必须养成维护会话的习惯。干到两三个小时之后/status看一眼上下文用量接近临界值时用/compact压缩。压缩前我会把关键结论先确认一遍“把我们刚才确定的三条修改方案先写进记忆再压缩。” 确保摘要不会丢重要信息。如果压缩之后还是觉得上下文很乱直接/clear开新会话依靠记忆文件里的内容重新开始。成本控制上/cost每天至少看一次。复杂的重构任务我会切旗舰模型简单整理、重排版、批量注释直接切轻快模型一进一出用量差很多。它不是单一的贵或便宜而是要匹配任务复杂度。6. 我踩过的坑和防御习惯6.1 auto-update failed: no write permission to npm prefix这是我很长时间没发现的隐性坑。Claude Code 表面运行正常但某天自动更新失败版本一直不升。看错误信息auto-update failed: no write permission to npm prefix我先以为是 npm 源的问题后来排查发现就是权限。解决方式上面已经写过要么改 npm 全局目录到用户目录要么 chown 授权。我推荐用户目录方案一劳永逸。判断安装路径的方法npm config get prefix如果路径在/usr/local下说明当前用户未必有写权限。可以先ls -ld $(npm config get prefix)看目录属主再决定用哪种方案。6.2 保护现场别让误中断变成大事故有一次我让 Claude Code 重构一个工具函数它改到一半我按Esc中断结果它已经动了好几个文件。我第一反应是看git diff然后按了两次Esc回退。还好动作快没有破坏现场。经过这次之后我总结出三条防御习惯大改动前先让 AI 列改动计划我确认了再执行。重要项目先git commit或git stash留底再让 AI 动手。中断后不急着开新指令先看一眼 diff确认状态干净再继续。不要盲目相信“撤销”能覆盖所有情况自己多做保护比依赖工具可靠。6.3 让 AI“做完”不等于“做对”审查意识要有Claude Code 的高效在于它能快速执行大量动作但这也意味着它可以在很短时间里犯一个大错误。我见过它自信地重构代码结果跑测试全红也见过它改配置时顺手改乱了无关字段。所以我坚持一条底线凡是改代码的任务一定要有一个“审查闭环”。要么让它/review要么自己看 git diff要么跑测试。三选一不能省。另外不要在上下文里粘贴密钥、token、数据库地址等敏感信息。它能读文件和执行命令不代表你应该把机密交出去。终端工具的便利性越高越要注意边界。我一直的体会是指令和快捷键不是背出来的是在一次一次中断、撤销和重试里形成的肌肉记忆。刚开始用的时候可以故意把一次任务拆成三个指令来发很快你就能感受到它和聊天式 AI 的差别。希望这份清单能让你少走点弯路把时间花在真正需要判断力的地方。