AI 评测指北： Vibe Coding 哪家强？ Benchmark 搞一把

Claude Code 、Gemini Cli 等命令行工具相继发布，这两个月 AI 编码又火出了新高度。 我对效率类工具一直都特感兴趣，喜欢折腾和把玩它们，加之这些工具是实实在在提升效率。 我去年底接触 Aider 、Cursor 、Cline 、Continue ，就想写篇博客来记录一下我对它们的感受。 最近又有些新感触！搞个博客来记录一下。

本来呀，我也只是想写一篇 “Aider 是怎么跑 benchmark 的” 的笔记。但看完了它的跑法之后呢， 感觉没啥可聊的。这两天正好看懂车帝搞了个智驾测试，挺有意思（特斯拉是真有点东西？）； 加上最近几年工作也是搞测试；再加上有好几个朋友说 Claude Code 牛出天际，我就想看看是不是那么回事！

我就充当一回“懂 AI 帝”，来评测一把。

如何评测？

我也知道，要完善的评测一个工具，是很麻烦的。毕竟场景那么多，每个工具都有自己的擅长领域。 你看懂车帝的评测，就有很多人喷，但也有很多人顶它。我下面先介绍一下我的评测方法。

我看到的“榜单”有两个，一个是 [Aider LLM Leaderboards][aider-bench]，还有一个是 [SWE-bench][swe-bench]。 前者可能比较小众，先简单介绍一下后者（让 AI 给我总结一把什么是 SWE-bench ）

SWE-bench （ Software Engineering Benchmark ）是一个专门用于评估大语言模型（ LLM ）在真实软件工程任务中表现的基准测试，最初由普林斯顿大学 NLP 团队于 2023 年发布。 它的核心任务是：给定一个 GitHub 开源项目的代码仓库和一个对应的 issue （问题描述），模型需要像人类开发者一样，理解问题、定位代码、修改文件，并生成一个补丁（ patch ），最终通过该项目原有的单元测试验证修复是否成功。 SWE-bench 的关键特点： 真实场景：所有任务都来源于 GitHub 上 12 个流行 Python 项目的真实 issue 和对应的 pull request （ PR ），共 2,294 个任务实例。 执行验证：采用“Fail-to-Pass”测试机制，即修复前测试失败，修复后测试通过，才算成功。 高难度：任务涉及多文件理解、跨模块调用、复杂依赖关系等，远超传统代码补全或算法题。

Aider LLM Leaderboards 虽然小众，但人家评测流程和数据都是开源透明的，我觉得它的数据还是挺有参考价值的。 有兴趣的小伙伴可以去看看。

我从 SWE-bench 中选了一个题 [pylint-dev__pylint-6528][pylint-dev__pylint-6528] 来评测这些工具。 我选它，是因为看中了这个题的几个特点：

1. 难度适中。它的难度评级是 15min - 1hour，简单的题是 15min 以内，比如算法题。难的题要好几个小时。
2. 这个题的答案要修改两个文件。我觉得这对 Coding 工具是有一些挑战的，只改一个文件在当下这个时间节点，对它们没啥挑战。
3. 这个题很好理解。我看了一遍题目的 problem statement ，我就看懂了，不需要很强的背景知识。
4. pylint 这个项目，我自己也接触过，有把握能在本地搭好评测环境、判断 AI 答案的准确性等。

不仅题目，评测流程也很重要。比如说，不同的 PROMPT 就会带来完全不一样的结果。我的评测原则和流程如下

1. PROMPT 要完全一致，或者基本一致。比如，我给每个工具说的第一句话都是一模一样的

   解决一下这个问题：{problem_statement}

2. 当工具问我要不要做某个操作时，我基本都会回答是，这样尽可能保证 apple-to-apple 。除非以下场景
   1. 它要跑 lint 命令。我会拒绝。比如，Aider 的一个机制就是会跑 lint 命令来让代码质量更好。但我也用过很多次，它跑 lint 命令的时候，会 lint 并尝试修改老代码，这其实引入了很大的风险。
   2. 它要跑 unit test 命令。我会拒绝。比如，很多工具都会尝试自动跑测试，但根据我的经验，它们的测试命令都非常粗糙。它可能直接建议我跑 pytest ，跑一遍可能都过年了。
   3. 它要给我添加测试。我会拒绝。因为 SWE-bench 数据集里面已经有测试用例了，不需要它来。

我评测流程，如果用伪代码来描述，就是

def evaluate():
	start_tool_with_default_parameters
	send_to_chat: `解决一下这个问题：{problem_statement}`
	enter yes until 它生成修复代码

	# 初步检查答案，保证它的答案不会让回归测试失败
	while 我主观觉得它还有戏:
		run PASS-TO-PASS tests  # 如果这个测试都跑不过，这个工具评测结果不及格
		if fail:
		 	send_to_chat: 有 X 个测试失败了：{failure_summary}
			enter yes until 它再一次生成修复代码
		else:
			# 认为它代码已经修改完毕，直接开始检查它的答案
			break

	# 检查最终答案
	while 我主观觉得它还有戏:
		run FAIL-TO-PASS tests
		if fail:
		 	send_to_chat: 有 X 个测试失败了：{failure_summary}
			enter yes until 它再一次生成修复代码
		else:
			break

更新(07-27 22:36): 这里 while 的地方有个主观部分，你可能会觉得它会影响这个评测的结果。严格来说，确实会有影响。但这里所谓的“主观”其实也是有判断标准的：即如果两次改动的代码都不符合预期，就认为它没戏。这个主要是考虑测试效率。

TL;DR 评测结果

我写了评测过程，让 AI 帮我总结了一个评测结果的表格。打分是我根据这次任务，主观打的。

评测结果分析

在评测过程中，我发现了一些有意思的细节，下面也和读者分享一波。另外评测还有很多局限性，也给自己跌跌甲，轻喷。

我从评测过程中，提炼了几个维度来评价这些工具。这里最重要的指标是问题最终是否被解决了。 如果问题解决了，过程坎坷一点也能接受。如果问题没解决，过程再惊艳，也没用。 因此，我给 Claude Code, Aider, Gemini Cli 打的分数比较高。其它就低一些。

第二个维度是交互体验。这里又可以细分：UI/UX ；可观测性；性能；稳定性。我暂时就想到这几个维度。

• UI/UX：指的是用户界面和用户体验。
  • Aider 界面简洁；交互基本都是一波流。但可观测性差了点。
  • Gemini Cli 的展示总是半屏（让我感觉有 bug 一样）；交互略微繁琐。
  • Claude Code 的界面也有繁琐，展示了很多工具的操作与结果；交互体验还行。另外它比较精致一点。
  • Trae 和 Cursor 都是 GUI 的
    • 两者都把过程搞得很繁琐，每一次工具操作都显示出来且不能折叠，繁琐。不过也是有点好处的。
    • 编辑的时候可以 accept 一部分，这个可控性比较好，这是 GUI 的优势
    • 工具的结果方便查看，这也是 GUI 的优势
• 性能与稳定性：
  • 稳定性方面：三个 Cli 工具感觉都有点小毛病。
  • 性能方面：Trae 的 edit 速度体感比较慢（感觉是设计上的问题，vscode 的 edit 速度也很慢）。
• 收费：
  • Aider 支持任何模型，加之有很多免费 API ，总体给高评分。
  • Gemini Cli 免费额度基本够用。但不支持其它模型。
  • Claude Code 贵出天际，一天不用上三个小时，感觉有点亏 🐶
  • Trae 似乎可以免费用，只是要排队。好像不能设置其它模型。
  • Cursor 有免费额度，额度很小。

值得一提的是，模型真的很重要。不同的模型，测出来结果差异可能会差很远。

还有个值得一提的是，这里评测的背景是解决一个实际问题。最后再附加一下个人的综合性观点

1. 假设我很有钱、或者工作里面需要经常堆 shi ，我应该会选择 cursor 。也会考虑 claude code 。
2. 在我钱不多、且编码不那么多的情况下，我会选择 Aider + VSCode(Copilot)
3. Gemini Cli 和 Trae 感觉目前竞争力还差点。如果 Trae 让我免费用，我也乐意 🐶

评测过程记录

评测过程比较细节与繁琐，感兴趣的盆友，可以查看博客原文。

• 微信公众号原文：https://mp.weixin.qq.com/s/DvTk3W5xxqzw79tw_5zqQA
• 知乎原文：https://zhuanlan.zhihu.com/p/1932909167150109858
• 博客原文：https://cosven.me/blogs/10024