1. 为什么你需要一份 Claude Code 命令速查手册1.1 它到底是什么适合谁来用先给没接触过的朋友一个定位Claude Code 是跑在终端里的 AI 编码助手通过对话方式帮你完成需求分析、代码编写、测试执行、问题定位、重构等一系列日常开发工作。它不是那种“粘贴代码进去让它补全”的 IDE 插件而是把你整个项目目录交给一个能调用工具、读写文件、执行命令的 AI 对话体。和传统 AI 补全工具相比它的特点在于“主动做事”而非“等你提问”。这个工具适合几类人。第一类是重度终端用户平时工作流建立在命令行上不习惯在多个窗口之间来回切换第二类是接手大型旧项目的人Claude Code 可以快速总结代码结构、梳理模块关系替代人工读半天源码第三类是写测试和脚本的开发者它能批量生成测试用例、修改配置、跑命令并读取结果再修正。当然如果你只是偶尔写几行代码或者更依赖图形界面这个工具也能用但学习收益没有前几类人高。我自己的使用场景比较典型同时维护好几个项目每个项目技术栈不同、目录结构也不一样。以前每次切换上下文都要重新读文档、回忆规范用了 Claude Code 之后项目的约定直接写在记忆文件里它每次启动都会先读一遍省掉大量重复沟通成本。但我刚上手那段时间并不顺利原因很简单指令不熟。同样一个操作命令参数敲错了工具就给出偏离预期的结果快捷键不知道就只能一直盯屏幕频繁打断上下文不管控对话到后面就开始答非所问。之所以整理这份手册就是把这些高频问题一次性摊开按场景归类把参数、注意事项和踩坑点都写清楚。1.2 整理这份手册的出发点我看到不少刚接触这个工具的朋友日常用法几乎都是“一句话丢给它让它改代码”。这当然能用但用得很浪费。Claude Code 真正值钱的地方在它那一套会话管理、上下文控制、子代理和自定义命令的机制。只要把命令学透很多繁琐操作可以压缩成一条指令很多反复出现的问题可以从源头规避。我整理这份手册有一个原则不堆砌命令只写“你每天真的会用到”的东西。像/help这种谁都知道的或者一年都用不上一次的冷门参数我一般不列进去。我会把指令按场景重新分组启动与会话管理、上下文与记忆、代码操作、子代理、权限与安全、工作流配置。每个命令尽量写清楚它是干什么的、什么时候用、有哪些注意点。这样你在遇到问题时能按图索骥而不是把整个命令列表背一遍。2. 高频指令全解析从启动到收工2.1 启动与会话管理的核心命令开发一天的工作通常从打开终端开始所以先把“怎么把 Claude Code 拉起来”这件事讲透。最基本的启动方式就是进入项目根目录输入claude。这时它会读取当前目录的配置和记忆文件进入交互式对话界面。这个模式适合长时间办公你可以在里面连续多轮提问和修改。如果你想让 AI 保持上一轮对话的上下文继续工作用claude --continue。这个命令不传参数会自动找到最近一次会话并恢复。它解决的问题是你已经让 AI 改了好几个文件中间去开会、回邮件回到终端后想继续而不是从零开始重新描述一遍需求。如果有多条历史会话想回到其中某一条就用claude --resume。执行后它会列出过去一段时间内的会话列表你选择要恢复的那一个。这个操作对应的是“昨天分析到一半的需求今天接着看”的使用场景。非交互模式是我的私藏用法参数是claude -p 具体指令。它不会打开交互界面执行完直接返回结果适合在脚本或 CI 流程里调用。比如你想写一个提交信息生成器可以先git diff拿到改动内容再传给claude -p让它生成提交说明。配合--output-format json还能直接拿到结构化输出方便程序解析。还有几个小参数值得记住。--model用于指定模型--append-system-prompt可以附加系统级提示词--permission-mode可以设置权限策略我在后面的安全章节细讲。退出交互模式用/exit或CtrlD。注意claude --continue只能续最近一次会话。如果你中间用过其它项目记得先切回原项目目录再执行这个命令否则它会续的是另一个项目的会话。实际经验是很多人分不清“新会话”和“继续会话”的区别结果经常重复描述需求。其实 Claude Code 的会话记录是保存在本地的按项目和启动目录归类。只要你不清理记录一直都在。启动时养成先想清楚“我是继续还是开新局”的习惯能省很多 token。2.2 上下文管理与记忆指令AI 对话模型有上下文窗口上限Claude Code 也不例外。上下文管理做得好不好直接决定工具是越用越顺手还是越用越笨。先说一下/context。这个命令会展示当前对话已经占用的上下文量、剩余空间以及哪些文件被引用过。开发过程中我会隔一会儿就敲一次尤其在任务变复杂、改了很多文件之后看一眼心里有数避免回答开始跑偏时才发现上下文快满了。/compact是上下文快满时的救急命令。它会将当前对话历史做一次压缩摘要把重要的结论和未完成事项保留下来丢弃大量过程性内容。压缩后模型对任务的“记忆”从详细日志变成了要点概括对话可以继续但细节会有损失。所以我的建议是压缩前先明确告诉 Claude “接下来我们只剩两轮对话你要把还没完成的事总结成清单”这样摘要会更有针对性。/clear是清空当前对话记录重新开始。它和/compact不同前者是彻底忘记后者是提炼后继续。如果你发现自己绕进一个死胡同AI 反复给出同一个错误方案别犹豫先/clear再重新描述需求和约束往往比继续纠缠高效得多。项目级记忆的载体是 CLAUDE.md 文件首次进入项目时可以执行/init让它自动扫描代码库并生成一份基础约定文档。这份文件会随每次启动被自动读取相当于给 AI 一份“项目背景说明书”。很多团队用法是把代码风格、目录规范、常用命令、测试指令、部署流程写进去这样 Claude 每次回答都自带项目上下文。我维护项目的习惯是CLAUDE.md里至少包含四个部分项目简介与技术栈、常用命令启动、测试、构建、lint、代码风格约定、目录职责说明。注意别把大段源码塞进去那会白白占用上下文写清楚“去哪找文件”比“贴文件内容”高效。2.3 slash 命令把复杂操作变成一行/开头的一类命令可以理解为“工具人模式”的快捷入口相当于把一串复杂操作封装成一条指令。/help不多说版本不同命令有新变化随时用它查清单。/review是用来做代码审查的它会扫描工作区改动逐文件检查潜在问题并给出优化建议。推送代码前去跑一次能拦住不少低级错误和逻辑遗漏。/agents会进入子代理管理界面你可以创建多个并行代理每个代理负责独立子任务比如一个代理分析接口定义另一个代理改前端页面这样能明显缩短整体耗时。/add-dir用于将某个目录显式加入上下文关注范围。对大型项目尤为有用模型不需要扫整个仓库只看你指定的几个关键目录既省 token 又提高准确性。与之配套的是在对话中用符号引用具体文件这个操作相当于“把文件内容临时附进当前对话当作参考”所有后面的对话都会带上这份信息。/model用于切换模型版本。如果你发现当前模型对某些任务响应风格不对或者想用更快的模型做简单改动可以随时切换。/cost用来查看本次会话的花费情况包括输入输出 token 数量和估算费用。团队协作时定期查看/cost能帮助判断工作流是否合理。/bug是一个比较有意思的指令它可以生成一份 Bug 报告模板把当前遇到的现象、日志和复现步骤结构化。自定义 slash 命令是压轴项。你可以把自己常用的操作写进.claude/commands/目录下的 Markdown 文件之后用/命令名直接调用。比如我可以写一个/commit命令内容让 Claude 先读 git diff再按团队规范生成提交信息。还可以写一个/demo命令约定它必须按“功能说明、前置条件、操作步骤、验证方式”四段式输出演示方案。这些自定义命令本质上是提示词模板但它比复制粘贴更可靠因为参数和步骤都被固化在文件里不会遗漏。我自己的实际体会是自定义命令至少能节省三成沟通成本尤其是那些每周都要做、但流程又比较固定的活比如发布检查、接口自测、测试报告生成。第一次花十分钟写好模板后面就是一条命令反复用。3. 快捷键与编辑器联动手不离键盘的操作体验3.1 终端内快捷键一览命令敲得再快不如快捷键顺手。这个工具是终端交互快捷键几乎决定了你的操作节奏。先列几个最核心的快捷键作用使用场景Esc中断当前 AI 输出发现回答跑偏立即停止省的 tokenCtrlC停止当前运行任务卡死或持续报错时强制终止CtrlD退出交互会话收工时退出CtrlR搜索历史命令用过的指令快速找回比重新敲快↑ / ↓上一条 / 下一条输入微调上一次指令时非常实用ShiftTab切换自动补全建议命令和参数过长时快速选择ShiftEnter换行不发送输入多行复杂指令时不提前触发执行Enter发送消息默认提交这几个键里最容易被忽略的是 Esc。很多新手不知道 AI 输出过程中是可以随时打断的。当你发现它写了三行已经离题万里直接按 Esc 打断然后再补充一句“停一下回到刚才的需求”能省大量 token 和时间。CtrlR 的历史搜索是我的高频操作。比如之前敲过一条很长的claude -p管道命令第二次我不想再完整打一遍按 CtrlR 输入几个关键字就能找回来。它搜的是 Bash 历史里的 Claude Code 相关命令覆盖面很全。提示不同终端模拟器对快捷键的支持有细微差别尤其 Esc 和 Ctrl 组合键在某些环境里可能被系统截获。如果你发现按键无反应先检查是不是终端占用了快捷键再确认当前版本是否更新。3.2 编辑器集成配置要点终端之外大多数开发者的主战场是编辑器。Claude Code 可以配合主流编辑器使用最常用的方式是保持编辑器打开旁边开一个集成终端专门跑对话。这样代码修改、AI 输出、手动验证都在一个窗口内完成省去反复切换窗口的碎动作。在 VS Code 里我的布局是左侧源码、右下集成终端。AI 改完文件后我在终端里输入git diff检查改动然后口头要求它做小幅修正。这比让 AI 直接解释改了什么更直观。还有一类集成是让 Claude Code 直接读取编辑器当前打开的文件。你可以用命令把当前文件路径和内容带进上下文相当于让 AI 自动聚焦在你正在看的代码上。不同编辑器的插件实现方式略有差异具体配置看插件说明思路都是一样让“当前正在编辑什么”成为 AI 的默认上下文。.settings 和配置文件也要在这里讲清楚。项目根目录下的.claude/settings.json可以固化很多默认行为我的建议是最少配置三块内容permission 模式、allowedTools 列表、禁用工具列表。这些配置能减少频繁弹窗确认也能防止 AI 误用高风险命令。因为每个项目的敏感程度不一样我通常按项目单独配置而不是全局统一。配合 Git 使用是一个心智负担最低的高效方案。比如我经常执行git diff | claude -p 总结这次改动并生成提交信息先用 diff 拿改动、再让 AI 生成规范提交说明。整个过程不进入交互模式一条管道命令搞定适合频繁提交的场景。配置文件的改动注意一点每次改完 settings.json最好重启会话让配置生效。有些项目我遇到过改完了没提示错误、但实际没加载的情况重启一次最稳。4. 高效工作流实战从需求到落地的标准打法4.1 工作流一接手陌生项目的快速启动接手一个以前没见过的项目最容易犯的错是上来就让它改代码。我的建议是严格按照“先理解、再规划、后动手”的顺序对应的流程可以拆成四步。第一步在项目根目录执行/init让它扫描代码库生成 CLAUDE.md。第二步执行/add-dir有选择性地把核心源码目录、配置文件目录加进去别一股脑全塞否则上下文很快被撑爆。第三步用类似“先整体介绍项目结构和模块职责我只要重点不要贴源码”这样一句话让它输出结构化概览。第四步根据概览圈定目标再开始改代码。我用模拟项目 X 举个具体例子那是一个前后端分离的订单管理系统。首次进入我执行/init后发现它生成的 CLAUDE.md 很完整包括启动命令、目录结构和常见业务术语。然后我只把src/domain和src/api两个目录加进上下文让它梳理订单状态流转。它给出了三张状态图说明和对应的核心文件位置我确认理解一致后才让它开始修改状态校验逻辑。整个过程没有一次返工原因是前几步的“理解”工作做扎实了。这一套流程的核心思想是让 AI 先“说清楚它看到了什么”你确认无误后再“让它干什么”。只要理解对齐后续返工的次数会大幅下降。遇到特别大的模块还可以拆分成多个子任务分开处理一次只让它聚焦一个业务闭环。4.2 工作流二旧项目迭代改造的安全路径旧项目最怕的是一改就挂。面对历史代码我强烈建议把测试放在改造之前。我的标准路径是这样的第一步挑出要改动的函数或模块先写好覆盖核心逻辑的测试用例哪怕只是断言当前行为第二步让 Claude 运行测试确认基线是通过的第三步告诉它“在保证测试全部通过的前提下完成某需求”第四步每次改完立即跑测试红了就让它自查修复绿了再继续。这背后的逻辑很简单旧项目往往没有详尽的文档测试就是最可靠的“行为说明书”。AI 在改代码时如果没有测试约束特别容易出现“我觉得逻辑没问题”但实际行为已经坏的状况。有了测试你给它设置了一个客观标准AI 自己就能根据测试结果迭代修正不需要你一处处人工检查。对于并行任务子代理是个好选择。比如一个需求同时涉及前端表单校验和后端接口参数调整可以创建两个代理分别处理。需要注意代理之间的任务不能有强力耦合文件层面最好完全隔离否则两个代理同时改同一个文件会互相覆盖。改造过程中上下文管理显得更重要。每次改完一个模块就/compact一次清理掉过程性描述保留“已改哪些文件、测试结果如何、还剩什么事”这类关键信息。如果不压缩三四轮改名之后对话就什么都记不住了回答开始偷懒和跑偏。4.3 权限、安全与成本控制Claude Code 能读写文件、执行命令这是它高效的根源也是安全风险的根源。权限设置不对轻则频繁确认弹窗影响体验重则让它在项目里乱跑命令酿成事故。这一点必须认真对待。权限模式大致分几档。默认情况下遇到危险操作它会弹窗让你选择 Ask、Allow 还是 Deny。选择 Allow 表示本次允许Ask 会继续弹窗Deny 则拒绝。还有一种自动接受模式它会记住你的偏好一段时间内相似操作不再询问。参数模式里有一个--dangerously-skip-permissions看名字就知道这是跳过所有权限检查的开关属于强力模式。除非你在完全隔离的测试环境里或者执行的是纯读取操作否则别碰。更精细的做法是在 settings.json 里配置 allowedTools。你可以允许Edit操作、指定可写的文件路径、限制只读命令范围把权限画一个圈。圈外操作一律拦截弹窗或拒绝。这个方案对团队协作尤其重要每个人都按自己的危险敏感度配置而不是统一强制。成本控制是另一件容易踩坑的事。AI 对话是按 token 计费的你让它扫描整个仓库或让它从头读一个大文件都是费用上涨的常见原因。我的建议是形成两个习惯第一任务尽量聚焦别在一轮对话里塞太多不相关需求第二定期执行/cost观察哪些操作开销最大针对性优化。团队协作时安全策略还可以进一步固化。比如在 CLAUDE.md 中写入“禁止修改数据库连接配置”“禁止在未确认时删除文件”“上线相关的命令必须经过审核”。这些规则会被 AI 自动读取作为行为约束。权限配置和规范性文件一起用才真正把安全边界立起来。5. 常见问题与排查技巧实录5.1 高频报错与解决思路用久了 Claude Code我已经形成一套问题排查的反射性动作。下面按常见的现象、原因和解决方法做成一个速查表方便你直接对照排查。现象常见原因解决思路对话到后面回答跑偏、逻辑混乱上下文窗口快溢出或历史信息过杂执行/compact压缩历史必要时/clear重开并按要点重述需求总是弹出权限确认影响流程allowedTools 配置缺失或权限模式过严在 settings.json 中按项目配置允许的命令和文件范围执行claude --continue后发现上下文不对当前目录不是上次会话所属项目先切回原项目目录再检查最近的会话记录告诉它改文件它却只给方案不变动上下文记忆不完整或对目标文件不明确用引用具体文件再明确说“请直接编辑该文件”输出格式混乱难用脚本解析没有指定输出格式-p模式配合--output-format json使用跑长任务时进度不可见像卡住子代理或长调用正常耗时等待输出用 Esc 中断确认状态或拆分任务减少单次等待有个问题特别常见我把需求描述得过于宏大比如“把这个项目整体重构一下”。Claude 的执行结果往往让人崩溃它不是不想做而是任务范围太大缺少优先级。解决思路是拆任务第一步先让它出重构方案分模块列清单第二步逐模块执行第三步单独验收集合。这比逼着它一步到位靠谱得多。权限卡顿的问题我也踩过几次。有一次在某个测试项目里每改一个文件就弹一次确认非常烦。后来把改动的目录写进 allowedTools再配合自动化测试验证整个流程才顺畅下来。5.2 性能与上下文管理的独家心得最后分享几个只有实际跑久了才会体会到的技巧每一条都是真金白银换来的经验。第一一次只让 Claude 做一件小事。你可能会觉得“让它一次做完更省事”但在实际执行中任务越小它每一步的把握度越高返工越少。把一个复杂需求拆成十几个小任务每次只推进一个整体时间反而更短。第二优先用引用文件别复制粘贴大段代码。复制粘贴不仅占上下文还容易把格式搞坏。直接引用路径Claude 自己去读既准确又省 token。如果你担心它读错文件可以在引用后面补一句“读完先简述文件里有什么”。第三把项目级约定写进 CLAUDE.md不要每次对话重复强调。比如“使用 pnpm 安装依赖”“测试命令是 npm run test:unit”这些约定写一次就够了。每次重复说既浪费上下文也增加不一致的风险。第四警惕“AI 能力幻觉”即它在一个不确定的问题上给出了笃定的答案。遇到高风险改动我会专门追问一句“你确认这里不会有副作用吗解释依据”。如果它解释含糊我就手动检查代码而不是盲信。第五非常规任务尽量用子代理隔离执行。主对话保持简洁和专注子代理负责探查、试错、生成备选方案最后把结果汇总结论交回主对话。这种方式能防止大量中间过程污染主对话也方便你中途回滚方案。说了这么多其实核心就一句话让 AI 在明确的上下文边界里做明确的事你控制流程它负责执行和产出。用顺手之后Claude Code 不只是编码助手更像是能和你默契配合的结对工程师。
