1,064,143,356 个 token：我如何使用 Cursor，以及第一个十亿教会了我什么

@nevsky

查看 @nevsky 的 Cursor 个人资料。

Cursor

当我打开自己的 Cursor 公开资料，看到大约 11 亿个 token时，连我自己都觉得这个数字很惊人。我确实大量使用 Cursor，有时一连好几个小时，但一个月十亿还是让我思考：这是高强度 AI 工作的正常规模，还是我只是在毫无意义地让模型反复搬运巨大的上下文？

为了弄明白，我导出 Usage CSV，查看消耗构成。这里的内容远比资料页上的一个大数字有意思。十亿个 token 本身几乎不能说明工作效率：关键在于它们是什么 token、被哪些模型使用，多少是新上下文，多少只是 Cursor 从缓存中重新读取的内容。

十亿个 token 里面有什么

我的导出文件里有 725 条独立用量事件，总计 1,064,143,356 个 token。其中约有 9.898 亿，即 93%，属于 Cache Read（缓存读取）。普通 Input 约为 6310 万，Cache Write（缓存写入）为 460 万，而模型直接生成的 Output 只有 660 万个 token.

这个比例相当不寻常。表面上是超过十亿个 token，但只有约 6% 是新输入，模型实际生成的文字和代码不到总量的 1%。绝大多数是 Cursor 以前已经见过、又通过缓存重新交给模型的上下文。

这就解释了数字为什么这么大。我经常使用很长的 Agent 会话，模型在同一个项目上工作数小时：查看文件、修改代码、运行应用、修复错误，再回到项目中已经熟悉的部分。上下文始终随着会话一起流转，即使其中很大一部分已经被缓存。

哪些模型消耗最多

消耗最多的是 Grok 4.6 High——约 5.957 亿个 token，超过我总用量的一半。接下来是 Composer 2.5，2.647 亿，然后是 Claude Fable 5 Thinking——约 1.51 亿。其他模型只占相对很小的一部分。

也有个别用量特别高的日子。 8 月 14 日——1.853 亿个 token，8 月 13 日——1.848 亿，8 月 18 日——1.446 亿。仅 8 月 13 日和 14 日，就有约 3.7 亿个 token 经过 Cursor。

同时，CSV 中只有 17 个活跃日，因此在真正使用 Cursor 的日子，日均用量约为 6260 万个 token。到了这个规模，已经很难只把 Cursor 看作带智能补全的代码编辑器。对我来说，它越来越像一个工作环境，多个 AI 模型在其中实际承担了相当大一部分工程工作。

十亿个 token，额外花了 20 美元

分析中最出乎意料的是费用。Cursor Dashboard 在同一时期显示约 9.489 亿 Total Tokens（总 token 数），其中 9.462 亿计为 Included（套餐内） ，只有 270 万计为 On-demand（按需付费）.

我在 CSV 里只找到五条付费 On-demand 事件，总计大约 20.43 美元额外费用。也就是说，我的确在高强度使用 Cursor，但如此巨大的用量几乎全都包含在套餐或免费用量中。

之后，“怎样减少 token 数”这个问题对我的吸引力大大降低。如果系统允许处理数亿 token，却不让费用同比增长，那么该优化的就不是计数器本身。更重要的是：长上下文会不会随着时间推移降低 Agent 的工作质量。

什么时候长会话有用

我最长的一次 Agent 会话持续了大约 九个小时，但这个数字本身现在已不让我害怕。如果 Agent 一直在做同一个大任务，累积的上下文反而有帮助。它了解架构，记得之前的决定，见过那些错误，也理解为何某些实现方案被否决。

比如，如果要彻底重做首页，把整个周期放在一个聊天里完全合理：研究现有实现，提出新结构，编写组件，适配移动端，运行项目，在浏览器检查页面，找出问题，完成最终打磨。每次小改动都开新聊天，在这里反而碍事。

问题不在会话变长时开始，而在于 任务已经变了，旧上下文却还跟着走。如果做完首页，接着做房源列表，然后切到 SEO、Cloudflare，又突然在同一段对话里接入 Telegram，Agent 就会收到海量信息：形式上都属于这个项目，却已经几乎与当前任务无关。

一个聊天，一个完整任务

由此得出我的主要结论：不是一个提示词一个聊天，也不是一个项目一个聊天，而是一个完整工作单元一个聊天。

首页可以有自己的 Agent 会话，经纪人板块另开一个，房源列表再开一个。基础设施迁移、SEO、Telegram 集成，或某个独立的大型 API 问题，也各有自己的对话。而在这样的每次会话里，进行几十轮迭代、待上几个小时，完全正常。

边界不在消息之间，甚至不在文件之间，而在任务意义之间。如果 Agent 做好了房源卡片，还要微调移动端布局、hover 或间距，仍是同一任务。如果做完卡片后决定彻底更改目录筛选架构，就该考虑新开会话了。

我给自己定了个简单的信号。如果下一条请求大致以 “那接下来再做一下……”，就值得检查：这究竟是在延续当前任务，还是已经开启下一项。

新聊天不该意味着失忆

自然会有一个问题：如果经常新开会话，怎样才能不用每次都向 Cursor 重新解释项目结构、设计规则和技术限制？

答案是，常驻知识本来就不应该只存在聊天历史中。为此有 Project Rules、User Rules 和 AGENTS.md。项目架构、技术栈、命名、目录结构、设计规则、限制、启动命令、响应式要求，以及 Agent 无论做什么任务都应知道的内容，都适合放到这里。

这样，新聊天就不再是重启项目，而只是 清理工作记忆。基础知识仍在，而几十个旧的中间决定、错误和讨论，不再占用当前上下文。

我觉得，在高强度 AI 工作中，这个区别尤其重要：一边是 项目的长期记忆，另一边是 具体任务的工作记忆。没必要把两者混在同一场无尽对话中。

大任务值得先规划

小改动我通常直接让 Agent 开干，但大任务适合先用 Plan Mode。如果改动涉及许多文件、多个系统部分，或需要架构决策，花几分钟提前研究，能让后续实现轻松很多。

例如，与其命令“重做房源系统”，不如先让 Agent 研究现有架构、数据、路由和依赖，再请它制定具体计划。检查计划后，再进入实现。

这能降低一种常见风险：AI 飞快写完最初 30–40%，随后发现架构限制，又开始重写自己的成果。功能越大，就越值得把两个阶段分开：理解任务 和 编写代码。

Subagents，像一支小团队

真正的大任务还有另一个层级—— Subagents。主 Agent 可以保留总体任务，将独立研究交给拥有各自上下文的专门智能体。

比如，主 Agent 负责新的房源系统。一个 subagent 研究现有架构，另一个检查 API 和数据，第三个做代码审查，第四个专门找移动端和无障碍问题。主 Agent 不必保存这些研究的每一步中间操作，它需要的是结论。

于是工作模式发生一点变化。不再是一个巨大的 AI 聊天，而是类似小团队的结构，主 Agent 担任协调者，汇总各个专家的结果。

代码还不算结果

另一个结论关于会话的结束。Agent 说“代码写好了”的那一刻，我越来越不认为任务已经完成。

正常工作流程还应该继续：实现、运行、检查结果、查找错误、修复、再次检查。对界面尤其如此：改动在代码里可能看起来正确，却在浏览器或某个屏幕宽度下崩坏。

如果 Agent 能访问浏览器、控制台日志和网络流量，就应该让它自己使用这些工具。生成代码只是中间阶段，最终成果应该是可用、经过验证的功能。

怎样判断旧聊天该关了

我不觉得有必要设定“每小时开新聊天”或“达到某个 token 数必须重置”之类的人为限制。会话时长本身并不能说明上下文质量。

但退化的迹象通常很明显。Agent 开始忘记已约定的限制，重复询问已经回答过的问题，动到与任务无关的文件，带回之前修好的错误，或与自己的决定矛盾。有时原因更简单：当前工作已经离最初任务太远。

这时，只要长期上下文已妥善放进项目规则，新聊天就不是丢掉累积知识，而只是给模型一个干净空间，去解决下一个问题。

我使用 Cursor 的工作循环

最后，我形成了一个相当简单的顺序：

任务 → 规划 → 构建 → 验证 → 提交 → 新聊天

先明确一个任务。大任务则单设规划阶段。接着 Agent 研究项目、实现方案，然后自行检查结果，修复发现的问题。一个完整工作单元验证通过后，就可以提交 commit，在新会话中进入下一任务。

常驻知识保存在 Rules 和 AGENTS.md，必要时把独立的大型研究交给 Subagents。这样，不仅软件项目本身有架构，与 AI 交互的过程也有了架构。

第一个十亿教会了我什么

最初， 1,064,143,356 个 token 看上去像是我使用 Cursor 极其低效的证据。拆解用量后，结论几乎相反：约 93% 是 Cache Read，真正的 Output 不到 1%，这段时间额外的 On-demand 费用只有约 20 美元。

所以，我的目标绝不是不惜代价减少用量。如果大量计算能把过去需要几周的工作压缩到几天，token 计数器本身就不是问题。

该优化的是 上下文质量、任务边界，以及 Agent 独立把工作推进到经过验证的结果的能力。也许，这里正在发生的变化，比提示词工程的又一次改进更重要：我们逐渐不再学习如何与单个模型对话，而是开始学习 把 AI 智能体作为一套完整的工作系统来管理。