Claude Code 完整实战指南:高频指令、终端快捷键与安全工作流
很早以前我也觉得AI 写代码就是把需求粘到网页聊天框里再把生成的代码一段段贴回项目。直到我把 Claude Code 装进终端、在一个真实仓库里敲出第一条命令之后这个习惯就被彻底改掉了。Claude Code 直接跑在你的代码目录里能读文件、能执行命令、能自己跑测试所有高频指令和快捷键都围绕着“在仓库里干活”这件事设计。这篇手册以我长期使用的版本为基准整理适合已经装好 Claude Code、但不想每次都在 /help 里翻命令的人也适合刚入坑、想搞懂效率工作流的新手。我不会把官方文档里每个参数都抄一遍只讲我自己在真实项目里反复用的指令、快捷键和操作习惯以及那些踩过之后才知道的边角细节。需要提醒的是Claude Code 迭代很快不同版本在命令名和交互细节上会有差异以下内容以当前主流版本为准真拿不准的时候敲一下 /help 看本机版本。1. 为什么我放着图形界面不用天天在终端里用 Claude Code1.1 从“贴代码进聊天框”到“在代码库里面对话”Web 版 AI 聊天工具的核心局限是它看不见你的项目。你只能把文件内容复制进去改完再复制回来一旦项目里有十几个文件交叉引用这种工作方式基本就断了。Claude Code 的价值在于它活在你的仓库里启动的时候就能感知当前目录结构、git 状态、文件内容甚至能主动打开文件确认上下文。这意味着你不需要每次对话都解释“我们项目用 React 和 TypeScript”“测试命令是 pnpm test”。它可以通过 CLAUDE.md 和文件系统自动获取这些信息。我接手陌生项目时的体验差别很明显以前先要花半小时读代码、看文档、理清目录结构现在直接让 Claude Code 先做一次代码库走读再交给我一份项目地图剩下的对话都在这个共同认知基础上展开。这种交互模式的改变不仅仅是“方便了一点”而是把 AI 从一个“问答工具”变成了“能动手的结对开发者”。它可以执行 shell 命令、修改文件、跑测试、提交 git只要你给了权限。所以学会控制它、约束它比学会命令本身更重要。1.2 第一次值得敲进去的三个命令如果你是第一次打开 Claude Code别急着让它写某个功能先把这三个命令用熟基本能覆盖 80% 的上手场景。claude --continue恢复最近一次会话的上下文。适合昨天聊到一半、今天接着干的情况不用重新解释项目背景。/help列出当前版本支持的全部命令和快捷键。版本不同内容可能不同遇到不确定的功能这是最可靠的入口。/init让 Claude Code 扫描当前仓库生成一份 CLAUDE.md 项目说明文件。这份文件会成为后续会话的项目记忆相当于给 AI 写了一份“入职手册”。我见过不少刚开始用的人打开 Claude Code 就问“帮我写个登录功能”结果 AI 对项目结构一无所知来回摸索了好几次才进入状态。正确做法是花两分钟先跑 /init让对话建立在项目基本盘之上。还没安装的话全局装一下 npm 包就行npm install -g anthropic-ai/claude-code然后进到项目目录敲 claude 启动。首次运行会引导你登录账号完成认证。2. 高频指令速查按使用场景分组照着敲就能用2.1 会话与上下文管理/clear、/compact、--continue、--resume会话和上下文管理是 Claude Code 日常使用里最影响体验的部分比选哪个模型更重要。/clear用来清空当前会话的上下文。我一般在两种情况用它一是当前任务已经结束准备切换到另一个完全不相干的功能二是对话跑偏了AI 开始扯一堆和当前目标无关的内容。清空之后上下文归零但也意味着前面的“记忆”全部丢失所以执行前我会确认关键决定已经写进代码或文档。/compact是长会话的救星。当一个会话里聊了太久上下文接近上限继续下去的效果会明显下降这时候输入 /compactClaude Code 会把之前的对话压缩成摘要放回上下文。注意压缩是有损的细节可能丢失。我的策略是在压缩前先让它把当前进度和待办写进 CLAUDE.md或者干脆开一个新的会话。配合交互式会话的是两个启动参数claude --continue直接恢复最近会话claude --resume进入历史会话列表让你选一个。从效率角度看跨天工作我基本都用 --continue省去了重启话题的成本如果我手头有多个项目并行则用 --resume 精确找回目标项目。命令行版本如果看到“继续还是开新会话”的选项根据任务的连续性决策即可。2.2 模型切换与费用监控/model、/cost、/statusClaude Code 支持在会话中切换模型对应命令是 /model。我日常习惯是普通代码生成、重构、写测试用 Sonnet速度和质量平衡涉及复杂架构设计、长文档分析、跨模块推理时用 Opus批量处理简单但量大的任务时用 Haiku省 token 也够用。具体可选模型以你账号能访问的为准/model 会列出清单。/cost用于查看当前会话的 token 用量和预估费用。这不是一个需要频繁关注的命令但在跑大规模重构或让 AI 通读整个仓库时我会敲一下心里有数。/status能显示当前会话的状态包括上下文使用比例、模型信息、会话 ID 等当你觉得 AI 反应变慢、判断它是不是上下文快满了的时候用这个命令确认。这里有个容易被忽略的点切换模型不会清空上下文。也就是说你可以先用 Opus 做架构规划再切到 Haiku 去执行简单实现规划内容仍然在上下文里不需要重新描述一遍。我经常这么组合使用来平衡成本和稳定性。2.3 把指定路径塞进上下文 语法与 /init对话之外Claude Code 最有用的上下文注入方式是 语法。在输入框里输入 可以呼出文件选择器也可以直接输入相对路径把具体文件加入上下文。比如src/utils/format.ts就能让 AI 看到这个文件的完整内容不用靠它自己猜。也可以把整个目录加进上下文。比如src/components适合让 AI 先了解某个模块的整体风格再动手。这里要控制好量一次性塞入整个大目录会快速消耗上下文效果反而变差。我一般只把当前改动涉及的目录加进去其余让 AI 自己按需读文件。/init的作用则更进一步它现在会在仓库里生成或更新 CLAUDE.md沉淀项目技术栈、命令、目录结构和代码风格等信息。CLAUDE.md 是跨会话持久的项目记忆之后每次开启新会话Claude Code 都会自动把这份文件作为背景信息。这也是为什么我说它是“入职手册”它解决的是 AI 每次“失忆”后重新熟悉项目的问题。2.4 配置与账号/config、/login、/logout、/update/config用来打开 Claude Code 的配置文件包括用户级和项目级两层。用户级配置在~/.claude/settings.json放全局偏好、常用权限策略项目级配置在当前项目的.claude/settings.json放团队共享规则。这个文件我一般会维护两样东西允许自动处理的工具白名单以及提醒 AI 不要触碰的安全路径。账号切换用 /login 和 /logout。团队合作时如果一台机器上多个账号轮流用这两个命令比反复删 token 文件省事得多。版本更新方面交互式会话里可以用 /update 触发检查和升级也可以在终端跑npm update -g anthropic-ai/claude-code。Claude Code 版本更新频率很高我遇到过旧版本某个命令行为不一致的情况升级后恢复正常。碰到奇怪问题先升级再排查是性价比最高的路径。2.5 非交互模式 claude -p把 Claude Code 变成自动化工具很多人用 Claude Code 只开交互式会话其实它还支持一条命令跑完就退出claude -p 你的提问。这个 print 模式非常适合作自动化的“胶水层”。我举个例子。假设我要批量给几十个组件文件加上统一的注释头手工让交互式会话逐文件处理太慢用脚本写又容易出错。我写一个循环对每个文件执行claude -p 给 src/xxx.ts 添加符合项目规范的注释头就能批量完成。配合--output-format json还能拿回结构化的输出结果方便进一步处理。在 CI 场景里claude -p也有用武之地。比如在提交前让 AI 检查 diff 是否存在明显问题输出 JSON 结果给 CI 判断。需要注意权限问题非交互模式同样受权限模式约束而且自动化流程里没人盯着弹窗确认所以一般只跑只读分析或配置好允许工具白名单后再跑写操作。这个度要自己把握好别一上来就 bypassPermissions 往仓库里乱写。3. 快捷键与终端操作习惯告别频繁返工3.1 先记住这四个其它都可以慢慢来Claude Code 的快捷键设计思路和终端工具保持一致学起来不费力真正影响效率的就那么几个快捷键作用我的使用场景CtrlC中断当前响应AI 生成方向跑偏不想等它说完就停止CtrlD退出 Claude Code结束工作时退出会弹确认连按两次才真正退出CtrlL清屏并显示当前会话摘要刷屏后重新聚焦顺便看一眼进度CtrlR打开历史会话搜索找回很久之前的某个会话CtrlC 是打断利器。有时候 AI 已经开始动手改文件但你意识到这个方案不对直接 CtrlC 中断省得它继续生成无效代码还能避免不必要的 token 消耗。这一点和操作普通终端程序的直觉完全一致。CtrlL 的摘要功能容易被忽略。清屏之后屏幕顶部会显示当前会话的简要状态相当于不丢上下文地“重新铺开桌布”。我每切换一个子任务都会用一下让视觉干净的同时确认 AI 还记着当前目标。CtrlD 按两下退出的设计很贴心防止误触直接把会话杀掉。临时想退出去干别的再用 --continue 回来也很顺。3.2 输入框里的操作习惯Tab 补全、方向键历史和 / 斜杠菜单除了全局快捷键输入框本身也有一些常用操作。输入以/开头时会弹出命令菜单和自动补全比如敲/co就能定位到 /compact。输入 路径时同理 Tab 可以接受补全和终端里补全文件路径的肌肉记忆一致。方向键上和下会翻阅历史输入。如果你做过类似“先让 AI 跑一遍测试再改代码”的重复指令用方向键把上一条命令调出来微调一下就行不用重新敲。这里有个隐藏价值历史输入和自动补全配合起来你会发现高频操作实际上只需要输入几个字符。比如我输入/comp加了 Tab 再回车基本秒切到 compact 确认界面。这些细节单独看不值一提叠加起来却能明显降低操作的“摩擦感”。3.3 配合 VS Code 时的 ShiftCtrlPClaude Code 官方提供了 VS Code 扩展这里最值得记的快捷键是 ShiftCtrlP。它的作用是打开 Peek 面板在不离开编辑器的情况下展示 Claude Code 的交互界面适合边看代码边给它下达指令。我自己的习惯是大范围文件浏览和阅读代码时留在 VS Code 里配合 Peek 操作需要密集执行命令、看完整输出时切回终端。两种界面各有优势Peek 适合轻量对话终端适合跑长任务和查看日志。这里没有绝对的“最佳使用方式”取决于你当下的工作状态是“读代码”还是“跑任务”。3.4 我用顺手之后形成的小习惯几点长期使用积累出来的经验每天开工第一件事claude --continue恢复昨天会话而不是开新会话让 AI 重新熟悉项目。每完成一个功能模块就/clear一次避免上个功能的信息干扰下个功能的实现。CLAUDE.md 已经写好了项目底盘清空上下文也不会损失核心信息。觉得上下文快爆的时候用 CtrlL 看一眼会话摘要再决定是开新会话还是 /compact。写命令时强制自己记忆核心缩写比如 cocompact、momodel配合斜杠菜单的自动补全手速能快不少。这些小习惯单看都很琐碎但长期下来Claude Code 给我的感觉就不再是一个需要“伺候”的工具而是接手项目后能立刻进入状态的老搭档。4. 高效工作流从陌生仓库到交付一个功能的完整流程4.1 第一步不是写代码而是把 CLAUDE.md 建起来我接手一个不熟悉的仓库时绝不会上来就让 Claude Code 写功能。第一步永远是/init让 AI 扫描仓库结构、构建命令、测试方式、依赖关系生成一份项目说明文件。这份文件从今往后就是它在本仓库里所有会话的共同背景。CLAUDE.md 的维护是一个持续过程。初始化生成的版本只是起点每当我发现 AI 频繁问同一个项目问题时就把答案写进 CLAUDE.md。比如“支付模块走 mock 服务”“环境变量从 .env.local 读取”“新组件放 src/components/xxx 目录”。这些信息越沉淀AI 后续工作越顺。我还会在~/.claude/CLAUDE.md里放一些跨项目的个人偏好比如“提交信息用中文”“优先保持类型安全”“不要随意升级依赖版本”。用户级和项目级两层记忆叠加让 Claude Code 在任何一个项目里的行为都更接近我的预期。4.2 任务描述模板让 Claude 少问三遍新手在使用时最常见的挫折是“AI 问来问去不干活”很多时候问题不在于 AI而在于需求描述太模糊。我现在给 Claude Code 提需求遵循一个固定模板背景这个任务的目的是什么处于项目的哪个阶段。目标具体要完成什么最好能写清验收标准。涉及文件哪些文件可以改哪些不能碰。约束技术栈限制、风格要求、性能最低标准。比如我不会写“帮我优化这个页面”而是写“背景用户列表页首屏加载慢。目标把首屏请求数从 15 个降到 5 个以下JSON 体积控制在 100KB 以内。涉及文件src/pages/UserList.vue、src/api/user.ts。约束不要引入新依赖保持现在的手写排序逻辑。”这样的描述AI 基本不需要反复追问第一轮就能给出可用方案。如果你觉得这个模板太麻烦至少把“验收标准”和“约束”这两段写清楚它们能直接决定输出质量。4.3 计划-执行-验证三步法即使需求描述清晰我也不会让 Claude Code 一次性把所有代码写完。更稳的做法是把过程拆成三步计划要求“先不要改代码输出实施方案列出涉及的文件、改动点和潜在风险”。执行确认计划合理后让它按方案实现。验证明确要求“实现完成后运行测试和 lint输出检查结果”。这么做的好处是极大减少“AI 猜错方向改了一堆文件然后发现不对”的情况。尤其涉及多文件改动时计划阶段相当于免费的 code reviewAI 会把它的思路摊在桌上你在它动手之前就能拦截掉错误方案。执行阶段我建议配合权限模式使用。计划阶段用只读模式AI 只能读文件不能改确认后切到 acceptEdits让它可以编辑文件但执行命令时仍然弹确认最后验证阶段再恢复常规确认模式。这套流程相对慢但出错概率显著下降适合改动量大的任务。4.4 git 小步提交与回滚兜底Claude Code 有能力自己执行 git 操作但这把双刃剑需要小心。我的规则是让它“每完成一个逻辑步骤就提交一次提交信息用中文概括改动”。小步提交的回滚成本最低一旦某一步改坏了直接 reset 回上一个提交点就行不用手动撤销几十个文件的改动。有一次我让 AI 做一个跨模块的重构它一口气改了 20 多个文件。中途我发现某处的行为变了但因为是一次大 commit定位问题花了很长时间。从那之后我强制要求分步提交这个习惯再没吃过亏。如果你不想让 Claude Code 碰 git直接在任务描述里写“不要执行任何 git 操作你自己改完就行”它通常会遵守。不过我还是建议放开 git 权限但配合小步提交约束这样才能享受到“AI 自己管理改动”的便利同时保留足够的容错空间。4.5 多会话编排什么时候开新会话、什么时候 continueClaude Code 的上下文容量有限如何编排会话是长期使用必须面对的课题。我的判断标准很简单后续工作是否依赖前面的对话细节。如果一个功能的实现过程需要多轮迭代比如“先设计接口再写实现再跑测试修复”我用 --continue 保持同一会话的连续性如果一个功能已经收尾接下来是另一个独立功能直接开新会话避免旧上下文干扰新任务。会话之间靠 CLAUDE.md 和 git 记录来衔接。我平时会把每轮会话的结论写回项目文档让下一个会话不需要重新推理一遍。这个“外部化记忆”的做法比依赖 AI 的上下文窗口更可靠而且团队其他人也能看到完整的决策过程。5. 权限模式与安全边界让 Claude 在可控范围内动手5.1 权限模式怎么选Claude Code 的权限模式决定了 AI 在什么范围内可以自主行动。我整理了一个对照表权限模式行为典型场景default每次工具调用都弹确认刚接手新项目还不完全信任 AIacceptEdits自动接受文件编辑命令仍需确认方案已确认实施阶段plan只允许只读操作不能修改文件需求分析、方案设计阶段bypassPermissions跳过一切确认全自动流水线但风险最高慎用我最常用的组合是 plan 设计 acceptEdits 实施 default 验证。三阶段对应三种模式既保证 AI 有足够权限干活又能把关键动作卡在人工确认这一关。bypassPermissions 我基本只在完全自动化的测试环境里用而且前提是跑在隔离容器或沙箱里。在正常开发环境开着这个模式风险完全不可控。一次我不小心在非沙箱环境下放开了权限AI 尝试执行了一个卸载依赖包的命令我反应过来赶紧 CtrlC 中断从此再不敢大意。5.2 hooks 自动化的合理玩法Claude Code 支持 hooks 机制可以在特定事件点触发自定义脚本。我实际用得多的是三个事件点PreToolUse工具调用前触发可以做安全检查。PostToolUse工具调用后触发可以做自动清理。UserPromptSubmit用户提交输入时触发可以注入额外上下文。举个例子我在 PreToolUse 里写过一个检查如果 AI 要执行 npm 卸载命令自动拦截并提示。这个 hook 来自一次真实事故我莫名其妙少了几个依赖后来发现是 AI 把“清理临时依赖”理解成了“卸载项目核心依赖”。另一个实用场景是 UserPromptSubmit 注入当前 git 状态。每次提问时自动把当前分支名、未提交改动数量附加到上下文AI 就能知道自己改到哪了。这个能力不需要多复杂却让它在长会话里保持对项目状态的感知。5.3 不要让 Claude 碰到的信息Claude Code 会读取上下文中的文件内容有些信息本身就不应该进入对话。我有一条铁律CLAUDE.md 和项目说明里绝不写密钥、token、数据库连接串。表面上 AI 只是读一眼但这些内容可能出现在历史记录、会话摘要、甚至被压缩后暴露在日志里。生产环境命令同样不建议碰。我见过有人让 AI 直接跑数据库迁移命令一旦指令写错后果不是本地能抹平的。如果确实需要 AI 操作生产环境至少先让它输出准备执行的命令人工确认后再执行而不是直接在对话里放行。5.4 安全底线 checklist总结一份我每次配置新项目时都会过的检查项CLAUDE.md 不包含敏感凭据只写技术信息和项目约定。项目级 settings.json 设置了禁止 AI 修改的路径和工具。高危命令默认弹确认不开放 bypassPermissions。定期审查 hooks 和权限配置看有没有被自己越改越松。大型自动化任务先在隔离环境跑一遍确认无异常再到真实仓库。这些底线不需要多复杂关键是想清楚一个问题如果 AI 把坏事的权限拿到了你的回滚方案是什么想清楚之后再放开权限才能既享受效率又睡得着觉。6. 我踩过的坑与当前版本的边界6.1 上下文膨胀compact 不是万能的我吃过最大的亏是上下文膨胀。早期我以为 /compact 能无限压缩结果有一次在 12 万 token 的会话里压缩了好几次最后 AI 开始“失忆” —— 忘记了我定义的输出格式把已经完成的模块重新实现了一遍。原因很简单压缩会丢失细节。一个 5 万 token 的会话压缩成 2000 token 摘要中层的决策、临时的约定、一张表里的字段关系可能全部蒸发。从那以后我的策略是避免让一个会话活太久一般达到上下文用量的 60% 左右就开始收尾把重要结论写进 CLAUDE.md 或项目文档然后开新会话。6.2 模型切换后行为差异同一个任务换模型之后行为可能完全不一样。我之前在一个会话里用 Sonnet 开局中间切到 Haiku 做批量任务结果它对项目规范的理解出现了偏差代码风格明显不一致注释也简化了很多。原因在于不同模型在指令遵循和风格一致性上的表现有差距。现在的处理方式是小任务和批量任务单独开会话用 Haiku 跑核心架构和关键逻辑放在 Sonnet 或更强模型上并用 CLAUDE.md 把代码风格写死。尽量避免在同一个复杂会话里频繁换模型不然前后行为的割裂感会很明显。6.3 自动化脚本的翻车点claude -p做自动化很好用翻车也常发生在自动化里。一次我写了个脚本循环处理 200 个文件某个文件触发了 AI 的高权限操作而脚本没有设置针对单次调用的耗时限制整个队列被卡住了好几分钟。跑自动化之前我会先设置超时机制每一条命令给一个合理的时间上限同时把权限模式卡在只读或 acceptEdits尽量不引入需要交互的确认流程最后一定要先在小样本上跑一遍确认输出格式和效果没问题再全量执行。自动化最忌“只管启动、不管过程”一个小样本验证能避免大范围返工。6.4 版本迭代太快怎么跟上Claude Code 的版本更新频率高命令和配置项会经常调整。之前我看过某条命令在新版被改名旧脚本直接跑不通。现在我有一件很朴素的事每次升级后敲一下 /help快速扫一眼有没有新增或变更项目里用到的命令在升级后先跑一遍冒烟测试确认没问题再继续大规模使用。配置和 hooks 相关的变化我会关注官方文档和更新日志。这东西没有捷径工具迭代快就意味着你需要定期花十几分钟重新学习。好在核心命令体系相对稳定日常能用到的 /init、/clear、/compact、路径、--continue 这些基本盘变化不太大先吃透这些再跟上版本节奏就不会慌。最后分享一点个人体会命令和快捷键别急着背全先把 /help、/init、/compact、CtrlL、CtrlR 这五个用熟再逐步加上 /model、hooks 和 -p 模式。命令数量从来不是效率的关键真正让你快起来的是把上下文管理好、让它在可控范围内放手干活的那套节奏感。工具天天在变这套核心思路不会过时。