Claude Code 常用命令详解:从启动到代码审查的完整指南

发布时间:2026/10/13 3:09:19
Claude Code 常用命令详解:从启动到代码审查的完整指南
1. 启动与进入三种姿势别只会敲一个 claude1.1 直接进入交互会话先把目录切对再说话我第一次在一台新电脑上敲下 claude 命令时差点被一串权限确认吓退。后来用久了才发现Claude Code 本质上就是一个跑在终端里的结对编程搭档真正拉开效率差距的不是 prompt 写得多炫而是你能不能熟练使用那几条常用命令。最熟悉的用法就是先cd到项目目录然后输入claude进入交互式 REPL。很多人会忽略一个关键前提当前目录决定了 Claude 看到的世界。我建议始终在 git 仓库的真正工作目录下启动而不是在用户根目录或某个外层目录启动。因为 Claude Code 会基于当前目录读取文件、执行命令、生成上下文快照如果你在根目录启动它扫描到的文件可能是几万个无关文件响应速度和准确性都会明显下降。第一次启动时一般会要求完成登录和授权不同环境的流程不太一样跟着提示走即可。启动后你会看到一个交互式输入框跟普通终端提示符很像但可以直接用自然语言下达任务。这个模式适合处理需要多轮往返的活写功能、重构、查报错、改配置。在我实际体验中进入一个干净仓库的交互模式给一句先帮我看懂这个项目的入口在哪是打开一段高效会话的最好方式。1.2 一次性提问-p / --print 的真正价值不是所有问题都值得启动一个完整会话。当你只是想快速知道当前分支和主分支差了几个提交某个函数在哪定义这类封闭式问题用claude -p ...更合适。-p或者--print让 Claude 执行完就把答案输出到 stdout 并退出不会进入交互循环也不会开启一个常驻会话。claude -p 找出 tests 目录下最近一周内标记了 TODO 的测试列出文件名和行号这段输出是纯文本可以继续管道给其他命令处理。如果要结构化数据还可以加--output-format json方便脚本解析。我一般在写扫描脚本、做 CI 辅助、或者想快速验证一个想法时用它而正经写代码时仍然回到交互模式。注意-p模式默认没有历史会话它更像一次即问即答所以别指望它能记住上一轮的语境。1.3 断线续传-c 与 --resume 怎么选Claude Code 的会话是持久化的。终端关闭、SSH 断开、甚至电脑重启会话都保存在本地所以恢复比想象中重要。claude -c或--continue会直接继续最近一次会话适合刚才聊到一半停下来现在想接着聊的场景。claude --resume会列出历史会话让你选择适合在多条会话线里挑某一个。我一般的使用习惯如果只是中断连接后想恢复用-c如果上午和下午开了多个不相干的话题用--resume。这里有一个很容易踩的坑恢复会话之后不要直接下达新任务先问一句我们之前进行到哪里了让 Claude 给出状态总结再接着干活。否则它可能带着一堆过期的上下文做错误假设反而比新开一个会话更糟糕。2. 会话内的操作命令中断、退出、切模式和看帮助2.1 CtrlC 与 CtrlD中断和退出别混淆在交互会话中CtrlC 是中断当前生成CtrlD 是退出整个会话。很多人第一次用会把两者混掉结果想退出却把正在生成的回答打断了下次又要重新拼接上下文。我的经验是如果你只是想阻止当前这个错误方向继续执行用 CtrlC如果今天的工作结束、彻底不再用这个会话了再按 CtrlD。这里要特别注意中断并不是回退。Claude 可能已经做了一部分文件修改你按 CtrlC 之后工作区里可能留着半截改动。所以中断之后最好补一句话把刚才改到一半的文件恢复原状或总结当前文件状态避免留下垃圾改动。我在一次批量重命名任务中按过几次 CtrlC结果半个目录的文件名已经变了没有这句补充想手动恢复相当痛苦。2.2 ShiftTab 切换执行模式调的是审批粒度Claude Code 在执行文件写入、运行命令前通常会征求许可。如果你觉得每次确认太烦可以用 ShiftTab 切换模式常见的有普通模式、自动接受编辑模式等输入框上方会有状态提示。普通模式适合处理核心业务代码每一步重要操作都会过你这一关自动接受编辑模式适合大范围重命名、格式化、批量替换这类低风险改动。切换模式的本质是调整审批粒度被动一点安全主动一点高效。我个人的建议是涉及删除文件、修改配置文件、安装依赖这类操作宁可保持普通模式一条条确认只有在处理大量模板代码时才切到自动编辑。不要图省事全局开启自动接受尤其是项目里含有密钥文件或生产配置时一个自动化的误操作可能比手动改十次还难收拾。2.3 /help 与一条命令记忆法不用把每条命令背下来。/help会列出当前版本支持的所有斜杠命令这也是我最常用的一条命令之一。我的记忆技巧是把命令分成三类——会话行为类/compact、/clear、项目记忆类/init、/memory、代码链路类/review、/lint、/export、/cost。记住类别之后具体命令完全可以在输入/时弹出的补全里找不用硬背。注意不同版本的功能会调整如果你在某个版本里发现某条命令不存在别慌以/help列出的现状为准。还有一些快捷键会随版本变化比如某些版本支持 ESC 中断、上下方向键翻历史这些都可以通过/help和终端自身的按键提示确认。3. 会话状态管理/compact、/clear、/memory、/init 别用混3.1 /compact上下文太长时先压缩而非清空对话轮次多了之后Claude 的上下文窗口会被占满表现出来就是它开始反复问你同一件事执行速度变慢token 消耗明显增加。这时候用/compact。它会把当前对话压缩成一份摘要保留主线目标、关键决策和待办丢掉冗长的原始内容。注意 compact 之后上下文变短了但信息是有损压缩重要细节可能丢失。所以我通常在 compact 之后立刻追加一句根据压缩后的摘要列出接下来还需要完成的 5 件事让它把摘要里的任务显式化再继续工作。使用场景举例一个大功能拆了十几个小步骤每步都带着报错和日志反复讨论这时历史里全是噪声compact 非常有用。但如果只是临时换个问题不要用 compact因为压缩本身也消耗 token而且有损直接 /clear 重新开反而更干净。3.2 /clear换话题时的重开机制/clear 会清空当前会话让上下文彻底归零。和 /compact 的区别compact 是续写同一本书并整理章节目录clear 是换一本新书。适用场景是话题完全切换比如刚做完前端样式要转去排查数据库迁移脚本或者当前会话已经被大量错误尝试污染继续下去只会把 Claude 带偏。我自己的经验是当你发现 Claude 开始根据上一轮的错误结论做推导说明上下文已经被污染了。这种情况下别犹豫果断 /clear重新给一个干净、准确的初始指令。损失少量历史节省大量 token。有人觉得清空太浪费于是硬撑着一个超长会话继续聊反而越聊越乱最后花的成本更高。3.3 /memory 与 /init给项目写一份入职手册Claude Code 支持项目级记忆。/init 会在项目根目录生成一份记忆文件常见的默认文件名是 CLAUDE.mdClaude 每次启动都会自动读取它。你可以把项目的测试命令、目录结构、编码规范、禁止改动的路径写进去。这相当于给 AI 一份入职手册让它不用每次重新理解项目约定。/memory 可以查看和编辑当前记忆内容。这俩很容易搞混init 是初始化/生成记忆文件memory 是查看/管理当前会话里已加载的记忆。我写 CLAUDE.md 的经验是尽量用当我想 X 时你应该 Y这种明确规则而不是散文式描述规则条目不要超过一屏否则 Claude 反而抓不住重点。另外项目演进后要定期让 Claude 根据当前代码更新记忆文件不然它会抱着旧约定不放明明目录重构了还在按老路径找文件。4. 代码产出命令从 /review 到 /lint 再到 /export4.1 /review提交前让 Claude 查漏但别把它当唯一评审Claude Code 能在你完成一批改动后对工作区变更做审查。我推荐在提交代码前跑一次/review。它不像是让你把 Claude 当成最终评审人而是当作第二个程序员它会重新读一遍 diff找出你自己没注意到的逻辑缺口、调试残留、边界条件疏漏。在实际体验中它最擅长的是自查式的低级遗漏比如留下一行console.log、忘处理空数组、条件分支写反。比较弱的是对产品语义和团队命名品味的判断所以不要全部照单全收。我个人的配合用法是先自己git diff看一遍然后/review最后针对它提到的点补测试。如果你是那种提交前懒得看 diff 的人至少让 /review 先帮忙兜底但最终合并前自己还是要扫一遍尤其是它建议删除的代码块要确认不是误判。4.2 /lint把机械问题从对话里剥离出去/lint 会按项目已有的 lint 规则检查代码。这个命令的价值不在于它多聪明而在于它把人和工具的分工理顺了格式、命名、未使用变量这类机械问题全交给 lint把 Claude 的注意力留给逻辑。运行之前确认项目里已经正确安装了 lint 配置否则它会提示找不到规则。我一般在 /review 之前先跑 /lint因为 lint 报的问题往往会影响 review 的判断质量让 Claude 把精力浪费在这里少了个分号上。也可以在编辑器里打开保存时自动格式化让每个文件尽量保持统一风格减少 review 时的噪声。实测下来一个干净的 lint 结果能让 /review 的报告质量大幅提高因为它不会花篇幅在风格问题上。4.3 /export把对话沉淀成可用文档而不是只留在终端里/export 可以把当前对话导出成文档通常是 Markdown。我通常用它做两件事一是把设计讨论、决策过程导出放到项目 docs 目录相当于自动生成的第一版设计文档二是把一次复杂的排障全过程导出交给同事继续排查或复盘。在项目交接时这是神器比口述一遍省力得多。但注意两点第一export 只是导出对话记录不是导出代码改动代码改动请正常走 git第二导出完成后记得脱敏终端路径、内部 IP、敏感环境变量这些内容很可能藏在对话里直接扔进团队文档会有泄露风险。我一般导完先扫一眼把含敏感信息的行删掉再提交。5. 授权、成本与排障/cost、/doctor 与权限确认该这样用5.1 权限确认能放则放该收则收Claude Code 默认对文件写入和命令执行做权限控制。常见交互是弹出一个确认列表你可以选择允许本次、允许本次会话、始终拒绝等。这里的关键不是全放或全拒而是按操作类型区分读取、搜索类操作大可以放行写入项目文件可以分批确认执行删除、安装依赖、改写配置这类不可逆或有副作用的操作多花两秒确认很值得。有些环境和脚本可能允许跳过权限比如通过启动参数直接关闭权限确认。这种模式只适合隔离环境或 CI 容器千万别在真实生产仓库里默认开启。一旦开启AI 可能会在无人确认的情况下执行有破坏性的命令风险完全不可控。我自己在本地机器上始终保留权限确认只有跑那些重复性极强、完全可回滚的批量操作时才临时放开。5.2 /cost别让一个会话悄悄烧掉太多/cost 显示当前会话累计消耗的 token 和估算金额。它对我最大的提醒作用是别把会话当聊天室。一个会话里如果堆了几百轮琐碎问题cost 会悄悄涨上去。看到数值偏高后我的操作顺序是先 /compact 压缩上下文然后审视是不是该 /clear 开新会话最后再评估是不是 prompt 里重复喂了很多大文件。有些人会忽略 cost觉得反正有预算。但成本不只是钱的问题当一个会话的 token 消耗过大往往意味着上下文已经臃肿到影响输出质量Claude 可能抓不住重点。把 /cost 当成一个会话健康度指标来用比单纯看金额更有价值。5.3 /doctor出问题先诊断而不是重装遇到启动报错、命令不响应、模型列表加载不出来先别急着重装。/doctor 会检查安装路径、依赖版本、环境变量、权限状态等然后输出诊断信息。它解决的问题往往是环境问题而非产品 bug某个依赖版本不一致、系统变量没配对、配置目录权限不对。我遇到过一次升级后所有会话都打不开跑 /doctor 发现是旧配置目录权限异常改完立刻恢复正常。经验是如果 /doctor 输出正常但问题还在再开一个带详细日志的会话抓日志把日志尾部贴给模型本身分析。排查顺序比盲目重装重要得多重装往往浪费十分钟还没解决根因。6. 组合工作流一次真实开发中的命令走查6.1 从新项目初始化到首轮代码生成模拟一个全新项目我把它叫模拟项目X。你刚把它 clone 到本地准备开始开发。命令序列很简单cd /path/to/模拟项目X claude进入交互后第一件事不是写功能而是/init让 Claude 阅读仓库并生成 CLAUDE.md把项目结构、构建命令、测试命令记录下来。之后开始第一个任务比如按 CLAUDE.md 里的约定新增一个命令行参数解析模块并补上对应的单元测试。功能实现后先自己看 diff再跑/lint最后/review确认没有遗漏。一个正常工作流就闭环了。6.2 修复 Bug 场景下的命令节奏假设线上报了一个列表页偶尔出现空白的 bug。我建议的序列是先claude --resume恢复一个专门排查该问题的历史会话如果之前已经开过然后问根据当前代码哪些位置的异步数据没有兜底处理让 Claude 先给排查范围。对话过程中如果反复贴了多份日志导致上下文膨胀适时/compact并让它重列待办。定位到根因后让 Claude 给出修复 patch人工检查 diff再跑相关测试、/lint、/review。如果这次排查思路很有价值用/export导出排障记录放进 docs 里。注意不要在会话中途同时塞进无关需求否则很容易把 Claude 的注意力拉偏导致 bug 没修完又引入新问题。真遇到这种情况果断 /clear。6.3 常用命令速查表场景命令说明启动交互会话claude进入当前目录的 REPL单次提问claude -p ...输出答案后直接退出继续最近会话claude -c接着上次的上下文选择恢复会话claude --resume列出历史会话供选择查看帮助/help查看当前版本所有命令压缩上下文/compact将对话摘要化保留主线清空会话/clear上下文彻底归零查看记忆/memory查看和编辑项目记忆初始化记忆/init生成 CLAUDE.md 记忆文件审查改动/review检查当前工作区变更运行 lint/lint执行项目已有的 lint 规则导出对话/export将对话导出为 Markdown查看成本/cost查看当前会话 token 估算环境诊断/doctor检查安装与运行环境最后分享一个自己踩过的坑我一度把 /clear 当成万能工具一觉得上下文乱就清空结果把好不容易整理出来的项目规则也一起清掉了。后来才习惯把重要约定先写进 CLAUDE.md再放心去 /clear。命令本身都很简单难的是判断什么时候该用哪一条。希望这份常用命令清单能帮你少走点弯路。