Copilot换Cursor，我的MCP配置笔记

上周六下午，我正对着一个重构到一半的TypeScript项目发呆。改动涉及六个文件，数据流从API层一路穿到组件，中间隔着三层类型定义。Copilot的自动补全——那个我用了快一年的Copilot——在光标处弹出三行建议，是我已经写好的日志语句的重复。

那一刻我把它卸载了。

这不是冲动。我用Copilot做了近一年的主力，它确实擅长两件事：在你写样板代码时把它补完，在你写单元测试时猜出下一行的断言。可一旦你进入修改别人的代码、理清跨文件的调用链、或者不知道该往哪个方向改的状态，它就沉默得像个摆件。

Cursor不一样。至少这三个月用下来，它让我改掉了“先自己搜一遍代码再问AI”的习惯。它直接把整个仓库塞进上下文，你问“这个函数的调用方在哪”，它给你列出来；你说“把这个接口从回调改成Promise”，它连带着把类型定义和调用处的报错一起改了。

这篇不吹不黑，就写两个事：我为什么换，以及那个让Cursor真正拉开差距的东西——Model Context Protocol，简称MCP。顺带把我踩过的配置坑也记下来。

先从 Copilot 卡在哪说起

Copilot 最大的问题不是笨，是“看不见”。

你说“帮我重构一下这个模块”，它只能看到你当前打开的文件和它记得的上下文。它对项目的理解停留在单文件层面，而现代软件工程的问题几乎全是跨文件的。你问它“这个工具函数还有谁在用”，它要么瞎编一个答案，要么让你自己去找。

这不是Copilot的错，是产品定位的问题。GitHub从一开始就把Copilot定位成“行级补全”，而不是“项目级助手”。它给你的是鱼，不是渔。你要自己去理清调用链、自己确认改哪里、自己写完改动后跑测试——它只是让你的手速快了一点。

好消息是，Copilot最近在VS Code里也加了一个“Agent模式”，能搜索整个仓库、改多个文件。但据我实测，它跑一次的时间、准确率和上下文利用率，跟Cursor的差距还是存在的。

如果你只写独立脚本、算法题、或者前后端完全分离的小项目，Copilot足够用，订阅费也便宜。但如果你天天在十万行代码的仓库里游走，你会想看看Cursor。

真正拉开差距的是 MCP

Cursor 最让我上头的，不是它的补全有多快，而是它有了“手”和“眼”。

Model Context Protocol，这个协议你可以简单理解成：给AI接上外部工具的USB接口。不用MCP的时候，AI是个只会读代码的回答器。用了MCP之后，它能去查数据库、调浏览器、读你服务器的日志、检查API返回，然后把结果带回来处理。

我用得最多的是让它直连本地数据库。传统流程是：你发现接口报错，自己打开数据库客户端、查表结构、手动模拟一条SQL，再把结果贴给AI。现在我在Cursor的配置里加了MCP，让它可以自己查数据库的结构和记录。

它给我一个查询结果，我看到数据里时间字段是timestamp，但代码里当成了string在格式化，问题一下就明确了。

配置过程不复杂，就三步：

1. 装一个MCP Server（比如 npx @modelcontextprotocol/server-postgres）
2. 在Cursor的设置里找到MCP目录，添加一条配置
3. 重启Cursor，在对话里让你提供的工具生效

我的配置长这样：

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "DATABASE_URI": "postgresql://localhost:5432/mydb"
      }
    }
  }
}

第一次跑通那天，我让Cursor直接查了线上数据库里一张争议很大的报表的表结构，它当着我的面列出所有字段和索引，然后说：“这个统计数据有重复，因为你用了一个不带去重的JOIN。”

那次我承认：这玩意儿跟Copilot完全不在一个物种上。更多关于生态和趋势的内容，我会常刷社区的行业动态看看大家在玩什么，毕竟这协议更新得比我想象中快。

Cursor 也不是没坑

讲道理，Cursor有自己的毛病。

内存占用高是头一个。开一个稍微大点的仓库，同时挂着MCP服务，16G内存的机器会明显吃力。我的笔记本是32G内存，开了一整天Cursor和几个容器之后，系统开始用交换分区，风扇声堪比起飞。

第二个坑是配置项容易崩。MCP Server一旦启动失败，Cursor不会给你明显的报错，只在底部的输出面板里打一行日志。我第一次配服务器时，因为Node版本太旧，npx拉不到最新包，MCP列表一直是空的。我以为是配置没生效，来回改了拓扑——折腾了两个晚上，最后发现是环境变量的问题。

这里给一个排查思路：先单独在终端里跑一遍 npx @modelcontextprotocol/server-postgres，看它能不能正常起来；起不来的话，问题大概率在环境或者网络，不在Cursor。

第三个问题是token消耗。开着MCP的Cursor，一个会话下来吃掉几万个token很正常。如果你用的是Cursor的付费版，额度像水一样流走。我有个月底的教训：那天我连续用MCP让Cursor查了十几次数据库，中午看的额度，下午就快见底了。

Copilot 和 Cursor 怎么选，我的判断

如果让我做一个粗暴的对比表，大概是这样的：

| 维度 | GitHub Copilot | Cursor |
|------|--------------|--------|
| 补全速度 | 极快，行级补全响应<0.3s | 稍慢，但可接受 |
| 跨文件理解 | 弱，以当前文件为主 | 强，仓库级索引 |
| 外部工具接入 | 刚起步，生态少 | 支持MCP，生态在做加法 |
| 上手门槛 | 低，装插件即用 | 稍高，需理解Agent和MCP概念 |
| 每月价格 | 10美元 | 20美元起 |
| 适合场景 | 熟手写代码加速 | 重构、排查、跨模块改动 |

我的结论偏向明显：如果你是在一个代码库深耕、经常要改老代码、或者想用AI做不止于补全的事，Cursor值得换。如果你主要写脚本和简单页面，Copilot仍然是性价比之选。

而且这俩工具都在快速迭代，一个月前的结论一个月后就可能作废。想跟进这方面的深层改动和实操经验，我建议直接去社区的AI编程实战板块，那里的更新速度比博客和公众号快得多。

最后一个建议：别盲目换

我见过不少人换了Cursor后又换回去，原因几乎一样——不习惯。

Cursor的对话式交互和Agent行为模式，跟“光标亮一下建议”的Copilot是两种工作方式。你不能指望Copilot的肌肉记忆直接迁移过去。你得学习怎么给Agent下指令、怎么拆任务、怎么信任它改的代码、怎么审它生成的diff。

这有个学习成本，大概一周左右。

至于MCP，它的成熟度还处于“能用但不够稳”的阶段。有些服务器插件只有早期版本，文档不全，坑也比较多。如果你不是重度用户，可以先不接MCP，用Cursor默认的能力感受一下，等需要外部数据时再动手配。

工具始终是工具，换个工具不会让你瞬间变强，但它确实能减少你和代码之间的摩擦。这是我换回来后最大的感受。关于我的配置细节，包括我的MCP环境、用的Node版本、以及完整配置，我都整理在PromptCube 首页，你可以直接参考我的环境组合，不用重走弯路。文章链接：https://promptcube.net/posts/10172