Claude Code 性能优化与成本控制指南：让 AI 编程助手又快又省

前言

在之前的系列文章中，我们讲了上下文管理的操作细节，讲了怎么写好 Prompt，也在 CI/CD 指南里提到了一些成本控制的基础策略。但一直缺一篇从性能和成本视角系统性地讲优化的文章。

Claude Code 很强大，但它不是免费的。每一次对话、每一次文件读取、每一次代码生成，都在消耗 token。用得好，它是效率倍增器；用得不好，账单会让你心疼。

这篇文章的目标很明确：在不牺牲输出质量的前提下，让 Claude Code 又快又省。

一、理解成本：Token 计费机制

要优化成本，首先得理解成本是怎么产生的。

1.1 什么是 Token

Token 是大语言模型处理文本的基本单位。它不是字符，也不是单词，而是模型分词器切出来的"片段"。

一个关键认知：中文比英文消耗更多 token。 同样的语义，中文通常需要 1.5-2 倍的 token 数量。这是因为中文字符在模型的词表中覆盖率较低，经常被拆成多个 token。

# 英文：4 tokens
"Hello world" → ["Hello", " world"]

# 中文：约 6-8 tokens  
"你好世界" → ["你", "好", "世", "界"]（每个字可能 1-2 个 token）

这意味着如果你主要用中文和 Claude 交互，token 消耗会比英文用户更高。写 CLAUDE.md 和 Prompt 时，这一点值得考虑。

1.2 Token 消耗的构成

每次你和 Claude Code 对话，token 消耗由以下部分组成：

关键点：对话历史和工具调用结果是累积的。 会话越长，每一轮的 token 消耗越大，因为之前所有的内容都要重新发送给模型。

1.3 输入 vs 输出的价格差异

Claude 的计费模型中，输出 token 比输入 token 贵得多（通常是 3-5 倍）。这意味着：

• 让 Claude 生成大段冗余代码 = 烧钱
• 让 Claude 输出简洁精准的回答 = 省钱
• 在 Prompt 中明确要求"只输出关键代码，不要解释"可以显著降低输出 token

1.4 模型价格对比

直观感受：Opus 的输出成本是 Sonnet 的 5 倍，是 Haiku 的 60 倍。

1.5 一个真实会话的成本拆解

假设一个典型的 bug 修复会话：

会话过程：
1. 你描述 bug（200 tokens 输入）
2. Claude 读取 3 个文件（3000 tokens 工具结果）
3. Claude 分析并提问（500 tokens 输出）
4. 你补充信息（100 tokens 输入）
5. Claude 读取 2 个文件（2000 tokens 工具结果）
6. Claude 给出修复方案（800 tokens 输出）
7. 你确认执行（50 tokens 输入）
8. Claude 修改代码（600 tokens 输出）

累积消耗：
- 第 1 轮：系统 prompt(2000) + CLAUDE.md(500) + 输入(200) = 2700 输入 + 分析输出
- 第 4 轮：上述所有 + 历史对话 + 新输入 ≈ 8000 输入 + 方案输出
- 第 7 轮：所有累积 ≈ 12000 输入 + 代码输出

用 Sonnet：约 $0.05-0.08
用 Opus：约 $0.25-0.40

会话越长，后面每一轮的成本增长越快。 这就是为什么会话管理如此重要。

二、模型选择策略

选对模型是成本优化的第一步，也是最容易被忽视的一步。很多人默认用 Sonnet 做所有事情，但其实不同任务适合不同模型。

2.1 三个模型的定位

Opus — 深度思考者：

• 复杂的架构设计和重构
• 跨多个文件的大规模改动
• 需要深度推理的 bug 排查
• 安全审计和代码审查

Sonnet — 全能选手：

• 日常功能开发
• 中等复杂度的 bug 修复
• 代码解释和文档生成
• 大多数编程任务的最佳性价比选择

Haiku — 快速执行者：

• 简单的代码格式化
• 变量重命名、类型标注
• 生成样板代码
• 简单的问答和查询

2.2 按任务类型选模型

2.3 在 settings.json 中配置模型

你可以在 settings.json 中设置默认模型，避免每次手动切换（详见 settings 指南）：

{
  "model": "claude-sonnet-4-20250514",
  "smallFastModel": "claude-haiku-4-5-20251001"
}

smallFastModel 用于 Claude Code 内部的一些轻量任务（如自动补全、文件摘要），设置为 Haiku 可以进一步降低成本。

2.4 会话中切换模型

用 /model 命令可以在���话中随时切换模型：

# 开始用 Sonnet 做日常开发
> 帮我实现用户登录功能
 
# 遇到复杂问题，切换到 Opus
/model opus
> 这个认证流程有竞态条件，帮我分析一下
 
# 问题解决，切回 Sonnet
/model sonnet
> 好的，帮我把修复代码写上

实战建议： 默认用 Sonnet，遇到 Sonnet 搞不定的问题再切 Opus。大多数日常开发任务，Sonnet 和 Opus 的输出质量差异不大，但成本差 5 倍。

2.5 同一任务的成本对比

以"重构一个 200 行的 React 组件"为例：

对于这种中等复杂度的任务，Sonnet 是最优选择 — 质量接近 Opus，成本只有 1/5。

三、上下文优化

如果说模型选择决定了"单价"，那上下文管理决定了"用量"。上下文是成本的最大变量 — 同样的任务，上下文管理好的人可能只花 1/3 的 token。

关于上下文管理的具体操作命令和技巧，请参考上下文管理指南。这里我们从成本角度讲"为什么"和"策略"。

3.1 上下文膨胀的常见原因

3.2 三个核心策略

策略一：及时 /clear

完成一个任务后立即 /clear，不要在同一个会话里做不相关的事情。这是最简单也最有效的成本控制手段。

# 反面示例：一个会话做三件事
> 帮我修复登录 bug          ← 消耗 5000 tokens
> 顺便加个暗黑模式          ← 消耗 15000 tokens（包含之前的 5000）
> 再帮我写个单元测试        ← 消耗 30000 tokens（包含之前的 20000）
# 总计：约 50000 tokens

# 正面示例：三个独立会话
> 帮我修复登录 bug          ← 消耗 5000 tokens
/clear
> 帮我加个暗黑模式          ← 消耗 10000 tokens
/clear
> 帮我写个单元测试          ← 消耗 10000 tokens
# 总计：约 25000 tokens — 省了一半

策略二：善用 /compact

当任务进行到一半但上下文已经很大时，用 /compact 压缩。关键是给一个好的压缩提示：

/compact 保留：1. 当前的修改方案 2. 已确认的文件列表 3. 下一步计划。丢弃所有调试过程。

策略三：精准喂上下文

不要说"帮我看看这个项目"，而是说"帮我看 src/auth/login.ts 的第 50-80 行"。越精准，Claude 读取的文件越少，上下文越干净。

3.3 长会话 vs 短会话的成本对比

3.4 CLAUDE.md 的精简原则

CLAUDE.md 在每一轮对话中都会被发送，所以它的每一行都在持续消耗 token。

# 反面示例：冗长的 CLAUDE.md（约 2000 tokens）
这个项目是一个使用 Next.js 构建的博客系统，我们使用了 Tailwind CSS 
进行样式管理，使用 next-intl 进行国际化处理，支持中文和英文两种语言...
（大段描述性文字）
 
# 正面示例：精简的 CLAUDE.md（约 500 tokens）
## 技术栈
Next.js 16 + Tailwind v4 + next-intl (zh/en)
 
## 规则
- 组件放 components/，工具函数放 lib/
- 所有文本用 i18n key，不硬编码
- 提交前跑 npm run lint

精简 CLAUDE.md 从 2000 tokens 到 500 tokens，一个 20 轮的会话可以节省 30000 tokens 的输入消耗。

四、Prompt 经济学

好的 Prompt 不仅能提高输出质量，还能直接省钱。这不是重复Prompt 指南的内容，而是从成本角度重新审视 Prompt 的写法。

4.1 一次到位 vs 多轮迭代

多轮迭代的成本是指数增长的，因为每一轮都要重新发送之前所有的对话历史。

# 模糊 Prompt — 需要 5 轮对话
> 帮我写个表单
  Claude: 什么表单？什么字段？
> 登录表单，有邮箱和密码
  Claude: 需要验证吗？用什么 UI 库？
> 要验证，用 shadcn
  Claude: 需要记住密码功能吗？
> 要
  Claude: （终于开始写代码）
# 消耗：~25000 tokens

# 精确 Prompt — 1 轮搞定
> 在 app/login/page.tsx 创建登录表单：
> - 字段：邮箱（必填，格式验证）、密码（必填，最少 8 位）
> - UI：用 shadcn/ui 的 Form 组件
> - 功能：记住密码 checkbox，提交调用 /api/auth/login
> - 错误处理：显示在表单下方
# 消耗：~8000 tokens

一个精确的 Prompt 可以节省 60-70% 的 token。

4.2 结构化 Prompt 模板

减少歧义就是减少重试。推荐使用这个模板：

[任务] 简明描述要做什么
[文件] 涉及哪些文件
[要求] 具体的技术要求
[约束] 不要做什么

实际示例：

帮我给 BlogPost 组件添加阅读时间显示：
- 文件：components/BlogPost.tsx
- 在标题下方、日期旁边显示
- 按中文 300 字/分钟计算
- 不要修改现有的样式结构
- 不要添加新的依赖

4.3 从成本角度看 Prompt 技巧

Prompt 指南里的技巧，从成本角度重新解读：

4.4 批量操作 vs 逐个操作

如果你有多个相似的修改，一次性说清楚比逐个提交要省得多：

# 逐个操作 — 3 个独立请求
> 把 UserCard 组件的 className 改成 Tailwind
> 把 UserList 组件的 className 改成 Tailwind
> 把 UserProfile 组件的 className 改成 Tailwind
# 每次都要重新加载上下文，总计 ~30000 tokens

# 批量操作 — 1 个请求
> 把以下三个组件的 CSS modules 迁移到 Tailwind：
> 1. components/UserCard.tsx
> 2. components/UserList.tsx  
> 3. components/UserProfile.tsx
> 保持现有样式效果不变。
# 一次完成，总计 ~15000 tokens

4.5 控制输出长度

在 Prompt 中明确告诉 Claude 你想要多详细的输出：

# 省 token 的写法
> 修复这个 bug，只输出修改的代码，不需要解释。
 
# 烧 token 的写法
> 帮我修复这个 bug
# Claude 会��出：问题分析 + 解决方案 + 完整代码 + 解释 + 后续建议

一个"不需要解释"可以减少 30-50% 的输出 token。

五、会话管理策略

会话管理是上下文优化的延伸，但更侧重于"什么时候开新会话"和"怎么拆分任务"。

5.1 单长会话 vs 多短会话

经验法则： 如果一个任务需要超过 15 轮对话，考虑拆分成多个子任务。

5.2 什么时候该开新会话

• 当前任务已完成，要开始新任务
• Claude 开始"犯糊涂"（重复之前的错误、忘记约定）
• 调试陷入死循环（同一个方案反复尝试）
• 你需要换一个完全不同的思路
• 会话已经超过 20 轮对话

5.3 /resume 的成本考量

/resume 可以恢复之前的会话，但要注意：恢复的会话会加载之前的对话摘要，这本身也消耗 token。

# 适合 /resume 的场景
- 昨天的任务做到一半，今天继续
- 需要之前讨论的架构决策作为上下文
 
# 不适合 /resume 的场景
- 之前的会话已经很长了（摘要也会很大）
- 新任务和之前的会话关系不大
- 之前的会话里有很多错误的尝试

如果之前的会话很长，与其 /resume，不如开新会话，手动把关键决策复制过去。这样上下文更干净，成本更低。

5.4 子任务拆分

大任务拆成小任务，每个小任务一个会话，是最有效的成本控制策略之一：

# 反面示例：一个会话做完整个功能
> 帮我实现完整的用户认证系统，包括注册、登录、忘记密码、
> 邮箱验证、OAuth、权限管理...
# 会话会非常长，后期每轮成本极高

# 正面示例：拆分成独立会话
会话 1：设计认证系统的数据模型和 API 接口（输出设计文档）
/clear
会话 2：实现注册和登录 API
/clear
会话 3：实现忘记密码和邮箱验证
/clear
会话 4：实现 OAuth 集成
/clear
会话 5：实现权限管理
# 每个会话都从干净状态开始，总成本更低

关键技巧：让第一个会话输出一个设计文档或计划，后续会话把这个文档作为输入。这样既保持了连贯性，又避免了上下文累积。

5.5 多 Agent 并行的成本影响

Claude Code 支持多 Agent 并行执行（详见多 Agent 指南）。从成本角度看：

• 优势： 多个 Agent 各自有独立的上下文，不会互相污染
• 劣势： 每个 Agent 都要加载系统 prompt 和 CLAUDE.md，有固定开销
• 适合： 多个独立的子任务（如同时修改前端和后端）
• 不适合： 需要频繁共享上下文的紧耦合任务

# 适合并行的场景
claude --task "重构 UserService" &
claude --task "重构 OrderService" &
# 两个服务互不依赖，并行更快且总成���相近
 
# 不适合并行的场景
# 如果 OrderService 依赖 UserService 的接口变更
# 串行执行更合理，避免返工

六、缓存与复用

Claude Code 有内置的缓存机制，理解并利用它可以显著降低成本。

6.1 Prompt Caching 机制

Claude API 支持 prompt caching：如果连续请求的前缀部分相同，缓存命中的 token 只收 10% 的价格。

在 Claude Code 中，以下内容通常会被缓存：

6.2 最大化缓存命中率

保持 CLAUDE.md 稳定： 频繁修改 CLAUDE.md 会导致缓存失效。把它写好后尽量不要改动。

避免频繁切换项目： 在同一个项目中连续工作，系统 prompt 和 CLAUDE.md 的缓存命中率最高。

会话内保持连贯： 不要在一个会话中频繁切换话题，这会降低对话历史的缓存效率。

6.3 自定义命令的复用价值

自定义 slash 命令（详见 Skills 指南）不仅提高效率，还能省钱：

# .claude/commands/review.md
审查以下代码的变更：
- 检查是否有安全漏洞
- 检查是否符合项目编码规范
- 检查是否有性能问题
- 只输出发现的问题，不要重复代码
 
$ARGUMENTS

使用自定义命令的好处：

1. Prompt 复用： 不用每次手动输入详细的审查要求
2. 输出控制： 命令中可以包含"只输出问题"这样的约束，减少输出 token
3. 一致性： 每次执行的 Prompt 相同，缓存命中率更高

6.4 代码片段和模板复用

把常用的代码模式放在 CLAUDE.md 或项目文档中，让 Claude 直接引用而不是每次重新生成：

# CLAUDE.md 中的模板引用
## 组件模板
新建 React 组件时，参考 components/Button.tsx 的结构。
 
## API 路由模板
新建 API 路由时，参考 app/api/users/route.ts 的错误处理模式。

这比每次在 Prompt 中描述"我想要什么样的组件结构"要省 token 得多。Claude 会直接读取参考文件，而不是让你在对话中描述。

6.5 利用 .claudeignore 减少噪音

创建 .claudeignore 文件，排除不需要 Claude 关注的文件和目录：

# .claudeignore
node_modules/
dist/
.next/
coverage/
*.lock
*.log

这不会直接减少 token 消耗，但能防止 Claude 在搜索文件时读取无关内容，间接减少工具调用产生的 token。

七、CI/CD 成本控制

CI 环境下的 Claude Code 使用有一个特殊问题：无人值守意味着无法中断浪费。 一个配置不当的 CI 任务可能在你不知情的情况下烧掉大量 token。

完整的 CI/CD 配置请参考 CI/CD 指南。这里聚焦成本控制策略。

7.1 触发条件优化

不是每个 PR 都需要 Claude 审查，不是每次 push 都需要 Claude 跑测试。

# GitHub Actions 示例：只在特定条件下触发
on:
  pull_request:
    paths:
      - 'src/**'        # 只有源码变更才触发
      - '!src/**/*.md'   # 排除文档变更
    types: [opened, synchronize]  # 不在 close 时触发
 
# 进一步优化：只在大 PR 时触发深度审查
jobs:
  review:
    if: github.event.pull_request.changed_files > 5
    steps:
      - uses: anthropic/claude-code-action@v1
        with:
          model: claude-sonnet-4-20250514

7.2 max_turns 限制

在 CI 中一定要设置 max_turns，防止 Claude 陷入无限循环：

# 限制最多 10 轮交互
claude --max-turns 10 --task "审查这个 PR 的代码变更"

没有 max_turns 的 CI 任务就像没有超时的 HTTP 请求 — 迟早会出问题。

7.3 CI 场景的模型降级

CI 中的大多数任务不需要 Opus。合理的模型分配：

# 按任务类型选择模型
- name: Code Review
  run: claude --model claude-sonnet-4-20250514 --max-turns 5 --task "..."
 
- name: Fix Lint
  run: claude --model claude-haiku-4-5-20251001 --max-turns 3 --task "..."

7.4 成本预算和告警

通过 Anthropic API 的用量监控，设置每日/每月的成本上限：

# 在 CI 脚本中检查当日用量（伪代码）
DAILY_COST=$(curl -s https://api.anthropic.com/v1/usage | jq '.daily_cost')
MAX_DAILY=50  # $50/天的上限
 
if (( $(echo "$DAILY_COST > $MAX_DAILY" | bc -l) )); then
  echo "⚠️ 已达到每日成本上限 ($DAILY_COST/$MAX_DAILY)，跳过 Claude 审查"
  exit 0
fi

建议设置三级告警：

• 提醒： 达到预算的 70%
• 警告： 达到预算的 90%
• 停止： 达到预算的 100%，自动跳过非关键的 Claude 任务

八、团队成本管控

个人开发者可以靠自觉控制成本，但团队需要制度和工具。

8.1 API Key 管理

不要共用一个 API Key。 共用 Key 的问题：

• 无法追踪谁消耗了多少
• 一个人的误操作影响所有人
• 无法按人设置限额

推荐做法：

方案 A：每人一个 API Key
- 优点：用量追踪精确，可以按人设限
- 缺点：管理成本高

方案 B：按项目分配 API Key
- 优点：可以按项目追踪成本
- 缺点：同一项目内无法区分个人用量

方案 C：使用 API Gateway（推荐团队方案）
- 通过代理层统一管理，按用户/项目/团队维度追踪
- 可以设置细粒度的限额和告警

8.2 按项目分配预算

不同项目的 Claude 使用量差异很大。建议按项目特点分配预算：

8.3 成本监控方案

搭建一个简单的成本监控仪表盘：

// 成本追踪脚本示例
interface UsageRecord {
  user: string;
  project: string;
  model: string;
  inputTokens: number;
  outputTokens: number;
  cost: number;
  timestamp: Date;
}
 
// 从 Anthropic API 获取用量数据
async function fetchUsage(apiKey: string): Promise<UsageRecord[]> {
  const response = await fetch('https://api.anthropic.com/v1/usage', {
    headers: { 'x-api-key': apiKey }
  });
  return response.json();
}
 
// 按维度聚合
function aggregateCost(records: UsageRecord[], groupBy: 'user' | 'project' | 'model') {
  const groups = new Map<string, number>();
  for (const record of records) {
    const key = record[groupBy];
    groups.set(key, (groups.get(key) || 0) + record.cost);
  }
  return groups;
}

关键监控指标：

• 每日/每周/每月总成本
• 按人均成本排名 — 找出异常高的使用者（可能需要培训优化技巧）
• 按模型分布 — 如果 Opus 占比过高，可能有优化空间
• 按时段分布 — 识别使用高峰，优化 CI 调度

8.4 团队使用规范

在项目的 CLAUDE.md 中加入成本意识条款：

# CLAUDE.md 成本控制条款
 
## 模型使用规范
- 日常开发默认使用 Sonnet
- 只在复杂架构设计和疑难 bug 时使用 Opus
- CI 任务优先使用 Haiku
 
## 会话管理规范
- 单个任务完成后执行 /clear
- 会话超过 15 轮时考虑 /compact 或开新会话
- 不在同一会话中处理不相关的任务
 
## 输出控制
- 代码修改任务加上"只输出修改部分"
- 不需要解释时明确说明

8.5 不同规模的成本策略

九、性能优化技巧

成本之外，速度也很重要。没人喜欢等 Claude 思考 30 秒。

9.1 响应速度的影响因素

模型速度排名： Haiku >> Sonnet > Opus

Haiku 的响应速度通常是 Opus 的 3-5 倍。对于不需要深度推理的任务，用 Haiku 不仅省钱，还更快。

9.2 减少不必要的工具调用

Claude Code 每次工具调用（读文件、执行命令、搜索）都会增加延迟和 token 消耗。

# 低效：让 Claude 自己找文件
> 帮我修复用户登录的 bug
# Claude 可能会：搜索文件 → 读 5 个文件 → 再搜索 → 再读 3 个文件

# 高效：直接告诉 Claude 在哪
> 帮我修复 src/auth/login.ts 第 45 行的空指针错误，
> 相关类型定义在 src/types/auth.ts
# Claude 直接读 2 个文件，开始修复

减少工具调用的技巧：

1. 提供具体文件路径 — 不要让 Claude 猜
2. 说明项目结构 — 在 CLAUDE.md 中列出关键目录
3. 一次给够信息 — 避免 Claude 需要多次读取才能理解上下文
4. 使用 @file 引用 — 直接把文件内容喂给 Claude

9.3 Hook 的性能影响

Hooks 在每次工具调用时执行，如果 Hook 脚本本身很慢，会显著影响整体体验。

// settings.json 中的 Hook 配置
{
  "hooks": {
    "afterWrite": {
      "command": "eslint --fix $FILE"  // 每次写文件后自动 lint
    }
  }
}

优化建议：

• Hook 脚本要快： 目标是 1 秒内完成。如果 lint 整个项目要 10 秒，改成只 lint 变更的文件
• 避免不必要的 Hook： 不是每个事件都需要 Hook。只在真正需要的地方加
• 异步执行： 如果 Hook 不影响后续操作，考虑异步执行

# 慢：lint 整个项目
eslint .
 
# 快：只 lint 变更的文件
eslint "$FILE"

9.4 MCP 工具的延迟考量

MCP（Model Context Protocol）工具（详见 MCP 指南）引入了外部服务调用，每次调用都有网络延迟。

优化建议：

• 本地优先： 能用本地工具解决的，不要用远程 MCP 服务
• 批量查询： 如果 MCP 工具支持批量操作，一次查多个比多次查一个快
• 缓存结果： 对于不常变化的数据（如数据库 schema），考虑缓存到本地文件
• 超时设置： 给 MCP 工具设置合理的超时，避免一个慢请求阻塞整个会话

9.5 网络优化

如果你在中国大陆使用 Claude Code，网络延迟可能是最大的性能瓶颈：

• 使用稳定的网络连接
• 考虑使用 API 代理减少延迟
• 避免在网络不稳定时执行大型任务（断线重连会浪费已消耗的 token）

总结

Claude Code 的性能优化和成本控制，归根结底就是三个核心原则：

选对模型 — 不是最贵的就是最好的。Sonnet 能搞定 80% 的日常任务，Haiku 能处理简单的格式化和查询，只有真正复杂的架构设计和疑难 bug 才需要 Opus。

管好上下文 — 上下文是成本的最大变量。及时 /clear、善用 /compact、精准喂上下文，这三招能省下一半以上的 token。

写好 Prompt — 一个精确的 Prompt 胜过五轮模糊的对话。一次到位，减少来回，控制输出长度。

快速参考清单

推荐阅读

• 上下文管理指南 — 上下文管理的完整操作手册
• Prompt 指南 — 写出高质量 Prompt 的技巧
• CI/CD 指南 — CI/CD 环境下的完整配置
• 多 Agent 指南 — 多 Agent 并行架构
• Settings 指南 — 模型和工具的详细配置
• Hooks 指南 — Hook 系统的配置和优化
• MCP 指南 — MCP 工具的使用和配置
• Skills 指南 — 自定义命令的创建和复用