Copilot vs Cursor vs Claude Code

短短几年间,AI 编码工具从玩具式自动补全,变成了能读整个 repo、规划改动、编辑多个文件、跑测试、并迭代的真正的结对程序员。今天主导话题的有三个工具:GitHub Copilot、Cursor、Claude Code。它们重叠很多,却围绕不同的中心点设计——一个 IDE 插件、一个 AI 优先的编辑器、一个终端原生的 agent。本指南拆解每个如何工作、各自在哪发光、以及如何选。

从自动补全到 agent

把这些工具放在一个自主性谱系上看会有帮助,因为这一条轴解释了它们的大部分差异:

• 补全(Completion)——模型建议接下来几行;你接受或拒绝。摩擦最低、风险最低、工作单元最小。
• 辅助编辑(Assisted edit)——你用自然语言描述一个改动;工具在一个或多个文件上提出一个具体 diff;你审查并应用。
• agentic 任务——你陈述一个目标;agent 规划、编辑多个文件、跑命令/测试、读输出,循环直到完成。

更高自主性意味每个 prompt 的杠杆更大——但也意味更大的 diff 要审、更多出错的方式。选工具,很大程度上是在选某个任务该落在这个谱系的哪个位置。

LOW AUTONOMY  ──────────────────────────────────▶  HIGH AUTONOMY

  completion          assisted edit           agentic task
  "next few lines"    "change these files"    "achieve this goal"
  ───────────         ─────────────────       ──────────────────
  Copilot             Cursor                  Claude Code
  ghost text, Tab     Composer, multi-file    plan → act → verify

  you review:
  one line       ▸    one diff           ▸    a whole change set

这些工具没有一个只坐在单个点上——Copilot 加了 agent 模式,Cursor 能跑命令,Claude Code 也能做小编辑。但每个都有一个重心,而这正是本指南其余部分要勾勒的。

GitHub Copilot

Copilot 是采用最广的工具,也是对你现有工作方式要求改变最少的那个。它作为扩展安装进 VS Code、JetBrains IDE、Neovim、Visual Studio,把 AI 叠加到你现有的环境上。

它如何工作

• 行内补全——你打字时,它把附近代码和打开的文件作为上下文发送,流式给出一个建议(ghost text),你用 Tab 接受。
• Copilot Chat——一个侧边栏,用于提问、解释、以及限定在当前文件或选区的编辑。
• Agent 模式——较新版本加了一个能跨文件编辑、跑任务的多步 agent,缩小了与 Cursor 和 Claude Code 的差距。

它如何读你的代码

Copilot 的输出只和它能看到的一样好。行内模型被喂入光标周围的代码、你打开的标签页、最近编辑的文件;较新版本叠加了轻量的仓库索引,并让你在 Chat 里用 @ 引用文件或符号。实践要点:把相关文件开着;当一个补全跑偏时,通常意味着模型看不到它需要的类型、辅助函数或接口——而不是它“不会写代码”。

典型工作流

你待在编辑器里,让建议随打字流出,用一句引导性注释或一个函数签名来导航,用 Tab 接受:

// debounce: call fn only after `wait` ms of silence   ← 你打这句
function debounce(fn, wait) {            ← Copilot 填入 ↓
  let t;
  return (...args) => {
    clearTimeout(t);
    t = setTimeout(() => fn(...args), wait);
  };
}

对比一个函数更大的东西,你切到 Copilot Chat 或 Agent 模式,在侧边栏描述改动,但日常模式就是这种近乎隐形、让你保持心流的补全。

模型与运行环境

Copilot 是模型灵活的——你可以按任务在前沿模型(包括 GPT 与 Claude 系列)中挑选——并在它的扩展所到之处运行:VS Code、JetBrains IDE、Visual Studio、Neovim。计费是按席位的固定订阅,有 free、pro、business/enterprise 档,使成本可预测,也是它在许多组织里成为默认选项的一大原因。

优势与弱点

优势:可能最低的摩擦——它在你已经用的编辑器里工作,擅长样板、重复编辑、测试、以及“补完这个函数”,按席位定价易于做预算。弱点:行内补全只看到窄窄一片上下文,所以历史上它在全 repo 推理上弱于 Cursor;agent 模式补上了大部分差距,但更新、实战检验更少;而体验只会和你所用的那个具体编辑器集成一样精致。

Cursor

Cursor 是围绕“AI 作为主界面”重建的 VS Code fork。因为团队掌控整个编辑器,AI 是织进编辑回路里的,而非外挂上去。

它如何工作

• 代码库索引——Cursor 为你的 repo 构建 embedding,以便检索语义相关的文件进上下文,而不只是你打开的那些。
• Composer / 多文件编辑——描述一个改动,Cursor 在多个文件上提出协调一致的 diff,在审查 UI 里展示。
• Tab 补全——一个强大的“下一处编辑”预测,常把你跳到你接下来想改的地方。

它如何拉取上下文

因为 Cursor 拥有整个编辑器,它能把你的 repo 索引成 embedding,自动检索语义相关的文件——不只是你打开的那些。你也能用文件、文件夹、文档或符号的 @ 提及来显式导航上下文,并加项目规则(一个 .cursor/rules 文件),它随每个 prompt 同行,让模型始终遵循你的约定。

典型工作流

标志性回路是 Composer:描述一个改动,看 Cursor 在多个文件上提出协调的 diff,再逐块接受或拒绝。

▸ 你写:
Rename User.fullName to displayName everywhere — update the
GraphQL schema, resolvers, and the React components that read it.

▸ Cursor 提出一个可审查的变更集:
  src/models/user.ts          ~ field + getter
  src/graphql/schema.graphql  ~ type User
  src/graphql/resolvers.ts    ~ resolver map
  web/components/Profile.tsx  ~ 3 usages

日常你在 Tab——一个把你跳到下一处想改的地方的“下一处编辑”预测——和 Composer(用于任何跨多文件的事)之间交替。

模型与成本

Cursor 让你在前沿模型间选择,并提供一个“auto”模式,把每个请求路由到合适的模型。定价把订阅与按用量计费(用于更重的模型调用)结合,所以你的账单随你推过它的 agentic 工作量缩放——清闲日里慷慨,重度依赖时则明显。

优势与弱点

优势:同类最佳的多文件编辑、快速的审查回路、以及凭索引带来的强大全 repo 检索;单是 Tab 模型就是实打实的生产力提升。弱点:它是个要采用的独立编辑器(一个 VS Code fork——多数扩展能沿用,但仍是一次迁移),索引超大 monorepo 可能需要调优,重度 agent 使用下按用量成本会让你意外。

Claude Code

Claude Code 是一个终端原生的编码 agent。它不活在编辑器里,而是跑在你的 shell 里(并与 IDE 集成),围绕 agentic 工作构建:给它一个目标,它就规划、编辑文件、跑命令、读结果、迭代。

它如何工作

• tool use——它读写文件、跑 shell 命令、grep 代码库、跑测试,用输出决定下一步。
• agentic 循环——plan → act → observe → repeat,让它端到端完成更大任务,而非一次一个 diff。
• 可组合性——身为终端原生,它能塞进脚本、CI、headless 自动化,并能驱动 sub-agent 做并行工作。

实践中的 agentic 循环

你在终端给它一个目标,看它工作:探索 repo、提出计划、编辑文件、跑命令、读输出、修正方向——循环直到目标达成或它需要你的输入。

$ claude "the build is failing on main — find and fix it"

● running the build to see the error…
  ✗ TS2345 in src/api/client.ts:42 — argument type mismatch

● reading client.ts and its caller…
● editing src/api/client.ts — thread the generic through fetchJson<T>

● re-running the build to verify…
  ✓ build succeeded

Fixed: the return type of fetchJson<T> wasn't propagated to the
caller. Patched and confirmed the build now passes.

上下文:按需读取

Claude Code 不预先索引,而是按需拉取上下文——它边推理边 grep、列目录、读文件,像开发者那样。这让它的视图保持最新、没有陈旧索引,并能在任何 repo 里零搭建工作,代价是早期要花几个回合发现结构。

扩展它

• sub-agent——委派并行或专门的工作(搜索、评审),让主上下文保持干净。
• MCP——经 Model Context Protocol 连接外部工具与数据源(issue tracker、数据库、浏览器)。
• Hooks 与 headless 模式——强制策略,并在脚本和 CI 流水线里非交互地运行它。

优势与弱点

优势:对大型多步任务最合适——重构、“修这个失败的 build”、脚手架一个服务——因为它会规划,且关键在于它靠跑测试和读输出验证自己的工作;身为终端原生,它能脚本化进 CI 与 headless 自动化,并能扇出到 sub-agent。弱点:它不像编辑器插件那样手把手的行内体验,高自主性产出你必须仔细审查的更大 diff,而按用量定价意味一个大任务比单次补全花得多。

一个任务,三个工具

差异在单个具体任务上最易体会。假设你要给一个 Express API 加请求限流。同一个目标,随你伸手去拿多少自主性而样貌不同:

• Copilot——你创建 middleware/rateLimit.ts,写一句描述 token-bucket 限流器的注释,让行内补全逐个函数填实现;接线进 app 你自己来。
• Cursor——你打开 Composer:“加一个 token-bucket 限流 middleware 并应用到 /api 路由。”它把新文件外加对 app.ts 和路由文件的编辑作为一个可审查的变更集提出。
• Claude Code——你说:“给 API 加限流,带测试,并确保它们通过。”它写 middleware、接线、加测试、跑套件、迭代到全绿——再报告它改了什么。

注意这个权衡。用 Copilot 你做了接线、对每一行了如指掌;用 Claude Code 你描述了一个结果、审查了一个完成且测过的改动。同一个任务——杠杆大小迥异,审查面也迥异。

正面对比

它们底层共享什么

尽管外壳不同,三者都建立在同一套机制上,理解它会让你更善用其中任何一个:

• 一个前沿 LLM 做推理;工具的活儿主要是上下文组装与动作执行。
• 检索——挑选把哪些文件/片段放进有限的上下文窗口,在很大程度上决定输出质量。好的检索胜过用糟糕上下文的更大模型。
• 上下文窗口有限——每个工具都靠裁剪、摘要或索引来塞下。“它为什么忽略了那个文件?”通常是个上下文问题。
• tool use / function calling 才是把聊天模型变成能编辑并验证的 agent 的东西(见我们的 tool-use 深入篇)。

定价、模型与隐私

除了纯能力,三个实践维度在真实采用中决定很多:

• 定价模型。Copilot 按席位、可预测。Cursor 和 Claude Code 把订阅与按用量成本混合,所以重度 agentic 工作花得更多——但每个 prompt 也做得更多。按你实际会跑多少自主工作来做预算,而非只看标价。
• 模型选择。三者都让你瞄准前沿模型,结果因任务而异;值得多试几个。只是记住,工具的上下文组装往往比你选哪个模型更要紧。
• 隐私与治理。你的代码离开你的机器去到模型。在标准化用某个工具之前,查它的留存与训练策略、企业版或零留存选项、以及你组织对 AI 生成代码的立场。

选对工具

• 整天做小的本地编辑 → Copilot,在你已用的编辑器里零摩擦。
• 触及若干文件的 feature 工作 → Cursor,因其多文件 composer 和全 repo 检索。
• 你能描述完就走开的大任务(重构一个模块、修一个失败的测试套件、脚手架一个服务) → Claude Code,因其带自我验证的自主执行。
• 诚实的答案:许多工程师同时跑两个——一个补全工具求心流,加一个 agent 干重活。

你在做的改动有多大?

  一行或一个函数 .................. Copilot      (保持心流)
  若干文件,你来导航 .............. Cursor       (Composer + 审查)
  你能描述完就走开的整个任务 ...... Claude Code  (plan → act → verify)

  拿不准?从谱系更低处开始,再逐级升级。

最佳实践与陷阱

• 审查每份 diff。工具越快,越容易 merge 微妙错误的代码。你提交的归你所有。
• 刻意给上下文——把工具指向对的文件、贴上报错、点名约束。含糊的 prompt 得到通用的代码。
• 让 agent 验证——让工具跑测试/linter 闭合回路,抓住它自己的错误。
• 留意 secret 与许可——清楚什么代码离开你的机器,以及你组织对 AI 生成代码的政策。
• 按任务大小选,而非忠诚度——驱动选择的应是谱系,而非品牌;许多工程师同时开着两个工具。
• 别外包理解——若你讲不清生成的代码,你就维护不了它(也在面试里辩护不了它)。