Cursor 用了一年，说点实话

# Cursor 用了一年，说点实话

为什么还在用

2025年初，GitHub Copilot 的 IDE 集成越来越香，但有个问题——它太听话了。你说"优化这段代码"，它给你重写一遍，然后问你"还需要什么帮助吗"。那种感觉就像你的实习生，技术不错，但缺乏判断力。

Cursor 不一样。它的 context 意识强得多，能把整个项目结构、git diff、甚至你打开的其他文件都纳入理解范围。第一次用它的 Tab 补全时，我盯着屏幕看了五秒钟——这玩意儿怎么知道我想让那个函数处理空指针？

当然，它也不是银弹。下面是我这一年踩出来的真实体验。

真正的杀手锏：Composer 模式

很多人用 Cursor 就开了个新文件问 AI 写代码，那是在浪费它。Composer 模式（Cmd+I）才是真正的杀招。

它的逻辑是：给你一个模糊需求，它自己拆任务、开文件、写代码、跑测试、修 bug。上周我让它加一个用户导出 CSV 的功能，从需求到 PR 只用了 20 分钟。什么概念？手动写需求文档 + 设计接口 + 实现 + 单元测试，一小时打底。

但有个坑：Composer 有时候会"过度工程"。你让它加个日志，它给你搭一套完整的 logging framework。我的应对策略是——在 prompt 里明确限制范围：

// 在 prompt 里说清楚边界

只修改 src/logger.ts，不要动其他文件。加一个 warn 级别的日志方法，格式和现有 info 保持一致。

越具体，它越不会跑偏。

Tab 补全 vs 完整重生成

Cursor 有两个补全模式：Tab（行级）和 Cmd+L（整个编辑器）。这两个的区别我花了三个月才搞清楚。

Tab 补全适合"续写"场景——你写了一半的函数名、变量名，它预测你接下来要写什么。这时候它会参考当前文件的上下文，准确率很高。

Cmd+L 适合"改一整块"——选中一段代码，让它重写。但这里有个坑：如果你的选中范围太大（比如整个文件），它会倾向于大改而不是优化，经常把原本能跑的东西改出 bug。

我的建议：Tab 补全日常用，Cmd+L 只在明确知道要改什么的时候用，而且尽量缩小选中范围。

跟 Git 的联动

Cursor 的 chat 能直接读 git diff，这意味着你可以说"帮我看看这次提交改了什么，有没有潜在问题"，它会把所有变更放在上下文里分析。这个功能在 code review 时特别好用。

但要注意：如果你的项目 commit 历史很长，它可能会把一些无关的历史变更也塞进 context，导致回答噪音增加。我的做法是先用 git log -10 看最近的提交，然后在 prompt 里限定范围：

基于最近 5 次 commit 的变更，分析有没有可能引入的类型安全问题。

什么时候不该用 Cursor

说点反话：有两类场景 Cursor 反而会让你更慢。

第一是"从零构建一个全新模块"。比如你现在要加一个支付系统，从零设计表结构、API、前端组件。这时候 AI 给你的方案往往是"能用但不够好"的，因为它的训练数据偏向于"修改已有代码"而不是"设计新系统"。你花了 20 分钟让它生成，然后发现架构有问题要推翻重来，反而不如自己先画个草图。

第二是"调试一个复杂的并发 bug"。Cursor 在静态分析上很强，但对运行时状态的理解有限。你跟它说"这个接口偶尔超时"，它能帮你猜方向，但真要定位问题，还是得自己上 profiler。

结论

Cursor 最适合的场景：在你已经有代码基础的项目里做增量开发。它是个高效的"高级实习生"，不是架构师。用好它的办法是——给明确边界、缩小操作范围、保留最终判断权。

别指望它替你思考，但确实能替你跑完那 80% 的重复劳动。