写在开头

这几个月AI相关新闻的火爆程度大家都已经看见了，作为一个被裹挟在AI时代浪潮中的程序员，在这几个月里我也是异常兴奋和焦虑。甚至都兴奋的不想拖更了。不仅仅兴奋于AI对于我们生产力的全面提升，也焦虑于Copilot等AI辅助编码工具，会将程序员这个工种和我们所熟悉的传统软件开发流程彻底颠覆，用计算机的极高效率碾压人类的低效率.

当然这些也都是后话了，我们目前能做的，就是保持敏锐的嗅觉，尝试去迎接AI时代的来临。做“未来世界的幸存者”.

本文是我深度体验了Github Copilot, ChatGPT等产品后，对于这些AI辅助开发工具的一次横向评测。写本文的初衷是帮助大家快速筛选出一款合适你的AI辅助工具。相信我， 请不要再怀疑 这些工具是否能给你带来效率提升。当你尝试使用后，很快就会习惯它们，甚至是离不开它们.

本文评测的工具有:

• Github Copilot
• ChatGPT(GPT-3.5)
• New Bing
• Cursor.so

这些工具可以结合起来使用，提升你的开发效率。所以这些工具之间并不是互斥关系。文章的最后会给出总结以及我的一些想法.

Github Copilot

Github Copilot是由Github和OpenAI合作推出的一个人工智能代码辅助工具，采用了OpenAI的GPT技术，能够为开发人员提供实时的代码提示和生成功能，类似于一个AI助手，帮助开发人员更快速、更方便地编写代码.

当前的Github Copilot基于GPT-3模型，它可以分析上下文并根据已有的代码和注释来推断出应该写什么代码。通过使用Github Copilot，开发人员可以减少手动输入代码的时间，提高代码的质量和效率。它支持多种编程语言，如Python、JavaScript、TypeScript、Ruby等，并可以与主流的集成开发环境（IDE）和文本编辑器配合使用.

使用体验

我已经深度使用了Copilot接近一个月，但每当我和同事朋友们聊到Copilot的使用体验，以及它在哪方面能够提高我的效率时，我仍很难用语言去描述，我只能粗略的总结为下面几个结论:

• 编写你熟悉的语言时，他仅能帮助你减少一些重复模板代码的编写。编写你不熟悉的语言时，他能够准确推断你的意图，直接生成代码，免除了查询如何使用API的耗时工作
• 它顺着你的心流生成片段代码，但很难从0开始为你创造整段代码，即使它是可以生成整段代码的，但是也常常是需要你手工修改的。

接下来看一下我常用的几种使用方式.

1. 根据上下文生成代码

它可以根据函数名，类名，注释，来推断你想写的代码，帮你填充.

2. 根据代码生成注释

反过来，它可以尝试理解你的代码，为你生成注释，你只需要给他一个 // 前缀 。

3. 帮你起变量名

它可以帮你器变量名，这可是很多英语不好的程序员的大福音。毕竟，编码的30%时间，是在想变量名.

4. 和你聊天，当然，是聊代码！

你没有听错，copilot可以在你的代码里聊天，但是显然不能和他唠家常。它并不是chatGPT，无法给你常识回答（应该是被故意限制了交流范围），只会和你扯皮.

正确的使用方式是让它和你讨论你写代码，他会总结你的上下文代码，并且给你一个它认为“合理”的解释.

以上就是我常用的几种方式，我查阅了很多资料，基本上面涵盖了大部分操作方式。当然，可能还有我没挖掘到的使用方式.

编码能力

说完使用体验，我想要引出我本次横向评测的一个评测标准，就是通过相近的试题，看下这几个工具的编码能力有何区别，给大家直观地对比。我们就先从Copilot开始.

独立编写：单例模式

我给它们设定的题目是独立写一个单例模式，这个题目是国内Java开发者“常考题”，里面除了基本的代码，还有很多细节需要注意，也可以很好的用来向AI们提问，看看它们是否真正地理解它们写的内容.

让我们欢迎第一位选手，Github Copilot.

上面的编码动画也是我认为最符合我日常使用copilot的案例，从创建类文件后，copilot帮我自动生成了私有变量，私有构造方法，以及获取单例的公有方法。在写公有方法的期间，它最开始的代码没有考虑双重检查锁，我给了它一些提示，它补全了剩余的代码.

需要注意的是，由于单例模式在网上有太多的学习资料，Copilot肯定也吸取了大量优秀代码，才能写的如此高效。并不代表所有复杂的代码题都能够帮你自动补全，并保证正确性。所以大家谨慎看待它的独立编码能力，也不要过分乐观.

补全项目现有代码

第二个测试，我们让它补全项目的现有代码，我拿一个我自己写的代码举例，其中有一个DiffDTO实体类，有一个addDiffDTO方法一行都没写，需要补全.

可以看到它自动补全了代码，并且会用到上面已有的方法和变量。这也是它的强项，根据上下文信息推断代码该怎么补全，写出来的代码质量很高，不能说每次都可直接使用，但80%的情况下你是无需做大幅度修改的.

不足之处

Github Copilot有不足之处吗？我想了想，有以下几点:

• 所有代码上下文通过https传到云端（微软的服务器），尽管我通读了微软的隐私保护政策，它承诺不会有任何代码被泄露。但放在国内网络安全大环境下，这样的处理数据方式，在国内公司内使用很可能会受到影响，需要用户注意。
• 对于复杂的代码逻辑，比如连你都一下子看不懂的屎山代码，它的理解能力同样欠缺。它擅长的是网络上有很多公开资料的代码段落和实现方式。

ChatGPT

让我们来看下一位选手，最近火出圈的chatGPT.

chatGPT是一款基于GPT模型的聊天机器人，它可以像人类一样进行自然语言对话。它不仅可以回答用户的各种问题，还可以学习和理解用户的需求，提供更恰当的回答和建议.

得益于其基于GPT模型的强大语言处理能力。GPT模型可以理解代码中的自然语言描述部分。其次，chatGPT在训练阶段使用了大量的代码相关文本语料，包括代码库、API文档、程序员交流论坛等，因此具有一定的代码理解和识别能力。此外，chatGPT还可以通过不断的学习和自我优化，逐渐提高其对于代码相关问题的处理能力和准确度.

我文中使用的chatGPT是GPT-3.5版本。我们直接进入正题，看看它的编码能力。由于是对话方式，所以我们需要向它描述我们的需求.

编码能力

独立编写：单例模式

我:

请用Java写一个单例模式 。

ChatGPT:

                          
                            public class Singleton {
​
 private static Singleton instance;
​
 private Singleton() {
 // 私有构造函数
 }
​
 public static synchronized Singleton getInstance() {
     // 双重检查锁定
     if (instance == null) {
        synchronized (Singleton.class) {
           if (instance == null) {
               instance = new Singleton();
           }
       }
     return instance;
      }
   }
}
​
// 使用方法
Singleton s = Singleton.getInstance();

                          
                        

写的不错，很有面试题刷多了的开发人员的风格，写了经常会被问到的双重校验锁，但是没有用volatile，让我们继续发问.

我:

为何要用双重检查锁定?

ChatGPT:

双重检查锁定（double-checked locking）是一种常见的单例模式的实现方式。它的目的是在不使用同步锁的情况下实现单例模式的线程安全，避免了每次获取对象实例时都进行同步锁的开销。但是，这种实现方式也有可能存在线程安全问题.

具体来说，双重检查锁定是在 getInstance 方法中加入了双重检查，即先判断实例是否已经存在，如果不存在再进行同步锁的操作。这样可以减少同步锁的开销，提高了效率.

但是，在多线程环境下，双重检查锁定也有可能出现线程安全问题，原因是在某些情况下，多个线程可能同时通过第一重检查，然后同时进行同步锁的操作，导致出现多个实例.

为了避免这种情况，需要将 getInstance 方法设置为 synchronized 关键字，保证在同一时刻只有一个线程可以访问该方法，从而避免多个实例的出现。但是，这样会带来一定的性能开销，因为每次访问 getInstance 方法都需要进行同步锁操作.

讲得不错，但很难不让人觉得是看多了面试文章。我们顺着volatile的问题继续问问他为啥不写volatile.

我:

上面的代码依然有漏洞，可以优化下吗 。

ChatGPT:

是的，即使使用了双重检查锁定，上面的代码仍然有漏洞，也就是可能出现线程安全问题。为了解决这个问题，可以使用 Java5 中引入的 volatile 关键字，通过禁止指令重排来保证线程安全.

优化后的代码如下:

                          
                            public class Singleton {
private static volatile Singleton instance;
​
private Singleton() {
// 私有构造方法
}
​
public static Singleton getInstance() {
    if (instance == null) {
        synchronized (Singleton.class) {
            if (instance == null) {
            instance = new Singleton();
            }
        }
    return instance;
    }
}
}
​

                          
                        

上面的代码中，我们将 instance 字段添加了 volatile 关键字，这样可以保证在多线程环境中，instance 变量的读取和赋值操作是原子性的，即保证了线程的可见性和有序性，从而避免了出现多个实例的情况.

注意，这里的 volatile 关键字只是作用于 instance 字段本身，而不是整个 getInstance 方法。这样做可以减小同步锁的范围，提高了效率.

它自己想到并解决了volatile的细节问题，我们再结合他写的代码，问问一些面试官会问的问题.

我:

上面的代码中，同步的是一个Singleton.class，可以用int变量代替吗 。

ChatGPT:

不可以，使用 int 变量代替 Singleton.class 进行同步是不可行的.

因为在 Java 中，每个类都有一个唯一的 Class 对象，多个线程使用同一个类的 Class 对象进行同步，可以保证线程安全。而使用 int 变量进行同步，由于 int 是基本数据类型，它在内存中的每一份拷贝都可能不同，因此不能保证多个线程都使用同一个 int 变量进行同步，从而无法保证线程安全.

此外，使用 Class 对象进行同步还有一个好处，即可以保证实例变量的可见性，因为同步代码块中的读写操作都是在同一条线程中执行的.

因此，使用 Singleton.class 对象进行同步是保证线程安全的最佳方式，不建议使用其他方式进行同步.

回答的不错，理解了我提示语中的 Singleton.class 是指的它自己代码中的类，最后问一个volatile的细节.

我:

上面的代码中，如果不使用volatile，有可能会出现重排序问题，能具体展开讲讲吗 。

ChatGPT:

是的，如果没有使用volatile关键字，就有可能出现重排序问题.

在Java中，编译器和处理器都会对指令进行重排序，这是为了优化程序性能。例如，在一个if语句中，为了避免每次都进行判断，编译器可能会将判断条件提前到if语句外面。在单线程环境下，这种重排序是没有问题的，因为程序执行的结果是一样的。但是，在多线程环境下，重排序可能会导致线程安全问题.

考虑下面的代码:

                          
                            public class Singleton {
private static Singleton instance;
​
private Singleton() {}
​
public static Singleton getInstance() {
    if (instance == null) {
        synchronized (Singleton.class) {
            if (instance == null) {
            instance = new Singleton();
            }
        }
    return instance;
    }
}
}

                          
                        

在这个代码中，如果没有使用volatile关键字，就有可能出现下面的重排序:

0. 线程A调用getInstance()方法，发现instance为null，进入同步块。
1. 线程B调用getInstance()方法，由于instance还没有被初始化，也发现instance为null，也进入同步块。
2. 线程A执行instance = new Singleton()，在执行该语句时，可能会被重排序为下面这样：

                          
                            memory = allocate(); //1：分配对象的内存空间
ctorInstance(memory); //2：初始化对象
instance = memory; //3：将对象赋值给instance变量

                          
                        

这个重排序是允许的，因为在单线程环境下，这个顺序和原来的顺序没有区别。但是，在多线程环境下，这个重排序可能会导致线程安全问题，因为线程B此时检查instance不为null，就会直接返回instance，这个instance还没有被初始化，就会导致错误.

为了避免这种情况，可以使用volatile关键字来确保instance变量的可见性，从而避免重排序问题.

上面的对话，是一个典型的面试题，网上有很多文章也会顺着这个思路写下来，所以chatGPT回答的得心应手，并不代表在所有代码优化方面都能回答的这么细节和流畅。但不得不说，如果你第一次用chatGPT，你还是会被它的能力和思路所震惊.

接下来我们让chatGPT解决一个kotlin中并发接口的设计，看看它对于不那么常见的复杂问题的解决能力 。

独立编写：Kotlin+Reactor设计并发接口

这是我在 实际开发过程中遇到的一个比较难写的代码例子 ，在kotlin中使用reactor框架来写一个批量查询接口，由于性能要求，该接口中的每个查询必须并发执行（线程池执行）。我把这个遇到的实际问题作为测试的case，让我们来问问chatGPT.

我:

Kotlin中，如何用reactor框架写一个并发处理的方法，要求入参是List ，方法中将字符串后面拼接同样的字符串，输出List 。

ChatGPT:

您可以使用Reactor框架中的 Flux 来实现这个要求。下面是一个示例代码:

                          
                            import reactor.core.publisher.Flux
import reactor.core.scheduler.Schedulers
​
fun processStrings(strings: List<String>): List<String> {
      val flux = Flux.fromIterable(strings)
      .flatMap { str -> Mono.fromCallable { str+str }
      .subscribeOn(Schedulers.parallel())
  }
  return flux.collectList().block() ?: emptyList()
}
​

                          
                        

在这个例子中，我们使用 Flux.fromIterable 方法创建一个 Flux ，并使用 flatMap 方法处理每个字符串。在 flatMap 中，我们使用 Mono.fromCallable 方法来创建一个异步执行的函数，该函数将每个字符串转为大写。同时我们使用 Schedulers.parallel() 指定执行该函数的调度器，以实现并发执行的效果.

最后，我们使用 collectList() 方法等待所有异步操作完成并将结果作为 List<String> 返回.

需要注意的是，我们使用了并发执行，因此结果顺序可能与输入顺序不同。如果您需要保持结果顺序与输入顺序相同，可以使用 concatMap 方法代替 flatMap .

在它给出的代码上，我加入了一个随机休眠的函数来验证是否代码真的执行了异步，并且给了它入参 [0-9]，然后执行，事实证明chatGPT给出的代码直接可以跑通，并且真正是并行执行的。给出结果:

                        
                          Current ThreadName: parallel-1  sleep time: 188
Current ThreadName: parallel-2  sleep time: 483
Current ThreadName: parallel-3  sleep time: 785
Current ThreadName: parallel-4  sleep time: 524
Current ThreadName: parallel-5  sleep time: 175
Current ThreadName: parallel-6  sleep time: 894
Current ThreadName: parallel-7  sleep time: 440
Current ThreadName: parallel-8  sleep time: 158
Current ThreadName: parallel-9  sleep time: 227
Current ThreadName: parallel-10  sleep time: 300
Result:[99, 33, 66, 1010, 22, 11, 44, 77, 88, 55]

                        
                      

但是它的代码中使用了flatMap并没有保证返回结果List中的顺序和入参顺序相同，对于我的需求来说这是不可接受的，chatGPT在刚才的回答中考虑到了这个问题，告诉了我解决方案，使用concatMap代替，于是我修改为concatMap，结果如下

                        
                          Current ThreadName: parallel-1  sleep time: 933
Current ThreadName: parallel-2  sleep time: 715
Current ThreadName: parallel-3  sleep time: 278
Current ThreadName: parallel-4  sleep time: 182
Current ThreadName: parallel-5  sleep time: 14
Current ThreadName: parallel-6  sleep time: 313
Current ThreadName: parallel-7  sleep time: 228
Current ThreadName: parallel-8  sleep time: 650
Current ThreadName: parallel-9  sleep time: 554
Current ThreadName: parallel-10  sleep time: 334
Result:[11, 22, 33, 44, 55, 66, 77, 88, 99, 1010]

                        
                      

看上去一切ok，但其实问题很大。使用了concatMap后，实际上使用concatMap的这段代码并没有真正的并发执行，而是类似串行的方式，得到了结果。（本文不具体展开解释为何使用了concatMap后会有如此效果） 。

既然答案和我想要的有偏差，那就继续追问chatGPT.

我:

这段代码如何在保证返回值顺序和入参顺序相同的情况下，真正的并发执行?

ChatGPT:

可以使用flatMapSequential操作符替换concatMap操作符来实现真正的并发执行，并且保证返回值顺序和入参顺序相同.

修改后的代码如下:

                          
                            fun processStrings(strings: List<String>): List<String> {
     val flux = Flux.fromIterable(strings)
         .flatMapSequential { str ->
             Mono.fromCallable {
                 str+str
             }.subscribeOn(Schedulers.parallel())
         }
     return flux.collectList().block() ?: emptyList()
}

                          
                        

                        
                          Current ThreadName: parallel-1  sleep time: 755
Current ThreadName: parallel-2  sleep time: 342
Current ThreadName: parallel-3  sleep time: 340
Current ThreadName: parallel-4  sleep time: 562
Current ThreadName: parallel-5  sleep time: 405
Current ThreadName: parallel-6  sleep time: 399
Current ThreadName: parallel-7  sleep time: 250
Current ThreadName: parallel-8  sleep time: 351
Current ThreadName: parallel-9  sleep time: 169
Current ThreadName: parallel-10  sleep time: 118
Result:[33, 22, 11, 44, 55, 66, 77, 88, 99, 1010]

                        
                      

chatGPT回答基本正确了.

不过，有时候提问同样的问题，chatGPT会给出很多种错误答案，有的是编译错误，有的是串行执行不符合我的要求，以至于我不得不重新提问了好几次。这个过程中，我没有好好做截图。但我发现它其实就是在给出一些网络上常见的博客写的解法，很多时候都是错误的，或者说其实并不对应我对它的诉求.

不足之处

chatGPT针对代码方面的回答做了很多特殊的调优，所以它能够作为一个帮助程序员编码的工具。很多时候，我都更愿意问chatGPT而不是自己去谷歌答案。这已经证明了我足够信任它。如果要说有什么不足之处，我想到以下几点:

• 面对不常见的复杂代码设计题，没有做到优秀的水平，但相信未来不断地训练后，会变得更加完善。
• 它不能全程辅助你编码，这一点比不上Copilot。
• 它不能阅读你整个项目的代码，无法和Copilot一样有强大的上下文能力。当然你可以手动给他很多上下文代码，但是相比Copilot肯定还是差距很大。毕竟Copilot可能阅读了你整个项目后给出一些建议。

New Bing

引用New Bing官网的介绍，New Bing 就像您在搜索⽹络时身边有⼀个研究助理、个⼈规划师和创意伙伴。您可以问你的实际问题，当你提出复杂的问题时，Bing 会给你详细的答复。 得到⼀个实际的答案。 Bing 会查看⽹络上的搜索结果，为您提供⼀个总结性的答案。 要有创意。当你需要灵感时，必应可以帮你写诗、写故事，甚⾄为你创造⼀个全新的形象.

总的来说，你可以理解为New Bing是一个chatGPT + Bing搜索引擎内网络信息 的加强版对话机器人.

使用体验

New Bing目前已经和谐了国内的IP，用国内IP访问任何new Bing相关的网页会强制跳转的Bing搜索首页。所以需要打开科学工具后使用，本文不具体展开。网上有很多攻略可查.

编码能力

我们仍然使用刚才的测试例子（单测+Kotlin并发接口）来测试NewBing的代码编写能力。Bing有三种对话模式可选，需要选到“更多 精确”，这种模式下，它会认认真真地给我们写代码.

独立编写：单例模式

我们直接提问，请看截图.

给出的代码比较基础，让我们追问下，让他修改.

它修改的很快，现在代码基本已经成型了。让我们和之前测试chatGPT提问一模一样的问题.

可以看到，页面下方，他还会给一些符合你问题上下文的推荐提示.

独立编写：Kotlin+Reactor设计并发接口

让我们来欣赏一下NewBing面对复杂问题的编码能力.

将它写的代码放入Demo，编译不通过.

继续质问它 。

最终它完成了代码，但是写法在我看来有些奇怪。整体来看，和chatGPT的使用体验是相似的.

不足之处

NewBing和chatGPT相比，给我感觉不分伯仲，面对不常见的复杂代码设计题，依然有一些力不从心。并且，不知道是不是使用了搜索引擎内的原因，比chatGPT更容易出现错误的结果.

相比Github Copilot，则和chatGPT一样，由于没有足够的代码上下文，对你的帮助远没有Copilot那么好用.

Cursor.so

Cursor.so 是 OpenAI 最近推出的一款IDE，它可以帮助你提供想法并编写代码。最值得一提的是，它是一款免费软件，OpenAI 还承诺将持续更新和改进，为用户带来更多新的功能和体验.

为什么它会受到关注，主要是因为它能够免费使用内置了类似Github Copilot的插件，毕竟Copilot是付费软件，很多小伙伴还没法免费体验到.

编码能力

独立编写：单例模式

cursor主要有两个功能，一个可以自动生成代码edit，一个是根据当前代码进行聊天chat。各自有独立的快捷键来启动.

我们让他写一个Java中的单例模式类，快捷键command+K，输入中文 ”写一个线程安全的单例模式“，它给出了如下答案.

                        
                          public class Singleton {
    private static volatile Singleton instance;
    private Singleton() {}
    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

                        
                      

写的不错，带上了双重校验和volatile，很像是熟读面试代码的面试者。既然本段代码没什么细节问题，那就试用下聊天功能command+L 。

解释的和chatGPT以及NewBing都类似，并且还支持聊天历史记录展示.

补全项目现有代码

让他补全之前Copilot补全过的同样测试代码，写入threadLocal变量的代码，可以完成.

当我准备更进一步问问他对于这个代码怎么看的时候，它服务开始了长时间的不稳定.

不足之处

服务不稳定

不支持插件

没有插件市场，甚至没有集成版本控制，比如Git，在UI中没法查看改动的代码，所以几乎已经告别了开发大型项目了。只要稍微做一些代码改动，你就会忘记了代码的改动是哪里.

基础功能缺失

比如打开一个项目文件夹后居然不支持关闭，文件类型没有高亮区分，整体用下来感觉Cursor.so还处于一个很早期的阶段.

总结

最后，总结下这几个产品作为一个AI辅助编码工具的优缺点.

Github Copilot:

优点:

• 可以根据提示自动生成代码，提高开发效率。
• 可以学习你项目中的代码风格，获取足够多的上下文，并根据其生成代码。
• 支持多种编程语言，适用范围广。

缺点:

• 可能会存在隐私问题

chatGPT和New Bing:

优点:

• 随时随地可用，不依赖代码项目，是你查询谷歌时的完美替代品。

缺点:

• 它不能全程辅助你编码，这一点比不上Copilot，并且无法和Copilot一样有强大的上下文能力。
• 对于复杂的代码逻辑，理解能力未必能让你满意。

Cursor.so 。

优点:

• 免费的同时能够体验AI辅助编程，就是最大的优点

缺点:

• 基础功能缺失，不能称之为一个可靠的IDE
• 服务不稳定

一句话总结，如果你希望将这几个产品用于辅助你编程，提高编码效率，使用Github Copilot结合chatGPT是一个可行的方式。你可以在编写代码时使用Github Copilot，遇到问题时再求助chatGPT。如果暂时不想为Github Copilot付费，可以只使用chatGPT。不过，由于Cursor.so的使用体验不够好，且不易替代Github Copilot，建议还是等待Cursor.so之后的版本.

最后此篇关于谁能真正替代你？AI辅助编码工具深度对比（chatGPT/Copilot/Cursor/NewBing）的文章就讲到这里了,如果你想了解更多关于谁能真正替代你？AI辅助编码工具深度对比（chatGPT/Copilot/Cursor/NewBing）的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。