很多人没用明白 Claude Code：我的 10 个技巧带你少走弯路我只整理一些自己日常高频使用、确实能改善体验的进阶

很多 AI Coding 选手装上 Claude Code 之后，以为自己已经会用了。

不就是打开终端，输入需求，然后等它写代码吗？

但实际用久了会发现，真正影响体验的不是“会不会提问”，而是这些细节：权限弹窗怎么少一点、说错话怎么回退、上下文快满了该怎么处理、多个方案能不能并行探索、能不能像一个小团队一样分工干活。

这些功能大多藏在命令、参数和配置里，不看文档很难自然发现。

很多 Claude Code 最佳实践写得看起来很完整（比如 shanraisshan 的 claude-code-best-practice），但对刚入门的人来说，门槛也确实偏高。

所以这篇不简单讲 Claude Code 是什么，也不写特别重的“大牛手册”。

我只整理一些自己日常高频使用、确实能改善体验的进阶技巧。适合已经入门，但还没完全用顺手的人。

如果你现在对 Claude Code 的使用还停留在“打开终端直接聊”，那花几分钟看下这篇文章，绝对能给你一些帮助。

权限弹窗太频繁？先切对 permission mode

Claude Code 执行任务的时候，经常会遇到权限确认。有时候只是创建文件、移动文件、执行一个常见命令，它也要问你一下。用得多了之后，这种弹窗会非常打断节奏。

很多人知道要配置 permission，但问题是配置了 permission 也不一定好使，这也是很多小白说不清楚的痛点。

很多人知道可以用 shift + tab 切换到 plan 模式。

plan 模式的作用是让 Claude Code 先和你讨论方案，不直接修改代码。

但其实 shift + tab 本身不只是切 plan，它更准确地说是在切换权限模式。截至当前版本，Claude Code 主要支持这些权限模式：

default（默认模式）：每次涉及权限时都需要你手动确认。
acceptEdits（允许编辑模式）：自动接受编辑，并在工作目录中自动批准一些常见文件系统 Bash 命令，比如 mkdir、touch、rm、rmdir、mv、cp、sed 等。
plan（计划模式）：只读，Claude Code 会提出建议，但不会修改代码。权限提醒方式和 default 类似。
dontAsk（不询问模式）：根据 permissions.allow 的设置，自动跳过部分权限确认，让 Claude Code 执行被允许的工具调用。
bypassPermissions（高权限模式）：无脑跳过大多数权限确认，适合在低风险、可回滚的临时项目里使用，不建议在重要项目里长期打开。
auto（自动模式）：由后台模型判断是否需要提醒，不需要提醒的操作会直接通过。当前只支持 Claude 官方部分“优质付费”用户，普通用户和 Pro 用户暂时还不能使用。

默认情况下，shift + tab 主要是在 default、acceptEdits、plan 之间切换。

如果你想进入 dontAsk 或 bypassPermissions，一般需要通过 CLI 参数启动：

claude --permission-mode=dontAsk
或者
claude --permission-mode=bypassPermissions

平时尽量配置好 permission，然后使用 dontAsk 模式。这样能减少大量重复确认，同时又不会完全放飞。

当然如果你胆子大不怕 AI 删库，项目也有 Git 管理，那就直接 bypassPermissions（出了问题自行负责≧ω≦）。

Pasted image 20260424163348.png

说错话别补一句，用 `/rewind` 回到原消息

我之前在节省 Token 的文章里说过：尽量在原消息上编辑，而不是连续补充纠错。

但后来发现，居然有挺多朋友不知道怎么在 Claude Code 里“回到原消息”。

常见错误做法有两个，第一个是在终端里继续补一句：刚刚我说错了，其实是 XXXX。

第二个是用 ↑ / ↓ 找到之前那条消息，改完后再发一次。

这两种方式看起来像是在修正，但问题是：中间那条错误消息以及回复依然留在上下文里。

Claude Code 仍然可能受到它的影响，你也在继续浪费上下文。

更好的方式是用 /rewind 或者 /undo 命令，它会调出历史窗口，你可以选择恢复到某个位置。里面常见的选项包括：

Restore conversation：恢复到对应会话位置；
Summarize from here：从这里开始总结当前对话。

Pasted image 20260424165143.png 当然，也有更简单的方法：连续按两次 esc。效果也是类似的。

所以以后说错需求，不要再补一句“刚才我说错了”。直接回到那条消息，改掉它。这才是真正意义上的“少污染上下文”。

会话别乱清，`/resume` 可以找回历史窗口

Claude Code 用久了之后，一定会遇到上下文管理问题。

很多人知道这两个命令：

/clear # 清空上下文
/compact # 压缩当前上下文

但这里有一个很容易被忽略的点：很多时候，不建议所有事情都塞在一个会话里做。

一个会话里聊太久之后，哪怕 compact 过，历史包袱也会越来越重。

我的习惯是：一个比较明确的任务，就开一个新窗口。比如：

一个窗口专门做 bug 修复；
一个窗口专门做方案讨论；
一个窗口专门写测试；
一个窗口专门改文档。

那问题来了：如果你新开了一个窗口，做完之后突然想回到之前那个没做完的任务，怎么办？这时候就该用 /resume 指令了，它可以打开历史对话窗口，让你选择恢复之前的会话。

Pasted image 20260427200826.png 如果你结合之前推荐过的 CC-Switch，还可以更直观地做会话管理。

点击会话管理之后，就能看到多个历史会话。复制对应命令到终端执行，就可以直接进入那个会话。

长图_2026-04-28.png 至于说怎么快速打开上一次的会话，claude --continue就可以直接恢复最近一次 resume。这两个命令也都有缩写：claude -c 和 claude -r。

这类命令看起来不花哨，但用顺手之后非常重要。它能让你从“一个窗口聊到底”，变成“按任务管理会话”。体验差别很明显。

临时查东西不用占用上下文的办法

在 Claude Code 里，正常对话都会进入主上下文，也会产生 Token 消耗。

但有些需求其实很轻，比如只是想看一下当前路径，或者想问一句旁支问题，不希望它影响当前主任务。

这种时候，没必要把所有东西都塞进主对话。这里介绍两个很实用的小操作。第一个是 !。

这个指令可以让你在 Claude Code 里直接执行 Bash 命令，比如 !ls、!pwd 这样的操作。

这样你就不用切出窗口，也不用让 Claude Code 专门回答你“当前目录有什么”。适合喜欢在终端里连续工作的朋友。 Pasted image 20260428165151.png 另一个指令是 /btw。

这个指令适合做旁支提问。比如你正在让 Claude Code 修一个 bug，突然想问：刚才为什么选择这个方案？又或者当前任务里它改了哪些关键文件？

这种问题如果直接发到主对话里，会打断当前推进节奏。用 /btw 就更合适。

它会开启一个单独的小区域来回答问题，不会把主线对话节奏搅乱。回答完之后，按 esc 就能退出。 Pasted image 20260428165920.png 这个功能特别适合在长任务里临时确认信息。

你不用打断它正在做的事，也不用强行把旁支问题混进主上下文。

不进交互界面，也能用 Claude Code

这个技巧不一定高频，但在脚本和临时查询里很方便。

大多数时候，我们是这样使用 Claude Code 的：进入某个项目目录，打开终端，输入 claude，然后进入交互界面，开始让它理解项目、修改代码。

但有时候你只是想轻量地问一个问题，或者把某个命令结果交给 Claude Code 处理。这时候不一定要进入完整交互界面，可以使用 claude -p。

比如你就是随便想问一个小问题，根本不用关心当前是不是在工作空间里，直接问就行。 Pasted image 20260428112409.png 它也可以和管道配合。

比如你想快速了解一个文档讲了什么，就可以把内容通过管道传给 Claude Code。 Pasted image 20260428113327.png 如果你经常写 Shell 脚本，这个参数能组合出不少轻量用法。

比如：解释一段日志；总结一个配置文件；分析某个命令输出；快速生成一段提交说明；把脚本输出转成更可读的格式等等。

它不是最常用的功能，但在一些临时场景里非常顺手。

branch 和 worktree 隔离出你的“平行世界线”

有时候写代码最麻烦的不是“不会写”，而是你有两个方案，但不知道哪个更合适。

比如一个方案改动小，但可能不够优雅；一个方案结构更好，但改动范围更大。

这时候你可以用 /branch，它会从当前对话状态复制出一个分叉，相当于开一条新的探索路线。就像是一条“平行世界线”。

你可以在原来的分支里讨论方案 A，在新的 branch 里讨论方案 B。长图_2026-04-28 1.png 不过这里一定要注意：/branch 分出来的是上下文，不是文件系统。

也就是说，它只是让对话进入了另一条路线，但你仍然在同一个项目目录里操作同一批文件。如果其中一个 branch 已经开始改代码，另一个 branch 也会看到这些文件变化。

所以我一般建议用 /branch 的场景是开发前的方案讨论，而不是已经进入大量写代码阶段之后再乱分。

还有个注意点：官方说，当设置了 CLAUDE_CODE_FORK_SUBAGENT 时，/fork 不再是 /branch 的别名，而是会生成一个 forked subagent。也就是说，它不再是普通的“对话分叉”，而是走 subagent 模式。

那有没有办法让分叉的目录文件相互不影响，去做不同的探索和代码生成呢？

确实也有办法。小机灵鬼可能已经想到了：直接复制一个目录出来不就得了。

是的，复制一份当然可以。但如果你是在 Git 项目里，我更推荐用 Git 分支或者 worktree。

当然，你可能觉得新建分支也麻烦，那就可以看看 Claude Code 自带支持的 worktree。它可以直接通过 claude --worktree 启动创建。

比如我这里创建了一个 worktree，名字叫 test-haha。那么在当前项目的 .claude/worktree 文件夹下，就会出现一个 test-haha 目录，里面拥有当前项目的所有文件。

这就是更接近真正意义上的“平行世界”。长图_2026-04-28 2.png 如果你需要让 Claude Code 试不同实现方式，或者经常进行一些多方案比对的实战，这个功能非常推荐。

上下文和分支信息，直接放进状态栏

Claude Code 用久了之后，你会经常关心几个问题：

当前上下文用了多少？
现在在哪个 Git 分支？
当前模型是什么？
当前目录是什么？
任务是否还在正常推进？

你可能知道输入 /context 查看上下文，然后退出去能看到当前目录。但每次都这么做也挺麻烦，这时候 Claude Code 自带的 /statusline 功能就派上用场了。

它可以配置状态栏，把一些关键信息直接显示在界面底部。比如上下文占用、分支信息、模型信息等等。长图_2026-04-29111.png 如果你觉得自带的状态栏不够好看，或者想要更多增强功能，也可以用插件。我这里推荐两个：

想要简洁方便的，可以试试 CCometixLine（见下图中第一行）：github.com/Haleclipse/…
想要更强自定义和更多增强功能的，推荐 claude-hud（下图中二三行）：github.com/jarrodwatts…

长图_2026-04-291112.png

状态栏这个东西，看起来只是锦上添花。但在长任务里，它能减少很多不必要的确认。

你不用一直问“现在上下文还剩多少”“当前分支对不对”，信息直接摆在眼前。

炫酷的 teammate，让团队给你打工

Claude Code 里的 subagent，很多人应该已经听过了。

但 teammate 知道的人可能还不多。

如果说 subagent 像是你临时叫来的一个专员，那么 teammate 更像是真的组了一个小团队。

我做了个视频演示。

[视频上传失败]

这个视频里展示的是一个比较简单的查询天气团队效果。

配合 tmux，可以实现自动创建 agent，并自动开启分割窗口。

简单理解的话，subagent 更像是同一个 Claude Code session 里的一个专项线程。你让它做一件事，它做完之后把结果交回主 agent。

而 teammate 是一个更独立的个体。它有自己的窗口，可以作为团队里的另一个角色参与任务。

更关键的差异是：subagent 之间通常不能直接互相交流，只能完成任务后向主 agent 汇报。teammate 组成的是一个团队，成员之间可以通过任务列表和消息进行协作。

当然，代价也很明显：teammate 会更贵。因为每个 teammate 都有自己的 context，成本可以理解成按人数往上加。

两者大致可以这样对比：

对比项	subagent	teammate
所属功能	Subagents	Agent Teams
运行方式	在同一个 Claude Code session 里被调用	启动独立 Claude Code 实例
是否有独立窗口 / tmux pane	通常没有	可以有，支持 tmux / iTerm2 split panes
你能不能直接和它交互	一般不能，只能等它把结果交回主 agent	可以，能直接进入 teammate pane 交互
通信方式	subagent → 主 agent 汇报	teammates 可通过任务列表和消息互相协作
适合场景	快速专项任务，比如 review、查 bug、写测试	多人协作式任务，比如前端/后端/测试/架构并行干活
成本/开销	相对低	更高，每个 teammate 有自己的 context

一个典型使用场景可以是这样：

创建一个 Agent Team，生成 5 个成员，重构项目的商城部分。

1. nm_fe 负责商城前端重构
2. nm_rd 负责商城 API 重构
3. nm_dba 负责商城 DB 迁移
4. nm_qa 负责重构部分全量回归测试
5. nm_doc 负责文档更新

请让他们并行工作，不允许破坏现有功能，所有测试必须完全通过。

这类任务如果只靠一个 agent 做，也不是不行。

但它会在一个上下文里来回切换角色，时间长了容易混乱。 teammate 的思路是：把不同角色拆开，让它们像团队一样并行推进。

开启方式是在 .claude 下的 settings.json 添加环境变量：

{  
	"env": {  
		"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1",  
	},  
	"teammateMode": "tmux"  // 开启 tmux 分屏模式
}

这个功能目前更适合尝鲜和复杂任务探索，不一定适合所有人日常使用。

但如果你经常让 Claude Code 处理大型重构、多模块协作、测试和文档同步，它会打开一个很不一样的工作方式。

不喜欢终端？可以试试可视化客户端

Claude Code 最典型的使用方式是在终端里用 CLI。有些人很喜欢这种 geek 感。但也有很多人（比如非开发）确实不适应终端。

我试过一些通过 ACP 协议接入的客户端，比如 VS Code 插件、CC GUI、codeg、Zed，整体都还不错。当然，Trae、Qoder、CodeBuddy 这些非 Claude Code 客户端就不在这里讨论了。

上面提到的很多功能，到了客户端里门槛会低很多。比如原消息编辑、标签页切换历史会话，在一些客户端里就是点一下的事，不需要记命令，可以说是上手就会。

这里我重点说一下 Anthropic 官方客户端 cowork。

Cowork 可以理解成 Anthropic 自家的高级客户端。它不仅可以完成代码开发，还有类似 OpenClaw / Hermes 的本地文件操作能力。更让人眼馋的是，它还带有类似 Computer Use 的能力，可以直接操作你的电脑，比如陪你跟你电脑里的 AI 进行国际象棋对战。

不仅有类似 Claude Code 版本的小龙虾、Hermes 这样的本地文件操作能力，也有着类似 Computer use 这样的直接操作你的电脑陪你一起打人机（比如下国际象棋）。

不过这些能力之前主要限制在 Claude Max 用户里，后来才逐步下放到 Pro 用户。

这节偏尝鲜，不是 Claude Code 的主流用法。如果你只想稳定提效，可以先跳过。

这里主要教你用第三方自定义 API 配置 cowork：

正常安装
首次打开不要登录，菜单点开 help → troubleshooting → enable developer mode
它会提示重启，重启后就开启了开发模式
找到 Developer → Configure third-party inference。
在 Gateway 中添加你的第三方 Base URL 和密钥。

某些 baseUrl 无法获取到模型列表的（比如国内的各类 Coding Plan），需要在下方 Identity & models 中配置模型名称。

比如这里我配置的是最近白嫖的小米模型。配置完成后，点击 Apply locally，再重启即可。 Pasted image 20260430143323.png Pasted image 20260430144244.png Pasted image 20260430155003.png 不过 cowork 毕竟还比较新。如果看功能完整性和稳定性，目前当然还是 CLI 更强。