Token 深度优化指南

一、理解 Token 经济学

Token 是什么

英文：约 4 个字符 = 1 个 token
     "Hello world" = 2 tokens

中文：约 1-2 个汉字 = 1 个 token
     "你好世界" = 2-4 tokens

代码：变量名、符号、空格、换行都算 token
     function add(a, b) { return a + b; } = 约 12 tokens

价格计算

以 Claude Sonnet 为例（2026 年价格）：

输入：$3 / 百万 tokens
输出：$15 / 百万 tokens

一次典型的对话：
- 系统 Prompt + CLAUDE.md：~2k tokens
- 你的输入：~500 tokens
- Claude 的输出：~2k tokens
- 工具调用和结果：~3k tokens
- 单轮对话总计：~7.5k tokens

20 轮对话 = ~150k tokens = $0.45 输入 + $0.45 输出 ≈ $0.90

成本陷阱

最大的成本不是对话轮数，而是：

1. 读取大文件
   - 一个 1000 行的代码文件 ≈ 20k tokens
   - 读 10 个文件 = 200k tokens = $0.60

2. 长对话不压缩
   - 30 轮对话 + 多次文件读取 ≈ 500k tokens
   - = $1.50+

3. 重复读取
   - 同一个文件被读取 3 次 = 3 倍成本

二、上下文管理策略

策略 1：精确上下文

# 差：让 AI 自己找
"帮我修复登录 bug"
→ AI 可能读取 10+ 文件来定位问题
→ 消耗 100k+ tokens

# 好：直接指出
"src/services/auth.ts 第 45 行的 login 函数，
当密码错误时没有返回正确的错误码"
→ AI 只需读取 1 个文件
→ 消耗 5k tokens

成本差异：20 倍

策略 2：分阶段对话

# 差：一个对话做所有事
"帮我做一个完整的用户管理系统"
→ 上下文不断膨胀
→ 后半段对话质量下降

# 好：分多个对话
对话 1："设计数据模型" → 完成后关闭
对话 2："实现注册接口" → 完成后关闭
对话 3："实现登录接口" → 完成后关闭

每个对话的上下文都是精简的

策略 3：善用 /compact

# 什么时候用 /compact：
# 1. 完成一个子任务后
# 2. 对话超过 15 轮后
# 3. 准备切换话题时
# 4. 感觉 Claude 开始"忘记"之前说的话

/compact
# Claude 会压缩上下文，保留关键信息
# 典型压缩比：3:1 到 5:1

策略 4：用 CLAUDE.md 代替重复说明

# 每次对话都要说（浪费 token）
"我的项目用 Next.js 14，TypeScript，Tailwind CSS，
数据库是 PostgreSQL，用 Prisma ORM，
代码规范是..."

# 写入 CLAUDE.md（一次性投入）
# 之后每次对话自动加载，不需要重复

策略 5：Headless 模式处理简单任务

# 简单任务不需要交互模式
claude -p "检查 types.ts 有没有类型错误"
# 消耗：~5k tokens

# 管道输入
cat error.log | claude -p "分析这个错误"
# 消耗：~3k tokens

# 对比：进入交互模式
claude
> 读一下 types.ts
> 检查有没有类型错误
# 消耗：~10k tokens（多了对话开销）

三、Prompt 精简技巧

技巧 1：去掉废话

# 差
"你好，我是新手，请问能不能请你帮我看看这个函数，
如果你有时间的话，能不能帮我优化一下，非常感谢！"
# 约 50 tokens

# 好
"优化 src/utils/parser.ts 的 parseCSV 函数性能"
# 约 15 tokens

成本差异：3 倍+

技巧 2：用结构化代替叙述

# 差
"我想做一个功能，就是用户可以上传头像，然后保存到 S3，
还要压缩一下，生成缩略图，然后返回 URL 给前端显示..."
# 约 60 tokens

# 好
"头像上传：
- 接收图片
- 压缩到 500KB
- 生成 100x100 缩略图
- 上传 S3
- 返回 URL"
# 约 30 tokens

成本差异：2 倍

技巧 3：引用而不是复制

# 差
"看这段代码：[粘贴 200 行代码]"
# 消耗：~4k tokens

# 好
"看 src/services/user.ts 的 createUser 函数"
# 消耗：~15 tokens + Claude 自己读取（可缓存）

成本差异：巨大（而且 Claude 自己读取更精准）

技巧 4：明确约束避免返工

# 差
"实现一个缓存函数"
# Claude 可能实现一个简单版本，然后你要改 3 次
# 总消耗：3 轮对话 × 5k = 15k tokens

# 好
"实现一个缓存函数：
- 支持 TTL 过期
- 线程安全
- LRU 淘汰策略
- 最大容量 1000"
# Claude 一次到位
# 总消耗：1 轮对话 × 5k = 5k tokens

成本差异：3 倍

技巧 5：不要让 AI 做多余的事

# 差
"帮我写一个排序函数"
# Claude 可能：
# - 写函数
# - 写测试
# - 写文档
# - 优化性能
# 消耗：10k+ tokens

# 好
"写一个快速排序函数，只需要函数本身"
# 消耗：3k tokens

四、模型选择策略

不同任务用不同模型

Claude Haiku（最便宜）：
- 简单查询
- 格式转换
- 代码补全
- 简单脚本

Claude Sonnet（性价比最高）：
- 一般开发任务
- 代码审查
- 测试生成
- 文档编写

Claude Opus（最强但最贵）：
- 复杂架构设计
- 难以调试的 Bug
- 性能优化分析
- 安全审计

实际成本对比

同一个任务（实现一个 CRUD API）：

Haiku：~$0.05（但质量可能不够）
Sonnet：~$0.20（推荐）
Opus：~$0.80（质量最高）

如果任务简单，用 Haiku 省 75%
如果任务复杂，用 Sonnet 是最佳平衡

在 Claude Code 中切换

# 使用 fast 模式（Opus 的快速版）
/fast

# 启动时指定模型
claude --model claude-sonnet-4-6

# 简单任务
claude --model claude-haiku-4-5-20251001

五、文件读取优化

避免读取大文件

# 差：读取整个文件
"读一下 src/utils/helpers.ts"
# 如果文件 500 行 = ~10k tokens

# 好：只读需要的部分
"读一下 src/utils/helpers.ts 第 100-150 行"
# 只消耗 ~2k tokens

避免重复读取

# 差
"读一下 auth.ts"          # 读取一次
"改一下第 10 行"           # Claude 可能又读取一次
"改一下第 20 行"           # 又读取一次

# 好
"读一下 auth.ts，然后改第 10 行的 X 为 Y，第 20 行的 A 为 B"
# 只读取一次

用 Grep 代替全文读取

# 差
"读一下所有用了 fetchUser 的文件"
# 可能读取 10 个文件 = 50k+ tokens

# 好
"搜索所有用了 fetchUser 的文件"
# Grep 只返回文件名和匹配行 = ~2k tokens
# 然后只读取需要的文件

六、监控与控制

查看当前消耗

# 在 Claude Code 中
/cost

# 显示：
# - 当前会话的 token 使用量
# - 输入/输出 token 分别多少
# - 估算费用

设置预算

# 在 Anthropic Console 中设置：
# - 每日预算上限
# - 每月预算上限
# - 超出后的行为（通知/停止）

团队成本控制

# 不同用途用不同 API Key
# 开发用一个 Key（限额高）
# 测试用另一个 Key（限额低）
# CI/CD 用第三个 Key（限额中）

七、实战省钱案例

案例一：大文件重构

场景：重构一个 800 行的工具函数文件

差的做法：
"重构 src/utils/helpers.ts"
→ 读取整个文件（20k tokens）
→ 生成大量修改（10k tokens）
→ 总计：30k tokens

好的做法：
1. "列出 src/utils/helpers.ts 中的所有函数名"
   → 消耗：5k tokens（Claude 只输出函数列表）

2. "重构 string 相关的函数到 src/utils/stringUtils.ts"
   → 消耗：10k tokens

3. "重构 array 相关的函数到 src/utils/arrayUtils.ts"
   → 消耗：10k tokens

总计：25k tokens（省了 17%），且每步可控

案例二：代码审查

场景：审查一个 PR 的 30 个文件改动

差的做法：
"审查这个 PR 的所有改动"
→ 读取 30 个文件 = 300k tokens

好的做法：
1. "列出这个 PR 改了哪些文件"
   → 消耗：2k tokens

2. "重点审查 src/api/ 下的改动"
   → 消耗：30k tokens

3. "审查 src/services/ 下的改动"
   → 消耗：30k tokens

总计：62k tokens（省了 80%）

案例三：学习新代码库

场景：接手一个陌生项目

差的做法：
"帮我理解这个项目"
→ 可能读取大量文件 = 200k+ tokens

好的做法：
1. "读 README，告诉我项目是什么"
   → 消耗：3k tokens

2. "画出 src/ 的目录结构"
   → 消耗：2k tokens

3. "解释 src/core/ 的入口文件"
   → 消耗：5k tokens

4. "数据是怎么从 API 到页面的"
   → 消耗：10k tokens

总计：20k tokens（省了 90%），按需探索

八、速查表