REECHO大鱼总舵装好 Claude Code 之后，大多数人第一反应是敲一下 claude 回车，然后问它"你会什么"。但这个终端里的 AI 编码助手，真正的效率来源恰恰是它那一整套命令行体系——从会话内的斜杠命令、权限控制，到面向脚本的 -p 参数。我见过不少同事用了两周还停在"聊天框"阶段，不是工具不行，是根本没摸到命令行的门道。
这篇是 Claude Code 从入门到精通系列的第二篇，专门把终端命令这一层彻底拆开：安装启动、日常交互、会话状态管理、bash 执行权限、自动化调用参数、配置与排错，一条一条过。适合已经跑通基本对话、想进一步提升效率的开发者；也适合准备把 Claude Code 集成进 CI 或脚本工作流的工程师。全文不对读者分什么"基础版/进阶版"，我默认你已经知道 Claude Code 是用来干嘛的，下面这些东西是我踩坑两个月之后真正会留在配置里的部分。
1. 先把底座立起来：安装启动与运行环境
1.1 三种安装方式怎么选
终端命令的起点当然是"怎么装上"。Claude Code 目前的安装途径主要是三条：npm 全局安装、官方原生安装器、Homebrew（macOS）。
npm 是最通用的，一条命令搞定：
bash复制npm install -g @anthropic-ai/claude-code
这个方法在 macOS、Linux、Windows 的 WSL 里都能用，适合已经装了 Node.js 的开发机。短板是升级依赖 npm，学校或公司内网 npm 源偶尔会同步慢，连 npx 都不行的时候容易卡住。
原生安装器现在的体验比 npm 好，安装之后是一个独立二进制，不占 Node 环境。macOS/Linux 上一般是官方脚本，Windows 上也有官方提供的安装包，双击就能装。升级走自身机制，和 npm 无关。我个人的建议是：如果是主力开发机，优先原生安装器；如果机器上有严格的软件管理流程、或者你在多台机器间要保持统一风格的安装方式，npm 反而更省心。
Homebrew 也是一条路，但和上面两条相比没有额外优势，日常用 brew install claude-code 即可，适合习惯 brew 管理一切的朋友。
1.2 启动命令与首次登录
安装完成后，终端里直接敲：
bash复制claude
就进入交互式会话。首次启动会要求登录。严格来说 Claude Code 的登录和网页端 Claude 账户是绑定关系，走一遍 OAuth 流即可，浏览器弹出来确认一下就好。
如果你不想绑账号，而是用 API Key，那就在环境变量里放好：
bash复制export ANTHROPIC_API_KEY=sk-ant-api03-xxxx
有了 Key 之后启动过程会跳过交互式登录，适合服务器、CI 这类没法开浏览器的环境。claude 默认会读取当前目录作为"工作目录"，所有文件操作、命令执行都以这个目录为根，所以养成习惯：先 cd 到项目目录，再启动 claude，不要在一个全盘目录下直接开。
1.3 跨平台的几个注意点
Windows 上我强烈建议用 Windows Terminal 跑 Claude Code，不要用老的 cmd 窗口。cmd 对 ANSI 颜色、交互式 UI 的支持都不行，Claude Code 在终端里的富文本界面会显示得乱七八糟。如果你习惯 Git Bash，也没问题，但要注意脚本类操作时路径分隔符会用 /，和 Windows 原生命令不总是一致。
Ubuntu 这类 Linux 发行版上玩的人越来越多，容易踩的坑是 shell 默认不是 bash，比如某些发行版默认 dash 导致登录脚本不生效。建议装完以后确认一下 echo $SHELL，把 shell 固定为 bash 或 zsh，免得每次启动都要手动 source 环境变量。
VS Code 用户可以直接装 Claude Code 的官方扩展，扩展本质上是嵌入了同一个 CLI。好处是可以把对话面板放在编辑器侧栏，读取当前打开的文件，但对终端命令本身没区别，本文讲的命令在扩展里照样能敲。
1.4 接本地模型：把 LLM 底座换成本地推理
现在很多人喜欢把 Claude Code 指向本地模型服务，比如 LM Studio。原理很简单：Claude Code 本身只是一个命令行客户端，它通过 OpenAI 兼容接口去呼叫后端模型。你在启动前设置好两个环境变量：
bash复制export ANTHROPIC_BASE_URL=http://localhost:1234/v1
export ANTHROPIC_MODEL=lmstudio:qwen2.5-coder-7b-instruct
然后照常 claude 启动，请求就走本地了。需要注意两点。第一，Claude Code 的很多功能依赖工具调用（function calling），本地模型如果工具调用能力不够强，它可能表现为"一直在想但不动手"，或者生成的命令完全是错的。第二，不是所有本地模型都支持长上下文，Claude Code 默认会给模型发大量系统提示，小显存模型很容易被上下文塞爆。用 LM Studio 这类工具时，先把上下文长度设置调大，再把系统提示精简，才能勉强跑得动。这个方案适合做离线实验、代码审查，真要写完整个项目，老老实实用官方模型。
提示：
ANTHROPIC_MODEL的命名不是随便写的，不同版本的前缀规则有差异，如果你设置后报 "model not found"，优先去对应模型的 README 或文档里找正确的模型 ID 写法。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 会话内的日常交互：这些命令每天都在用
2.1 斜杠命令先认识一圈
进了会话之后，输入 / 就会弹出斜杠命令列表。这一层是所谓"终端命令全面解析"里最先要用起来的。常用的几个：
/help：查看帮助，建议新手至少翻一遍；/status：当前会话的状态、模型信息；/cost：本次会话消耗了多少 token 和费用；/model：切换模型，比如从默认模型切到更大上下文型号；/export：导出会话内容，做记录用。
斜杠命令本质上是给 CLI 本身的指令，不是发给模型的提示词。理解这一点很关键：你敲 /clear 不是告诉模型"忘掉之前的话"，而是直接操作客户端上下文。
2.2 附带资源：@ 引用文件与目录
在提示语里用 @ 可以引用文件或目录。比如：
code复制@src/utils/parser.ts 帮我看看这个文件的重构方向
Claude Code 会把对应文件内容附加到上下文里，相当于你手动贴了一段代码给它。目录也可以引用，比如 @src，会扫描目录内的文件，但不会无脑全塞进去，它会先列文件再按需读取。
这个 @ 机制是日常高频操作，甚至比一些斜杠命令更重要。我习惯让模型先看整体再动手，一条 prompt 里通常会这样写：
code复制@src 先读一下目录结构，然后把 @src/utils/request.ts 里关于重试逻辑的部分提取出来，说说问题在哪。
多个 @ 可以混用，但别一次塞几十个文件，上下文有限，模型"读不过来"和"读不完"都会影响质量。
2.3 中断、退出与多会话切换
日常交互里，随时可能想让模型停下来。Esc 键是"停止生成"；如果模型正在执行一串操作，Esc 会打断当前步骤，但不会撤销已经发生的文件修改。Ctrl+C 是更硬的打断。退出会话用 /exit，或者连续按 Ctrl+C。
多窗口并行是我自己最喜欢的一个用法。终端里开两个标签页，一个跑"梳理架构"的会话，一个跑"改bug"的会话，互不干扰是因为每个会话默认都绑定在启动时所在的目录上，会话历史也是按目录隔离的。后面讲到 --resume 时这部分会更清楚。
2.4 一个很容易忽略的交互点：权限提示
第一次让 Claude Code 执行命令、写文件时，终端里会弹出权限确认，选项大致是"允许一次、始终允许、拒绝"。很多人嫌麻烦全选"始终允许"，这是省事还是埋雷，第四章节我会专门展开。这里只提一句：交互式的权限提示是命令层的一部分，不是弹窗打扰，它决定了后续哪些命令可以自动跑。
3. 上下文状态三件套：/init、/clear、/compact 的实战时机
3.1 /init：给项目建立长期记忆
/init 是 Claude Code 里被低估的一个命令。执行后，它会扫描项目结构，在目录下生成一个 CLAUDE.md 文件，里面记录了项目约定、常用命令、架构要点。此后每次新开会话，Claude Code 都会自动读取这个文件，模型一进来就"知道"项目背景。
真正的用法是把你脑子里那些不成文的规则写进去。比如"所有新接口必须写单元测试""数据库迁移文件要按日期命名""这个仓库不允许改 public 目录"。模型每次干活前都会先读 CLAUDE.md，比你在每条提示里重复约束要有效得多。
我的建议是：项目起步阶段就跑一次 /init，然后手工编辑 CLAUDE.md 把它调到真正贴合团队规范的状态。规则变了就再跑一次，或者直接改文件，不需要每次对话都在提示里重新立规矩。
3.2 /clear：什么时候必须用
/clear 会把当前会话上下文清空，模型"失忆"，token 占用归零。适合的场景很明确：一个任务彻底完成了，下一个任务和它毫无关系；或者你发现自己和模型来回纠缠了很久，上下文已经在崩溃边缘。
有一个判断标准：当你感觉模型的反应越来越"絮叨"、总是引用很早之前的错误决定，或者开始忘记你最近的修改，说明上下文已经污染了，这时候别犹豫，/clear 之后重新开个干净会话。
有人担心 /clear 会丢目标代码。不会，文件系统才是代码的真身，上下文只是模型的"工作记忆"。清空之前如果担心，可以先 /export 一份记录，仅此而已。
3.3 /compact：长会话的折中方案
/compact 做的事情是压缩当前上下文，而不是清空。它会保留对话摘要和关键决策，把早期的完整细节丢掉，腾出空间。
长会话里，比如你从早到晚维护一个复杂重构任务，/compact 是比 /clear 更好的选择：模型还能记住"项目背景"、"已经改了哪些文件"、"下一步计划"，但记不住每一轮的完整输出。
代价是压缩后的记忆有失真风险。模型可能会漏掉某些约束，我实测中遇到最多的是压缩后它忘了"这个 bug 只在 Windows 上复现"这类环境相关的关键条件。所以压完聊两句就要验证一下，如果发现它开始胡说，立刻补一句约束或直接 /clear 重开，不要硬着头皮继续。
3.4 /rewind 与 /redo：上下文撤销
/rewind 可以把会话回滚到某个历史检查点，/redo 是反方向重做。这个机制对"模型跑偏"很管用：它改了一堆文件但方向完全错了，与其手动 git reset，不如先在会话里回滚，让它基于正确的上下文重新来。
但要注意，/rewind 回滚的是会话逻辑和上下文，不是文件系统。如果模型在这一轮里真的执行了 rm 或 git push，外部副作用是不会跟着撤销的。所以涉及破坏性操作前，优先用第 4 章讲到的权限机制去限制它，而不是寄希望于事后回滚。
4. 终端权限：Claude Code 执行 bash 命令背后的安全模型
4.1 bash 工具的工作机制
Claude Code 最强的地方在于它能直接在终端里执行命令，而不只是给你代码片段。本质上这是一个"终端权限"的授权问题：模型提出命令，客户端请求你批准，批准后命令在本地 shell 中执行。
权限确认弹出来后，有三个常见选项："允许一次""始终允许""拒绝"。选"始终允许"之后，该命令会被写进允许列表，下次同类操作就自动执行，不再问你。整个允许列表可以通过 /permissions 管理，也可以直接改配置文件。
我的建议是：权限管理要有倾向性。像 ls、git diff、cat 这类只读命令，直接放行，省得每步都弹窗；像 rm 这类破坏性命令，永远别放行；介于中间的，按项目风险谨慎放开。
4.2 从"执行者"变成"质检员"：多步骤任务的正确姿势
真正的高效用法是让 Claude Code 并行执行一条完整链路。举例来说，我经常这样下指令：
"修改 src/worker.ts 里的重试逻辑，加指数退避，写完之后跑 npm run test:worker，如果测试挂了，先读报错，再修，再跑，循环直到通过。"
它会自己规划：读文件、改代码、装依赖、跑测试、看报错、再改。这个过程如果每一步都弹权限，体验会很割裂，所以在开始前我会先把只读命令和测试命令放进允许列表。
别让它一步到位改完再跑。我建议明确要求"小步走"，比如"先改这一个函数，然后跑对应的单测，通过了再改下一个"。模型在长链路里如果一口气干三件事，中间任何一步出错，它都容易在错误的上下文里连环补救，那才是灾难。
4.3 安全红线与配置封堵
哪些命令不该放权？我的名单是：
rm -rf一类无恢复手段的删除操作；- 直接
git push --force覆盖远端历史； - 下载远程脚本直接执行，比如
curl ... | sh； - 任何涉及生产环境鉴权、数据库写操作、批量修改文件权限的命令。
如果不想靠记忆，可以在配置文件里显式禁用：
json复制{
"disallowedTools": [
"rm",
"git push --force",
"bash -c curl*sh*"
]
}
不同版本的配置结构略有差异，但核心是 allowedTools 和 disallowedTools 两个数组，一个白名单一个黑名单。我还习惯在项目根目录的 .claude/settings.json 里写项目级别的限制，比如"禁止访问 .env 文件"，这样不管谁在哪个会话里启动，红线都还在。
提示：如果你开的会话在共享目录或者服务器上，务必先确认配置的权限限制。权限体系是本地信任模型，它防不住"你自己点了始终允许"，也防不住"同事带着宽松配置进你的目录"。
5. 面向脚本与 CI 的调用参数：非交互模式的正确姿势
5.1 -p 参数：一行命令出结果
交互式会话适合"人和模型来回讨论"，但如果你只是想让模型处理一个明确任务，非交互模式更合适。核心参数是 -p（或 --print）：
bash复制claude -p "用一句话解释什么是回调函数"
-p 会把模型输出直接打印到 stdout，适合管道拼接、写脚本。不加 -p 直接传 prompt，Claude Code 通常会进入交互式界面，这不是自动化想看到的。
输出格式用 --output-format 控制：
bash复制claude -p "列出当前目录所有 js 文件" --output-format text
text 是纯文本；json 是结构化输出；stream-json 适合实时流式读取，CI 里做增量处理比较方便。
5.2 把 Claude Code 接进管道
脚本里最有价值的是把 Claude Code 当成一个"命令"来组合。比如：
bash复制cat error.log | claude -p "总结这个日志里的错误原因，按严重程度排序"
又或者：
bash复制git diff | claude -p "帮我 review 这段 diff，指出潜在 bug"
这类用法完全是非交互的，可以在 CI 和本地脚本里反复跑。唯一要留意的是输出稳定性：-p 模式下模型输出的格式仍然有随机性，如果你要解析输出，务必在 prompt 里指定输出格式，比如"只输出 JSON，不要 Markdown"。
输出重定向也值得用：
bash复制claude -p "生成代码注释" --append-output output.txt
--append-output 会把结果追加到指定文件而不覆盖，这在循环处理多个文件时很实用。
5.3 会话恢复：--resume 与持续工作流
自动化场景里，--resume 是个容易被忽略但很救命的参数。它可以恢复之前某次会话的上下文，命令格式：
bash复制claude --resume <session-id>
如果你不带 session-id，有些版本会进入一个交互选择器，列出最近的会话让你选。这个参数最典型的用法是：白天在交互式会话里跟模型聊了一路，晚上想继续，直接恢复那个会话，模型还记得白天的所有上下文。
拿不到 session-id 的时候，我记得目录下的会话记录都存在本地的历史文件里，可以先用 claude --resume 的交互列表确认，再把这个 id 沉淀进脚本。做 CI 集成时，如果任务被中断，用 --resume 续跑比新开会话省太多 token。
5.4 环境变量与输出日志
自动化里最怕的是"不知道模型在干什么"。交互式模式下你能看着它一步步执行，非交互模式下只能靠日志。
Claude Code 会往日志文件里输出执行记录，位置在用户目录下的 .claude 目录里。我把日志目录固定到一个方便的地方（比如在配置里配好日志路径），然后配合 tail -f 观察。在 systemd 服务里跑的时候，记得把 stdout 和 stderr 分别重定向，不然日志全堵在 Journal 里很难翻。
另一个容易踩的坑：环境变量污染。多个项目共用同一台机器，.env 里随手 export 了 ANTHROPIC_API_KEY，换个项目跑的时候它可能还残留着。脚本里用 env 精确传参，比依赖全局环境变量省心：
bash复制ANTHROPIC_API_KEY=sk-ant-xxx claude -p "任务内容"
6. 配置项与常见报错：把命令行的最后一块拼图补齐
6.1 配置文件的层级关系
Claude Code 的配置不是一个文件都搞定的，而是分了几层。用户级配置在 ~/.claude/ 目录下，项目级配置在项目根目录的 .claude/ 目录下，项目级会覆盖用户级。这些文件一般叫 settings.json。
CLAUDE.md 是另一回事，它是给模型看的"项目背景文档"，不是给客户端看的配置。分层理解之后，很多"我改了配置怎么没生效"的问题都会迎刃而解——先确认你改的文件层级是不是当前会话真正读取的那一层。
6.2 值得现在就改的几个配置项
常见的配置项包括：
model：默认模型。如果你有更适合特定任务的模型，直接在这里定死，省得每次/model；allowedTools/disallowedTools：第 4 章提到的权限白名单和黑名单，建议项目级显式维护；env：给会话注入环境变量，适合把 API Key 等敏感信息从命令行剥离。
我的一份项目级 settings.json 大概长这样：
json复制{
"model": "claude-sonnet-4-5",
"allowedTools": [
"ls",
"cat",
"git diff",
"git status",
"npm run test"
],
"disallowedTools": [
"rm",
"git push --force"
]
}
这些都是可以操作的，具体字段名以你装的版本为准，结构不会差太多。
6.3 三个高频报错的排查思路
第一个是登录态失效，表现是启动后直接让你重新登录。多半是 OAuth token 过期，或者你手动改了环境变量。直接重新 claude 走登录流程即可，不要反复折腾配置文件。
第二个是 "your organization has disabled claude subscription access for claude code" 这类组织限制提示。要么是企业管理员在后台关掉了这个功能，要么是订阅套餐本身不包含。终端命令里没有绕过的手段，只能联系管理员或者换用自己的 API Key 试试。
第三个是模型名填错，报 "model not found" 或 404。这个我在配本地模型时遇到过很多次，大概率是 ANTHROPIC_MODEL 或 /model 里填的标识符和实际模型 ID 对不上。逐个检查环境变量、配置文件、本地模型的可用模型列表，基本都能定位。
6.4 我的配置建议
最后给一套我目前在用的组合，算不上标准答案但能省不少事：
- 用户级配置只放基础项：默认模型、日志路径；
- 项目级配置放权限和项目专属指令；
- CLAUDE.md 里沉淀项目约束，让每个新会话都自动继承；
- 需要接本地模型时，单独开一个 shell 脚本，export 好
ANTHROPIC_BASE_URL和ANTHROPIC_MODEL再启动，免得玩完忘了还原，把后续会话全带偏。
这套组合我跑了几个月，最大的感受是稳定。命令行工具最怕的不是功能少，而是行为不可预期。把配置收敛好，Claude Code 在终端里就是一把真正的尖刀。
实际用下来还有个体会，很多人学终端命令总想背下来，我反而觉得 Claude Code 的命令体系不需要背，你只要记住每一层是干什么的：启动命令管环境，斜杠命令管会话，权限命令管边界，-p 参数管自动化，配置文件管长期行为。需要的时候用 /help 查一下，比硬记准确得多。遇到想不起来某个参数的写法，直接在当前会话里问它也行，这大概就是用 AI 工具学工具最舒服的地方。