Cursor 与 Copilot 深度对比：AI 编程工具实战评测

Cursor 与 Copilot 深度对比：AI 编程工具实战评测 | 前端进阶之旅

Full translation

完整中文译文

更新，4 月 1 日（这不是玩笑）。Insider Preview 版本目前变得更加可用和强大。在 2 月和 3 月期间，我看到了多次流式更新，我下面提出的大部分问题现在都已修复。在 2 月的 LinkedIn 上注意到了一些微软员工的观点，不知道这篇博文是否被转化成了待办事项呢？:)

免责声明！ 最好的 AI 编程工具就是对你可用的那个，它提供给你最好的模型和合理的令牌限制。从下面的文本来看，似乎 GitHub Copilot 是一个糟糕的产品——它不是。我使用 Copilot，我也很高效。只是当我从 Cursor 切换时，这是一个令人恼火的体验。

标题是我的 Cursor 2025 年回顾的截图，里面使用了接近 1T 的令牌——我想人们可能会称我为重度用户。我自 2023 年以来一直在使用它，它碰巧是我最喜欢的 VSCode 分支。我尝试过不同的 AI 辅助 IDE：Kiro、Antigravity、Windsurf、Project IDX；以及 VSCode 扩展如 Continue、Cody。

当我去年 12 月在 Cursor 中的月度令牌限制用完时，我花了更多时间使用 GH Copilot（Insider Preview 版本，具有最新功能）。在此之前，我偶尔使用 Copilot，大多是通过媒体/文章和同事的讨论跟踪它的进展。很难不注意到 Copilot 这个主要的 AI 编程助手。自 2023 年以来，我形成了这样的观点：相比之下，GH Copilot 是一个不太完善的产品，大约落后 6 个月。最近 Copilot 的新功能发布速度已经缩小了差距，但整体执行质量仍不够出色。

我不喜欢 Copilot 的地方

Plan Mode 相比于 Cursor 的实现显得非常糟糕。我在 Cursor 中经常使用它，但在 Copilot 中看不出使用的必要。当我在 GH 中第一次尝试时，我甚至不知道是否提供了计划——它只是一个子智能体生成的几个段落文本，点击"Proceed"按钮只是将模式切换到"Agent"并将"Proceed"文本粘贴到聊天中。这所有的一切似乎都是浪费了子智能体的令牌，它做了许多工具调用但只提供了非常通用的响应。在 Cursor 中，你会得到一个详细的结构化 .MD 计划；有一个"Build"按钮允许你在新对话中生成一个新的智能体（可以选择不同的模型和清洁的上下文）；或者你可以在同一线程中继续实现它。

对话功能很差（这是 UX 的核心）。例如，你无法克隆对话或从中间的某个消息分支出去——这是我在 Cursor 中经常使用的功能，用来管理不断增长的线程和上下文溢出。GH 中还有其他一些 UX 便利功能缺失，使体验令人恼火（例如，不稳定的提示输入框、将文件的选定部分添加到对话中不是瞬间明显的，由于微弱的动画等）。

没有手动对话摘要功能，只有自动摘要。以下是我是如何被这个"功能"困住的……在聊天的中间（我不知道聊天会有多长，因为没有令牌计数器；否则我会把它分支到新线程中），我输入了"Proceed"。实现开始后，我看到了几个工具调用，然后摘要启动了，智能体搞迷糊了，询问"你想让我继续什么？"。

长期缺少令牌计数器。Insider Preview 在 1 月底添加了此功能。Copilot 中关于此功能的 issue 自 2025 年 4 月以来就存在，并获得了许多点赞。Cursor 自我有记忆以来就一直有上下文窗口使用指示器。

令牌计数器缺失太长时间。Insider Preview 在 1 月底添加了此功能。

Copilot 中关于此功能的 issue 自 2025 年 4 月以来就存在，并获得了许多点赞。Cursor 自我有记忆以来就一直有上下文窗口使用指示器。

更短的上下文窗口。例如，GPT-5 系列的输入限制为 272K，Anthropic 的 Claude 模型默认的总上下文大小为 200K。我有一种感觉，在 Copilot 中我的对话会比在 Cursor 中更快地撞到摘要阈值——事实证明这有原因。为什么要设定这些低的默认值？

Gemini 3 Pro 不稳定。我 11 月份最喜欢的模型在较长的对话中随机抛出错误——重试没有帮助；我只能放弃这些对话或切换模型。我在 Cursor 中从未遇到过这种不稳定。

GitHub instructions 不如 Cursor 的 rules。例如，没有语义规则——智能体自动拉取相关的 instructions。我甚至为这个便利功能做了一个小的变通。最近 Insider Preview 添加了对 Agent Skills 的支持，这正是做到了这一点，但

提示管理中堆积的遗留问题。有 instructions、聊天模式、不同的提示方法——最近当在我们团队的仓库中进行清理时（使用了 GH Copilot），出现了许多关于"我应该如何正确设置护栏"的问题。一个很好的例子是 Cursor 如何放弃了其 Rules 规范，将 Agent Skills 作为默认选择，并立即为现有的 Cursor rules/commands 提供了迁移路径。

这也是 Copilot 中另一个不完整功能的例子。Copilot 中的 Agent Skills 仅限自动——模型决定何时将 skill 拉入线程。由于某种原因，无法明确引用 skill。我们对 Spec-Driven development 使用了 /spec 和 /task 斜杠命令，这些是显式调用的。当引入 Agent Skill 时，Cursor 添加了两种选项来使用它们——自动或通过斜杠命令。

提示管理中堆积的遗留问题。有 instructions、聊天模式、不同的提示方法——最近当在我们团队的仓库中进行清理时（使用了 GH Copilot），出现了许多关于"我应该如何正确设置护栏"的问题。一个很好的例子是 Cursor 如何放弃了其 Rules 规范，将 Agent Skills 作为默认选择，并立即为现有的 Cursor rules/commands 提供了迁移路径。

这也是 Copilot 中另一个不完整功能的例子。Copilot 中的 Agent Skills 仅限自动——模型决定何时将 skill 拉入线程。由于某种原因，无法明确引用 skill。我们对 Spec-Driven development 使用了 /spec 和 /task 斜杠命令，这些是显式调用的。当引入 Agent Skill 时，Cursor 添加了两种选项来使用它们——自动或通过斜杠命令。

缺少多模型并行智能体 - Cursor 允许你选择多个模型来处理单个提示；每个都创建一个 Git worktree，你可以继续在你最喜欢的 worktree 中工作。Copilot 有一个后台智能体功能，允许你启动一个新的 GH Copilot CLI 智能体——虽然它也依赖于 worktree，但它不提供相同的便利。

获取新模型可能很慢。GH 宣布 Copilot 中模型可用性的通知与模型发布的同一天就来了。但通常是可选的，需要 Copilot 订阅管理员手动启用新模型。在 Cursor 的情况下，我是通过它的模型选择器了解到新模型发布的

没有选择模型推理等级的选项。例如，对于 GPT-5.2，选择器中只有一行，而 Cursor 中有 8 个选项（low、medium、high、xhigh，然后是相同四个选项加 -fast 后缀，成本高两倍但速度更快）。从技术上讲，可以为 OpenAI 模型切换推理等级为"High"，但仅在实验性设置"Chat: Responses Api Reasoning Effort"下提供，这是一个有点尴尬且难以找到的功能。

恢复检查点可能不可靠。我在聊天历史中回溯时多次遇到损坏的解决方案。坦诚地说，在 Cursor 中也并不总是可靠的；有时智能体倾向于绕过标准编辑工具进行更改。只是 GH 的检查点恢复似乎不太可靠。

系统提示似乎显得笨拙且效果不佳。例如，在 Copilot 中，我经常在智能体完成长对话后收到一个带有"Plan"部分的响应。本质上它用大量计划内容填充报告顶部。工作都完成了，谁还会关心呢？这与 Cursor 的体验相比令人困惑。此外，在 CLI 中使用 Copilot 时，它经常误解意图，无法生成正确的命令，需要进一步交互。

Cursor 最近发布的子智能体功能目前还没有被 Copilot 实现。用户体验更好；整个编排看起来更精致。请看下面：在 Cursor 中我一次点击就启动了在各自工作树中运行的平行智能体，它们反过来又启动了子智能体。与 GH 非常简陋的实现相比较：

Copilot 中的模型无法查看图片文件——你只能将图片粘贴到聊天中；这样模型才能看到图片，否则就无法识别。用例？使用 ADB 拍摄屏幕截图并保存为 PNG 供进一步检查——在我意识到 Copilot 缺乏这个基础功能之前，我花了好几个小时运行失败的验证循环。Cursor 在这方面做得很好。

我喜欢 Copilot 的地方

（期待已久的）Token 计数器提供了详细的分析。观察智能体编码最近如何因验证而突飞猛进是很有趣的——你可以轻松检查工具调用结果在对话中占用了多少空间。

你可以检查提示——在"Output > GitHub Copilot Chat"下，你可以查看非常详细的 LLM 跟踪。例如，你可以看到什么样的提示被用来包装你的交互，这可能很有用，特别是如果你喜欢折腾的话。

对标准工具开放——Cursor 中没有 UI 来控制标准工具选择，仅限 MCP。如果你想要折腾，可以配置工具包，可以看到它们的准确名称。例如，我经常明确要求 GH 使用 runSubagent 工具来委派给子智能体——对于较大的任务，效果奇佳。

某种程度上是开源的——虽然后端部分尚未开源，但扩展程序已经开源。此外，许多 AI 编码助手功能已合并到 vscode 中，这使得第三方扩展的开发变得容易得多。不过遗憾的是，GH Copilot 始终需要登录，这阻碍了真正的本地 LLM 使用——关于这一点的 issue 很受欢迎，但已经搁置近一年。

MCP 安装更容易——我发现 GH 中的集成更简便（按钮点击即可）；使用 Cursor 时我必须手动更新配置文件。

与 GitHub 的生态系统和集成——Copilot 已集成到 GH 网页应用中；你可以在用手机浏览 GitHub 时轻松地将 issue 分配给云智能体；该扩展在许多 IDE 中可用（尽管非 VSCode IDE 据说在功能方面存在差异）。他们最近添加了对 Claude Code 和 Codex 的支持，允许你通过 GH 订阅运行其他主要编码智能体。Copilot 的覆盖范围和影响力很广。

更多 Token——GH 的高级请求模式似乎相比 Cursor 基于 Token 的定价允许更多的使用。不幸的是 Copilot 中没有用户可见的仪表板来进行清晰的对比。

来自 SharePoint 的创造者...

此乃双关。企业气息给软件增添了某种令人厌恶的风味。在我看来，SharePoint 或 Dynamics CRM 是经典案例——界面丑陋，运行缓慢。URL 中的".aspx"扩展让人想起用来构建它们的那些几十年前的 ASP.NET Web Forms。

不知为何，GitHub Copilot 似乎在步其他企业产品的后尘……它经常感觉像是由（a）不使用它的人和（b）不在乎的人创建的软件。一个由幻灯片公司制造的产品。

这种"不在乎"的态度最近才显露无遗，当有用户发现了一个绕过账单的漏洞时。那真是太搞笑了！漏洞报告被私下提交给微软安全响应中心；那边的人说计费不归他们管，建议在公开 GitHub 仓库上提 issue——这样每个人都能看到这个漏洞并免费占用微软的 Token。甚至之后，GH 的 issue 还被某个 AI 机器人自动关闭了。几天后，在这个漏洞获得公众关注和媒体报道后，issue 才被重新打开。

Copilot 与其他产品的对比可能会成为哈佛商学院又一个案例研究，讲述一家大型成熟企业如何变得迟缓、与市场脱节，而更灵活、更有活力的初创公司如何构建更好的产品。

它就是能用

当我使用 Cursor 时，"它就是能用"经常浮现在我脑海。选项和切换没那么多。他们喜欢构建极简主义且精致的 UI（我不喜欢 GitHub 的原因之一就是在我眼中它的界面经常很丑）。一个小例子就是 CLI 中的 Copilot：

AnySphere 有些封闭和神秘。以他们的 Composer 发布为例，他们将自己的模型与一个未指名的业界最佳模型对比，并模糊地描述他们的做法——甚至没有提到新模型的上下文窗口大小。或者他们如何实现"使用你自己的 API 密钥"功能，而他们在后端处理所有 LLM 请求，使得在闭环内使用变得不可能。

Apple 与 Microsoft、iOS 与 Android、初创公司与企业——所有这些类比总结了我对比 Cursor 和 Copilot 时的印象。

某些评论可能仅对已登录用户可见。登录以查看所有评论。

如需进一步操作，你可能需要考虑将此人加入黑名单和/或举报滥用。