附录 C：性能基准参考
本附录提供常见 Claude Code 任务类型的典型 token 用量、成本估算和性能特征参考数据。所有数字均为近似值，代表真实开发工作流中观察到的典型范围。
按任务类型划分的 Token 用量
Token 计数代表完成一项任务的总 token 数（输入 + 输出），包括 context 累积。实际用量因代码库大小、CLAUDE.md 长度和对话历史而存在显著差异。
探索与理解类任务
| 任务 | 典型 Token 范围 | 备注 |
|---|---|---|
| 解释单个 100-200 行文件 | 3,000–6,000 | 一次文件读取 + 解释 |
| 理解一个模块（5-10 个文件） | 10,000–25,000 | 多次文件读取、交叉引用 |
| 绘制完整子系统架构图（20+ 个文件） | 30,000–80,000 | 深度探索；建议用子 agent 隔离 |
| 回答关于某个函数的问题 | 1,500–4,000 | 定向读取 |
| 端到端解释陌生代码库 | 50,000–150,000 | 范围极广；计划压缩 context |
| Git 日志分析（最近 50 次提交） | 5,000–15,000 | 随提交信息长度变化 |
代码编写类任务
| 任务 | 典型 Token 范围 | 备注 |
|---|---|---|
| 为某个函数编写单元测试 | 2,000–5,000 | 一次读取 + 生成 |
| 实现简单工具函数 | 1,500–4,000 | 通常无需读取文件 |
| 实现 CRUD 接口（标准模式） | 5,000–15,000 | 读取 schema + 现有处理器 |
| 实现中等规模功能（3-5 个文件） | 15,000–35,000 | 多次读取、多次写入 |
| 实现复杂功能（10+ 个文件） | 40,000–100,000 | 考虑用子 agent 分解 |
| 为一个模块编写完整测试套件 | 10,000–30,000 | 模块读取 + 测试生成 |
| 将文件迁移到新 API/库 | 5,000–20,000 | 取决于文件大小和库复杂度 |
Bug 修复类任务
| 任务 | 典型 Token 范围 | 备注 |
|---|---|---|
| 修复简单 bug（已提供错误信息） | 3,000–8,000 | 定向文件读取 |
| 调试复杂多文件问题 | 20,000–60,000 | 探索密集；context 很快填满 |
| 追踪性能问题 | 15,000–50,000 | 取决于分析深度 |
| 修复失败测试（原因不明显） | 5,000–20,000 | 测试文件 + 相关源文件 |
| 修复安全漏洞 | 10,000–30,000 | 安全分析 + 多个文件 |
代码审查与分析类任务
| 任务 | 典型 Token 范围 | 备注 |
|---|---|---|
| 审查小型 PR（1-3 个文件） | 5,000–12,000 | Diff + 文件 context |
| 审查中型 PR（5-10 个文件） | 15,000–35,000 | 较大 diff + 跨文件分析 |
| 审查大型 PR（20+ 个文件） | 40,000–100,000 | 考虑用子 agent 审查 |
| 模块安全审计 | 15,000–40,000 | 模块内所有文件 + 分析 |
| 性能审计 | 10,000–30,000 | 代码 + 查询分析 |
| 依赖漏洞扫描 | 5,000–15,000 | package.json + npm audit 输出 |
自动化与脚本类任务
| 任务 | 典型 Token 范围 | 备注 |
|---|---|---|
| 编写 shell 脚本 | 2,000–6,000 | 通常无需读取文件 |
| 创建 CI/CD 工作流文件 | 3,000–8,000 | 若有现有配置则读取 |
| 配置 GitHub Actions 工作流 | 4,000–10,000 | |
| 批量重命名/重构（10 个文件） | 10,000–25,000 | 并行方式更高效 |
| 为单个文件添加类型注解 | 3,000–8,000 | 取决于文件大小 |
| 为模块生成文档 | 5,000–15,000 | 模块读取 + 文档生成 |
成本估算
以下估算基于 2025 年初 Anthropic API 的近似定价。订阅计划（Pro、Max）按固定费率收费，此处数字不适用于订阅用户——仅反映 API（按量付费）的使用成本。
定价档位（近似值，以实际为准）：
| 模型 | 输入 token（每百万） | 输出 token（每百万） | 缓存读取（每百万） |
|---|---|---|---|
| Claude Haiku 4.5 | ~$1 | ~$5 | ~$0.10 |
| Claude Sonnet 4.6 | ~$3 | ~$15 | ~$0.30 |
| Claude Opus 4.6 | ~$5 | ~$25 | ~$0.50 |
Prompt 缓存是自动的——Claude Code 会缓存 CLAUDE.md、系统提示和其他稳定内容。缓存读取费用约为正常输入价格的 10%，在长 session 中大量复用相同 context 时可显著降低成本。
典型任务成本（Sonnet，近似值）：
| 任务 | 预估成本 |
|---|---|
| 快速提问 / 解释单个函数 | $0.01–$0.05 |
| 编写单元测试 | $0.03–$0.10 |
| 实现 CRUD 接口 | $0.10–$0.30 |
| 实现中等规模功能 | $0.30–$0.80 |
| 调试复杂问题 | $0.40–$1.50 |
| 完整 PR 审查（大型 PR） | $0.80–$2.50 |
| 架构规划 session | $1.00–$4.00 |
模型选择的成本影响： 使用 Opus 4.6 与 Sonnet 4.6 执行同一任务，每 token 成本约相差 1.7 倍。但 Opus 会话因更深度的推理往往消耗更多 token，实际成本差异通常在 2-3 倍。对于 Sonnet 能产出满意结果的任务，一个月高强度使用的成本差异仍然可观。
速度基准
延迟主要由输出长度决定。首 token 时间通常为 1-3 秒，完整响应时间取决于输出长度。
| 任务 | 典型总耗时（Sonnet） |
|---|---|
| 简短解释 | 3–8 秒 |
| 编写一个函数 | 5–15 秒 |
| 编写一个测试文件 | 10–30 秒 |
| 实现中等规模功能 | 30–120 秒 |
| 大型重构（10+ 个文件） | 2–8 分钟 |
| 复杂调试 session | 5–20 分钟（交互式） |
并行 agent 加速效果：
对于独立任务，运行 3 个并行子 agent 相比顺序执行可提供约 2.5–3 倍的速度提升（含编排开销）。对于可完全并行化的任务（如审查 30 个文件），并行执行能显著减少实际等待时间。
Context 窗口参考
Claude 各模型有不同的 context 窗口大小。截至 2026 年初：
| 模型 | Context 窗口 | 备注 |
|---|---|---|
| Claude Haiku 4.5 | 200,000 tokens | 标准 |
| Claude Sonnet 4.6 | 200,000 tokens | 标准 |
| Claude Opus 4.6 | 200,000 tokens | 标准 |
| Claude Opus 4.6（1M） | 1,000,000 tokens | Max/Team/Enterprise 自动启用；可通过 CLAUDE_CODE_DISABLE_1M_CONTEXT=1 禁用 |
200,000 tokens 看似很大，但实际上比预期填满得更快：
| 内容 | 近似 Token 数 |
|---|---|
| 1,000 行 TypeScript | ~6,000 tokens |
| 一个 CLAUDE.md（200 行） | ~1,500 tokens |
| 100 条对话消息 | ~20,000–60,000 tokens |
| 完整测试套件输出（200 个测试） | ~15,000–30,000 tokens |
| 大型 PR diff（500 行变更） | ~10,000–20,000 tokens |
持续高质量输出的实际上限： Claude Code 通常在 context 窗口容量的 60-70% 以内保持高质量输出。超过这个比例后，质量开始出现可感知的下降；超过 90% 后，下降较为明显。
对于 200K 窗口，这意味着：
- 舒适工作区间：最多约 130,000 tokens
- 质量开始下降：130,000–180,000 tokens
- 应压缩或清空 context：超过 180,000 tokens
基准对比：子 Agent vs 顺序处理
对于涉及大量文件的任务，使用子 agent 能带来显著的性能优势：
场景：审查 10 个文件的安全问题
| 方式 | 实际耗时 | 消耗的主 Context | 质量 |
|---|---|---|---|
| 顺序处理（全在主 context 中） | 3-5 分钟 | ~30,000-50,000 tokens | 后期文件质量下降 |
| 每文件一个子 agent（并行） | 1-2 分钟 | ~5,000 tokens（仅摘要） | 全程保持一致 |
场景：实现需要大量代码库探索的功能
| 方式 | 实现后 Context 占用 | 可用于迭代的 Context |
|---|---|---|
| 全在主 context 中探索 | 80,000-120,000 tokens | 有限 |
| 用子 agent 探索，摘要返回主 context | 20,000-30,000 tokens | 充裕 |
在拥有大量相关文件的大型代码库中，将探索任务委托给子 agent 的效率提升最为显著。
降低 Token 消耗的技巧
以下习惯可在典型工作流中减少 30-60% 的 token 用量：
明确指定要读取的文件。 "读取 src/auth/session.ts，特别是
refreshToken函数"，而不是"读取 auth 模块"。在不相关任务之间使用
/clear。 开始新任务前清除 30,000 tokens 的无关对话，在 API 计划下可节省真实的成本。主动压缩 context。 在 context 达到 50% 时压缩，比等到 90% 再压缩能产生更好的摘要。
用子 agent 处理探索任务。 一个读取 20 个文件的子 agent 消耗的总 token 数相同，但可以将其中 80% 的 token 隔离在主 context 之外。
保持 CLAUDE.md 简洁。 CLAUDE.md 的每一行在每次 session 开始时都会消耗 token。一个 400 行的 CLAUDE.md 每次 session 可能消耗约 3,000 tokens——每月 100 次 session 就是 30 万 tokens 的纯开销。
避免重复读取未变更的文件。 如果 Claude 在本次 session 中已读取过某个文件，直接引用其中的信息，而不要要求 Claude 重新读取。
用
/btw进行快速查询。 在/btw浮层中回答的快速参考问题，不会消耗任何主 context token。