通义灵码与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语言生成能力做了大幅提升,也欢迎大家去体验感受新版本的能力。

目录
相关文章
|
9天前
|
弹性计算 安全 开发工具
灵码评测-阿里云提供的ECS python3 sdk做安全组管理
批量变更阿里云ECS安全组策略(批量变更)
|
1月前
|
人工智能 自然语言处理 安全
创新不设限,灵码赋新能:通义灵码新功能深度评测
自从2023年通义灵码发布以来,这款基于阿里云通义大模型的AI编码助手迅速成为开发者心中的“明星产品”。它不仅为个人开发者提供强大支持,还帮助企业团队提升研发效率,推动软件开发行业的创新发展。本文将深入探讨通义灵码最新版本的三大新功能:@workspace、@terminal 和 #team docs,分享这些功能如何在实际工作中提高效率的具体案例。
|
2月前
|
自然语言处理 测试技术 开发者
通义灵码全面评测:以PyCharm为例,展示智能编码助手的强大功能
《通义灵码全面评测:以PyCharm为例,展示智能编码助手的强大功能》
|
2月前
|
自然语言处理
通义灵码个人版评测
通义灵码个人版评测
|
2月前
|
人工智能 自然语言处理 PHP
通义灵码体验评测
通义灵码体验评测
103 2
|
6月前
|
人工智能 自然语言处理 测试技术
通义灵码评测: 阿里云出品通义大模型AI代码编程辅助工具
通义灵码是阿里云出品的一款基于通义大模型的AI智能编码辅助工具,提供行级/函数级实时续写、自然语言生成代码、单元测试生成、代码注释生成、代码解释、研发智能问答、异常报错排查等能力,并针对阿里云 SDK/OpenAPI 的使用场景调优,助力开发者高效、流畅的编码。
1101 0
|
7月前
|
程序员 开发者
《开发者评测》之通义灵码评测活动获奖名单
通义灵码评测一等奖、二等奖、潜力奖获奖名单正式公布!
305 0
|
测试技术 开发工具 开发者
智能编程的未来:通义灵码全功能评测
本文全面评测了通义灵码,一款智能代码撰写助手。从便捷的安装体验到高效的代码续写能力,通义灵码表现出色。它不仅能生成和解释代码,还能自动撰写单元测试,有效解答编程问题,并提供准确的错误分析。这些功能共同提升了编程效率,尤其对于新手和经验丰富的开发者都是极大的帮助,使其成为值得尝试的工具。
1584 0
智能编程的未来:通义灵码全功能评测
|
16天前
|
人工智能
带上团队一起来做 AI 编程实践丨通义灵码联合TGO鲲鹏会开启 AI 大课
带上团队一起来做 AI 编程实践丨通义灵码联合TGO鲲鹏会开启 AI 大课
|
12天前
|
人工智能 搜索推荐 安全
数百名研发人员用通义灵码,33%新增代码由AI生成,信也科技研发模式焕新升级
目前,信也科技数百名研发人员正在使用通义灵码,周活跃用户占比70%,新增代码中有33%由通义灵码编写,整体研发效率提升了11%,真正实现了数百研发人员开发效能的全面提升。

热门文章

最新文章