Cursor 与 GitHub Copilot 的比较，不能只看谁补全代码更快。对 Python 开发者而言，更有区分度的问题是：代理模式能否完成跨文件任务，代码审查能否发现真实缺陷，以及工具能否稳定遵守项目约定。
两款产品的功能、界面和套餐会持续变化，因此与其记住一张静态功能表，不如建立一套能在自己的代码库中重复运行的测试方法。
别把代码补全和代理模式混为一谈
代码补全通常处理局部上下文：补全一个表达式、函数体或测试用例。代理模式面对的则是一个完整目标，可能需要搜索仓库、编辑多个文件、运行命令，再根据失败结果继续修改。
例如，下面两条请求看似相近，实际考察的能力不同：
补全 calculate_total() 的函数体。
阅读 CONTRIBUTING.md，实现 calculate_total()，补充边界测试，运行项目规定的检查，并总结修改过的文件。
第二条任务同时测试了上下文检索、项目约定、多文件编辑、命令执行和错误恢复。评估 Cursor 与 Copilot 时，应把这类代理任务与普通补全分开计分，否则一次漂亮的补全很容易掩盖仓库级任务中的问题。
还要记录人工干预次数。代理最终完成任务并不代表效率高：如果开发者需要反复指出测试目录、格式化命令和业务规则，说明工具还没有可靠地理解项目。
用同一个 Python 小项目做对照实验
下面的项目故意留下一个未实现函数，并把约定写入版本库。它不依赖第三方运行时库，只需要安装测试和静态检查工具。
运行前请确保本机已有 Python 3.11 或更高版本，然后复制以下命令：
mkdir -p ai-editor-benchmark/src ai-editor-benchmark/tests
cd ai-editor-benchmark
cat > src/__init__.py <<'PY'
PY
cat > src/pricing.py <<'PY'
from decimal import Decimal
def checkout_total(prices: list[Decimal], discount_pct: int = 0) -> Decimal:
'''Return the discounted total rounded to two decimal places.'''
raise NotImplementedError
PY
cat > tests/test_pricing.py <<'PY'
from decimal import Decimal
import pytest
from src.pricing import checkout_total
def test_applies_discount_and_rounds_half_up() -> None:
assert checkout_total([Decimal('10.01'), Decimal('0.04')], 10) == Decimal('9.05')
def test_empty_cart_is_zero() -> None:
assert checkout_total([]) == Decimal('0.00')
def test_rejects_invalid_discount() -> None:
with pytest.raises(ValueError):
checkout_total([Decimal('10.00')], 101)
def test_rejects_negative_price() -> None:
with pytest.raises(ValueError):
checkout_total([Decimal('-0.01')])
PY
cat > CONTRIBUTING.md <<'MD'
# Project conventions
- Monetary calculations must use Decimal, never float.
- Validate that discount_pct is between 0 and 100.
- Reject negative prices with ValueError.
- Quantize results to Decimal('0.01') using ROUND_HALF_UP.
- Do not add runtime dependencies.
- All changes must pass pytest, Ruff, and mypy in strict mode.
MD
cat > pyproject.toml <<'TOML'
[tool.pytest.ini_options]
pythonpath = ['.']
[tool.ruff]
line-length = 88
[tool.mypy]
strict = true
TOML
python -m venv .venv
. .venv/bin/activate
python -m pip install pytest ruff mypy
pytest -q
TOML
最后一次测试预期失败，因为函数尚未实现。接下来分别在 Cursor 和配置了 GitHub Copilot 的编辑器中打开同一份干净副本，提交完全相同的提示：
阅读 CONTRIBUTING.md，并完成当前仓库中的定价功能。
要求：
1. 实现缺失的生产代码。
2. 如有必要，补充测试，但不要删除或弱化现有测试。
3. 运行 pytest、ruff check . 和 mypy src。
4. 修复检查发现的问题。
5. 总结修改内容、执行过的命令以及仍然存在的风险。
比较时不要只看最终代码，可以记录以下指标：
| 指标 | 观察内容 |
|---|---|
| 首次通过率 | 第一次实现能否通过全部检查 |
| 约定遵守度 | 是否使用 Decimal、ROUND_HALF_UP 和规定的异常 |
| 自主性 | 是否主动读取约定、运行命令并修复失败 |
| 修改范围 | 是否改动无关文件或削弱测试 |
| 可解释性 | 总结是否与真实改动和命令输出一致 |
| 人工成本 | 完成任务前需要多少次提示或确认 |
为了公平，每次测试都应从同一个 Git 提交开始，并尽量使用相同模型等级、权限和上下文。若一个工具允许执行终端命令，而另一个工具没有相同权限，测试结果反映的是整体工作流，而不只是模型能力，应在结论中明确注明。
代码审查要测试发现问题，而不是生成摘要
许多 AI 审查都能复述 diff，但真正有价值的审查需要指出可触发的缺陷、解释影响，并给出验证方式。可以在单独分支中故意加入边界错误，再让两个工具审查同一份 diff。
例如，把折扣校验错误地写成只拒绝大于 100 的值，却遗漏负数；或者使用默认的 Decimal 舍入方式，而不是项目要求的 ROUND_HALF_UP。然后使用这样的审查提示：
审查当前分支相对主分支的 diff。只报告能够由代码和项目约定支持的问题。
每个问题必须包含：
- 文件和相关代码位置
- 可触发问题的输入
- 实际影响
- 建议增加的最小测试
不要只总结改动，也不要把纯风格偏好标成缺陷。
审查结果可以按严重度、准确率和可操作性评分。尤其要关注误报：一个工具列出十条听起来合理的问题，却只有一条真实可复现，往往不如只报告两条且都准确的工具。
也不要让 AI 审查替代 pytest、类型检查、静态分析和人工审批。它更适合补充检查盲区，而不是成为唯一质量门禁。
项目约定必须既能被阅读，也能被执行
自然语言规则有助于 AI 理解意图，但只有自动化检查才能稳定阻止违规代码合并。较可靠的做法是同时维护三层约束：
- 在
CONTRIBUTING.md或团队指定的指令文件中描述架构和业务规则。 - 在
pyproject.toml中配置 Ruff、mypy 和 pytest。 - 在 CI 中执行相同命令，避免本地代理声称成功但没有真正验证。
可以把本地检查统一成一个脚本：
cat > check.sh <<'SH'
#!/usr/bin/env bash
set -euo pipefail
python -m pytest -q
python -m ruff check .
python -m mypy src
SH
chmod +x check.sh
./check.sh
随后把代理提示简化为“完成任务并运行 ./check.sh”。这能减少工具猜测命令的空间，也让不同编辑器接受相同的验收标准。
需要注意的是，不同产品读取项目指令的机制可能不同，而且会随版本变化。基准测试应先显式要求读取 CONTRIBUTING.md，再单独测试各产品官方支持的自动指令机制。这样可以区分模型没有遵守规则，还是配置根本没有被加载。
快速自测：你真的在比较正确的能力吗
- 任务需要搜索仓库、修改多个文件并运行测试，应该主要评估什么？ 代理模式，而不是单行补全速度。
- AI 审查生成了很长的 diff 摘要，是否说明审查质量高？ 不一定。关键是能否发现可复现、与改动相关且可操作的问题。
- 把编码规范只写在提示词里是否足够？ 不够。重要约定还应进入版本库，并由测试、类型检查和 lint 规则执行。
- 能否直接宣布 Cursor 或 Copilot 永远更适合 Python？ 不能。结果会受到任务类型、模型、编辑器集成、权限、仓库规模和团队流程影响。
选择工具时看工作流，而不是只看演示
如果日常工作主要是局部编辑和快速补全，应重点比较延迟、建议命中率以及对现有 IDE 的影响。如果经常处理陌生仓库、跨文件重构和测试修复，则应提高代理模式、终端反馈循环和上下文检索的权重。代码审查密集的团队还要单独测量缺陷发现率与误报率。
正式采用前，可以用三到五个真实但已脱敏的任务做限时试用，并记录首次通过率、人工干预次数和无关改动数量。同时限制代理对密钥、生产环境和高风险命令的访问，所有生成代码仍需经过现有 CI 与人工审批。
真正更好的工具，不是某次演示中写出最多代码的那个，而是在你的 Python 项目约定下，以更少干预交付可验证改动的那个。