Claude Code 速度优化指南：定位慢会话并提升实际工作效率

Claude Code 变慢时，不要第一时间怪模型。更常见的原因是会话历史太长、文件探索范围太大、测试日志太吵、以及提示词没有说明哪些目录不该读。本站的日常内容生产也踩过这个坑：写文章、翻译、构建、部署和排错都塞进同一个会话后，响应会越来越慢，判断也会变得模糊。后来我改成先看 /usage 和 /context，再按阶段 /compact。这篇文章面向刚开始使用 Claude Code 的开发者，讲清楚如何诊断速度问题、如何限定读取范围、CLAUDE.md 应该写什么、子代理适合处理什么，以及哪些做法会让速度更糟。

调整之前先诊断

第一步是诊断。/usage 是当前使用情况的入口：API 用户能看到会话 token 和本地估算费用，订阅用户会看到套餐使用条和使用归因。它适合作为工作仪表盘，但最终账单仍应以 Console 为准。第二步看 /context。它能帮助你判断上下文被会话历史、内存、MCP、工具定义还是其他指令占用了。如果真正的负担是 MCP 或过大的 CLAUDE.md，单纯切换模型并不能解决问题。第三步是带目标地 /compact。不要只输入命令就结束，而要说明保留哪些内容：修改文件、失败测试、决策、未解决问题。这样压缩后仍能继续工作。

# Run these inside Claude Code before changing the workflow
/usage
/context
/compact Preserve changed files, test failures, decisions, and open questions

建立快速的默认工作流

我的基本流程是：重任务开始前看 /usage 和 /context；阶段结束时带说明执行 /compact；切换到无关任务时使用 /clear。清空不是失败，而是避免旧上下文污染新任务。然后限制 Claude Code 的阅读范围。不要说“理解整个项目再修复”，而是指定先读哪些文件、运行哪个测试、不要扫描哪些目录、最后返回哪些证据。最后保持 CLAUDE.md 精简。官方 memory 文档强调，CLAUDE.md 应放每个会话都需要知道的事实。很长的流程、低频 playbook、特定领域规则，应该放到 rules 或 skills 中，避免每次请求都背着它们。

claude -p "Fix only the null-check bug in src/api/auth.ts.
Read src/api/auth.ts and tests/auth.test.ts first.
Do not scan node_modules, dist, coverage, or unrelated feature folders.
Return the changed files, commands run, and remaining risks."

CLAUDE.md 只放每次都需要的事实

下面的例子故意写得很短。它只给 Claude 一个稳定的仓库地图，而不是把 memory 变成永久资料库。

# CLAUDE.md

## Project commands
- Build: npm run build
- Test: npm run test
- Type check: npm run typecheck

## Fast navigation
- API code: src/api/
- UI components: src/components/
- Tests: tests/

## Do not read unless explicitly requested
- node_modules/
- dist/
- coverage/
- .wrangler/

## Compact instructions
When compacting, preserve changed files, failing tests, decisions, credentials policy, and next actions.

用小基准测试衡量

不要只凭感觉优化。用宽泛提示和限定范围提示各跑一次同类任务，再比较耗时、读取文件数量和最终证据质量。

$runs = @(
  @{ Name = "wide"; Prompt = "Find and fix the auth bug in this project" },
  @{ Name = "scoped"; Prompt = "Fix the null-check bug in src/api/auth.ts only" }
)

foreach ($run in $runs) {
  $elapsed = Measure-Command { claude -p $run.Prompt }
  [pscustomobject]@{
    Name = $run.Name
    Seconds = [math]::Round($elapsed.TotalSeconds, 1)
  }
}

三个实用场景

小型 bug 修复

只给目标文件、失败测试和验收条件。这样探索会从几十个文件下降到少数几个文件，修复后的复核也更快。

大型重构

把任务拆成调查、修改、测试、审查四步。每一步结束后压缩，只保留决策和未解决点，不把原始探索日志带到下一阶段。

文章与翻译流水线

把翻译、页面列表检查、批量验证交给子代理。主会话只保留选题、最终判断、发布确认和风险记录。

团队落地时的判断标准

速度优化不能只看少了多少秒。Claude Code 的实际速度由等待时间、探索次数、返工次数和验证成本一起决定。一次回答快了二十秒，但漏掉关键测试，最后需要半小时返工，这不是优化，而是把成本推迟了。

我建议先连续记录一周轻量日志：任务类型、开始时间、最初允许读取的文件数、运行过的验证、执行 /compact 的位置、最后残留的风险。只要有这些字段，就能看出慢在哪里。如果每次都在找同一类目录，说明 CLAUDE.md 缺少地图；如果每次都读巨大日志，说明需要 hook 或命令行过滤；如果每次都重新解释业务前提，说明 memory 设计不够好。

对新手来说，最安全的第一步不是改复杂设置，而是统一 prompt 模板。每次写清楚目标、允许读取范围、禁止读取范围、完成条件、验证命令和最终报告格式。这个模板看起来很朴素，但能明显减少 Claude 的迷路时间。

团队使用时，还要把速度和证据绑定。最终回复应包含修改文件、执行命令、验证结果和未确认风险。这样速度提升不会牺牲质量，也方便下一位开发者或代理继续接手。

需要避免的失败案例

第一个坑是把 /compact 当成万能加速按钮。如果不说明要保留什么，失败命令或设计理由可能在摘要里变淡。
第二个坑是把 CLAUDE.md 写成仓库。旧事故、个人偏好、低频流程全部放进去，会让每次会话都付出额外成本。
第三个坑是为了速度删除验证。正确做法不是不看日志，而是只保留失败片段、期望结果和复现命令。

已确认的官方文档

Claude Code costs and /usage: https://code.claude.com/docs/en/costs
Claude Code monitoring and telemetry: https://code.claude.com/docs/en/monitoring-usage
Claude Code memory and CLAUDE.md: https://code.claude.com/docs/en/memory

本次重写确认的内容

本文已按 Claude Code 当前 Costs、Monitoring、Memory 官方文档重写，核心从旧的 /cost 习惯转向 /usage、/context、/compact、CLAUDE.md 和限定范围提示词。

下一步

如果团队想让 Claude Code 更快，不要先购买更大的模型或增加自动化。先标准化提示词形状、memory 文件和验证回执。下面的内部链接延续同一套操作模型。