Copilot 和我认识得早，从 2023 年就开始用；Cursor 是 2024 年中换上的。两个都用了快一年，不是来比高下的，是记一下我分别在什么场景下更愿意打开哪一个。结论先放前面：它们解决的是两类不同的事。

一、Copilot：当前文件里的续写手

Copilot 最顺手的时候，是我正写着一段、思路清楚、只差把下一行敲出来的时候。比如写一个控制器，方法签名和参数都定了，它就顺着把方法体补全。这种"在当前文件上下文里续写"的事，它反应快、打断少，几乎无感。

我每天八成的时间其实都在干这种活：按既定模式补代码、写样板、对接已经定好的接口。Copilot 嵌在编辑器里，不用切窗口，这点体验上它赢。

但它的短板也明显：它主要看当前打开的文件和附近几行。让它"顺便把调用方也改了"，十次有三次会改错地方，或者根本没意识到还有个调用方。这种时候我宁可自己跳到调用方手动改两行，也不冒险让它跨文件联想。

二、Cursor：跨文件的理解者

Cursor 我一般在"要动的不止一个文件"时打开。它的 @ 引用能把几个相关文件一起喂进去，让它先理解再改。比如我要给一个领域模型加个字段，涉及实体、DTO、映射配置、还有两个用到它的服务——这种跨文件的改动，Cursor 比 Copilot 稳。

我印象深的一次：把一个方法从同步改成异步，涉及六七个文件。我在 Cursor 里把入口文件和几个关键调用方都 @ 进去，说清"只改这一条链路"，它给出的改动清单基本覆盖了，我只补了两处它没注意到的隐蔽调用。

不过 Cursor 也有让我皱眉的时候：它有时候过于"积极"，会顺手把我觉得没必要动的地方也优化掉。所以我用它的习惯和 Claude Code 一样——改完必 diff。

三、我怎么换着用

说人话就是：单文件、顺着写，开 Copilot；多文件、要先看懂再改，开 Cursor。没有谁替代谁，是两个动作。

  • 写新接口的实现方法 → Copilot；
  • 重命名一个被多处引用的类 → Cursor；
  • 补一段我已经想清楚逻辑的单元测试 → Copilot；
  • 理解一个我不熟的老模块再小改 → Cursor，先让它读再让我问。

价格上两家我都付过订阅，Copilot 是按编辑器装、Cursor 是独立应用。我现在的实际节奏是：平时默认 Copilot 开着，遇到跨文件任务才切到 Cursor，用完切回来。切来切去的麻烦有，但比强行用错工具返工划算。

顺带说个反直觉的发现：我原本以为 Cursor 既然能读多个文件，质量就一定压过 Copilot。实际用下来，单文件续写 Copilot 反而更少出"多余动作"——它不试图理解全局，也就不轻易乱改。所以不是谁更强，是各自在各自的地盘上更省心。把它俩当同一个东西的不同档位用，比单纯选"更好的那个"更贴合我的日常。

四、一点没想明白的

有一件事我到现在没定论：到底是"一个足够强的 agent 统一兜底"好，还是"按场景分工具"好。去年我觉得分着用麻烦，今年反而觉得分着用更可控。也许再过半年想法又会变，先这么记着。

五、钱以外的真实代价

除了订阅费，还有两个不太被提起的代价。一个是上下文的搬运：Cursor 要我手动把相关文件 @ 进去，选哪些文件本身就费脑子，选少了它理解偏、选多了又淹没重点，这步我至今没找到省事的办法。另一个是"该用哪个"的判断本身也要练，新人容易不管什么任务都丢给 Cursor，结果一堆本该一行补全的活也被它搞出大改动。

我也被保险公司式的期待坑过：有阵子以为"既然有 AI 了，速度应该翻倍"，于是排期排得更紧，结果审核时间反而变长，因为产出多了、要审的也多了。后来我把"它写完到我能合"这段时间单独算进去，排期才恢复合理。工具快了，不等于交付快了，中间那道人把关的工序没消失，只是从"写"挪到了"审"。

所以这两款我都不会卸载，但也都不会神话。它们各自把一类动作做顺了，剩下的——判断、负责、兜底——还是我自己的事。