作者| 徐傑承
審校| 言徵
正當谷歌與微軟為搶佔AI搜尋引擎市場爭得不可開交時，一部分程式設計師卻無心吃瓜。因為他們已經提前意識到了，當這場搜尋之戰落下帷幕後，軟體巨頭們將繼續攜帶著ChatGPT或其他人工智慧生成工具，朝著自動編碼的藍海大步進發。到時別說是吃瓜，連自己的飯碗都有可能受到威脅。
在現今的自動編碼領域，最成熟且最為人所知的兩款AI，正是近來風頭無兩的ChatGPT以及微軟於去年6月上線的AI程式設計工具Copilot ，而這「二位」也正是現階段最被寄予厚望將取代程式設計師的當紅明星。那麼就目前而言，ChatGPT與Copilot的編碼能力究竟如何，是否真如傳言所說將在短期內取代所有初級甚至部分中級開發者呢？
日前，一位美國技術專家利用多個JavaScript函數需求，測試了ChatGPT與Copilot在資料處理與演算法生成方面的能力。接下來，就讓我們一起透過這些結果來了解一下目前AI在編碼方面的真實水平，然後捫心自問，自己是否真的將會被取代呢？
1、JavaScript函數接受可變數量數組並傳回交集
#第一場測試中，測試者首先要求ChatGPT和Copilot產生一個JavaScript函數，具體條件為：需要能接受可變數量的陣列並傳回它們的交集。
OpenAI ChatGPT：
微軟Copilot：
#對此ChatGPT所產生的函數假定提供少於一個陣列是無效的。透過使用Set，ChatGPT確保結果中不存在重複項。交集應該是集合運算，重複的應該被刪除。 Copilot程式碼則傳回了一個可能包含重複項的陣列。
而ChatGPT和Copilot都沒有按照長度對原始參數進行升序排序，這是一個微不足道的優化，卻能帶來巨大的改變。如果任何參數的長度為0，則沒有交集；不管怎樣，它縮短了循環，因為最大交集與最短數組參數相同。
隨後，測試者要求ChatGPT和Copilot提高函數的執行效率。
OpenAI ChatGPT：
微軟Copilot：
#面對以上問題，Copilot產生了與先前請求相同的程式碼。而ChatGPT給出了不同的答案並添加了評論，稱該函數不會像預期那樣對對象起作用，但這項描述並不準確。
######而後，測試者利用相同方式檢驗了ChatGPT與Copilt所提供的兩個最快交集庫所產生程式碼的運作效率和記憶體消耗情況。 ###########################ChatGPT所產生程式碼執行時所佔用的CPU較低，但運作效率並不理想，而Copilot生成程式碼雖然對於堆的使用量較低，但CPU佔用率和運作效率較差。 ############總而言之，在這項測試中ChatGPT與Copilot都無法產生足夠高效的程式碼；ChatGPT在這個問題中給出的假設有誤；而Copilot所產生的函在參數包含重複值時，會產生不產生集合的程式碼。 ############2、JavaScript函數：笛卡爾積#############第二場測試，則是要求ChatGPT與Copilot完成一個笛卡爾積的JavaScript函數。 ############OpenAI ChatGPT：###########################微軟Copilot：################################################################################### ###################
熟悉笛卡爾積的人都會知道，從記憶體利用率和效能的角度來看，ChatGPT和Copilot所產生的結果都是爆炸性的。簡單的實作將消耗大量的RAM以儲存所有的組合，並且直到所有組合產生後才能傳回結果。 ChatGPT和Copilot產生的函數都存在這些缺點。
隨後，測試者再次要求ChatGPT和Copilot提高函數效率。
OpenAI ChatGPT：
微軟Copilot ：
針對這項需求，ChatGPT的表現令人感到驚訝。但在整體函數中，ChatGPT犯了一個嚴重的錯誤，yield [item,...result]並不在生成器內部，而是在一個recursion之中。而Copilot則直接無視了需求變化，回傳了與先前相同的結果。
在程式碼運作效率及記憶體消耗情況方面，ChatGPT和Copilot的表現則如下表所示。
整體看來，ChatGPT與Copilot都無法產生笛卡爾積函數的正確程式碼；ChatGPT會做出可能無效的假設，例如需要兩個參數；雖然偵測結果顯示ChatGPT產生的程式碼記憶體效率較高，但其根本無法順利運作。
3、JavaScript函數儲存物件與原始參數
第三回合，測試人員要求二者產生能夠儲存物件與原始參數的JavaScript函數。
OpenAI ChatGPT：
微軟Copilot：
#對此，ChatGPT與Copilot都產生了較為低效的程式碼，先進行字串轉換再進行字串比較的效率很差，並且會大量消耗記憶體。
雖然有些JavaScript值無法轉換為字串，例如Infinity和NaN。但遺憾的是，JavaScript JSON規範是在資料科學和微服務時代之前定義的，而這些值的存在主要是為了在程式碼出現某些錯誤條件時，程式還可以用特定的值來表示所產生結果。
最後，為驗證函數效率，測試者將ChatGPT與Copilot產生的程式碼與常用快取工具nano-memoize 和micro-memoize進行了橫向對比，使用以下程式碼產生第12個斐波那契數列。
######################其中nano-memoize是運作效率最高的，幾乎是ChatGPT和Copilot所產生程式碼運行效率的兩倍，並且其所使用的記憶體也是最低的，而micro-memoize的表現則可以說緊隨其後。雖然在CPU利用率方面，Copilot表現不錯，但綜合來看，ChatGPT和Copilot在這場測試中的表現依然不足以擊敗一個成熟的程式設計師。 ############4、總結與預測############透過這三場測試，我們不難發現，雖然使用ChatGPT和Copilot所產生的程式碼肯定具有一定價值。但就目前而言，無論是ChatGPT還是Copilot，都無法透過簡單的任務描述產生足夠準確且高效的程式碼，甚至在某些情況下，它們也會犯下一些非常糟糕的錯誤。在得知這個結果後，不少開發者也分分錶示：感覺自己還能再撐幾年。 ############對於如今的企業或是程式設計師而言，如果你希望利用ChatGPT、Copilot或是其他程式碼產生工具來幫助自己完成一些簡單的輔助編碼任務以加速構建，那麼你完全能夠得到足夠的支持。但如果希望依靠它們徹底解放研發，那麼你可能需要花大錢為其配備一整支強大的調試團隊。 ##########
然而即便結果如此，今天的我們仍不能忽視AI在自動編碼領域的潛力以及這些系統背後強大的軟體企業。可以肯定的是，伴隨著訓練量與技術成熟度的成長，未來的自動編碼工具將繼續擴充其在不同場景的業務數據，並逐步嘗試解決一些更專業、更場景化的實際任務。
最後，對於「AI到底能否在未來取代程式設計師」這個問題，目前最可靠的答案，也許就是前阿里以色列機器視覺實驗室負責人Itamar Friedman在一次訪談中所做出的預測了——「在未來的10到20年內，人工智慧系統將可能使非程式設計師的創造者使用自然語言指令進行0錯誤的開發，屆時我們的世界仍將需要大量的程式設計師，但其角色將可能會發生難以預測的變化。」
參考連結：
https://medium.com/@anywhichway/chatgpt- vs-copilot-vs-programmers
https://github.com/anywhichway/nano-memoize
https://github.com/planttheidea/micro-memoize
以上是三場PK，暴露了ChatGPT的層次！的詳細內容。更多資訊請關注PHP中文網其他相關文章！
