通义灵码与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月前
|
人工智能 自然语言处理 IDE
通义灵码使用指南
一款不用充钱也能让你变强的插件 通义灵码(TONGYI Lingma),可以称之为中国copilot 的平替品。我们一起看看如何使用安装,功能介绍,常用问题,客户测评等。
通义灵码使用指南
|
11天前
|
自然语言处理 JavaScript 前端开发
通义灵码是一款基于通义大模型的智能编码辅助工具
通义灵码是一款基于通义大模型的智能编码辅助工具
17 1
|
1月前
|
人工智能 自然语言处理 算法
CodeFuse成功支持通义千问算法大赛,评测方案已开源
首届通义千问AI挑战赛成功举办,CodeFuse 为大赛提供技术支持,模型微调框架 MFTCoder 和 CodeFuseEval 评测框架为大赛保驾护航,助力大赛圆满完成。我们基于leetcode 阿里和蚂蚁最新面试题库建设了“模型赛马”在线打榜的评测方案,目前验证集已作为 CodefuseEval 的一项任务在 Github 上开放,欢迎大家下载使用。
38 1
|
2月前
|
程序员
阿里发布通义千问!1行代码,免费对话GPT大模型
阿里发布通义千问!1行代码,免费对话GPT大模型
173 1
 阿里发布通义千问!1行代码,免费对话GPT大模型
|
3月前
|
自然语言处理 数据安全/隐私保护 开发者
通义灵码使用问题
通义灵码使用问题
130 0
|
3月前
|
自然语言处理 IDE 开发工具
通义灵码常见问题
通义灵码常见问题
312 0
|
4月前
|
测试技术 开发工具 开发者
智能编程的未来:通义灵码全功能评测
本文全面评测了通义灵码,一款智能代码撰写助手。从便捷的安装体验到高效的代码续写能力,通义灵码表现出色。它不仅能生成和解释代码,还能自动撰写单元测试,有效解答编程问题,并提供准确的错误分析。这些功能共同提升了编程效率,尤其对于新手和经验丰富的开发者都是极大的帮助,使其成为值得尝试的工具。
791 0
智能编程的未来:通义灵码全功能评测
|
4月前
|
自然语言处理 IDE 测试技术
通义灵码测评
个人测评
70873 2
|
4月前
|
SQL XML 自然语言处理
通义灵码夸赞
简述在通义灵码使用过程中的开心经历