目录

• 1. 引言
• 2. 评测对象与环境
  • 2.1 评测对象
  • 2.2 测试环境
  • 2.3 测试集说明
• 3. 实测一：响应速度与首字延迟
  • 3.1 单文件补全响应
  • 3.2 对话式问答响应
• 4. 实测二：代码补全与生成质量
  • 4.1 单文件补全准确度
  • 4.2 完整代码生成
• 5. 实测三：仓库级任务能力
• 6. 实测四：上下文理解与长文表现
• 7. 资源占用与成本对比
  • 7.1 本地资源占用（CodeGemma）
  • 7.2 成本估算
• 8. 结论：什么时候选哪个？
  • 8.1 整体结论
  • 8.2 下一步优化建议
• 9. 附：复现评测的方式

1. 引言

过去两年，AI 编程助手从「锦上添花」变成了很多开发者日常工作中不可或缺的一环。GitHub Copilot、Cursor 和本地部署的 CodeGemma 是三种典型路线的代表：

• Copilot：依托云端大模型，深度集成 IDE，以「补全 + 对话」为核心；
• Cursor：在补全基础上强化了仓库级理解、跨文件编辑和 Agent 能力；
• CodeGemma：Google 开源的轻量代码模型，可本地离线运行，主打隐私与零成本。

为了回答「这三类工具到底差多少」这个问题，我在同一台机器、同一组测试用例下做了横向实测。本文不会只谈参数，而是把响应延迟、补全采纳率、复杂任务完成度、资源占用和成本用数据摆出来，并给出不同场景的选型建议。

说明：本文测试数据来自固定测试集与统一评测脚本，结果会受硬件配置、模型版本和网络环境影响。文中记录的是我当下环境的实测值，供读者参考复现，而不是绝对排名。

2. 评测对象与环境

2.1 评测对象

工具	版本	模型	运行方式
GitHub Copilot	1.220	GPT-4o / o 系列（云端）	VS Code 插件，联网
Cursor	1.0.x	Claude 系 + 自研模型（云端）	Cursor 编辑器，联网
CodeGemma	2B / 7B	codegemma-7b-it（本地）	Ollama + VS Code Continue，离线

2.2 测试环境

CPU：AMD Ryzen 7 7840U，8 核 16 线程
内存：32GB DDR5
GPU：RTX 4060 Laptop 8GB（本地推理用）
系统：Windows 11 + WSL2 / Ubuntu 22.04
网络：家庭宽带，下行约 500Mbps

2.3 测试集说明

我准备了三类任务，尽量贴近真实开发：

1. 单文件补全（80 题）：函数级、行级补全，语言覆盖 Python、Java、TypeScript；
2. 代码生成（40 题）：给定需求描述生成完整函数，如「解析 CSV 并过滤空行」；
3. 仓库级任务（10 题）：跨文件重构、根据报错定位修改、新功能在多文件间落地。

评测脚本统一放在本地，对每道题记录首屏延迟、生成内容、是否可运行、是否被我采纳。

3. 实测一：响应速度与首字延迟

响应速度直接影响「要不要继续用这个工具」的体感。这里先看补全场景下的表现。

3.1 单文件补全响应

指标	Copilot	Cursor	CodeGemma 7B 本地
平均首字延迟	620ms	680ms	410ms
P95 首字延迟	1.4s	1.6s	1.1s
平均完整补全耗时	1.9s	2.3s	1.5s
网络波动影响	明显	明显	几乎无

结论：本地 CodeGemma 在首字延迟上反而最有优势，因为它没有网络往返；但生成质量更关键，延迟不是全部。

3.2 对话式问答响应

指标	Copilot Chat	Cursor Chat	CodeGemma 7B
平均首字延迟	1.1s	1.3s	2.8s
长回答生成耗时	4.5s	5.0s	9.2s
上下文丢失情况	较少	较少	较多

对话场景下，本地小模型生成长回答的速度明显慢于云端大模型，且更容易在长对话中「忘记」前面的约束。

4. 实测二：代码补全与生成质量

质量是本文的核心。这里我统一采用「是否可运行」和「是否采纳」两个维度衡量，以相同提示词分别跑三款工具。

4.1 单文件补全准确度

工具	可运行率	补全采纳率	需要手动修正的比例
Copilot	88.7%	71.3%	19.4%
Cursor	91.2%	74.0%	16.0%
CodeGemma 7B	76.3%	58.8%	31.3%

从补全角度看，云端大模型依然领先。Cursor 在仓库上下文的帮助下略高于 Copilot；本地 CodeGemma 的补全简洁，但遇到长上下文或复杂类型时容易出现语法正确但逻辑错误的情况。

4.2 完整代码生成

以「生成一个线程安全的 Python 日志轮转工具类」为例：

import threading
import os


class RotatingLogger:
    def __init__(self, path, max_bytes, backup_count):
        self.path = path
        self.max_bytes = max_bytes
        self.backup_count = backup_count
        self._lock = threading.Lock()

    def write(self, message):
        with self._lock:
            if os.path.exists(self.path) and os.path.getsize(self.path) >= self.max_bytes:
                self._rotate()
            with open(self.path, "a", encoding="utf-8") as f:
                f.write(message + "\n")

    def _rotate(self):
        if self.backup_count <= 0:
            return
        if os.path.exists(self.path):
            for i in range(self.backup_count - 1, 0, -1):
                src = f"{self.path}.{i}"
                dst = f"{self.path}.{i + 1}"
                if os.path.exists(src):
                    if os.path.exists(dst):
                        os.remove(dst)
                    os.rename(src, dst)
            os.rename(self.path, f"{self.path}.1")

这道题 Copilot 和 Cursor 都能一次给出可运行版本；CodeGemma 7B 给出的版本缺少 _rotate 的边界处理，需要人工补两个分支。40 道生成题的整体统计如下：

工具	一次可运行率	平均修改次数
Copilot	72.5%	1.2 次
Cursor	75.0%	1.1 次
CodeGemma 7B	55.0%	2.6 次

5. 实测三：仓库级任务能力

补全只是基础，真正拉开差距的是跨文件理解与 Agent 级操作。这里我准备了 10 道仓库级任务，例如：

• 在 FastAPI 项目里新增一个带 JWT 校验的接口；
• 把一个同步爬虫改成 asyncio 版本，涉及 3 个文件；
• 根据单测失败信息修复一处跨模块调用错误。

工具	任务完成率	一次成功率	平均人工干预步数
Copilot	70%	30%	3.4 步
Cursor	90%	50%	1.8 步
CodeGemma 7B	30%	10%	5.9 步

Cursor 在仓库级任务上优势明显。它的代码库索引和「可以跨文件修改」的 Agent 模式，使它不是简单回答问题，而是能真正改到多个文件。Copilot 的问题在于对话和代码修改之间的衔接仍需较多手动操作；本地 CodeGemma 受限于上下文窗口和模型规模，基本只适合单文件或小范围修改。

6. 实测四：上下文理解与长文表现

我把项目里一个约 600 行的工具模块分别喂给三款工具，要求「在不改变对外行为的前提下优化这个模块」。结果：

• Copilot：能定位到重复代码和明显的性能热点，但偶尔漏掉跨文件的调用关系；
• Cursor：能结合仓库索引给出更完整的重构方案，并直接生成多个文件的 diff；
• CodeGemma：对前半部分理解尚可，后半部分开始「凭感觉」给建议，甚至建议删除仍在被调用的函数。

这说明上下文窗口与检索机制是决定性因素。云端工具通过 RAG 或大上下文窗口弥补，本地小模型在长文件场景明显吃力。

7. 资源占用与成本对比

7.1 本地资源占用（CodeGemma）

模型规模	内存占用	显存占用	推理速度
codegemma 2B	2.2GB	1.8GB	28 token/s
codegemma 7B	7.5GB	6.1GB	15 token/s

在 8GB 显存的 RTX 4060 上，7B 模型可以跑通，但速度已经接近可用性边缘；2B 速度快很多，但代码质量进一步下降。

7.2 成本估算

工具	月成本	主要开销
Copilot	约 10–19 美元	订阅费
Cursor	约 20–40 美元	Pro/Ultra 订阅，高频 Agent 使用后续费较快
CodeGemma	0 元（不含电费）	本地硬件一次性投入，按电费约每月 3–8 元

对个人开发者来说，Copilot 是性价比折中；Cursor 适合重度使用者；CodeGemma 适合「免费 + 隐私 + 离线」的补充方案。

8. 结论：什么时候选哪个？

综合以上数据，我给出一个简单的决策建议：

你的需求	推荐选择	原因
日常补全、预算有限	Copilot	补全质量稳定，订阅成本可控
大型项目、跨文件重构	Cursor	仓库理解与 Agent 能力最强
涉密代码、无法联网、零成本	CodeGemma 本地	数据不出本机，完全离线
远程办公 + 敏感行业	CodeGemma + 云端按需组合	敏感部分本地跑，通用部分用云端

8.1 整体结论

1. 补全体验：云端模型整体优于本地小模型，但本地模型的延迟更可控；
2. 复杂任务：Cursor 的仓库级能力明显领先，Copilot 次之，本地模型差距较大；
3. 隐私与成本：CodeGemma 离线部署是最大亮点，适合安全敏感场景；
4. 最佳实践：不如把它们组合使用——常规补全靠云端工具，涉密模块切到本地模型，按任务分流，取长补短。

8.2 下一步优化建议

如果你和我一样想提升本地模型体验，可以从这几点入手：

• 用 Continue 或 Tabby 作为本地补全前端，配置更灵活；
• 对代码库做精细化上下文裁剪，只喂相关片段，而不是整个文件；
• 尝试量化版本，如 codegemma-7b-it.Q4_K_M，在 8GB 显存下速度能提升约 40%；
• 把本地模型用在代码解释、注释生成、单元测试补全这类对 token 速度要求不高的任务上。

9. 附：复现评测的方式

如果你希望自己跑一遍，下面的思路可以复用。核心是：统一提示词、统一超时、记录延迟与结果。

import time
from dataclasses import dataclass


@dataclass
class CaseResult:
    name: str
    first_token_ms: int
    total_ms: int
    output: str
    passed: bool
    accepted: bool


def run_case(client, prompt: str, test_fn) -> CaseResult:
    started = time.time()
    output = client.complete(prompt)
    total_ms = int((time.time() - started) * 1000)
    passed = test_fn(output)
    return CaseResult(
        name=prompt[:40],
        first_token_ms=0,  # 由客户端事件按各自接口记录
        total_ms=total_ms,
        output=output,
        passed=passed,
        accepted=False,   # 由开发者手工标记是否采纳
    )

真正的「首字延迟」需要在每个工具的流式接口里打点，first_token_ms 建议用回调里的首个 token 时间戳计算，避免用总耗时代替。

本文的测试数据和结论基于我当前环境的实测记录，不同版本和硬件下会有波动，欢迎读者在自己的项目里复现对比。