我 25 天在 Cursor 大号上花了 3018.98 美元

这是一份 Cursor 使用分析报告的整理。

统计周期是 2026-05-01 到 2026-05-25。这里先说明一下：这只是我 Cursor 大号的用量，不包括 ChatGPT Plus、Claude Pro、Cursor 小号 Pro，以及其他零散的 AI 工具使用。

我的感受是：我不是没有用好 Cursor，而是用得太顺手了。

25 天里，我基本把 Cursor 放进了日常工作的主流程：查代码、改代码、写文档、做方案、复盘日志、整理报告，很多事情都会先问它。问题也很明显：只要习惯变成“顺手就用”，模型档位和上下文范围就容易失控。

先看数据

按活跃日算，每天大约 79 次交互、126 美元成本。

这不是“偶尔问几个问题”的用法，而是把 AI 放进了工作流主干。

报告给我的标签是：深度用户、探索型、高风险。

“深度用户”很好理解：我用得多，场景也多。“探索型”也准确：我在 10 种模型之间来回试，什么任务都想看看哪个模型更顺手。

“高风险”不是说安全风险，而是成本结构风险：同样一件事，我可能用了过重的模型、过长的上下文、过深的推理档位。

钱主要花在三个地方

这份报告有用的地方，是把钱花在哪里拆出来了。

第一，Opus 用得太顺手

我的模型费用里，Opus 旗舰模型占了 76.3%。

其中 claude-opus-4-7-thinking-xhigh 一项就用了 1,039 次，花费 $2216.16，占我总费用的 73.4%。它的单次均费是 $2.133。

对比一下：

Opus 很强，尤其适合跨文件推理、复杂方案设计、长链路排障、对混乱上下文做判断。但问题在于，我并没有严格区分“必须用 Opus 的任务”和“普通模型足够的任务”。

很多时候，我是默认相信贵模型，懒得切。

这里的问题不是“不知道便宜模型能做”，而是切模型本身也要判断。懒得判断，就容易默认用最强的。

第二，Thinking 开得太多

我的 Thinking 费用占比是 77.0%，事件占比是 61.1%。

Thinking 模式的价值在于让模型多做推理，适合设计、排查、解释复杂系统。但如果只是改一段文案、整理一段 Markdown、写一个简单脚本，Thinking 往往不是必要条件。

报告里对 Thinking 的判断也比较明确：它不是不能用，而是应该当作“推理增强档”，不是默认档。

我之前的使用方式更像是：

只要不确定，就上 Thinking。

更合理的方式应该是：

只有任务真的需要多步推理时，才上 Thinking。

这两个习惯只差一个开关，月底账单会差很多。

第三，超长上下文吞掉了大头

我个人最贵的问题不是 Max Mode。事实上，我的 Max Mode 费用占比是 0。

花钱最多的是超长上下文。

报告显示，我有 387 条超过 2M Token 的事件，费用 $1899.62，占个人总费用 62.9%。

粗算一下：

• 超长上下文事件：387 次，约 $4.91 / 次
• 非超长上下文事件：1511 次，约 $0.74 / 次

也就是说，一次超长上下文请求的平均成本，大约是普通请求的 6.6 倍。

这解释了为什么有时候明明只是“让 AI 看看这个问题”，账单却突然跳得很快。Cursor 能吃很多上下文，但不代表每次都要把上下文塞满。

我以前经常把“上下文给足”理解成“尽量多给”。现在看，应该改成：

上下文要够，但不能无脑大。

Cache 用得不错

这份报告里，我最不需要改的是 Cache。

我的 Cache 命中率是 94.1%。这说明我至少有一个习惯是对的：同一个任务会尽量在同一个 Chat 里持续推进，而不是每个小问题都开新会话。

Cursor 的长会话如果维护得好，后续交互会大量命中 Cache Read，既省钱，也让模型更理解上下文。频繁新开 Chat 的问题是，每次都要重新解释背景，既浪费时间，也浪费 token。

所以我对自己的结论不是“少用 Cursor”，而是：

保持会话连续性，但减少无意义的大上下文。

后面准备怎么改

我不准备减少 Cursor 的使用，而是改掉几个明显费钱的习惯。

规则一：先分任务，再选模型

以后每次打开 Cursor，先判断任务类型：

• 简单改文案、补类型、改样式：用 Auto、Composer 或轻量模型。
• 日常自动化、批量整理、固定格式转换：交给能用的最便宜模型。
• 单文件/少量文件改造：用 Sonnet 或 GPT 中档。
• 跨模块重构、复杂 Bug、方案设计：用 Opus high。
• 真正需要长链路推理、风险很高的判断：再考虑 Opus xhigh。

模型不是身份象征，是工具档位。

规则二：工具类任务尽量 CLI 化、Skills 化

如果一个任务会重复出现，就不要每次都重新写 Prompt。

比如周报、代码检查、日志分析、文章发布、数据清洗、固定格式报告，这类事情应该尽量沉淀成 CLI 命令、脚本或者 Skill。人的工作是定规则和验结果，不是每次把同一段背景重新讲一遍。

这样做有两个好处：

• 输入更短，不需要反复解释上下文。
• 模型可以更便宜，因为流程已经被代码和 Skill 固化了。

规则三：可编排任务考虑 Cursor SDK

Cursor 已经有 SDK 了，后面一些“让 AI 按流程完成任务”的场景，可以不只停留在手动 Chat 里。

比如把一个需求拆成：读取仓库、定位文件、修改代码、跑测试、生成总结。过去这类事情更像一次手动对话；有 SDK 之后，可以用脚本把 Agent 调起来，让它在固定目录、固定模型、固定检查步骤里跑。

这类场景不一定要上最贵模型。日常自动化可以先用便宜模型，只有在失败、需要复杂判断、或者要做最终 review 时，再切到更强的模型。

规则四：先让 AI 找范围，再让 AI 深入读

以前我容易一上来就把大范围上下文塞给 Cursor。

更好的流程应该是两步：

1. 先让 AI 根据文件名、目录结构、关键词搜索判断可能相关的范围。
2. 再把真正相关的文件和片段交给强模型深入分析。

这相当于先做范围收敛，再用强模型做判断。

很多超长上下文其实不是因为任务复杂，而是因为我偷懒跳过了“缩小范围”这一步。

规则五：Thinking 只给需要推理的任务

Thinking 很适合这些场景：

• 多因素权衡的架构设计
• 难复现 Bug 的根因分析
• 跨文件行为链路梳理
• 安全、稳定性、成本相关的判断
• 需要反驳自己方案的 review

但它不适合当万能默认值。

如果任务只是“把这段整理成更通顺的中文”，我不需要一个旗舰模型在后台展开长链路推理。

规则六：把一次好对话沉淀成模板

报告说我是“探索型”。这个标签挺准：我愿意试，也容易试过头。

下个月我想做的不是减少探索，而是把有效探索沉淀下来：

• 好用的 Prompt 变成模板。
• 常见任务形成模型选择规则。
• 长上下文任务先写检索步骤。
• 每周回看一次最贵的几条请求。

我想保留探索，但不想每次都从零开始试。

我的下月 Cursor 使用策略

如果把这次复盘变成行动清单，我会这样改：

1. 默认不从 Opus xhigh 开始。 除非明确是复杂推理任务，否则先用中档模型。
2. 超过 2M Token 的任务必须停一下。 先问：能不能拆文件、拆阶段、拆问题？
3. 一个任务一个 Chat。 保留 Cache 优势，不把 unrelated 的事情混在同一个会话里。
4. 重复任务先做成 CLI 或 Skill。 不把固定流程反复交给高价模型自由发挥。
5. 自动化任务优先用便宜模型。 只有失败重试、复杂判断和最终 review 才升级模型。
6. 适合编排的任务尝试 Cursor SDK。 把“让 AI 实现一个任务”从手动对话变成可复用脚本。
7. 复杂任务先写计划，再动手。 先用 AI 列搜索范围和验证方式，再让它写代码或报告。
8. 月底复盘 Top 10 最贵请求。 不只看花了多少，还看那次请求是否真的值得。

我不想把 Cursor 当成一个必须压缩的成本项。它确实提高了我的判断速度、试错速度和表达速度。

但用得粗，它就会把“懒得判断”变成账单。

最后

过去我们评价一个工程师怎么用工具，常常看效率：写得快不快、查得准不准、交付稳不稳。

AI 编程之后，还要多看一层：你有没有把任务复杂度和模型成本匹配起来。

我的 5 月账单不低，而且这还只是 Cursor 大号。再加上 ChatGPT Plus、Claude Pro、Cursor 小号 Pro，AI 工具已经不是“偶尔试用”的支出，而是一项长期的工作成本。

真正要改的不是“少用”，而是“分层使用”。

下个月，我希望看到的不是 Cursor 使用次数下降，而是这三个数字下降：

• Opus xhigh 占比
• Thinking 默认开启比例
• 超长上下文费用占比

如果这些下降了，而产出没有下降，那说明模型调度这件事开始变得像样了。