Cursor套餐与计费解析：Pro、Pro+、Ultra选档指南

1. Cursor 是什么：先把“编辑器”和“AI 算力”分开看

上周有个做后端的哥们儿在群里贴了张截图，问我 Cursor 这玩意儿到底该怎么买——他试用期结束，弹出来三个选项：Pro、Pro+、Ultra，价格从二十美元一路顶到两百美元，中间还夹着一堆“额度”“用量”“按量计费”的小字。他说自己看了半天定价页，越看越糊涂。

这事儿挺典型。很多人第一次接触 Cursor，脑子里先冒出来的类比是“VS Code 装了个 AI 插件”。这个类比只对了一半，而且对的那一半恰恰最容易让人在账单上翻车。对的部分是：Cursor 的操作方式、快捷键、侧边栏布局、插件生态确实和 VS Code 高度接近，你几乎不用重新学怎么开文件、怎么打断点、怎么跑终端命令，迁移成本低到可以忽略。错的部分是：它不是一个买断制的软件授权，而是一份“编辑器加每月一定额度模型调用”的打包订阅。你付的钱里头，一大半买的是推理算力，只有一小部分买的是那个 IDE 外壳。

想明白这一点，很多困惑就自动解开了。比如为什么同一个编辑器，有人每月二十美元用得舒舒服服，有人一个月账单能翻十倍；比如为什么官方要把套餐切成三档而不是一刀切；比如为什么你明明没敲几行代码，额度却掉得飞快。这些问题的答案都不在编辑器里，而在计费模型里。

这篇东西就是想把 Cursor 的套餐结构和计费方式拆开讲清楚，顺带把我自己在选档、控量、避坑上踩过的东西摊出来。从没碰过的新手能看懂它到底在卖什么，已经在用的老用户能对着算一遍自己该不该升档。

1.1 它真正解决的是“上下文搬运”这件苦差事

要理解 Cursor 的价值，得先回到日常写代码最烦的那部分。写代码这件事本身其实不算最累，累的是围绕代码的那些搬运工作：改一个函数签名，得顺着调用链一个个文件找过去；接手一个陌生仓库，得花半天时间搞清楚入口在哪、数据怎么流；写一个 CRUD 接口，样板代码翻来覆去那几段，写完还得自己检查字段名有没有拼错。

传统 IDE 的补全只能看到当前文件的几十行，它不知道你三个目录之外还有哪些引用。Cursor 的核心能力就是把这个“视野”撑开——它能把整个仓库建索引，让你用自然语言描述意图，它去定位相关文件、组织上下文、生成改动。所以你会发现它最出彩的场景几乎都是“跨文件”的：重命名重构、给老代码补测试、把一个模块的逻辑迁到另一个框架下。单文件的小补全反而是它最不起眼的功能。

这里有个关键概念值得单独拎出来说：上下文工程。模型生成质量好不好，很大程度取决于喂给它的上下文里有没有真正相关的那几段代码。Cursor 的价值有很大一部分体现在“帮你挑上下文”这件事上——索引、检索、把相关片段塞进窗口、控制窗口别爆掉。而这也正是钱花得最快的地方：上下文越长，token 越多，成本越高。你让它读二十个文件，和让它读两个文件，账单完全不是一个量级。

1.2 为什么要分三档而不是一刀切

从平台的角度看，AI 编程工具的成本结构非常畸形：绝大多数用户用量很小，少数重度用户能吃掉不成比例的算力。如果只有一个统一价格，结果必然是轻度用户在补贴重度用户。短期内看不出来，时间一长，重度用户越聚越多，成本就会失控。

所以三档套餐的设计逻辑不是“功能阉割”，而是用量分层。三档里的编辑器功能基本一致，差别主要在额度规模、可用模型的档位、以及在超出额度后的处理方式上。这跟健身房卖月卡和私教课是一个道理：进场权限一样，但你练多久、请不请教练，价格差得远。

理解了这层，选套餐的思路就变了。你不再需要问“哪档功能更全”，而要问“我一个月到底会用掉多少算力”。这个问题不好拍脑袋，得靠数据。后面第 4 节我会给一套具体的采样和估算方法。

提示：本文里出现的具体价格和额度数字，是我整理时在官方定价页上看到的那一版，进入 2026 年之后官方大概率还会调。下单前务必自己打开定价页核对一遍，别拿旧数字做预算。

2. Pro、Pro+、Ultra 三档套餐逐一拆解

三档套餐的名字起得很直白，但真正的差异藏在细节里。我按“谁适合用、能给什么、什么情况下会不够”这个顺序一档一档讲。

2.1 Pro：绝大多数个人开发者的起点

Pro 是最主流的一档，月费大致在二十美元这个量级，年付通常能打到八折上下。它给的东西可以概括成三块：完整编辑器能力、每月一笔模型调用额度、以及额度用完之后继续可用的降级通道。

先说额度。这一档附带的额度规模大致和月费本身等价，也就是你花二十美元，拿到大约二十美元等值的模型调用量。这个设计其实是把“订阅”和“预付费”揉在了一起——你既是订阅用户，又像是往账户里充了一笔钱。

再说降级通道。这是 Pro 最容易被忽略、但实际最重要的一个特性：额度用完之后，你并不是完全不能用了，而是会掉到一个较慢的队列里，或者切到成本更低的模型上继续工作。这意味着 Pro 实际上是“有成本上限”的——你再怎么造，也不会突然冒出一张几百美元的账单。

什么人适合 Pro？我的判断标准很简单：如果你每天写代码的时间里有 30% 到 50% 在和 AI 交互，主要用它做代码补全、单文件改写、偶尔的跨文件小重构，那 Pro 基本够。真正会用超的人，通常是那种把 Agent 模式当主力、一开就是几十轮自主循环的重度玩家，或者天天让它读大仓库做全局分析的架构角色。

有个细节值得注意：Pro 档在模型选择上通常会有一些限制，成本最高的那几个推理模型要么用不了，要么会以更高的倍率消耗额度。如果你特别依赖高端推理模型做复杂重构，光这一条就可能把你推向上一档。

2.2 Pro+：卡在中间的“缓冲档”

Pro+ 是后来才加进来的一档，月费大致落在六十美元这个量级。它的定位很明确——填 Pro 和 Ultra 之间那段巨大的价格鸿沟。二十美元到两百美元，中间差了十倍，这个跨度对很多“用量偏重但没到极端”的人来说太不友好了。

这一档给的额度大致是 Pro 的三倍上下，也就是六七十美元等值的调用量。同时在使用体验上会更宽松一些：高端模型的可选范围更大，超额后的降级也没那么难受。

Pro+ 最适合的人群我觉得是全职靠 AI 辅助写代码的独立开发者。这类人一天六七个小时泡在编辑器里，Agent 模式用得频繁，但又没到“同时开三个项目、让 AI 跑长链条任务”的程度。他们用 Pro 会在月中就见底，用 Ultra 又明显浪费——就像每天通勤三十公里的人，买辆续航六百公里的车确实没必要。

另一个容易被忽视的适用场景是小团队里的技术负责人。这类人自己不一定是代码量最大的，但要频繁做代码审查、理解别人写的模块、评估技术方案。这些任务的特点是一次性消耗大、但总次数不多，Pro+ 的额度规模刚好能覆盖。

2.3 Ultra：把 AI 当第二个工程师来用

Ultra 是顶配，月费大致两百美元。额度规模按倍数算，大致是 Pro 的二十倍量级，也就是四百美元等值上下的调用量。

这个价格听起来吓人，但换个角度算就不一样了：两百美元一个月，折合到每个工作日不到十美元。如果你用它替换掉一部分外包工作、或者省下每周几小时的机械劳动，账是算得过来的。真正的问题不是贵不贵，而是你有没有那个用量去把它吃满。买了 Ultra 却每月只用掉十分之一额度，那才是最亏的。

Ultra 的典型用户画像我观察下来有这么几类。一类是做大型重构或者技术迁移的，比如把一个跑了五年的老项目从一套技术栈搬到另一套，这种活儿动辄涉及几百个文件，Agent 模式一开就是长链条任务，额度消耗是普通开发的十倍以上。一类是做研究或者原型验证的，需要反复让模型生成、评估、再生成。还有一类是把 Cursor 当成“全天候结对伙伴”的独立开发者，几乎所有编码决策都要过一遍 AI。

需要提醒的是，Ultra 档在高成本模型上的限制最少，这既是好事也是坏事。好事是你想用什么就用什么，坏事是你很容易在不知不觉中把额度烧光，因为高倍率模型的消耗速度可能是普通模型的好几倍。用 Ultra 的人一定要养成看用量的习惯，不然月底那几天会很难受。

2.4 三档横向对比：一张表看清差异

这张表里我最想让人注意的是最后一行。很多人选档的时候只盯着“够不够用”，忘了算“用不用得满”。Pro+ 的尴尬在于它夹在中间，如果你用量刚好卡在 Pro 上限附近，升到 Pro+ 会有一大半额度闲置；Ultra 的尴尬则在于它的额度对大多数人来说根本吃不完，单位成本反而比 Pro 高。选档的本质是在“额度不够带来的摩擦成本”和“额度闲置带来的浪费”之间找平衡点。

3. 计费方式详解：钱到底是怎么花出去的

套餐价格只是账单的一部分，甚至是比较好懂的那部分。真正让人栽跟头的是计费机制。这一节我把三层结构拆开讲。

3.1 三层结构：订阅费、包含额度、超额按量

Cursor 的账单结构大致是三层叠加。

第一层是固定订阅费，按月或按年付，这部分是确定的，不会因为你用量少而退。

第二层是包含额度，订阅费里已经打包进去的那部分调用量。这部分用不完通常不结转到下个月，也就是月底清零。这一点很关键——如果你某个月出差了两周，额度就白白浪费了，这也是为什么年付虽然便宜但风险更高：你一次性锁定了一年的额度节奏，中间任何波动都自己扛。

第三层是超额按量计费。当包含额度耗尽后，不同档位的处理方式不一样：低档位通常是降速或强制切到便宜模型，高档位则允许你继续按实际用量扣费。这一层是最容易失控的，因为它没有硬上限。我见过有人开了按量计费又忘了关，月底收到一张远超预期的账单。

我的建议很直接：除非你对自己的用量有非常清晰的把握，否则不要随手打开超额按量扣费。宁可让它在额度用完时降速，也别给自己留一个无底洞。降速带来的体验损失是可预期的，账单失控带来的心理冲击是不可预期的。

3.2 从“按次数”到“按 token 额度”的转变

这里有个历史背景值得讲，因为它直接解释了为什么现在的计费看起来这么绕。

早期这类工具的计费方式很朴素：每月给你几百次“快速请求”，用完了就进慢速队列。这个模型对用户很友好，因为次数是可见、可数、可预期的。但它有一个致命问题：不同模型的成本差异被抹平了。你调用一个轻量模型完成一次补全，和调用一个高推理模型做一次跨仓库分析，都算“一次请求”，可实际成本可能差几十倍。结果就是用户会倾向于把所有任务都丢给最贵的模型，平台成本结构崩掉。

所以后来的调整方向很明确：改成按 token 用量折算额度。你消耗多少 token，就按对应模型的单价扣多少钱，额度用完了就是没钱了。这个模型更公平，但也更难懂——因为 token 是不可见的。你没法像数请求次数那样数 token。

这个转变带来的实际影响是：同样的操作，成本可能差十倍。举个具体例子，让模型回答“这个函数做什么”，可能只消耗几百 token；让它“读完这五个文件，把里面的重复逻辑抽出来重构成一个公共模块”，随随便便就是几万 token 起步，如果中间还有多轮 Agent 循环，翻十倍很正常。很多人抱怨“额度掉得莫名其妙快”，根源就在这里——他们用 Agent 模式做了几次大范围重构，这玩意儿是真烧钱。

3.3 团队版与席位计费：按人头算的坑

团队场景的计费逻辑和个人完全不一样，是按席位（seat）来的。每个席位有自己的月费和自己的额度池，管理员统一付费。

这里有几个坑得提前说清楚。

第一个坑是闲置席位。团队里总有人开了账号但基本不用，可席位费照收。我见过一个十几人的团队，实际天天用的不到一半，剩下那些席位纯属浪费。解决方法是定期清理，把连续一两个月零用量的席位停掉，需要时再开。

第二个坑是额度不共享。很多团队管理员以为团队额度是一个大池子，谁用得多谁用得多，实际上是各席位独立。这意味着某个重度用户额度用完后，没法从闲置同事那里“借”额度过来。

第三个坑是权限和计费脱钩。管理员往往能控制谁能用哪些模型，但很难精细控制谁花多少钱。你要是给全团队开了最高档模型的权限，账单会很难看。我的做法是默认只开中档模型权限，需要高端模型的单独申请，这样能挡掉大部分不必要的消耗。

4. 怎么算自己该买哪一档：一套可复现的估算方法

前面讲的都是机制，这一节讲怎么落地。选档这件事不能靠感觉，得靠数据。我给你一套我自己在用的方法，三步走。

4.1 第一步：做两周真实用量采样

不要拿试用期第一天的体验做判断。试用第一天你肯定在疯狂试功能，用量会虚高；试用第三周你可能已经过了新鲜劲，用量又会虚低。比较靠谱的做法是正经用两周，把每天的实际消耗记下来。

如果你已经在用某一档，可以直接在账户的用量页面看历史数据。如果还没开始用，那就用最低档先跑两周，每天记录三个数：当天总消耗、当天用了哪些模型、当天有没有开 Agent 模式做长任务。

采样期最忌讳的是“刻意省着用”。你要模拟的是真实工作状态，不是考试。该开 Agent 就开，该让它读大仓库就读，不然采出来的数据没有参考价值。

我把这两周的数据整理成一张表，格式大概是这样的：

两周下来，你会得到两个关键数字：日均消耗和波动幅度。日均消耗决定你大概落在哪一档，波动幅度决定你要不要留缓冲。

4.2 第二步：用临界点公式算升档是否划算

选档的本质是比较两个成本：额度不够带来的摩擦成本，和额度闲置带来的浪费。我习惯用一个简单的不等式来判断。

假设你日均消耗为 D 美元，一个月按 22 个工作日算，月消耗约 22D。设某一档月费为 P，附带额度为 Q。

• 如果 22D 明显小于 Q 的一半，说明这档对你来说额度过剩，降一档更划算；
• 如果 22D 在 Q 的 0.6 到 0.9 之间，说明这档匹配得刚好，留了一点缓冲；
• 如果 22D 接近或超过 Q，你就得考虑升档，或者接受月中有几天降速。

用代码写出来更直观：

def recommend_tier(daily_usage, workdays=22, tiers=None): """ daily_usage: 日均消耗（美元等值） tiers: [(名称, 月费, 附带额度), ...] """ monthly = daily_usage * workdays print(f"预估月消耗: {monthly:.1f} 美元等值") for name, price, quota in tiers: ratio = monthly / quota if ratio < 0.5: tag = "额度过剩，可降档" elif ratio < 0.9: tag = "匹配良好" elif ratio < 1.1: tag = "勉强够，月中有降速风险" else: tag = "明显不够，建议升档" print(f"{name:6s} 月费{price:>4} 额度{quota:>4} 占用率{ratio:5.0%} {tag}") tiers = [("Pro", 20, 20), ("Pro+", 60, 70), ("Ultra", 200, 400)] recommend_tier(daily_usage=2.5, tiers=tiers)

跑一下就知道自己落在哪个区间。这个方法看着粗糙，但比拍脑袋靠谱得多。关键是 daily_usage 这个输入要真实，别自己骗自己。

4.3 第三步：用一个模拟项目做账单推演

公式是静态的，项目是动态的。我建议你拿手头一个真实项目跑一遍全流程，看看账单长什么样。

模拟项目：一个中等规模的服务端项目，大约两百个源文件，需要做一次数据库访问层的重构，把散落在各处的查询逻辑收敛到一个统一的数据访问层。

推演过程大概是这样：

第一阶段是摸底。让 AI 读整个仓库，梳理现有的数据访问逻辑分布在哪些文件、各自什么形态。这一步要读几十个文件，token 消耗很大，粗略估计占整个项目消耗的两成。两百个文件的仓库全量索引加分析，几万到十几万 token 是常态。

第二阶段是方案设计。基于摸底结果，让它给出重构方案，包括新层的接口设计、迁移顺序、风险点。这一步消耗不大，主要是推理，不涉及大量文件读取。

第三阶段是逐模块执行。这是最烧钱的部分，占六成以上。每个模块都要读原文件、生成新代码、检查调用方、改引用。如果开 Agent 模式让它自己循环，消耗会再翻一倍，但省下来的人力也很可观。

第四阶段是回归验证。生成测试、跑、修。这部分消耗中等。

整个项目跑下来，如果全程高强度使用 Agent，总消耗可能落在几十到一百多美元等值这个区间。对照一下：Pro 的月额度肯定不够，Pro+ 大概率够，Ultra 绰绰有余。所以结论是这类项目期间临时升到 Pro+，做完再降回 Pro，比长期挂 Ultra 划算得多。

这个推演方法的价值在于，它让你在做之前就知道大概要花多少，而不是月底看账单吓一跳。

5. 省钱动作与踩坑实录

机制讲完了，最后讲点实操层面的东西。这部分是我自己攒下来的，有些是省钱技巧，有些纯粹是交了学费换来的教训。

5.1 六个能立刻降账单的动作

第一个动作：把“默认模型”调低一档。大部分人从来不改默认设置，一直用着高成本模型做日常补全。日常补全、单行改写、写注释这类任务，用中低档模型完全够，质量差异肉眼几乎看不出来。只有在做复杂重构、架构分析的时候才需要切到高档。这一个动作通常能省下三到四成额度。

第二个动作：Agent 模式设一个轮次上限。Agent 最大的风险是“跑飞”——它自己循环几十轮，每轮都在烧钱，最后给你一个并不需要那么复杂的结果。我现在给所有长任务都设一个轮次上限，跑到上限就停下来让我看一眼，确认方向对了再继续。这个习惯帮我挡掉了大量无效消耗。

第三个动作：别让它读整个仓库。索引全仓库很方便，但“索引”和“每次对话都塞进去”是两回事。做具体任务的时候，手动指定相关目录，比让它自己去大海捞针省得多。你越清楚自己要改哪里，就越应该主动缩小上下文范围。

第四个动作：定期清上下文。一个对话窗口聊了几十轮之后，历史消息会一直挂在上下文里，每轮都要重新计费。做完一个任务就开新窗口，别在一个窗口里从早聊到晚。

第五个动作：把重复性任务写成规则文件。项目根目录放一个描述项目规范的文件，把代码风格、目录约定、常用命令写进去。这样模型不用每次重新摸索，既省 token 又提高准确率。

第六个动作：月末检查用量。养成每月最后几天看一眼用量页面的习惯。如果发现额度大量闲置，下个月果断降档；如果发现连续几个月都在月中见底，就考虑升档。别让套餐设置一直停在半年前的状态。

5.2 常见问题速查表

5.3 我个人踩过的几个坑

第一个坑是高估自己的用量。我一开始直接上了最高档，结果第一个月用掉的额度不到十分之一。那时候的想法是“买贵的总没错，省得中途被限速”，但实际上大部分时间我都在做常规开发，根本用不上那么大的额度。后来降了两档，体验几乎没差别，钱省了一大半。教训是：先低后高，别先高后低，降档的心理门槛比升档高得多。

第二个坑是在错误的场景用错了模型。有段时间我图省事，所有任务都用最高档的推理模型，包括改个变量名、加个注释这种。后来看用量明细才发现，这些琐碎任务占了我近一半的消耗，而它们用最低档模型效果完全一样。这个习惯改掉之后，同样的工作量，额度消耗直接砍半。

第三个坑是团队席位没及时清理。有个小团队找我帮忙看账单，一个月几百美元的支出，实际天天用的只有三个人，剩下七八个席位是项目启动时统一开的，人早就不在这个项目上了。清理完当月账单直接降了六成。这件事之后我养成一个习惯：任何按席位计费的服务，每季度强制过一遍名单。

第四个坑比较隐蔽，是年付锁死了灵活性。年付确实便宜，但如果你的项目节奏有波动——比如某个季度特别忙、某个季度基本不写代码——年付就等于把额度节奏焊死了，闲的那个季度额度全浪费。我的建议是：先按月付跑三个月，确认用量确实稳定了，再考虑转年付。

注意：不要为了“把额度用满”而制造需求。这是最隐蔽的浪费——为了不浪费已经付的钱，去做本来不需要 AI 参与的工作，最后既浪费了时间，又养成了坏习惯。额度用不完是好事，说明你的工作节奏健康。

最后分享一个小习惯，我觉得挺有用：每月初花五分钟，把上个月的用量数据和你实际完成的工作对一遍，算一个“每美元产出”。这个数字比单纯看额度消耗有意义得多——它告诉你钱花得值不值，而不只是花得多不多。有时候用量涨了但产出涨得更多，那是好事；有时候用量没变但产出掉了一半，说明你在用 AI 做一些它并不擅长的事，该调整了。