Cursor涨价40%背后：一个程序员的账单复盘

三月某个周二早晨，我收到一封邮件。主题栏写着："Cursor订阅更新"。

心里一沉。我从早期就开始用Cursor，那时候它还只是VS Code的一个分支，加了些巧妙的LLM集成。当时觉得像魔法。现在感觉像在交房租。

新定价从固定月费改成了"计算单元"制。重度用户如果不改习惯，成本要涨40%。我花了一周审计自己的使用情况：查日志、测替代品、优化工作流。以下是原始数据，以及你应该如何准备。

数字不会说谎

先看实际变化。2026年3月1日之前，我付20美元/月买Pro套餐，享受无限快速请求和充足的慢速请求额度。

现在Pro套餐还是20美元，但只包含500个"计算单元"（CU）。每个CU代表特定数量的上下文处理和生成。

以下是我2月和3月的用量对比：

超额费用打得我措手不及。我没意识到多少后台进程在消耗CU。大文件的自动补全建议、后台索引，都算进额度里。

我不是个例。我的技术负责人也遇到了类似 spike。我们团队六个开发者，集体账单从120美元涨到近350美元。对初创公司预算来说，这不可持续。

上下文膨胀如何杀死预算

最大的元凶不是我写的代码，是我发送的上下文。

2024和2025年，我们变懒了。整个文件往聊天里丢。@Codebase功能随便用，假设AI能自己搞定。旧定价隐藏了这种低效——你可以浪费，不受惩罚。

新模式对token体积惩罚很重。现在把2000行文件丢进去问个简单问题，成本是以前的十倍。

3月5日我做了测试，让Cursor重构一个React组件。

尝试1（偷懒版）：

用@Codebase，让它扫描整个项目文件夹。

- Token用量：12,500

- CU消耗：45

- 结果：正确，但昂贵

尝试2（优化版）：

手动只选相关三个文件，贴进上下文。

- Token用量：1,800

- CU消耗：6

- 结果：正确，速度一样

差距惊人。精准操作让我单次交互省了86%成本。乘以每天数百次交互，你就知道钱去哪了。

大多数开发者没这么做。我们被训练得偷懒，因为工具过去奖励偷懒。那个时代结束了。

本地优先工作流的崛起

价格冲击逼我去找别的出路。我没法硬扛成本，开始重新测试本地模型。

两年前，本地模型太慢或太蠢。2026年，它们能覆盖80%的任务。

我在M3 MacBook Pro上搭了Ollama，跑最新的Llama-4-8B模型。完全离线运行。代码补全延迟约800毫秒——比Cursor慢，但不用按token付费。

关键发现：我把80%的机械性工作（简单重构、写测试、文档）转到本地模型。剩下20%需要深度推理的复杂任务，才用Cursor的云端Claude-4。这样混合使用，我的CU消耗降到了新限额以内。

团队正在评估统一方案。有人提议全员本地+共享一个Cursor企业账号做复杂任务。我们还在算这笔账。

行业正在分裂

这次定价调整不只是Cursor的事。它标志着AI编码工具市场的成熟。

低价无限时代结束了。提供商开始按实际计算成本收费。这对重度用户是阵痛，对行业是健康调整——它迫使开发者思考效率，而不是无脑消耗资源。

我的建议：现在就审计你的用量。找出那些@Codebase的滥用、那些整文件粘贴的习惯。本地模型已经够好，值得认真考虑混合方案。

2026年的开发者需要新技能：不是写更多提示词，而是写更精准的提示词。不是用更大的上下文，而是用更聪明的上下文。

工具变了，我们也得变。