根据 Red Hat 对 219 个真实会话的分析，Claude Code 有四分之三的 token 预算仅用于读取代码库。这一发现颠覆了“AI 驱动的编程代理在生成代码上浪费时间”的常规假设，并表明开发者应该解决上下文管理问题，而不仅仅是关注模型速度。

这一结论背后的数据

Red Hat 研究了与 Anthropic 的 Claude Code 的 219 次交互，并计算了每轮交互的 token 使用量。在样本中，中位数的交互分配了 75% 的 token 用于摄取周围的代码和文档，而只有 25% 用于生成新行。由于大多数 AI 提供商对输入和输出 token 的计费速率相同，因此交易中的“读取”部分驱动了大部分成本。

为什么读取成本至关重要

优化策略

许多团队投入资源追求更快或更大的模型，希望通过速度提升来缩短每次生成的秒数。如果四分之三的工作仅仅是拉取上下文，那么更快的模型只能节省一小部分总时间。真正的杠杆在于模型每轮交互需要处理多少上下文。

成本控制

当 AI 助手在每次请求时都重新读取相同的代码库状态时，输入 token 会激增。具有大上下文窗口的项目可能会看到账单大幅增加，即使生成的代码量保持适中。

工程重点

工具构建者往往追求更高的模型质量，却忽视了 prompt（提示词）是如何构建的。分析表明，“上下文工程”（即对喂给模型的代码进行修剪、缓存和摘要）比增量式的模型升级能带来更高的 ROI。

遏制读取开销的实用步骤

  • 修剪无关文件 – 从 prompt 中移除当前任务不需要的文件。更小的 prompt 意味着更少的输入 token。
  • 缓存重复读取 – 存储模型对代码库稳定部分的理解，并在不同轮次中重复使用，而不是重新发送相同的文本。
  • 压缩工具输出 – 当外部工具返回大型数据块（例如 lint 报告）时，在将其反馈给 Claude 之前先对其进行摘要处理。
  • 使用增量 diff – 仅发送自上次交互以来的更改，而不是整个文件的内容。

这些策略旨在防止 AI 在每次交互时都重新读取相同的代码库快照，从而降低延迟和成本。

反论：速度依然重要

一些开发者认为，更快的模型仍然很重要，因为它降低了那 25% 已生成 token 的延迟。在对延迟敏感的环境中（例如必须立即响应的 IDE 插件），每一毫秒都至关重要。以读取为主的特征并不会消除快速模型的优势，它只是降低了其相对影响。

下一步值得关注的方向

Red Hat 的研究基于有限的会话集，因此更广泛的采样可能会揭示其他语言或项目规模的不同 token 分布。如果未来的数据证实了 75% 的读取比例，我们可能会看到工具向自动修剪和缓存上下文的方向转变，甚至出现针对快速上下文摄取而优化的模型架构。

核心结论： 对于 AI 辅助编程，最廉价的性能提升来自于减少喂给模型的内容，而不是让它写得更快。Red Hat 的数据提出了一个明确的论点：修剪、缓存并摘要你的 prompt，你将在时间和金钱上看到切实的节省。