?作者 | 徐杰承

審校 | 言征

正當谷歌與微軟為搶占AI搜索引擎市場爭得不可開交時，一部分程序員卻無心吃瓜。因為他們已經(jīng)提前意識到了，當這場搜索之戰(zhàn)落下帷幕后，軟件巨頭們將繼續(xù)攜帶著ChatGPT或其他人工智能生成工具，向著自動編碼的藍海大步進發(fā)。到時別說是吃瓜，連自己的飯碗都有可能受到威脅。

在如今的自動編碼領域，最成熟且最為人熟知的兩款AI，正是近來風頭無兩的ChatGPT以及微軟于去年6月上線的AI編程工具Copilot，而這“二位”也正是現(xiàn)階段最被寄予厚望將取代程序員的當紅明星。那么就目前而言，ChatGPT與Copilot的編碼能力究竟如何，是否真如傳言所說將在短期內取代所有初級甚至部分中級開發(fā)者呢？

日前，一位美國技術專家利用多個JavaScript函數(shù)需求，測試了ChatGPT與Copilot在數(shù)據(jù)處理與算法生成方面的能力。接下來，就讓我們一起通過這些結果來了解一下目前AI在編碼方面的真實水平，然后捫心自問，自己是否真的將會被取代呢？

1、JavaScript函數(shù)接受可變數(shù)量數(shù)組并返回交集

第一場測試中，測試者首先要求ChatGPT和Copilot生成一個JavaScript函數(shù)，具體條件為：需要能接受可變數(shù)量的數(shù)組并返回它們的交集。

OpenAI ChatGPT：

微軟 Copilot：

對此ChatGPT所生成的函數(shù)假定提供少于一個數(shù)組是無效的。通過使用Set，ChatGPT確保結果中不存在重復項。交集應該是一個集合操作，重復的應該被刪除。Copilot代碼則返回了一個可能包含重復項的數(shù)組。

而ChatGPT和Copilot都沒有按照長度對原始參數(shù)進行升序排序，這是一個微不足道的優(yōu)化，卻能帶來巨大的改變。如果任何參數(shù)的長度為0，則沒有交集；不管怎樣，它縮短了循環(huán)，因為最大交集與最短數(shù)組參數(shù)相同。

隨后，測試者要求ChatGPT和Copilot提高函數(shù)的執(zhí)行效率。

OpenAI ChatGPT：

微軟 Copilot：

面對以上問題，Copilot生成了與此前請求相同的代碼。而ChatGPT給出了不同的答案并添加了評論，稱該函數(shù)不會像預期那樣對對象起作用，但這項描述并不準確。

而后，測試者利用相同方式檢驗了ChatGPT與Copilt所提供的兩個最快交集庫所生成代碼的運行效率和內存消耗情況。

ChatGPT所生成代碼執(zhí)行時所占用的CPU較低，但運行效率并不理想，而Copilot生成代碼雖然對于堆的使用量較低，但CPU占用率和運行效率較差。

總而言之，在這項測試中ChatGPT與Copilot都無法生成足夠高效的代碼；ChatGPT在該問題中給出的假設有誤；而Copilot所生成的函在參數(shù)包含重復值時，會生成不產(chǎn)生集合的代碼。

2、JavaScript函數(shù)：笛卡爾積

第二場測試，則是要求ChatGPT與Copilot完成一個笛卡爾積的JavaScript函數(shù)。

OpenAI ChatGPT：

微軟 Copilot：

熟悉笛卡爾積的人都會知道，從內存利用率和性能的角度看，ChatGPT和Copilot所生成的結果都是爆炸性的。簡單的實現(xiàn)將消耗大量的RAM用以存儲所有的組合，并且直到所有組合生成后才能返回結果。ChatGPT和Copilot所生成的函數(shù)都存在這些缺點。

隨后，測試者再次要求ChatGPT和Copilot提高函數(shù)效率。

OpenAI ChatGPT：

微軟 Copilot：

針對這項需求，ChatGPT的表現(xiàn)令人感到驚喜。但在整體函數(shù)中，ChatGPT犯了一個嚴重的錯誤，yield [item,...result]并不在生成器內部，而是在一個recursion之中。而Copilot則直接無視了需求變化，返回了與此前相同的結果。

在代碼運行效率及內存消耗情況方面，ChatGPT和Copilot的表現(xiàn)則如下表所示。

總體看來，ChatGPT與Copilot均無法生成笛卡爾積函數(shù)的正確代碼；ChatGPT會作出可能無效的假設，例如需要兩個參數(shù)；雖然檢測結果顯示ChatGPT生成的代碼內存效率更高，但其根本無法順利運行。

3、JavaScript函數(shù)儲存對象與原始參數(shù)

第三回合，測試人員要求二者生成能夠存儲對象和原始參數(shù)的JavaScript函數(shù)。

OpenAI ChatGPT：

微軟 Copilot：

對此，ChatGPT與Copilot均生成了較為低效的代碼，先進行字符串轉化再進行字符串比較的效率很差，并且會大量消耗內存。

雖然有一些JavaScript值無法被轉化為字符串，例如Infinity和NaN。但遺憾的是，JavaScript JSON規(guī)范是在數(shù)據(jù)科學和微服務時代之前定義的，而這些值的存在主要是為了在代碼出現(xiàn)某些錯誤條件時，程序還可以用特定的值來表示所產(chǎn)生結果。

最后，為驗證函數(shù)效率，測試者將ChatGPT與Copilot所生成的代碼與常用緩存工具nano-memoize 和micro-memoize進行了橫向對比，使用以下代碼生成第12個斐波那契數(shù)列。

其中nano-memoize是運行效率最高的，幾乎是ChatGPT和Copilot所生成代碼運行效率的兩倍，并且其所使用的內存也是最低的，而micro-memoize的表現(xiàn)則可以說緊隨其后。雖然在CPU利用率方面，Copilot表現(xiàn)不錯，但綜合來看，ChatGPT和Copilot在這場測試中的表現(xiàn)依然不足以擊敗一個成熟的程序員。

4、總結與預測

通過這三場測試，我們不難發(fā)現(xiàn)，雖然使用ChatGPT和Copilot所生成的代碼肯定具有一定價值。但就目前而言，無論是ChatGPT還是Copilot，均無法通過簡單的任務描述生成足夠準確且高效的代碼，甚至在某些情況下，它們也會犯下一些非常糟糕的錯誤。在得知這個結果后，不少開發(fā)者也分分表示：感覺自己還能再堅持幾年。

對于如今的企業(yè)或是程序員而言，如果你希望利用ChatGPT、Copilot或是其他代碼生成工具幫助自己完成一些簡單的輔助編碼任務以加速構建，那么你完全能夠得到足夠的支持。但如果希望依靠它們徹底解放研發(fā)，那么你可能需要花大價錢為其配備一整支強大的調試團隊。

然而即便結果如此，今天的我們仍不能忽視AI在自動編碼領域的潛力以及這些系統(tǒng)背后強大的軟件企業(yè)。可以肯定的是，伴隨著訓練量與技術成熟度的增長，未來的自動編碼工具將繼續(xù)擴充其在不同場景的業(yè)務數(shù)據(jù)，并逐步嘗試解決一些更專業(yè)、更場景化的實際任務。

最后，對于“AI到底能否在未來取代程序員”這個問題，目前最可靠的答案，也許就是前阿里以色列機器視覺實驗室負責人Itamar Friedman在一次采訪中所做出的預測了——“在未來的10到20年內，人工智能系統(tǒng)將可能使非程序員的創(chuàng)造者使用自然語言指令進行0錯誤的開發(fā)，屆時我們的世界仍會需要大量的程序員，但其角色將可能會發(fā)生難以預測的變化。”

參考鏈接：

https://medium.com/@anywhichway/chatgpt-vs-copilot-vs-programmers

https://github.com/anywhichway/nano-memoize

https://github.com/planttheidea/micro-memoize