Claude Code 完整实战指南：高频指令、终端快捷键与安全工作流

很早以前我也觉得，AI 写代码就是把需求粘到网页聊天框里，再把生成的代码一段段贴回项目。直到我把 Claude Code 装进终端、在一个真实仓库里敲出第一条命令之后，这个习惯就被彻底改掉了。Claude Code 直接跑在你的代码目录里，能读文件、能执行命令、能自己跑测试，所有高频指令和快捷键都围绕着“在仓库里干活”这件事设计。这篇手册以我长期使用的版本为基准整理，适合已经装好 Claude Code、但不想每次都在 /help 里翻命令的人，也适合刚入坑、想搞懂效率工作流的新手。

我不会把官方文档里每个参数都抄一遍，只讲我自己在真实项目里反复用的指令、快捷键和操作习惯，以及那些踩过之后才知道的边角细节。需要提醒的是，Claude Code 迭代很快，不同版本在命令名和交互细节上会有差异，以下内容以当前主流版本为准，真拿不准的时候敲一下 /help 看本机版本。

1. 为什么我放着图形界面不用，天天在终端里用 Claude Code

1.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是长会话的救星。当一个会话里聊了太久，上下文接近上限，继续下去的效果会明显下降，这时候输入 /compact，Claude Code 会把之前的对话压缩成摘要放回上下文。注意，压缩是有损的，细节可能丢失。我的策略是在压缩前先让它把当前进度和待办写进 CLAUDE.md，或者干脆开一个新的会话。

配合交互式会话的是两个启动参数：claude --continue直接恢复最近会话，claude --resume进入历史会话列表让你选一个。从效率角度看，跨天工作我基本都用 --continue，省去了重启话题的成本；如果我手头有多个项目并行，则用 --resume 精确找回目标项目。命令行版本如果看到“继续还是开新会话”的选项，根据任务的连续性决策即可。

2.2 模型切换与费用监控：/model、/cost、/status

Claude 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 的快捷键设计思路和终端工具保持一致，学起来不费力，真正影响效率的就那么几个：

Ctrl+C 是打断利器。有时候 AI 已经开始动手改文件，但你意识到这个方案不对，直接 Ctrl+C 中断，省得它继续生成无效代码，还能避免不必要的 token 消耗。这一点和操作普通终端程序的直觉完全一致。

Ctrl+L 的摘要功能容易被忽略。清屏之后屏幕顶部会显示当前会话的简要状态，相当于不丢上下文地“重新铺开桌布”。我每切换一个子任务都会用一下，让视觉干净的同时确认 AI 还记着当前目标。

Ctrl+D 按两下退出的设计很贴心，防止误触直接把会话杀掉。临时想退出去干别的再用 --continue 回来，也很顺。

3.2 输入框里的操作习惯：Tab 补全、方向键历史和 / 斜杠菜单

除了全局快捷键，输入框本身也有一些常用操作。输入以/开头时会弹出命令菜单和自动补全，比如敲/co就能定位到 /compact。输入 @ 路径时同理， Tab 可以接受补全，和终端里补全文件路径的肌肉记忆一致。

方向键上和下会翻阅历史输入。如果你做过类似“先让 AI 跑一遍测试，再改代码”的重复指令，用方向键把上一条命令调出来微调一下就行，不用重新敲。

这里有个隐藏价值：历史输入和自动补全配合起来，你会发现高频操作实际上只需要输入几个字符。比如我输入/comp加了 Tab 再回车，基本秒切到 compact 确认界面。这些细节单独看不值一提，叠加起来却能明显降低操作的“摩擦感”。

3.3 配合 VS Code 时的 Shift+Ctrl+P

Claude Code 官方提供了 VS Code 扩展，这里最值得记的快捷键是 Shift+Ctrl+P。它的作用是打开 Peek 面板，在不离开编辑器的情况下展示 Claude Code 的交互界面，适合边看代码边给它下达指令。

我自己的习惯是：大范围文件浏览和阅读代码时留在 VS Code 里，配合 Peek 操作；需要密集执行命令、看完整输出时切回终端。两种界面各有优势，Peek 适合轻量对话，终端适合跑长任务和查看日志。这里没有绝对的“最佳使用方式”，取决于你当下的工作状态是“读代码”还是“跑任务”。

3.4 我用顺手之后形成的小习惯

几点长期使用积累出来的经验：

• 每天开工第一件事，claude --continue恢复昨天会话，而不是开新会话让 AI 重新熟悉项目。
• 每完成一个功能模块就/clear一次，避免上个功能的信息干扰下个功能的实现。CLAUDE.md 已经写好了项目底盘，清空上下文也不会损失核心信息。
• 觉得上下文快爆的时候，用 Ctrl+L 看一眼会话摘要，再决定是开新会话还是 /compact。
• 写命令时强制自己记忆核心缩写，比如 co=compact、mo=model，配合斜杠菜单的自动补全，手速能快不少。

这些小习惯单看都很琐碎，但长期下来，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 review，AI 会把它的思路摊在桌上，你在它动手之前就能拦截掉错误方案。

执行阶段我建议配合权限模式使用。计划阶段用只读模式，AI 只能读文件不能改；确认后切到 acceptEdits，让它可以编辑文件但执行命令时仍然弹确认；最后验证阶段再恢复常规确认模式。这套流程相对慢，但出错概率显著下降，适合改动量大的任务。

4.4 git 小步提交与回滚兜底

Claude Code 有能力自己执行 git 操作，但这把双刃剑需要小心。我的规则是让它“每完成一个逻辑步骤就提交一次，提交信息用中文概括改动”。小步提交的回滚成本最低，一旦某一步改坏了，直接 reset 回上一个提交点就行，不用手动撤销几十个文件的改动。

有一次我让 AI 做一个跨模块的重构，它一口气改了 20 多个文件。中途我发现某处的行为变了，但因为是一次大 commit，定位问题花了很长时间。从那之后我强制要求分步提交，这个习惯再没吃过亏。

如果你不想让 Claude Code 碰 git，直接在任务描述里写“不要执行任何 git 操作，你自己改完就行”，它通常会遵守。不过我还是建议放开 git 权限但配合小步提交约束，这样才能享受到“AI 自己管理改动”的便利，同时保留足够的容错空间。

4.5 多会话编排：什么时候开新会话、什么时候 continue

Claude Code 的上下文容量有限，如何编排会话是长期使用必须面对的课题。我的判断标准很简单：后续工作是否依赖前面的对话细节。

如果一个功能的实现过程需要多轮迭代，比如“先设计接口，再写实现，再跑测试修复”，我用 --continue 保持同一会话的连续性；如果一个功能已经收尾，接下来是另一个独立功能，直接开新会话，避免旧上下文干扰新任务。

会话之间靠 CLAUDE.md 和 git 记录来衔接。我平时会把每轮会话的结论写回项目文档，让下一个会话不需要重新推理一遍。这个“外部化记忆”的做法，比依赖 AI 的上下文窗口更可靠，而且团队其他人也能看到完整的决策过程。

5. 权限模式与安全边界：让 Claude 在可控范围内动手

5.1 权限模式怎么选

Claude Code 的权限模式决定了 AI 在什么范围内可以自主行动。我整理了一个对照表：

我最常用的组合是 plan 设计 + acceptEdits 实施 + default 验证。三阶段对应三种模式，既保证 AI 有足够权限干活，又能把关键动作卡在人工确认这一关。

bypassPermissions 我基本只在完全自动化的测试环境里用，而且前提是跑在隔离容器或沙箱里。在正常开发环境开着这个模式，风险完全不可控。一次我不小心在非沙箱环境下放开了权限，AI 尝试执行了一个卸载依赖包的命令，我反应过来赶紧 Ctrl+C 中断，从此再不敢大意。

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、Ctrl+L、Ctrl+R 这五个用熟，再逐步加上 /model、hooks 和 -p 模式。命令数量从来不是效率的关键，真正让你快起来的是把上下文管理好、让它在可控范围内放手干活的那套节奏感。工具天天在变，这套核心思路不会过时。