用了半年Cursor，我有些话不吐不快

说实话，半年前第一次用Cursor的时候，我是真香了。

那时候刚从Copilot转过来，感觉像是从诺基亚直接跳到了iPhone——代码补全准得离谱，整个项目文件随便问，还能帮你重构。我当时甚至发了条朋友圈："AI编程终于不是玩具了"。

但用着用着，发现这玩意儿没那么简单。

那些官方Demo不会告诉你的坑

1. 上下文窗口看着大，实际能用的小

Cursor号称200k token上下文，听起来能塞下整个项目。但你试过就知道，当你让它分析一个5000行的文件时，它就开始胡说八道了。

我有次让它帮我理一个复杂的业务逻辑文件，结果它给我编出来几个根本不存在的函数名。我以为是代码问题，排查了半小时才发现——这货是在"推理"，而不是真正理解。

**坑点**：大文件场景下，Cursor会自己"脑补"一些内容，尤其是跨文件引用的时候。你的函数叫 getUserInfo，它可能给你写成 getUser，然后信誓旦旦地告诉你这俩是一个东西。

**我的解决方案**：把关键代码段先复制到聊天框，明确告诉它"只分析这段代码"。别指望它自己在大文件里找重点。

2. Refactor功能用不好，比没用还惨

Cursor的重构功能看着很强——你选中一段代码，让它"优化性能"或"重构为更清晰的版本"，然后它就给你一版看起来很专业的代码。

问题在于，它重构完的代码经常和你项目的其他部分风格不统一。

我有次让它重构一个React组件，结果它把我的函数组件改成了class组件。这倒没啥，但它顺手把我的hook调用都改了，导致后面其他依赖这些状态的组件全崩了。

**坑点**：Cursor重构时会按照"通用最佳实践"来，但不会管你项目的具体约定。你的项目约定是函数组件，它偏给你改成class；你约定用const，它给你改成let。

**我的解决方案**：重构前先明确说明你的项目约定，比如"保持函数组件风格"、"不要改变变量声明方式"。别只说"重构"，要给足够的约束。

3. 多文件编辑看着爽，其实容易炸

Cursor能同时改多个文件，这确实是它的杀手锏。但如果你敢让它一次性改超过5个文件，大概率会出现各种诡异问题。

最常见的是改了A文件忘了改B文件的import，或者改了一半发现第三个文件的函数签名也要跟着变，但它没改。

我有次让它帮我改一个API的返回结构，涉及到前后端十几个文件。它一开始改得挺顺利，然后突然卡住说"遇到了一些问题"。我一看，它改到一半把一个文件里的函数签名改了，但调用这个函数的另一个文件它忘了。

**我的解决方案**：多文件修改分批来，每次最多3个文件。改完一批就跑一遍测试，确认没问题再改下一批。

怎么用Cursor才不翻车

用了这么久，我也总结出一些经验。

明确它的角色：高级副手，不是主力

Cursor更像是一个"很厉害但偶尔会犯傻的实习生"。它能帮你写大部分代码，但核心逻辑、架构决策还得你盯着。

我现在的工作流是：我负责整体设计和关键逻辑，Cursor负责实现细节和单元测试。这样效率最高。

给足够的上下文，但别指望它自己找

和Cursor对话时，我会把相关代码段直接粘贴进去，而不是让它"去看某某文件"。后者它经常找错地方，或者干脆不知道你说的是哪个。

永远要Review它的代码

不管Cursor生成的代码看起来多完美，我都会认真过一遍。尤其是变量命名、错误处理、边界条件这些地方——Cursor写的代码经常在这些细节上翻车。

一句话总结

Cursor是个好工具，但它不是银弹。用好了能提效，用不好反而浪费时间。

关键在于：别太相信它，但也别不用它。把它当副手，别当主力，这才是正确姿势。