本文是我深度體驗了Github Copilot, ChatGPT等產品后，對于這些AI輔助開發工具的一次橫向評測。寫本文的初衷是幫助大家快速篩選出一款合適你的AI輔助工具。相信我，**請不要再懷疑**這些工具是否能給你帶來效率提升。當你嘗試使用后，很快就會習慣它們，甚至是離不開它們。

寫在開頭

這幾個月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之后的版本。