🔥 Claude Code 全部实用技巧大合集 🔥（2026 年 10 月版）

同样是 Claude Code，不同的人用出来的结果完全不同。

有人说 5 小时限额一下就见了底，也有人觉得根本用不完。

--> 差别就在配置和习惯上。

⭐️ 今天就给你讲清楚 Claude Code 的 12 个实用技巧。⭐️

里面的命令和提示词全部做成可以直接粘贴复制的。

⚠️ 开始之前……先确认版本 ⚠️

这篇文章里提到的功能大多是最近几个月才上线的。版本太低的话，输了命令也没反应。

在终端里用 claude --version 查一下，版本低就敲一行 claude update 就行。

本文的命令基于 10 月 18 日的 v2.1.302 版本。

1. 给每个子代理设置不同的 Effort

Effort 是决定 Claude 在回答之前想多深的一个值。分为 low、medium、high、xhigh、max，不同模型能选的档位略有差别。

很多人不管什么情况都直接挂在 Max 或 XHigh 上。毕竟感觉越高越好嘛。

但事实并非如此。

做同一个应用做对比时，Max 花了 79 分钟，其他 effort 只用了 16 分钟。

结果几乎一样。只是多花了时间和 token 而已。

我自己用下来总结是这样：

--> （核心）🔥 如果你能把提示词写得足够细，low 和 max 的最终结果很多时候差不多。🔥

--> 头脑风暴反而 low 或 medium 效果更好。

不过遇到复杂的设计、难缠的 bug、重要的评审时，确实需要更高的 effort。

关键不是“一律用 low”。

从 10 月 7 日起……调用子代理时可以指定 effort 了！

10 月 7 日的更新（v2.1.292）之后，主 Claude Code 在调用子代理时可以连 effort 一起指定。

现在这样下指令就行：

把现在要做的事分成三步交给子代理去做。

1. 找文件位置和整理资料用 low effort

2. 评估修改方向的利弊用 medium effort

3. 在最终代码里找 bug 的评审用 high effort

每个子代理实际用了什么 effort 要标出来，

主会话只把结论和依据文件路径带回来。

嫌每次都说得麻烦，可以把代理写成文件固定下来。

--> 比如存到项目的 .claude/agents/ 文件夹下的 light-research.md。

---

name: light-research description: 只负责找相关文件和依据位置的轻量调研专用 model: haiku effort: low

调用时临时指定的方法（上面那段提示词）和用文件固定的方法，两种都行！

2. 上下文管理与避免浪费 token

🤪 Claude Code 突然变“笨”，大多是因为上下文。

上下文就是 Claude 一次能记住的工作台。对话、读过的文件、命令结果全都会堆在这里。

--> 最近 Claude Code 的 1M（100 万 token）上下文已经是“默认值”了。

问题是很多人会把这 1M 一直填满。

这不只是 Claude 的问题，Codex 等所有 LLM 都有这个共同的极限。

⭐️ 技巧：把 autocompact 设到 500~700k⭐️

所以我一般会把自动压缩的阈值提前。

/autocompact 600k

就是把自动压缩所参照的窗口大小缩小到 60 万 token。

在填满 1M 之前，Claude 就会自动总结对话、腾出空间。

（想恢复默认值就敲 /autocompact auto。）

⚠️ 第二个要注意的地方：缓存过期⚠️

经常在同一个会话里长时间使用的人一定要看这条。

Claude Code 每次发请求都会把前面的对话整段重新发一遍。之所以又快又便宜，是因为有缓存。已经处理过的前面部分不会重新计算。

但这个缓存不是永久的。

• Pro 或 Max 订阅（在套餐包含的用量范围内）：主对话缓存 1 小时

• API key 或额外用量积分：5 分钟

• 子代理：即使是订阅也是 5 分钟

我屏幕上曾经出现过 ~852k uncached 的提示。这时候哪怕只发一句“继续”，也要把约 85 万 token 在无缓存的情况下从头处理一遍。用量可能会一下子掉一大截。

缓存失效的典型情况有这些：

1. 休息很久之后重新接上一个巨大的会话时

2. 长会话中途切换模型时（每个模型缓存是分开的）

3. 连接的 MCP 工具配置发生变化时

应对方法很简单：

• 离开座位前先整理一下。趁缓存还活着，用 /compact，或者干脆用 /clear 开一个新聊天。

• 更新到最新版本。从 v2.1.299 起，超过 20 万 token 的对话放置 54 分钟左右，Claude Code 就会在 1 小时缓存到期前自动帮你压缩。想关掉的话可以在 /config 的 Idle compaction 里关。

3. 用 /doctor prompt-audit 大扫除旧指令

以前听人推荐就复制粘贴进来的 CLAUDE.md。每次犯错就一条条加进去的规则。

这些大多是以旧模型为基准写下的。

新模型比旧模型更擅长遵守指令。

⚠️ 所以以前那种“必须！！”“绝对！！”要强调才听的规则，现在反而可能过度生效。⚠️

跟现在代码对不上的规则、彼此冲突的规则也堆了一堆。

现在一句命令就能检查了。

这是 9 月底更新（v2.1.283）加入的功能。

会检查哪些东西呢！

1. 项目和上层文件夹里的 CLAUDE.md、CLAUDE.local.md、AGENTS.md

2. ~/.claude/CLAUDE.md（适用于所有项目的个人指令）

3. .claude/ 里的规则（rules）、技能、自定义命令、子代理定义、输出样式

已安装插件里的技能和代理只做查看，不会建议修改。

判断基准是现在正在用的模型。以该模型为基准，找出过时的提示词模式，生成报告和修改建议。

（settings 文件或 .mcp.json 这类可能含密钥的文件不会被读取。）

4. 当 Claude Code 重复犯同一个错……修改工作环境本身

⛏️ 当 AI 又在瞎折腾、一个问题折腾了好几个小时的时候。⛏️

同一个问题已经说第三遍的话，那问题就不在模型，而在工作环境。

我从 Claude Sonnet 3.7 时代起用了一年多的一套方法。

大致说说思路……

--> 让 AI 重新分析它自己犯错的会话，把原因反映到项目指令和验证方法里。

⭐️ 具体这样做！直接“用会话 ID 分析失误”⭐️

1. 在反复出错的会话里敲 /status，会显示会话 ID。复制它。

2. 新开一个 Claude Code 会话（Codex 也可以），这样粘贴进去。

3. 看它给出的建议，只采纳靠谱的部分。

4. 确认效果。把以前出过错的需求再交一次，看这次还错不错。

⚠️ 不要什么都往 CLAUDE.md 里堆。⚠️

越长越吃上下文，规则之间还会互相打架！！！

• 项目全局规则放 CLAUDE.md

• 只跟某个文件夹或文件相关的规则放 .claude/rules/ 或那个文件夹里的 CLAUDE.md

• 重复性的操作流程做成技能（Skill）

• 绝对不能违反的规则用 Hooks 和权限设置来保证（第 10 条）

• 同一个 bug 反复出现就用回归测试兜住

这样累积起来的规则，偶尔用第 3 条的 /doctor prompt-audit 大扫除一下。第 4 条负责积累，第 3 条负责清理。

5. 用 Claude-Mem 在会话之间保留工作记忆

Claude Code 会话一结束，对话就忘了。

“上次那事为什么那么做的来着？” “那个报错当时是怎么修好的？”

每个新会话都得重新解释一遍。**

我用了一整年、唯一持续在用的 Claude Code 插件，正好能解决这个问题。

--> 就是 claude-mem。

⭐️ GitHub 星标已经突破 10 万了。⭐️

跟默认记忆有什么区别？

Claude Code 也有默认记忆（Auto Memory）。区别在这儿：

默认的 Auto Memory 会把 Claude 判断为重要的内容、项目中得到的经验总结成备忘。用 /memory 可以查看，不需要额外安装。

claude-mem 则会自动记录上个会话做了哪些工作、哪个报错怎么解决的、为什么做那个决策，下次会话时把需要的记录找出来用。

我屏幕上显示的 token 节省率一度达到 87%。

安装方法在终端里一行就能搞定。

在 Claude Code 里以插件形式安装也行。

❌ 下面这些人不推荐 ❌

1. 主要用 Codex 的人

2. 已经有其他记忆插件或自己搭好的记忆与交接体系的人

叠一个重复的工具上去只会让事情更复杂、成本更高。

如果你只用 Claude Code 一个环境，那还是强烈推荐。

6. 用 Statusline 一眼查看模型、Effort、上下文和用量

用 Claude Code 的时候，总是很好奇：

• 现在这个会话是 Opus？Sonnet？还是 Haiku？

• effort 设成多少了？

• 上下文用了多少？

• 5 小时限额和每周限额还剩多少？

🔥 把这些常驻在终端最下面一行的，就是 statusline。🔥

做法很简单。在 /statusline 后面用自然语言描述你想要的样子，Claude 会帮你写出脚本并直接应用。

我之前分享过的 5 款设计

以前分享过 5 款可直接复制粘贴的 statusline 提示词。

1. 极简款：模型、effort、项目、上下文一行搞定

2. 粉彩块：适合深色终端的粉彩高亮块

3. Nord Powerline：分段之间用箭头边界平滑衔接的条带

4. 限额点条：Pro 或 Max 适用。用点条显示 5 小时和 7 天用量、距离重置的剩余时间

5. 醒目仪表：青柠色模型徽章加斜线仪表。连上下文 token 数都有

提示词全文在原帖里。照抄粘贴，Claude 就会直接生成并应用。

7. 让 Claude Code 自己运行并验证结果

Claude 说“实现完成了！”，一跑起来就不行。按钮点不动、画面崩了、甚至根本打不开。

测试过了但应用其实不能用的情况，比想象中多得多。

所以要让 Claude 自己把应用启动起来、点一点试试。为此有专门的命令。

• /run：真正把项目里的应用跑起来并直接操作，确认改动是否生效。

• /verify：把改动的功能真正跑起来构建并执行，确认它是否可用。不拿测试或类型检查来代替。

• /run-skill-generator：把运行这个项目的方法（命令、环境变量、准备步骤）存成技能。运行流程复杂的项目，先做这一步。

• /verify 会把已经确认过的方法存到项目技能（.claude/skills/verify/）里，下次直接复用。

这样用：

1. 实现功能并先确认测试和构建

2. 用 /run 启动应用

3. 如果是网页，真的点一下、输一下。如果是 CLI 工具，用样例输入看实际输出

4. 用 /verify 重新确认原定目标是否达成

5. 不行就修，再跑一遍。把真实的命令输出或画面作为依据留下

8. 把写代码的 AI 和审查的 AI 分开

自己写的东西自己看不出错别字。AI 也一样。

写下代码的那个会话，脑子里已经全是“这肯定对”。

⭐️ 所以要用新上下文的审查员来把关。⭐️

• /code-review：从当前改动的代码、PR、分支、路径中找出 bug 和正确性问题。

• /code-review high 可以指定强度（从 low 到 max）。 （默认只出报告，想让它连修一起做，加 --fix 就会直接修。）

• /security-review：检查你的分支与远程默认分支之间的差异中的安全问题（认证、输入校验、信息泄露等）。

• /simplify：整理并修复重复、低效、过于复杂的结构。它不是找 bug 的工具。找 bug 是 /code-review 的事。

推荐顺序

1. 先用 /simplify 整理代码

2. 用 /verify 确认真的能跑（第 7 条）

3. 用 /code-review 找 bug

4. 如果涉及登录、支付、API key、个人信息，再加 /security-review

不是每次都非得跑四个。

⚠️ 小改动的话，只跑一个 /code-review 就足够。⚠️

想看得更深还有 /code-review ultra（等同 /ultrareview）。

（这是云端深度评审的方式，Pro 和 Max 可以免费试 3 次。）

9. 复杂任务在写代码前先确定设计与完成条件

把复杂的事交出去时，最先给 Claude 的不该是一大段编码指令，而是做到哪儿算完、什么时候算完。

不把这些定清楚，Claude 就会自己扩大范围。

⚠️ 会去改不该动的文件，甚至做你没让它做的事。⚠️

Plan Mode 的用法

在输入框里按 Shift+Tab 让 plan mode on 显示出来，或者直接敲 /plan。也可以像 /plan 修登录 bug 这样直接带上任务。

（在 Plan Mode 里，Claude 只会读文件、做计划。代码要等你批准之后才改。）

流程是：探索 → 计划 → 批准 → 实现 → 验证。

但改个错别字、改一行代码，做计划反而是浪费。官方文档的标准很清晰：能用一句话说清要改什么，就跳过计划。

10. 用 Hooks 自动强制关键规则

就算在 CLAUDE.md 里写了“绝对不要碰这个文件”，Claude 偶尔还是会碰。

🔥 CLAUDE.md 只是参考指令，Hooks 才是强制规则。🔥

最常用的 3 种

• PreToolUse：Claude 要改文件或执行命令之前的那一刻。用来阻止修改受保护文件，或拦截危险命令。

• PostToolUse：执行之后的那一刻。自动格式化改过的文件，或跑 lint。

• Stop：Claude 要结束回答的时候。测试没跑完就不许它结束。

示例：阻止修改生产配置文件

这样的 Hook 也可以直接让 Claude Code 帮你写。

--> “帮我做一个阻止修改 config/production.env 的 PreToolUse 钩子。”

这些场景适合用

• 每次改代码文件就自动跑项目格式化工具（PostToolUse）

• 动重要文件夹之前再要一次批准（PreToolUse）

• 没跑测试就不让结束工作（Stop）

• 拦截危险命令（PreToolUse + Bash）

11. 用 Git Worktree 同时跑多个 Claude Code 会话

开两个 Claude Code 窗口，在同一个文件夹里同时让它干活会怎样？

🚫 互相改同一个文件，一团乱。（这个真的超级超级头疼……）🚫

Worktree 是 git 的一个功能，把同一个仓库按任务拆到不同文件夹、不同分支。

Claude Code 一句命令就能搞定。

在两个终端里分别这样跑：

• claude --worktree feature-auth

• claude --worktree feature-dashboard

短的 -w 也可以。

这样就会生成 .claude/worktrees/feature-auth/ 文件夹，并在 worktree-feature-auth 这个新分支上工作。

--> ⭐️ 两个会话不会碰到对方的文件。⭐️

还有几个值得知道的点。

新的 worktree 不是从你当前所在的分支开始，而是从远程默认分支（main）开始。

用 claude --worktree "#1234" 这样给个 PR 号，就会从那个 PR 开始。

结束会话时会帮你清理 worktree。如果有还没处理的工作，删之前会问你是要留着还是删掉。

注意的地方

1. Worktree 只分开文件和分支。同一个本地数据库、端口、部署目标、外部 API 账号是共享的。两个会话用同一个端口起服务就会冲突。

2. 后面合并时，如果改过同一个文件就会冲突。

3. 彼此强关联的任务，先定好接口，或者按顺序来。

4. 每个会话的用量是分开算的。并行不等于省 token。

12. 用 /goal 反复自动验证直到达成目标

Claude 一个回合结束就会停下。哪怕测试还有 3 个没过，也会说一句“大部分修好了”就停。

• goal 是设好完成条件后，让 Claude 不达条件不罢休、一直干下去。（从 v2.1.139 开始有的功能。）

• 只敲 /goal 会显示当前目标和进度。

• 敲 /goal clear 会解除目标并停下。

怎么运作的……

每个回合结束时，会有一个独立的、小而快的模型读取条件和到目前为止的对话，判断条件是否满足。如果还没满足，Claude 就会继续下一个回合。

目标里一定要包含“把测试命令和结果输出到对话里”这类确认方法。这样判定模型才能知道是不是真的过了。

跟 /loop 或 Stop 钩子有什么不同？

--> goal 是一个回合结束就马上开始下一个回合，判定模型判断目标达成时停下。

/loop 是按固定间隔重复同一件事。比如 /loop 5m 检查部署状态。

Stop 钩子是回合快要结束时，用你自己写的脚本检查条件。

分开用也不错，组合起来更好。

1. 用 /plan 确定范围和完成条件（第 9 条）

2. 用 claude -w 给每个任务分 worktree（第 11 条）

3. 用 Hooks 每次改动就格式化、拦住受保护文件（第 10 条）

4. 用 /goal 反复执行，直到满足第 9 条定下的完成条件（第 12 条）

5. 用 /run 和 /verify 真正跑起来确认（第 7 条）

6. 用 /code-review 在新上下文里审查（第 8 条）

总结

1. effort 按任务区分。拆分给子代理。

2. 上下文别填满，注意缓存过期。

3. 旧的 CLAUDE.md 用 /doctor prompt-audit 大扫除。

4. 同一个错别怪模型，修环境。

5. 跨会话记忆用 claude-mem。

6. 模型、effort、上下文、限额用 statusline 常驻显示。

7. 别信“完成了”，用 /run 和 /verify 验证。

8. 写代码的 AI 和审查的 AI 分开。

9. 复杂任务先定计划和完成条件。

10. 必须遵守的规则用 Hooks。

11. 并行任务用 worktree。

12. 不到成功不罢休用 /goal。

Claude Code 的更新真的很快。有新功能上线我会再整理发出来。

觉得有用的话收藏一下，顺手分享给用 Claude Code 的朋友。