许多 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（出了问题自行负责≧ω≦）。
说错话别补一句，用 /rewind 回到原消息
我之前在节省 Token 的文章里说过：尽量在原消息上编辑，而不是连续补充纠错。
但后来发现，居然有挺多朋友不知道怎么在 Claude Code 里“回到原消息”。
常见错误做法有两个，第一个是在终端里继续补一句：刚刚我说错了，实则是 XXXX。
第二个是用 ↑ / ↓ 找到之前那条消息，改完后再发一次。
这两种方式看起来像是在修正，但问题是：中间那条错误消息以及回复依然留在上下文里。
Claude Code 依旧可能受到它的影响，你也在继续浪费上下文。
更好的方式是用 /rewind 或者 /undo 命令，它会调出历史窗口，你可以选择恢复到某个位置。里面常见的选项包括：
- Restore conversation：恢复到对应会话位置；
- Summarize from here：从这里开始总结当前对话。
当然，也有更简单的方法：连续按两次 esc。效果也是类似的。
所以后来说错需求，不要再补一句“刚才我说错了”。直接回到那条消息，改掉它。
这才是真正意义上的“少污染上下文”。
会话别乱清，/resume 可以找回历史窗口
Claude Code 用久了之后，必定会遇到上下文管理问题。
许多人知道这两个命令：
/clear # 清空上下文
/compact # 压缩当前上下文但这里有一个很容易被忽略的点：许多时候，不提议所有事情都塞在一个会话里做。
一个会话里聊太久之后，哪怕 compact 过，历史包袱也会越来越重。
我的习惯是：一个比较明确的任务，就开一个新窗口。列如：
- 一个窗口专门做 bug 修复；
- 一个窗口专门做方案讨论；
- 一个窗口专门写测试；
- 一个窗口专门改文档。
那问题来了：如果你新开了一个窗口，做完之后突然想回到之前那个没做完的任务，怎么办？
这时候就该用 /resume 指令了，它可以打开历史对话窗口，让你选择恢复之前的会话。
如果你结合之前推荐过的 CC-Switch，还可以更直观地做会话管理。
点击会话管理之后，就能看到多个历史会话。复制对应命令到终端执行，就可以直接进入那个会话。
至于说怎么快速打开上一次的会话，claude –continue就可以直接恢复最近一次 resume。
这两个命令也都有缩写：claude -c 和 claude -r。
这类命令看起来不花哨，但用顺手之后超级重大。
它能让你从“一个窗口聊到底”，变成“按任务管理会话”。体验差别很明显。
临时查东西不用占用上下文的办法
在 Claude Code 里，正常对话都会进入主上下文，也会产生 Token 消耗。
但有些需求实则很轻，列如只是想看一下当前路径，或者想问一句旁支问题，不希望它影响当前主任务。
这种时候，没必要把所有东西都塞进主对话。这里介绍两个很实用的小操作。
第一个是 !。
这个指令可以让你在 Claude Code 里直接执行 Bash 命令，列如 !ls、!pwd 这样的操作。
这样你就不用切出窗口，也不用让 Claude Code 专门回答你“当前目录有什么”。
适合喜爱在终端里连续工作的朋友。
另一个指令是 /btw。
这个指令适合做旁支提问。列如你正在让 Claude Code 修一个 bug，突然想问：刚才为什么选择这个方案？又或者当前任务里它改了哪些关键文件？
这种问题如果直接发到主对话里，会打断当前推进节奏。
用 /btw 就更合适。
它会开启一个单独的小区域来回答问题，不会把主线对话节奏搅乱。回答完之后，按 esc 就能退出。
这个功能特别适合在长任务里临时确认信息。
你不用打断它正在做的事，也不用强行把旁支问题混进主上下文。
不进交互界面，也能用 Claude Code
这个技巧不必定高频，但在脚本和临时查询里很方便。
大多数时候，我们是这样使用 Claude Code 的：进入某个项目目录，打开终端，输入 claude，然后进入交互界面，开始让它理解项目、修改代码。
但有时候你只是想轻量地问一个问题，或者把某个命令结果交给 Claude Code 处理。
这时候不必定要进入完整交互界面，可以使用 claude -p。
列如你就是随意想问一个小问题，根本不用关心当前是不是在工作空间里，直接问就行。
它也可以和管道配合。
列如你想快速了解一个文档讲了什么，就可以把内容通过管道传给 Claude Code。
如果你常常写 Shell 脚本，这个参数能组合出不少轻量用法。
列如：解释一段日志；总结一个配置文件；分析某个命令输出；快速生成一段提交说明；把脚本输出转成更可读的格式等等。
它不是最常用的功能，但在一些临时场景里超级顺手。
branch 和 worktree 隔离出你的“平行世界线”
有时候写代码最麻烦的不是“不会写”，而是你有两个方案，但不知道哪个更合适。
列如一个方案改动小，但可能不够优雅；一个方案结构更好，但改动范围更大。
这时候你可以用 /branch，它会从当前对话状态复制出一个分叉，相当于开一条新的探索路线。
就像是一条“平行世界线”。
你可以在原来的分支里讨论方案 A，在新的 branch 里讨论方案 B。
不过这里必定要注意：/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 目录，里面拥有当前项目的所有文件。
这就是更接近真正意义上的“平行世界”。
如果你需要让 Claude Code 试不同实现方式，或者常常进行一些多方案比对的实战，这个功能超级推荐。
上下文和分支信息，直接放进状态栏
Claude Code 用久了之后，你会常常关心几个问题：
- 当前上下文用了多少？
- 目前在哪个 Git 分支？
- 当前模型是什么？
- 当前目录是什么？
- 任务是否还在正常推进？
你可能知道输入 /context 查看上下文，然后退出去能看到当前目录。
但每次都这么做也挺麻烦，这时候 Claude Code 自带的 /statusline 功能就派上用场了。
它可以配置状态栏，把一些关键信息直接显示在界面底部。
列如上下文占用、分支信息、模型信息等等。
如果你觉得自带的状态栏不够好看，或者想要更多增强功能，也可以用插件。
我这里推荐两个：
- 想要简洁方便的，可以试试 CCometixLine（见下图中第一行）：https://github.com/Haleclipse/CCometixLine
- 想要更强自定义和更多增强功能的，推荐 claude-hud（下图中二三行）：https://github.com/jarrodwatts/claude-hud
状态栏这个东西，看起来只是锦上添花。
但在长任务里，它能减少许多不必要的确认。
你不用一直问“目前上下文还剩多少”“当前分支对不对”，信息直接摆在眼前。
炫酷的 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，再重启即可。
不过 cowork 毕竟还比较新。
如果看功能完整性和稳定性，目前当然还是 CLI 更强。
命令太多记不住？我做了个中文速查页
Claude Code 的命令、参数、环境变量变化超级快。
今天你刚记住一个用法，过段时间可能又新增了一批东西。
所以我做了一个网页，用来查看最新的 Claude Code 相关指令，并同步上游做了中文翻译。
地址是：
https://cc-quick.acecandy.cn
里面如果有新增指令，后面会带一个 new 标签。
历史上已经删除的指令，也不会继续展示在里面。
左上角的 最近变更，点击后可以查看最新版本更新了什么内容。
也可以直接跳到官网查看具体更新。
左侧支持切换多个栏目：
- 键盘快捷键
- MCP 服务器
- 斜杠命令
- 记忆与文件
- 工作流与技巧
- 配置与环境变量
- Skills 与 Agents
- CLI 与参数
如果你常常用 Claude Code，可以直接收藏这个页面。
不管是刚开始学习，还是某个命令突然想不起来，都可以打开查一下。
项目如果对你有协助，也欢迎点个 star。
写在最后
Claude Code 这类工具，表面上看是“会聊天就能用”。
但实则离“真正会用”还有很长的路要走。真正拉开体验差距的，往往不是一句神奇 Prompt，而是这些不太起眼的命令、参数和工作流。
我觉得在未来相当长一段时间里，Claude Code 依旧会是最好的智能编码工具之一。
就列如 OpenClaw 之前如日中天，后来还不是被 Hermes 抢走了不少热度。
但 Claude Code 不一样。至少从发布以来，它一直如老狗般稳坐大哥地位。熟练掌握它，多少有点掌握半个 AI Coding 未来的意思（笑）。
以上都是我自己在 Claude Code 使用上的一些小技巧。它们单独看都不大，但如果能熟练运用，效率差距会超级明显。
所以这篇不算大牛手册，更像是一份从“初步能用”到“稍微有点顺手”的补充笔记。
如果你也在用 Claude Code，可以先把这些命令码住，后面必定用得上。
我是单向箔，我们下次再见。
© 版权声明
文章版权归作者所有，未经允许请勿转载。
相关文章
暂无评论...
