Claude Code 性能优化：提速与降本

Token 是你的货币

使用 Claude Code 时，每一次交互都在消耗 Token。Token 不仅影响成本，还直接影响响应速度——输入的 Token 越多，等待时间越长。

理解 Token 的消耗机制，是优化 Claude Code 使用体验的第一步。

理解 Token 消耗

什么消耗 Token

消耗来源	说明	占比（典型场景）
系统提示	Claude Code 的内置指令	约 10-15%
CLAUDE.md	项目记忆文件	约 5-10%
对话历史	之前的对话内容	约 20-40%
文件内容	读取的文件内容	约 20-30%
工具调用	工具的输入和输出	约 10-20%
模型输出	Claude 的回复	约 10-15%

查看 Token 使用量

Claude Code 在每次响应后会显示 Token 使用统计：

> 帮我重构 Header 组件

[完成] 使用了 12,345 input tokens, 2,345 output tokens

也可以在会话中查看累计使用量：

/cost

Token 与成本的关系

以 Claude Sonnet 为例（价格可能变化）：

类型	价格	1000 次交互估算
Input Token	$3 / 1M tokens	~$30
Output Token	$15 / 1M tokens	~$45

一个典型的开发会话（2 小时）大约消耗 50-200K tokens，成本在 $0.5-$3 之间。

上下文窗口管理

Claude Code 使用的模型有上下文窗口限制。当对话内容超过窗口大小时，早期的内容会被压缩或丢弃。

上下文窗口的构成

┌─────────────────────────────────────────┐
│ 系统提示 (固定)                          │
├─────────────────────────────────────────┤
│ CLAUDE.md 内容 (固定)                    │
├─────────────────────────────────────────┤
│ 对话历史 (动态，可能被压缩)               │
│   ├── 用户消息 1                         │
│   ├── Claude 回复 1                      │
│   ├── 工具调用结果 1                     │
│   ├── ...                               │
│   └── 最新消息                           │
├─────────────────────────────────────────┤
│ 当前输入                                 │
└─────────────────────────────────────────┘

压缩机制

当上下文接近窗口限制时，Claude Code 会自动压缩早期对话：

保留最近的对话完整内容
将早期对话压缩为摘要
保留关键的代码变更记录
丢弃冗余的工具输出

手动管理上下文

当你感觉 Claude Code “忘记”了之前的内容，可以：

/compact

这会主动触发上下文压缩，释放空间给新的对话。

也可以开始新会话：

/clear

减少不必要的上下文

1. 精确描述需求

不好的做法：

帮我看看这个项目，然后优化一下性能

Claude Code 会读取大量文件来”理解项目”，消耗大量 Token。

好的做法：

src/utils/search.ts 中的 searchPosts 函数性能不好，
当文章超过 1000 篇时搜索很慢。帮我优化搜索算法。

直接指向具体文件和问题，减少不必要的探索。

2. 避免读取大文件

帮我看看 package-lock.json 有什么问题

package-lock.json 可能有几万行，读取它会消耗大量 Token。更好的方式：

帮我检查 package.json 中是否有过时的依赖，
不需要看 lock 文件

3. 使用 .claudeignore 排除无关文件

# .claudeignore
node_modules/
dist/
build/
.next/
coverage/
*.min.js
*.min.css
*.map
package-lock.json
pnpm-lock.yaml
yarn.lock

这些文件被排除后，Claude Code 在搜索和分析时不会浪费 Token。

4. 分步骤处理复杂任务

不好的做法：

帮我重构整个项目，把所有 JavaScript 文件转换为 TypeScript，
添加类型定义，更新测试，修复所有 lint 错误

好的做法：

第一步：帮我把 src/utils/format.js 转换为 TypeScript

完成后再处理下一个文件。每一步的上下文更小，响应更快。

高效的文件读取策略

1. 只读需要的部分

如果你知道问题在文件的某个区域：

读取 src/components/Header.astro 的第 50-80 行，
那里有一个导航菜单的 Bug

2. 用搜索代替全文读取

在 src/ 目录下搜索所有使用了 deprecated API 的地方

搜索只返回匹配的行，比读取整个文件高效得多。

3. 利用 CLAUDE.md 减少探索

在 CLAUDE.md 中写清楚项目结构，Claude Code 就不需要通过 ls 和 find 来探索：

## 关键文件

- 路由配置：`src/pages/` 目录，使用文件系统路由
- 全局样式：`src/styles/global.css`
- 工具函数：`src/utils/`
- 类型定义：`src/types/`
- 测试文件：`tests/`，与 src 目录结构对应

模型选择策略

Claude Code 支持多个模型，不同模型在能力和成本之间有不同的平衡：

模型	能力	速度	成本	适用场景
Opus	最强	较慢	最高	复杂架构设计、大规模重构
Sonnet	强	快	中等	日常开发、代码编写、Bug 修复
Haiku	够用	最快	最低	简单查询、格式化、小修改

按任务选择模型

# 复杂任务用 Opus
claude --model opus "设计一个微服务架构方案"

# 日常开发用 Sonnet（默认）
claude "修复 Header 组件的样式问题"

# 简单任务用 Haiku
claude --model haiku "帮我格式化这个 JSON 文件"

在会话中切换模型

/model sonnet

可以在同一个会话中根据任务复杂度切换模型。

响应速度优化

1. 使用 /compact 保持上下文精简

长时间会话后，上下文会变得臃肿。定期压缩：

/compact

2. 新会话处理独立任务

如果新任务和之前的对话无关，开一个新会话比在旧会话中继续更快：

# 新终端窗口
claude "新的独立任务"

3. 并行处理

对于互不依赖的任务，可以开多个 Claude Code 实例并行处理：

# 终端 1
claude "重构 src/utils/format.ts"

# 终端 2
claude "给 src/components/Search.astro 写测试"

# 终端 3
claude "更新 README.md 的安装说明"

4. 利用 Headless 模式批量处理

# 批量格式化文件
for file in src/utils/*.ts; do
  claude --print "格式化并优化 $file" &
done
wait

成本监控

追踪每日使用量

#!/bin/bash
# scripts/track-usage.sh
# 记录每日 Token 使用量

DATE=$(date +%Y-%m-%d)
LOG_FILE="usage-log.csv"

if [ ! -f "$LOG_FILE" ]; then
  echo "date,input_tokens,output_tokens,estimated_cost" > "$LOG_FILE"
fi

# 从 Claude Code 的使用统计中提取数据
# 具体路径取决于你的系统
USAGE_FILE="$HOME/.claude/usage.json"
if [ -f "$USAGE_FILE" ]; then
  INPUT=$(jq '.today.input_tokens // 0' "$USAGE_FILE")
  OUTPUT=$(jq '.today.output_tokens // 0' "$USAGE_FILE")
  COST=$(echo "scale=4; $INPUT * 0.000003 + $OUTPUT * 0.000015" | bc)
  echo "$DATE,$INPUT,$OUTPUT,$COST" >> "$LOG_FILE"
fi

设置使用预算

在团队中，可以通过 API 配置设置每日/每月的 Token 预算：

{
  "usage": {
    "daily_limit_tokens": 1000000,
    "monthly_limit_tokens": 20000000,
    "warning_threshold": 0.8
  }
}

优化实战案例

案例 1：大型代码库的搜索优化

问题：在一个 10 万行代码的项目中搜索，每次都很慢。

优化前：

帮我找到所有使用了 deprecated API 的地方

优化后：

在 src/ 目录下（排除 node_modules 和 dist），
搜索包含 @deprecated 注释的函数调用。
只看 .ts 和 .tsx 文件。

效果：搜索范围缩小 90%，Token 消耗减少 80%。

案例 2：重构任务的分步处理

问题：一次性重构 20 个文件，上下文溢出。

优化前：

把所有 class 组件重构为函数组件

优化后：

# 第一步：列出需要重构的文件
列出 src/components/ 下所有使用 class 的 React 组件

# 第二步：逐个重构
把 src/components/UserProfile.tsx 从 class 组件重构为函数组件

# 第三步：验证
运行 npm test 确认重构没有破坏功能

效果：每步的上下文更小，响应更快，错误更少。

案例 3：CLAUDE.md 优化

问题：CLAUDE.md 写了 200 行，每次启动都消耗大量 Token。

优化前（200 行）：

## API 文档
### GET /api/users
参数：...
返回值：...
### GET /api/posts
参数：...
返回值：...
... (150 行 API 文档)

优化后（50 行）：

## API
API 文档在 `docs/api.md`。
主要端点：/api/users, /api/posts, /api/comments
认证方式：Bearer Token

效果：CLAUDE.md 的 Token 消耗减少 75%，每次会话启动更快。

优化清单

优化项	预期效果	难度
配置 .claudeignore	减少 30-50% 搜索 Token	低
精简 CLAUDE.md	减少 5-10% 每次会话 Token	低
精确描述需求	减少 20-40% 探索 Token	中
分步处理复杂任务	避免上下文溢出	中
按任务选择模型	降低 30-60% 成本	低
定期 /compact	保持响应速度	低
并行处理独立任务	提升 2-3x 整体效率	中

常见问题

Q: 为什么同样的问题，有时候响应很快，有时候很慢？

A: 主要原因是上下文大小不同。在一个长会话的末尾，上下文可能已经很大了，导致响应变慢。试试 /compact 或开新会话。

Q: 如何知道哪些操作消耗了最多 Token？

A: 文件读取通常是最大的 Token 消耗源。一个 500 行的文件大约消耗 2000-3000 tokens。避免读取不必要的大文件。

Q: Opus 和 Sonnet 的实际体验差异大吗？

A: 对于日常开发任务（写代码、修 Bug、写测试），Sonnet 的表现已经很好。Opus 在需要深度推理的场景（架构设计、复杂算法）中优势更明显。建议默认用 Sonnet，遇到复杂问题再切换到 Opus。

Q: 有没有办法预估一个任务会消耗多少 Token？

A: 粗略估算：

简单问答：1-5K tokens
单文件编辑：5-15K tokens
多文件重构：20-50K tokens
大规模项目分析：50-200K tokens

优化 Claude Code 的使用效率，本质上是在优化人机协作的信噪比。减少噪音（不必要的上下文），放大信号（精确的需求描述），你就能用更少的 Token 完成更多的工作。

加载中...