Cursor 用了一年，说几句真话

# Cursor 用了一年，说几句真话

说实话，写这篇文章之前我在纠结。Cursor 确实让我工作流变快了，但让我写"推荐"类文章我又觉得在骗人。思来想去，还是决定把真实体验摆出来——好的地方夸，坑的地方也指出来，反正咱们都是写代码的，不说假话。

先把话说在前头

我是什么类型的开发者？前端为主，偶尔写点 Node.js 后端，项目都是中大型复杂度的那种（几万行代码，十几个模块）。用过 VS Code、WebStorm，现在主力是 Cursor。这篇文章基于我实际用了超过一年的真实经验，不是官方给的试用账号那种"三天体验"。

让我真香的地方

Tab 补全比 Copilot 强一个档次

这个不是夸张。Copilot 的 Tab 补全经常给我一些"看起来对但实际跑不通"的代码，而 Cursor 的 Tab 补全——尤其是现在基于 Codeium 引擎的版本——在补全函数名、变量名、导入语句这些细节上精准多了。

举个真实例子：

// 我在写一个文件上传组件，敲到一半

const handleFileUpload = async (file: File) => {

const formData = new FormData()

formData.append('file', file)

// 按 Tab，Cursor 直接帮我补全了后面整个请求逻辑

const response = await fetch('/api/upload', {

method: 'POST',

body: formData,

})

return response.json()

}

关键是它补全的变量名、API 路径、错误处理逻辑都是贴合上下文的，不是那种通用的模板代码。这在写重复性较高的 CRUD 代码时省了不少时间。

Composer 模式——多文件同时修改的神

这个项目有个很头疼的问题：改一个接口，前端、后端、类型定义、测试文件全部要动。以前用 VS Code 得开七八个标签页来回切，现在 Composer 模式可以直接跟我说"把这个 API 的响应格式从 camelCase 改成 snake_case，所有相关文件都改一下"，它会把涉及的文件都列出来，逐一修改。

当然不是说它每次都对。有时候它会误判依赖关系，把一个不相关的测试文件也改了。但比起手动改十几个文件，这个容错率完全在接受范围内——Review 一下 diff，把不该改的地方还原就行。

$ 符号引用上下文

这个功能我一开始没看懂，后来发现是真好用。在光标处输入 $ 然后回车，它会分析当前文件的上下文，生成一个可以在 AI 对话中引用的快照。相当于告诉 AI："就基于这个文件的上下文来帮我写代码"。

比如我在重构一个工具函数，想加个缓存逻辑，直接在编辑器里打 $ 选当前文件，然后跟 AI 说"加个基于 key 的内存缓存，超时 5 分钟"，它返回的代码直接就能用，不需要我再解释一遍类型定义和现有结构。

坑也得说清楚

价格问题

Cursor 免费版限制太多了——每天几次对话，每次只能处理一个小任务。Pro 版 20 刀/月，对于个人开发者来说不算贵，但要是团队用的话，成本就上来了。而且 Cursor 的 usage 统计不太透明，有时候感觉"明明没怎么用怎么额度就少了"。

我遇到过一次：周一早上打开发现周末额度被用光了，查日志才发现是某个 LLM 调用异常（可能是我写的 prompt 触发了无限循环），一天就刷完了。

对复杂项目的理解有时会飘

这是我吐槽最多的点。Cursor 在处理简单文件、小模块的时候没问题，但一旦项目结构复杂、跨文件依赖多，它偶尔会"自信地胡说八道"——比如引用了一个根本不存在的方法，或者搞混了两个同名但不同模块的类。

解决方式是用 @ 引用具体文件来约束它的上下文范围，但这也意味着你得花更多精力去管理引用，反而削弱了它的便利性。

快捷键偶尔冲突

我用 macOS，Cursor 的默认快捷键跟一些系统级快捷键有冲突。比如 Cmd+K 在某些场景下会抢走系统截屏的优先级。虽然可以自定义，但 Cursor 的快捷键配置界面做得不够直观，改起来挺费劲的。

总结

Cursor 不是万能的，但确实让我的开发效率提升了。我的建议是：如果你每天写代码超过 4 小时，值得试一试 Pro 版；如果是偶尔写点脚本，免费版够用了。

最重要的是——不要完全信任 AI 生成的代码，Review 永远是必须的。我见过太多人把 Cursor 生成的代码直接提交到生产环境，然后半夜被叫起来修 bug 的案例。

一句话：Cursor 是工具，不是替你思考的人。