给高级工程师的 9 个 Claude Code 提速技巧

下面这 9 个技巧，会直接改变你使用 Claude Code 方式。

1）不可妥协的规则，放 Hooks，不要只放 CLAUDE.md

CLAUDE.md 更像是一份建议。

Claude 会读取它，然后根据自己的判断决定什么时候遵守。

问题也出在这里。

只要是“判断”，就意味着 Claude 可能在某些情况下跳过规则，因为它觉得当前场景需要另一种处理方式。

Hooks 则不一样。

Hooks 是确定性的，只要匹配到对应的 tool call，就会无条件触发。

所以，任何不能交给 Claude 自行裁量的规则，都应该放进 hooks。

// .claude/settings.json
{
"hooks": {
"PreToolUse": [{
"matcher": "Write|Edit",
"hooks": [{ 
"type": "command", 
"command": "./scripts/block-sensitive-writes.sh"
      }]
    }]
  }
}

这个脚本会从 stdin 读取 tool input 的 JSON，然后通过退出码 2 来阻止操作。

比如：

阻止写入 .env 文件

每次文件编辑后自动运行 lint

强制执行 commit message 格式

这些都应该放进 hooks。

而命名规范、API 设计模式、需要结合上下文判断的约定，则更适合放在 CLAUDE.md 里。

简单说：

必须执行的规则，交给 hooks。

需要判断的规则，写进 CLAUDE.md。

2）CLAUDE.md 要短，否则它会反过来拖慢你

CLAUDE.md 里的每一个 token，都会和你真正的任务上下文争夺空间。

很多人以为，把 CLAUDE.md 写得越长，Claude 就越懂项目。

实际上，过载的 CLAUDE.md 往往会让 Claude 变得更低效。

我的规则很简单：

如果某条指令在过去一周没有明显改变 Claude 的行为，它就不应该继续留在 CLAUDE.md 里。

更深的背景、边界情况、参考材料，可以放到 memory/ 目录下的 companion files 里，让 Claude 在需要的时候再读取。

根目录的 CLAUDE.md，只保留一屏内容。

.claude/
  memory/
    api-conventions.md
    error-handling.md
    deployment-rules.md

CLAUDE.md  ← 只保留一屏

还有一个 /caveman-compress 命令也很有用。

它可以把 CLAUDE.md 压缩成更短、更直接的表达，大约能减少每次会话 46% 的输入 token，同时保留所有关键技术指令。

这类压缩不是为了好看。

它是为了让 Claude 把更多上下文空间留给当前任务。

3）Subagents 的核心价值不是并行，而是隔离上下文

很多工程师第一次发现 subagents 时，第一反应是：

“太好了，可以并行跑任务。”

这当然有用。

但 subagents 更重要的价值，是 context isolation。

当你在主会话里探索一个陌生模块、调试一个失败测试，或者追踪某个依赖问题时，所有走过的弯路都会进入上下文窗口。

错误猜测会留下。

失败方案会留下。

中途推翻的判断也会留下。

然后 Claude 会开始被这些内容锚定。

它后面的判断质量会变差。

.claude/agents/ 里的 subagents 会运行在独立上下文窗口中，并拥有自己的工具权限和指令。

这意味着它们探索过程中产生的污染，不会进入你的主会话。

.claude/
  agents/
    code-reviewer.md
    explorer.md
    test-validator.md

示例：

# .claude/agents/explorer.md
---
name: explorer
description: Explores unfamiliar modules and summarizes findings. 
             Use before starting any implementation on unknown code.
tools: Read, Glob, Grep
model: sonnet
---

You are a codebase explorer. Investigate the requested module 
thoroughly and return a clean summary of structure, dependencies 
and key patterns. Do not write any code.

更好的工作流是：

先让 explorer subagent 去调查模块。

它返回一份干净总结。

然后你在主会话里基于这份总结开始实现。

这样，主会话获得的是准确结论，而不是一堆探索噪音。

4）规格设计和代码实现，最好分成两个会话

把 specification 和 implementation 放在同一个会话里，是很多代码需要反复返工的根源。

因为当你完成问题探索时，上下文里已经塞满了半成型想法、被废弃的方案，以及探索阶段的推理痕迹。

Claude 会把这些内容继续带入后面的代码生成。

更干净的方法，是把它们拆成两个完全独立的 session。

Session 1：Specification

让 Claude 生成一份单独文档，覆盖：

架构决策

接口约定

数据结构

边界情况

失败场景

兼容性要求

Session 2：Implementation

开启一个全新的会话，只把 spec 文档作为输入。

此时 Claude 没有前面探索阶段的噪音。

它只根据已经确认的 contract 写代码。

# End of Session 1
# Save the output
claude > spec.md

# Start Session 2 clean
claude --context spec.md

第二个会话写出来的代码通常更干净。

原因很简单：

输入上下文本身就是干净的。

5）/compact 可以带总结指令，不要直接裸用

很多工程师输入 /compact 后，就接受 Claude 自动生成的摘要。

这其实很浪费。

因为当你不加任何说明时，Claude 会按自己的标准压缩会话。

它决定删掉的东西，不一定是你真正想删的。

/compact 可以接收明确指令，告诉 Claude 哪些内容必须保留，哪些内容可以压缩。

例如：

/compact preserve all API changes and their rationale, 
keep every error message and its solution, 
maintain the full list of modified files, 
summarize failed approaches in one line each

这在长时间无人值守的 session 里尤其重要。

因为 auto-compression 可能在你没有介入时自动触发。

更稳的做法，是把 compact policy 直接写进 CLAUDE.md。

## Compact Instructions

When summarizing this conversation:
- Preserve all API changes and their rationale
- Keep error messages and their solutions
- Maintain the list of modified files
- Summarize failed exploration attempts briefly

这样，每次自动压缩都会遵循你手动压缩时同样的规则。

最终留下来的上下文，不是“更短”而已。

而是保留了真正重要的信息。

6）Skills 是按需加载的，用它们固化团队约定

Skills 本质上是包含 SKILL.md 的目录。

这个文件里有 YAML frontmatter 和 markdown instructions。

它们不会每次都完整加载，而是 Claude 检测到任务匹配时才会加载。

启动时，Claude 会扫描所有可用 skills，只读取每个 skill 的 name 和 description。

每个 skill 大约消耗 100 tokens。

当你给 Claude 一个任务时，它会判断是否匹配某个 skill。

只有匹配时，才加载完整说明。

这让 skills 非常适合存放团队偏好。

也就是那些 Claude 本来就会做，但你希望它按照你们团队方式来做的事情。

.claude/
  skills/
    api-conventions/
      SKILL.md
    error-handling/
      SKILL.md
    commit-format/
      SKILL.md

示例：

# .claude/skills/api-conventions/SKILL.md
---
name: api-conventions
description: API design and endpoint conventions. 
             Applies in API, endpoint, REST and schema design contexts.
---

When writing API endpoints:
- Use RESTful naming with plural nouns: /users not /user
- Return consistent error shapes across all endpoints
- Version all routes under /api/v1/

Skills 大致可以分成两类：

Capability Uplift skills：给 Claude 增加它本来不具备的能力，比如浏览器自动化、PDF 生成等。

Encoded Preference skills：记录团队自己的偏好，比如 API 规范、错误处理方式、commit 格式等。

这里最关键的是 YAML frontmatter 里的 description。

它不只是描述。

它更像是路由规则。

你要写清楚这个 skill 应该在什么上下文里触发。

description 写得越精确，Claude 调用 skill 就越准确。

7）大规模迁移，用 Fan-out Pattern，不要开一个超长会话硬跑

在一个单独的长 Claude Code session 里做大规模迁移，是最慢也最不稳定的方法。

随着 session 变长，context 会不断膨胀。

Claude 会慢慢丢失早期文件细节。

转换质量也会逐渐漂移。

Fan-out pattern 的思路是：先调试模式，再并行执行。

第一步，选两三个有代表性的文件。

这些文件要覆盖代码库里的主要边界情况。

先在这几个文件上把转换方式调对。

# Tune on a small representative sample first
claude "refactor src/auth/login.py and src/auth/token.py 
to use the new error handling pattern, show me the diff"

当输出符合你的预期后，再把经过验证的模式扩展到整个代码库。

可以用 parallel subagents，让每个 agent 负责不同模块或目录。

# .claude/agents/migrator.md
---
name: migrator
description: Applies approved refactor patterns to a target directory.
             Use during large-scale codebase migrations.
tools: Read, Write, Edit, Bash
model: sonnet
---

Apply the refactor pattern from the provided spec file 
to every Python file in the target directory. 
Do not change logic, only apply the structural pattern.

然后 fan out：

# Fan out to multiple agents in parallel
claude "use the migrator agent on src/payments/"
claude "use the migrator agent on src/notifications/"
claude "use the migrator agent on src/users/"

重点是：

先在少量文件上验证规则。

再让多个 agent 按同一规则并行执行。

这样每个并行 agent 拿到的都是已经确认过的 pattern，而不是一边迁移一边猜。

8）并行 Claude 会话，用 git worktree 隔离文件系统

如果两个 Claude Code session 同时操作同一个 working directory，冲突几乎迟早会发生。

两个会话编辑的是同一份磁盘文件。

当两个 agents 在接近的时间写入同一个文件时，结果会变得不可预测。

git worktree 可以解决这个问题。

它能为同一个 repository 创建不同的物理目录路径。

每个 session 都在自己的目录里工作，彼此不会直接踩文件。

# Create a separate worktree for a review session
git worktree add ../project-review HEAD

# Main session works in the original directory
cd ~/project
claude "implement the rate limiting feature"

# Review session works in the worktree
cd ~/project-review
claude "review the rate limiting implementation 
and identify any security concerns"

最实用的模式是 writer + reviewer。

一个 session 负责实现。

它拥有完整的过程上下文，知道为什么这样改。

另一个 session 在单独 worktree 中做 review。

它没有前面实现时的思维惯性，所以反馈更客观。

这比让同一个 session 批评自己刚写的代码更可靠。

常用命令：

# List all active worktrees
git worktree list

# Remove the worktree when done
git worktree remove ../project-review

这个方法也适合同时跑 feature branch 和 hotfix session。

两个任务彼此隔离，不会互相污染。

9）连续错两次，就 /clear，不要继续补 prompt

当 Claude 在同一个问题上连续错两次时，很多人的本能反应是：

再解释一遍。

换个说法。

补更多细节。

让它再试一次。

这个本能很耗时间。

因为到第二次失败时，当前上下文大概率已经锚定在错误假设上。

你继续补 prompt，往往只是让 Claude 在错误地基上继续推理。

这时候应该用 /clear。

它会重置上下文。

代价只是重新输入一份干净的问题描述。

/clear

重新描述问题时，只放 Claude 真正需要的信息。

不要把刚才失败的尝试、来回纠正、错误方向一起带进去。

错误示范：

No that's still wrong, try again but this time...

更好的做法：

/clear

Refactor the auth middleware to support multiple providers. 
The interface must accept a provider name and return a 
standard claims object. Here is the current implementation: [paste]

根据我的经验，清空后重新开始的 session，通常会比在污染上下文里继续第三次、第四次尝试表现更好。

不是 Claude 突然变聪明了。

而是它终于摆脱了错误上下文。

最后

Claude Code 不是读一遍文档就能真正掌握的工具。

真正用得好的人，都学会了一件事：

把 context 当成一种资源。

它会被污染。

会被压缩。

也需要被重置。

这篇文章里的每个技巧，本质上都在围绕一件事：

更有意识地管理上下文。

Hooks 给你确定性控制，明确 Claude 可以做什么、不能做什么。

Subagents 和独立 session 给你干净上下文。

Skills 让你编码团队规则，而不用把所有内容塞进每次会话。

/compact 和 /clear 这类命令，则是让 Claude 推理保持清晰的精密工具。