Cursor 怎么用才不白花钱？三个月实操复盘

一、Cursor 是什么：一个把”改需求”变成对话的编辑器

先用一句话说清：Cursor（cursor.com）是一个 AI 代码编辑器，界面、快捷键、插件生态都沿用了 VS Code 那一套。你在 VS Code 里装的主题、插件、配置文件，基本能原样搬过来。它和普通编辑器的差别只有一个，但很关键：AI 不在侧边栏当一个聊天框，而是站在编辑器的正中央。

这个区别听起来小，用起来差很多。插件式的 AI 是”你把代码复制过去问它，再把答案粘回来”；Cursor 是”它看得见你的光标在哪、你打开的是哪几个文件、终端里刚报了什么错”。上下文不用你搬运，这是它效率高的真正原因，不是模型比别家聪明多少。

但也别把它想成”会写代码的魔法”。它做的每一处修改，都需要你看 diff、跑测试、确认逻辑。把它当成一个手很快、但从没在你公司上过班的同事，心态就对了：活儿可以交给它，责任还在你身上。

1.1 它是从 VS Code 分支出来的，不是插件

Cursor 不是给 VS Code 装一个扩展，而是直接基于 VS Code 的分支另做了一个编辑器。好处是迁移几乎零成本，你的键位肌肉记忆、常用插件、代码片段都能继续用；代价是它得跟着上游版本走，偶尔会遇到某个插件在新版本上水土不服。

理解这一点很重要，因为它解释了两件事。第一，为什么你不需要重新学一套编辑器的操作；第二，为什么它的 AI 能读到你整个项目的文件树，而插件做不到。插件被宿主限制了权限，编辑器自己则可以。

1.2 五个入口，先背下五个快捷键

五大能力其实对应五个入口，记住快捷键比记功能名有用：Tab 是智能补全，Ctrl/Cmd+K 是行内编辑，Ctrl/Cmd+L 是打开侧边对话，Ctrl/Cmd+I 是唤起 Composer 或 Agent，@ 是在对话里引用上下文。前三个改一行，后两个改一片，分工很清楚。

新手最容易犯的错，是拿 Chat 干所有事。让它在对话框里贴一大段代码再贴回来，等于把 Cursor 用成了网页版聊天工具，它最值钱的那部分能力你一点没用上。

1.3 和 Copilot 的根本差别在哪

Copilot 强在”补”，你写到一半它接下半句；Cursor 强在”改”，你描述需求它动多个文件。前者是打字加速器，后者是执行者。写新代码时两者的体感差距不大，改老代码时差距会突然拉开，因为改老代码的难点从来不是打字，是搞清楚”这个字段还有谁在用”。

所以这里有一个反常识的判断：Cursor 提效的关键不是补全，是把”改需求”变成对话。补全节省的是手速，一天撑死省半小时；而把”给这个接口加个限流”从两小时压缩到二十分钟，省的是整块的时间。你用它的时候，应该把大部分精力花在后一种用法上。

二、装之前先想清三件事

2.1 下载、登录、迁移配置

到 cursor.com 按系统下载，macOS、Windows、Linux 都有安装包。首次启动会问你要不要导入 VS Code 的配置，包括插件、主题、快捷键、用户设置，建议全选，省得后面一个个重装。导入完成后重启一次，插件才全部生效。

登录用邮箱或第三方账号都行。在 Cursor 里登录之后先别急着写代码，打开设置里的模型列表看一眼，确认你能用的模型有哪些。这个动作花十秒，能避免后面”为什么我的回答质量比教程里差”的困惑。

2.2 模型怎么选：别一直用最贵的

Cursor 支持在 Claude、GPT、Gemini 等系列之间切换，设置里可以给不同场景指定不同模型，也可以交给 Auto 自动挑。切换成本很低，值得你花半天做一次对比：同一个任务，分别用两三个模型跑一遍，看谁的改动更贴合你的代码风格。

一个实用的分配方法是：补全和格式调整用快模型，跨文件重构和读陌生代码用强模型。强模型的响应慢、额度消耗快，拿它去改一个变量名是浪费；快模型看不懂五个文件的调用关系，拿它做重构会给你挖坑。

2.3 免费额度能干什么，别急着付费

Cursor 的 Hobby 档免费但有限量，够你把五个入口都摸一遍，也够改一个小项目。真正的分界线是”每天都用”：一旦你发现自己一天要唤起十几次 Agent，免费额度会在下午就用完，那时候再考虑升级才合理。

订阅分 Hobby、Pro、Business、Ultra 几档，具体价格和额度以官网为准，活动期经常变。别在第一天就买年付，先用月付跑两周，确认它真的进了你的日常工作流，再谈长期。

三、核心功能拆解：五个入口，加一层规则

这一节把五个入口拆开讲。每个入口都写清”什么时候用、按什么键、注意什么”，你可以对着编辑器一个个试。

入口	快捷键	作用范围	典型任务	风险
Tab 补全	Tab 接受 / Esc 拒绝	光标附近几行	续写、改错、补参数	低，逐条确认即可
行内编辑	Ctrl/Cmd+K	选中片段或当前块	改写一个函数、加注释	低，改动可见
侧边对话	Ctrl/Cmd+L	当前文件 + 引用内容	问逻辑、解释报错	中，回答可能过时
Composer / Agent	Ctrl/Cmd+I	多文件	重构、加功能、迁移	高，必须看 diff
@ 引用	对话中输入 @	文件/文件夹/代码库/文档/网页	补上下文	低，但引用太多会稀释重点

3.1 Tab 补全：它预测的不是单词，是下一处修改

Cursor 的 Tab 和传统补全不是一回事。传统补全猜你要打的变量名，它猜的是”你接下来会改哪里”：你刚在一个函数里加了参数，它会跳到调用处提示你把参数补上；你改了接口返回结构，它会在另一个文件里提示同步。按 Tab 接受，按 Esc 拒绝，改动多处时它会一次性给你一个跨行预览。

刚上手会觉得它太激进，跳来跳去打断思路。熬过前两天就适应了，因为它的提示大多是对的。真觉得吵，可以在设置里关掉跨行跳转，只保留行内补全，等习惯了再打开。

3.2 Ctrl/Cmd+K：最被低估的入口

选中一段代码，按 Ctrl/Cmd+K，输入”把这个循环改成 map，保持原有顺序”，Cursor 会就地改写，改完给你一个 diff 让你逐块接受或拒绝。这个入口的好处是范围小、可预期，出错了一眼能看出来。

它最适合三类活儿：改写一段写得丑的逻辑、给一个函数补注释和类型、把一段重复代码抽成工具函数。不适合让它”优化整个文件”，范围一大，它就容易顺手改掉不该动的东西。

3.3 Chat：用来问代码，不要用来问语法

Ctrl/Cmd+L 打开侧边对话。它能看到你当前打开的文件，但你最好还是手动 @ 一下相关文件，别指望它猜。问”这个函数在什么情况下会返回空”比问”Python 怎么判断空列表”有价值得多，后者你去搜文档更快。

Chat 有一个被浪费的用法：让它解释报错。在 Cursor 里把终端报错贴进去，加上一句”这是我的改动，帮我判断是环境问题还是代码问题”，它给出排查顺序的成功率相当高，比在搜索引擎里翻半小时强。

3.4 Composer 与 Agent：威力最大，风险也最大

Ctrl/Cmd+I 唤起的是跨文件模式。你描述一个需求，它先列出要改哪几个文件、每个文件改什么，确认后一次性写入。Composer 更像”你主导、它执行”，Agent 模式则允许它自己读文件、跑命令、看报错再改，循环几轮直到任务完成。

这是 Cursor 真正的分水岭。用它改一个横跨五个文件的重构，你会明显感觉到”这不是补全，这是另一个人在干活”。但也正因为如此，它出错时不是错一行，是错一片，而且错得很自信。后面第四节会专门讲怎么控制这个风险。

3.5 @ 引用：上下文喂得准，比换模型管用

在对话或 Composer 的输入框里打 @，可以引用文件、文件夹、整个代码库、文档和网页。加了 @Codebase 之后，它会先检索相关文件再回答，处理陌生项目时这一步几乎是必须的。

引用不是越多越好。一次塞十个文件进去，重点会被稀释，它反而抓不住关键。比较稳的做法是先 @ 两个最核心的文件，再补一句”相关的调用方在 src/api 下”，让它自己去检索，比你把整个目录拖进去有效。

3.6 Rules：决定它像不像你的同事

Rules 是你写给它的长期约束，放在项目的 .cursor/rules 目录下，旧项目也可以用根目录的 .cursorrules 文件。里面写什么？技术栈版本、目录约定、命名风格、错误处理方式、哪些库不许引入、提交前要跑什么命令。

这里给一个独到判断：Rules 写得好不好，决定它像不像你的同事。同一个需求，没有 Rules 的 Cursor 给你的是一份”能跑的通用代码”，有 Rules 的 Cursor 给你的是一份”能直接过 review 的代码”。差别不在模型，在你有没有把团队的隐性知识写下来。

四、完整实操：从克隆到提交的六步

下面这套流程，是我现在接任何任务都走的顺序。它不快，但稳，能挡住八成的翻车。

4.1 第一步：先把项目跑起来

别急着让 Cursor 读代码。先按 README 把依赖装好、服务跑起来、测试跑一遍，确认基线是绿的。这一步不能省，因为后面它改完你要验证，基线本身是坏的，你根本分不清是谁的问题。

顺手在终端里记下三个命令：启动、测试、静态检查。后面每一步都要用，写在便签上也行。

4.2 第二步：用 @ 喂上下文，先问结构

打开 Composer，先不问”帮我改”，而是问”这个项目的请求从入口到数据库经过哪几层，各在哪个目录”。配合 @Codebase，它会给你一张调用链路图。这张图你要自己核一遍，核的过程就是你熟悉项目的过程。

核完之后，把你确认过的关键文件 @ 进去，再开始提需求。这一步多花十分钟，后面能少走两小时弯路。

4.3 第三步：先让它讲，再让它改

提需求时加一句”先说方案，不要动代码”。它会列出改哪几个文件、每个文件改什么、有没有风险点。你看完方案再回一句”按方案改”，它才开始写。

这个习惯的价值在于，方案阶段的错误成本几乎为零，代码写完再发现方向错了，成本是十倍。它给的方案经常有一个隐藏假设，比如”这个字段只有一处写入”，你正好知道不是，一句话就能拦住。

4.4 第四步：小步改，一次一个主题

一个需求拆成三到四个小步，每步只改一件事。先改数据层，跑通再改接口，最后改前端。每步之间提交一次，出问题能精准回滚。

最忌讳的是一句”帮我把这个功能做完”，Cursor 一口气改十二个文件，你面对一个巨大的 diff，既看不懂也不敢拒。改得越小，你越敢用。

4.5 第五步：看 diff，这是底线

改完不要点”全部接受”。逐个文件看 diff，重点看四类地方：删掉的代码是不是真的没用、新增的异常处理是不是在吞错、依赖有没有被悄悄升级、有没有它自己编出来的函数名。

这里必须说重一点：AI 改完一定要 review、要跑测试、要看 diff，不能盲信。它最常见的失败不是写错语法，是”写了一段语法正确但业务上不成立的代码”，这种东西只有你能看出来。

4.6 第六步：跑测试，再写清提交信息

测试挂了先别让它改测试。先判断是代码错了还是测试的预期过时了，这个判断只能你做。Cursor 写完的代码如果测试挂了，最坏的处理就是把断言改掉，那等于把报警器拆了。

静态检查也要跑。类型报错、未使用变量、循环依赖，这些它经常留着不收尾，因为它的目标是”这个功能能跑”，不是”这个仓库干净”。

提交时把”为什么改”写清楚，别只写”fix bug”。三个月后你回头看，或者在 review 时同事问起，这段说明比代码本身更有价值。如果是它写的代码，最好在提交信息里注明哪部分是 AI 生成、你做了哪些调整。

这不是形式主义。团队里一旦有人开始用 AI 写代码，追溯成本会上升，写清来源是唯一的补救办法。

五、三个真实场景，照着做一遍

5.1 接手陌生项目：两小时摸清一个老仓库

场景是接手一个没人写文档的老项目，三十万行，你只知道它是做订单的。用 Cursor 的做法是：先 @Codebase 问”订单从创建到完成经过哪些服务”，再让它画出状态机，然后挑一个最简单的接口，让它从路由追到 SQL，逐层讲给你听。

关键动作是”让它讲，你核对”。它讲错的地方，往往正是这个项目最绕的地方，那些绕的地方就是你要重点读的。两小时下来，你对项目的理解会超过读两天文档，因为文档可能是三年前的。

5.2 批量重命名与重构：一次改四十个文件

场景是把 user_id 统一改成 userId，涉及四十多个文件。在 Cursor 里别直接全局替换，先让它列出所有出现位置并分类：变量、数据库字段、接口参数、日志文案。分类之后你会发现，数据库字段不能动，日志文案动了会破坏监控看板。

然后分三批改：先改变量和函数签名，跑测试；再改接口层，跑集成测试；最后改前端调用。每批之间看一次 diff，确认没有误伤。四十个文件听起来吓人，拆成三批就是三个普通任务。

5.3 写测试与修 bug：先复现，再动手

修 bug 的正确顺序是：把报错和复现步骤给它，让它先写一个能稳定复现的测试，确认测试是红的，再让它改代码让测试变绿。这个顺序不能反，反了你就失去了验证手段。

写测试时它有个通病：喜欢测实现细节，比如断言某个私有方法被调用了几次。这种测试改一次代码就挂，维护成本极高。提需求时明确说”只测输入输出和边界条件，不要 mock 内部实现”，质量会好很多。

六、进阶技巧：六条能立刻用上的

6.1 把 Rules 写成团队规范，不是提示词

在 Cursor 里，很多人把 Rules 写成”你是一个资深工程师，请写优雅的代码”，这种话没有约束力。有效的写法是具体到可检查：”所有数据库查询必须走 repository 层””错误统一用 AppError 包装””新增接口必须补 OpenAPI 注释”。

判断标准很简单：一条规则如果没法在 review 时被判对错，它就不该写进去。写二十条能检查的，胜过写两百字形容词。

规则从哪来？从你的重复里来。如果你每次都要说”记得加日志、记得处理空值、记得更新类型定义”，说明这些话该进 Rules 了。判断方法很朴素：同一句话说过三遍，就写进规则文件，别再靠记忆重复。

6.2 让它先出计划，再动手

Agent 模式最大的浪费是”方向错了还跑得很远”。养成习惯：任何超过三个文件的任务，第一句都是”先给计划，不要改代码”。计划里如果出现你没听过的模块名，那多半是它编的，当场就能拦下。

6.3 用 @Docs 和 @Web 补它不知道的东西

模型的知识有截止时间，你用的框架上周刚发了新版，它可能还在按旧写法生成。这时候 @ 官方文档或网页，让它基于最新内容回答。做内部系统时，把接口文档挂成 @Docs 的索引，比每次粘贴文档省事得多。

6.4 粗活用快模型，细活用强模型

写单元测试、补类型注解、改格式，用快模型就够，快且省额度。设计表结构、拆解复杂重构、分析性能瓶颈，换强模型。Cursor 允许你在一次会话里切换，别嫌麻烦，这一步的性价比很高。

6.5 用 git 分支当”撤销键”

让它大改之前，先开一个 git 分支。Cursor 改崩了，一条命令回到干净状态，比在十几个文件里手动撤销快得多。这个习惯看起来笨，但它把”试试看”的成本降到了零，你会因此敢尝试更激进的改法。

6.6 MCP：把外部工具接进来

Cursor 支持 MCP，可以把外部工具接进对话，比如查数据库、读工单、调内部接口。接好之后，你可以直接说”看下这张表里昨天失败的任务”，它会自己去查，不用你复制粘贴结果。

但别一上来就接一堆 MCP。每接一个工具，Cursor 就多一份误操作的风险，尤其是带写权限的工具。先从只读的接起，确认它用得对，再考虑放开。

七、横向对比：五个对手，四种取舍

选工具别只看功能列表，要按”你最缺什么”来选。下面这张表按四个维度对比：多文件能力、中文表现、价格、可控性。这四项基本决定了一个人会不会长期用下去。

工具	多文件能力	中文表现	价格	可控性	适合谁
Cursor	强，Agent 可跨目录改	好，中文需求理解准确	免费档 + 三档订阅，以官网为准	中，靠 Rules 和 diff 约束	独立开发者、小团队
VS Code + Copilot	弱到中，以补全为主	好	按月订阅，价格稳定	高，改动范围小	不想换编辑器的人
通义灵码	中，单文件改写为主	很好，中文注释和文档强	有免费档，企业版另议	高	国内团队、Java 项目
Windsurf	强，Agent 流程顺	一般，中文偶有生硬	免费档 + 订阅	中	喜欢全自动流程的人
Cline	强，可自选模型	看模型，取决于你接哪家	插件免费，按调用量付费	很高，每步都要你确认	愿意折腾、在意成本的人
Zed	中，协作是亮点	一般	个人免费，团队付费	中	多人同时编辑的团队

四个维度里，最容易被低估的是可控性。多文件能力越强，一次改错的面就越大。Cline 把每一步都摊开让你确认，慢，但你心里有底；Cursor 的 Agent 更顺滑，代价是你要在最后一次性 review 一大片改动。选哪个，取决于你对自己的 review 能力有没有信心。

中文表现这一项，差距比想象中小。主流工具理解中文需求都没问题，真正的差别在中文注释、中文文档的生成质量，以及面对”按我们组的老规矩来”这种模糊表述时的表现。国内项目多、注释要求细的团队，通义灵码会更顺手。

八、价格与套餐：四档怎么选

Cursor 的订阅分四档，逻辑是按”重度程度”分层，不是按功能阉割。具体价格与额度以官网为准，这里只说结构和你该关注的点。

套餐	适合的使用强度	额度特点	要注意
Hobby	每周用几次，试水	免费、限量，够摸清功能	重度使用会在半天内耗尽
Pro	每天写代码的个人开发者	含一定额度，可开 Agent	超额后需另购或降速
Business	三人以上团队	集中计费、成员管理	按人头算，人多了不便宜
Ultra	全天候跑 Agent 的重度用户	额度最高	先算清你的实际消耗再买

一个反常识的结论：对多数人来说，Cursor 的订阅成本不是被”功能”决定的，是被”用法”决定的。同样一档套餐，有人一天用完，有人能用一周。差别在于你是拿它改一个函数，还是拿它反复重跑整个重构。

控制成本的办法有两个。一是把大任务拆小，减少无效重跑；二是在动手前先让它出计划，方向错了当场改，别等改完再返工。这两条比升级套餐管用。如果是团队采购，先让三个人用一个月，看真实消耗再谈年框，别按人头拍脑袋。

九、六个最常见的坑

9.1 不看 diff 就点全部接受

这是最贵的错误。它会在你没注意的地方删掉一行判空、改掉一个默认值、把同步改成异步。单看每一处都合理，合起来就是线上事故。养成习惯：全选接受这个按钮，尽量别用。

9.2 一次让它改十个文件

范围越大，它越倾向于”重写”而不是”修改”，重写就会丢细节。十个文件的任务拆成三次，每次三个文件，成功率会明显上升，你的 review 负担也会下降。

9.3 把它当搜索引擎用

问它”某个库的某个参数怎么配”，它可能给你一个三年前版本的答案。这类问题去查官方文档更快更准。它的价值在”结合你的代码回答”，不在”知道所有事实”。

9.4 不写 Rules，然后抱怨它不懂你

它不欠你一个”懂”。你的目录约定、命名习惯、禁用库，Cursor 无从得知，除非你写下来。花半小时写 Rules，能省掉后面几百次”不是这样，重来”。

9.5 指望它读懂整个大项目

上下文是有上限的。三十万行的仓库，它只能看到检索出来的那部分。所以它给出的结论经常”局部正确、全局错误”。大项目里的正确用法是：你负责划定范围，它负责在这个范围里干活。

9.6 年度订阅先买再说

AI 编辑器这个赛道三个月一变。先月付，用满一个月再决定。特别是你还不确定自己会不会长期用它的时候，年付锁住的不只是钱，还有你换工具的自由。

十、谁适合用，谁可以先等等

适合的第一类是做重构和维护老项目的人。新项目从零写，光靠补全工具就够；Cursor 的主场是老项目里那种”改一个字段要动八个文件”的活儿。

第二类是要读陌生代码的人。外包接手、换工作、接手离职同事的仓库，这些场景下它的”讲解”能力比”生成”能力更值钱。

第三类是小团队里没有专职架构师的人。它能扮演一个”什么都懂一点”的对话对象，帮你把方案过一遍，虽然它不承担后果。

可以先等等的也有三类。第一类是刚学编程的人，你还没有判断对错的能力，用它只会让你跳过”读懂代码”这一关，而这一关跳不过去。第二类是代码涉密、不允许上传的团队，这个不用多解释。第三类是已经很顺手的人，如果你的工作流里改代码只占两成时间，换编辑器的收益抵不过迁移成本。

十一、常见问题

11.1 Cursor 是免费的吗？

有免费档，但有限量，够试水不够日用。想稳定使用需要订阅，分几个档位，价格以官网为准。

11.2 它和 VS Code 能共存吗？

能。两个可以同时装，配置也能互相导入。建议先把 Cursor 当第二编辑器用两周，顺手了再切换主力。

11.3 插件和主题能带过去吗？

首次启动时选择导入即可，大部分插件能用。少数依赖特定版本接口的插件可能报错，重装一次通常能解决。

11.4 中文需求它听得懂吗？

听得懂。日常的”把这个改成异步””加个重试”都没问题。特别绕的业务规则，建议用中英混合加具体文件路径来描述，比纯口语更准。

11.5 Agent 模式会自己跑命令吗？

会，但默认需要你确认。涉及删除文件、装依赖、改配置的命令，一定要逐条看，别一路回车。

11.6 代码会被上传吗？

用云端模型时，相关代码片段会发给模型服务商。公司有合规要求的话，先看隐私条款，或者改用本地模型方案，别默认它”什么都不会传”。

11.7 它会不会把我的代码改坏？

会。所以用 Cursor 要看 diff、跑测试、留分支。它不是不可靠，是错的方式很隐蔽：语法全对，逻辑不对。

11.8 小项目值得用吗？

值得，但收益有限。小项目里你自己写可能更快，它的价值主要体现在”你不熟的技术栈”上。

11.9 为什么同一个问题两次回答不一样？

模型有随机性，上下文也随你打开的文件变化。想稳定复现，把关键文件 @ 进去，并把需求写得具体。

11.10 Rules 写在哪个文件里？

推荐放在项目内的 .cursor/rules 目录，按主题分文件。老项目也可以继续用根目录的 .cursorrules，但新项目建议用目录形式，好维护。

11.11 能离线用吗？

编辑器本身能离线打开，但 AI 功能依赖网络。完全离线场景需要另配本地模型，体验会打折扣。

11.12 学它要多久？

基本操作半小时，用顺手大约一周。真正的门槛不是快捷键，是”什么时候该信它、什么时候不该信”的判断力，这个只能靠项目喂出来。

十二、写在最后

用 Cursor 三个月，我对它的评价是：它没有让我写代码变快，它让我”敢改”了。以前看到一个耦合很深的模块，我会想”先放着吧，动它风险太大”；现在我会开个分支，让它先改一版看看。改坏了回滚，成本几乎是零。这种心理上的松弛，比省下的那几个小时更值钱。

但它也有一个真实的风险，值得写在这里：它最大的风险是让你不再读代码。当你习惯了描述需求、点接受、跑测试通过就提交，你对代码的理解会一点点变浅。三个月后你可能会发现，仓库能跑，但你讲不清它为什么能跑。

所以我给自己定了一条规矩：它改过的每一个文件，我至少完整读一遍；每周挑一个它改得最多的模块，自己重写一小部分。这条规矩很笨，但它是唯一能让你在用它的时候还在进步的办法。

如果你刚开始用，给一个具体建议：第一周别拿它做正经需求，拿它读代码。每天让它讲一个你不熟的模块，然后你去核对它讲得对不对。一周之后，你既摸清了项目，也摸清了它的脾气，这比看十篇教程都实在。