通义灵码与githubcopilot的对比评测

简介: 本文评测了通义灵码,与github copilot在一些代码编写能力上面的能力比较。虽然github copilot要强很多,但灵码目前的能力也不算很弱,并且在一些小类上会做的更好一些。值得试试看,也是免费的

被测版本:

GitHub Copilot : v1.130.0(与v2有小版本变化)

GitHub Copilot Chat : v0.8.2023092902(有小版本变化)

通义灵码:v1.0.0(正式版发布)

测试截止时间:2023年11月 01日

评测方案:

1)基于模拟的真实业务场景

一个程序是由很多不同的部分组成的,具体而言,是由环境准备,配置引用包(maven),编写后端代码(包含PO,DO,Web Controller,h2数据库,mybatis等),编写前端代码(包含html + js),做测试(junit,spring unit),编写打包DockerFile,编写shell,接入CI自动化流程等步骤组成的。

最后确保所有单元测试可通过,Web页面可访问,可上传文件。

2)相同的代码或配置文件,用github copilot和通义灵码分别做一遍

统计如下信息(下面信息是举例,具体详情请见后续表格):

交互总次数 : 
75
其中:
接受copilot提示的次数:24
用户输入的次数:32
用户删除的次数:19
--------------------
用户接受copilot提示的字符数量:2380
用户输入的字符数量:322
用户删除的字符数量:254

交互次数,就是把人机交互分为三种,一种是用户输入内容,一种是用户删除内容,一种是用户接受copilot提示的内容,分别看频次。

然后也会统计,用户接受copilot建议的字符串数量,用户自己输入的字符串数量和用户删除的字符串数量

原则上,用户输入越少,删除字符越少,代码助手越智能而用户与助手交互次数越少,代码助手越智能。

3)采纳原则

按照文档从上往下输入内容,当有提示的时候,判断是否采纳,如果有70%以上e 可用(主观)则采纳。

测评过程:

绿色标记是通义灵码做得好的,红色是通义灵码待改进的。(有详细测试链接,需要的话可联系我获取)

测试场景1级

测试场景2级

测试用例名

指标反馈:github copilot

(简称cop)

指标反馈: tongyi

 (简称ty)

额外说明,注解

初始环境准备

下载/注册

下载测试体验

顺畅

多ide支持

看支持的ide个数

vs,vscode,jetbrains,vim,auaredatastudio

vscode ,jetbrains

配置引用包

Maven新增引用支持

支持

支持,但软件版本老旧,有给出过错误的pom配置

编写代码

编写XML

编写photoMapper.xml ,内置CRUD SQL

交互总次数 : 

75

其中:

接受copilot提示的次数:24

用户输入的次数:32

用户删除的次数:19

--------------------

用户接受copilot提示的字符数量:2380

用户输入的字符数量:322

用户删除的字符数量:254

交互总次数 : 

99

其中:

接受copilot提示的次数:20

用户输入的次数:32

用户删除的次数:47

--------------------

用户接受copilot提示的字符数量:1889

用户输入的字符数量:315

用户删除的字符数量:261

编写XML

编写一个mybatis-config.xml,建立数据库连接

交互总次数 : 

36

其中:

接受copilot提示的次数:11

用户输入的次数:13

用户删除的次数:12

--------------------

用户接受copilot提示的字符数量:1193

用户输入的字符数量:121

用户删除的字符数量:138

交互总次数 : 

23

其中:

接受copilot提示的次数:12

用户输入的次数:6

用户删除的次数:5

--------------------

用户接受copilot提示的字符数量:1424

用户输入的字符数量:47

用户删除的字符数量:218

编写后端代码

编写一个PhotoPO类

交互总次数 : 

51

其中:

接受copilot提示的次数:15

用户输入的次数:21

用户删除的次数:15

--------------------

用户接受copilot提示的字符数量:1002

用户输入的字符数量:300

用户删除的字符数量:45

交互总次数 : 

14

其中:

接受copilot提示的次数:6

用户输入的次数:6

用户删除的次数:2

--------------------

用户接受copilot提示的字符数量:799

用户输入的字符数量:74

用户删除的字符数量:5

虽然这个效率很高,但因为是pojo类,实际上有更快地自动生成getter setter的方法。

所以这里效率高可能意义不大

编写后端代码

编写一个PhotoMapper接口,用来调用photoMapping.xml里面的statementID

交互总次数 : 

24

其中:

接受copilot提示的次数:11

用户输入的次数:10

用户删除的次数:3

--------------------

用户接受copilot提示的字符数量:576

用户输入的字符数量:102

用户删除的字符数量:9

交互总次数 : 

18

其中:

接受copilot提示的次数:7

用户输入的次数:8

用户删除的次数:3

--------------------

用户接受copilot提示的字符数量:463

用户输入的字符数量:140

用户删除的字符数量:21

也是个小类,行数不多

编写后端代码

编写一个MybatisUtil类,来保持链接

交互总次数 : 

36

其中:

接受copilot提示的次数:16

用户输入的次数:10

用户删除的次数:10

--------------------

用户接受copilot提示的字符数量:1188

用户输入的字符数量:224

用户删除的字符数量:74

交互总次数 : 

14

其中:

接受copilot提示的次数:7

用户输入的次数:5

用户删除的次数:2

--------------------

用户接受copilot提示的字符数量:639

用户输入的字符数量:103

用户删除的字符数量:4

这个明显好一些,不过一样,类比较简单

编写后端代码

编写一个PhotoService,完成CRUD,向controller提供服务

交互总次数 : 

79

其中:

接受copilot提示的次数:28

用户输入的次数:30

用户删除的次数:21

--------------------

用户接受copilot提示的字符数量:3005

用户输入的字符数量:363

用户删除的字符数量:280

交互总次数 : 

82

其中:

接受copilot提示的次数:29

用户输入的次数:31

用户删除的次数:22

--------------------

用户接受copilot提示的字符数量:2588

用户输入的字符数量:465

用户删除的字符数量:171

这是个大类,推荐还有一些差距,不过8成有了

编写后端代码

编写一个PhotoDO的方法类

交互总次数 : 

35

其中:

接受copilot提示的次数:13

用户输入的次数:14

用户删除的次数:8

--------------------

用户接受copilot提示的字符数量:958

用户输入的字符数量:172

用户删除的字符数量:32

交互总次数 : 

29

其中:

接受copilot提示的次数:12

用户输入的次数:12

用户删除的次数:5

--------------------

用户接受copilot提示的字符数量:817

用户输入的字符数量:209

用户删除的字符数量:15

编写后端代码

编写一个PhotoController类,处理http请求并通过PhotoService存入数据库

交互总次数 : 

118

其中:

接受copilot提示的次数:43

用户输入的次数:47

用户删除的次数:28

--------------------

用户接受copilot提示的字符数量:3662

用户输入的字符数量:610

用户删除的字符数量:66

交互总次数 : 

135

其中:

接受copilot提示的次数:59

用户输入的次数:49

用户删除的次数:27

--------------------

用户接受copilot提示的字符数量:3842

用户输入的字符数量:854

用户删除的字符数量:344

这也是大类,我接受了更多的业务框架类代码,但删除的也更多。

因此整体交互次数就会上去。

编写后端代码

编写一个启动MyApplication类,用来启动SpringBoot

交互总次数 : 

9

其中:

接受copilot提示的次数:5

用户输入的次数:4

用户删除的次数:0

--------------------

用户接受copilot提示的字符数量:402

用户输入的字符数量:30

用户删除的字符数量:0

交互总次数 : 

11

其中:

接受copilot提示的次数:5

用户输入的次数:3

用户删除的次数:3

--------------------

用户接受copilot提示的字符数量:429

用户输入的字符数量:36

用户删除的字符数量:10

编写后端测试

编写一个后端测试代码,测试PhotoService

交互总次数 : 

85

其中:

接受copilot提示的次数:34

用户输入的次数:36

用户删除的次数:15

--------------------

用户接受copilot提示的字符数量:3043

用户输入的字符数量:479

用户删除的字符数量:238

交互总次数 : 

112

其中:

接受copilot提示的次数:33

用户输入的次数:51

用户删除的次数:28

--------------------

用户接受copilot提示的字符数量:1847

用户输入的字符数量:1167

用户删除的字符数量:83

测试差距非常大。

会让我感受到的是,通义不理解我的源码。

而copilot理解

编写Html+js代码

写一个upload.html,里面包含html+js

交互总次数 : 

22

其中:

接受copilot提示的次数:8

用户输入的次数:9

用户删除的次数:5

--------------------

用户接受copilot提示的字符数量:885

用户输入的字符数量:98

用户删除的字符数量:34

交互总次数 : 

26

其中:

接受copilot提示的次数:9

用户输入的次数:10

用户删除的次数:7

--------------------

用户接受copilot提示的字符数量:1054

用户输入的字符数量:95

用户删除的字符数量:80

CICD环境准备

编写DockerFile

为项目配置一个DockerFile的配置文件

交互次数:2次

输入内容量:52

删除动作次数:0

交互次数:4次

输入内容量:101

删除动作次数:0

编写Shell脚本

设置一个NPM中国的加速镜像

交互次数:1次

输入内容量:11

删除动作次数:0

交互次数:1次

输入内容量:11

删除动作次数:1

yaml文件配置

咨询各类问题

项目配置/环境准备

我想新建一个maven项目,并通过vscode 编写代码,这个代码能通过控制台能输出helloworld

目的可执行性: 可执行

与chat交互次数:6次

目的可执行性: 不可执行

与chat交互次数:...次

灵 

发布上线

我想把这个springboot项目打成包输出并部署在阿里云容器服务上,我要怎么做

目的可执行性: 可执行

与chat交互次数:0次

目的可执行性: 可执行

与chat交互次数:2次

关键发现:

1)代码补全部分是基本可用的,有copilot的70~80%的能力

所有测试全局来看,通义的推荐效率是copilot的80%左右

具体见详细场景测试中的代码测试补全与copilot的对比部分

其中,语义简单的类,代码量小的类,通义效率比copilot高

(例如:编写Mybatis-config.xml,构建photoPO,photoDO,MapperUtil,这些简单的用于数据传输的POJO类)

但涉及到语义理解的,跨上下文携带(比如单元测试,或者需要引用其他类的代码结构复杂时),copilot的效率高于通义会让用户感觉copilot懂我。

(筛选 编写 PhotoService/Controller/做ControllerTest 这几个相对复杂的方法,进行统计)

能明显看到这类方法中,用户使用通义时所需要输入和删除的字符数更多,交互次数也更多一些。

所以在相对复杂的方法上,通义对用户语义的感知还有提升空间(具体见后表)

2)对用户代码含义理解,尤其是对用户本地输入的代码,注释和用户提出的问题的理解,距离copilot还有较大差距

这导致copilot给我的提示是真正让我觉得理解我本地的代码后才给出的建议。

这在单元测试环节尤其明显,在直接咨询通义灵码代码助手问题 ,如maven项目等相关内容,通义灵码距离copilot差距仍然较大

3)短期,通义灵码在触发时机和速度上都很流畅,但在交互层面还有一些优化的空间

触发时机

都很流畅,灵码在更能理解编码者意图,触发机制更懂我。

触发速度

都很流畅

偶尔copilot有些延迟,考虑服务器在境外

其他体验点

灵码在删除历史会话上没copilot便捷

生成多行代码时引用没有copilot便捷

编写一个mybatis-config.xml的案例里面resultMap的提示问题,在copilot里面不会的

copilot会在所有异常的地方都带一个命令,直接fix/Explain using copilot

最后:

这份测评只代表当前版本的效果,不代表插件最新的能力。同时,发稿前通义灵码的同学告知,他们已经在最新的版本中对自然语言描述生成代码能力整体提升,特别是html和c语言生成能力做了大幅提升,也欢迎大家去体验感受新版本的能力。

目录
相关文章
|
3月前
|
人工智能 文字识别 安全
大模型能力评测方式很多?
AI评测非单一分数比拼,而是多维度、多方法的系统工程。其核心框架可拆解为基础维度、主流基准与关键方法,共同构成模型能力的“CT扫描”系统。
313 0
|
6月前
|
人工智能 自然语言处理 JavaScript
通义灵码2.5实战评测:Vue.js贪吃蛇游戏一键生成
通义灵码基于自然语言需求,快速生成完整Vue组件。例如,用Vue 2和JavaScript实现贪吃蛇游戏:包含键盘控制、得分系统、游戏结束判定与Canvas动态渲染。AI生成的代码符合规范,支持响应式数据与事件监听,还能进阶优化(如增加启停按钮、速度随分数提升)。传统需1小时的工作量,使用通义灵码仅10分钟完成,大幅提升开发效率。操作简单:安装插件、输入需求、运行项目即可实现功能。
315 4
 通义灵码2.5实战评测:Vue.js贪吃蛇游戏一键生成
|
6月前
|
人工智能 自然语言处理 IDE
技术赋能新维度,灵码进化新突破:通义灵码2.5新功能尝鲜及深度评测
通义灵码是阿里云推出的基于通义大模型的智能编程助手,作为首款全栈智能辅助的国产编码工具,它为开发者提供“第二大脑”,并重构团队协作效能。2.5版本新增智能体模式,支持Qwen3系列模型,具备自主决策、工程感知和记忆能力,集成3000+MCP工具。其优势包括多模式对话体验、上下文增强、全流程工具链支持及个性化记忆功能,但仍存在上下文管理、权限控制和语言支持等方面的改进空间。此次更新标志着AI辅助开发进入全链路智能化新纪元,成为开发者真正的“结对编程伙伴”。
1148 36
|
2月前
|
人工智能 数据可视化 前端开发
AI Ping:精准可靠的大模型服务性能评测平台
AI Ping是清华系团队推出的“大模型服务评测平台”,被誉为“AI界的大众点评”。汇聚230+模型服务,7×24小时监测性能数据,以吞吐量、延迟等硬指标助力开发者科学选型。界面简洁,数据可视化强,支持多模型对比,横向对标国内外主流平台,为AI应用落地提供权威参考。
421 3
|
1月前
|
人工智能 自然语言处理 监控
58_大模型评估与评测:构建科学的多维度评测体系
在大语言模型(LLM)技术飞速发展的今天,如何科学、全面地评估和评测这些模型的能力已成为学术界和工业界共同关注的核心问题。2025年,大模型生态系统呈现出百花齐放的态势,从参数规模、架构设计到应用场景都出现了多样化的发展路径。在这种背景下,单一的性能指标或评测方法已经无法满足对大模型进行全面评估的需求。
|
5月前
|
人工智能 IDE 搜索推荐
通义灵码2.5评测:从编程智能体到记忆感知的AI编码革命
通义灵码2.5版本更新带来了多项新功能,包括Lingma IDE的开箱即用体验、编程智能体模式实现端到端编码任务、MCP工具集成扩展AI助手能力以及Qwen3模型升级大幅提升代码生成准确性和效率。此外,新增长期记忆与上下文感知功能,使开发更个性化和高效。尽管存在一些局限性,如复杂业务逻辑仍需人工干预,但整体显著提升了开发效率。官方还提供了高质量视频课程助力用户学习。
951 10
|
5月前
|
数据采集 人工智能 安全
揭秘大模型评测:如何用“说明书”式方法实现业务场景下的精准评估
本文旨在系统性地介绍如何在实际业务场景中开展大模型评测工作,帮助读者理解并掌握从需求分析、评测集设计与生成、评测维度设定、评测任务执行到评测报告输出的完整流程。
|
6月前
|
人工智能 Java API
通义灵码 2.5 版深度评测:智能编程的边界在哪里?
通义灵码 2.5 版深度评测:智能编程的边界在哪里?
201 2
|
6月前
|
传感器 人工智能 API
通义灵码2.5深度评测:编程智能体与MCP工具的革新体验
通义灵码2.5通过“智能体+MCP”组合,重新定义了AI编码助手的边界。其价值不仅在于代码生成效率,更在于通过工具链整合和环境感知,推动开发流程向“声明式编程”演进。对于开发者而言,它既是提升效率的利器,也是探索AI辅助开发边界的实验场。
467 8
|
7月前
|
算法 物联网 Swift
Qwen3 X ModelScope工具链: 飞速训练 + 全面评测
Qwen于近日发布了Qwen3系列模型,包含了各个不同规格的Dense模型和MoE模型。开源版本中,Dense模型基本沿用了之前的模型结构,差别之处在于对于Q和K两个tensor增加了RMSNorm;MoE模型去掉了公共Expert,其他结构基本与前一致。在模型大小上,涵盖了从0.6B到32B(Dense)和235B(MoE)不同的尺寸。
957 15