作者 | 何苗
大模型的火熱引爆了 AI 程式設計領域的全面革新，人們開始思考如何藉助 AI 提高程式設計效率的同時，也在思考未來需要怎樣的「新程式設計師」。
3 月 25 日下午，CSDN 與《新程式設計師》合作舉辦「新程式設計師大會（NPCon）的「AIGC 與大模型技術應用峰會」——AI 程式設計技術論壇在北京環球貿易中心成功舉辦。本論壇匯聚了來自中科院、微軟亞洲研究院、清華大學實驗室等學術機構，華為雲、aiXcoder 等企業代表們，從ChatGPT、大模型、開源等多個角度，圍繞智慧程式碼生成展開激烈的觀點碰撞，分享了 AI 程式設計最新鮮火熱的觀點。
當AI可以寫程式碼，程式設計師還能幹什麼？AI 寫的程式碼，誰或者如何來評定程式碼的質量？GPT-4 模型將為 AI 程式設計帶來怎樣的技術與思維革新？很多問題都在這場論壇中得到了解答，答案或許與你的認知相左，也歡迎留言來辯！
微軟亞洲研究院高級研究工程師盧帥：未來的AI程式設計的發展趨勢是一方面探討如何利用大模型來完成任務，另一方面思考如何進化它，以覆蓋更廣泛的智慧程式碼場景。
aiXcoder 聯合創始人郝逸洋：如果 AI 作為作業系統可以直接控制硬體，程式設計師就能解放雙手去編寫驅動、作業系統和軟體或是研發新的硬體，這就是軟體 3.0 的圖景。
華為雲 PaaS 技術創新 LAB 技術專家申博：當模型越來越大，對硬體性能要求越來越高，有可能會遇到「資料荒」的問題，我們能否讓 AI 自我演進，通過自我生成資料的方式學習，以達到與大資料同樣的效果？未來自我創造智慧是個有前途的方向。
清華大學知識工程實驗室研究助理鄭勤鍇：在將來，程式設計師需要具備一些更高級的技能和思維，比如 Geek （極客）思維，開發者應該更加註重這方面的培養。
中國科學院軟體研究所研究員、博士生導師王俊傑：現在的大模型可能有些時候對開發人員來說有點「不太專業」，但對測試人員來說「剛剛好」
一邊用大模型來生成程式碼，一邊想辦法讓它進化
在上午的主論壇，華為雲智慧化軟體研發首席專家王千祥表示 AI 程式設計肯定會超越 Coding 程式設計，因為現有的 ChatGPT、GPT-4 大模型工具的能力覆蓋到了程式碼補全、翻譯程式碼、解釋程式碼、DeBug 等多維度。
在AI 程式設計分論壇會議開場，為了對程式設計師最關心的程式設計技術問題做更深入的交流與探討，他作為論壇出品人，協助 CSDN 精心邀請了幾位親自動手做AI 程式設計的青年才俊來分享其實踐經驗與真知灼見，機會難得。
華為雲智慧化軟體研發首席專家 王千祥
以下，是該論壇的內容精華。
首先，微軟亞洲研究院高級研究工程師盧帥分享了《基於預訓練的程式碼理解與生成》主題演講，他表示：預訓練模型是目前探索出的程式碼智慧生成最佳解決方案，但其核心挑戰在於如何讓模型理解和推斷程式碼背後的意圖。
微軟亞洲研究院高級研究工程師 盧帥
「在編寫程式碼時，並不是所有的程式碼都是程式設計師自己原創的。」近年來，程式碼智慧引起了學術界和工業界的廣泛研究，基於人工智慧技術的自動化程序理解和生成可以極大地提高程序開發者的生產力。微軟已經在預訓練模型領域做了一些嘗試，並在 2020 年初提出了首個將文字和程式碼結合起來作為模型訓練的模型——CodeBERT。它覆蓋了 6 種程式語言，支持多項程式碼理解功能。
會上，盧帥詳細地介紹瞭如何將預訓練的模型應用於具體的程式碼智慧任務和場景中。「我們的研究並沒有完全關注如何擴大模型規模，而是從程式設計師或是軟體工程的角度，去思考將程式碼相關資訊和軟體工程知識融入預訓練模型中，增強模型對程序的理解。」
除了對大模型的訓練與最佳化以外，盧帥及其團隊還非常關注程式碼補全和程式碼審查的具體應用場景，在程式碼審查場景下，他總結出可通過人工智慧或預訓練模型來最佳化和提高開發效率的三種任務：
評估程式碼更改的質量；
輔助生成程式碼審查意見；
程式碼最佳化。
目前 GPT-4 還有許多沒有覆蓋到的情況，例如缺少程式碼語法樹等資訊；由於長度限制，無法對項目級程式碼進行分析；程式碼個性化模型問題，未來都很值得思考。
在大型模型時代，GPT-4 影響廣泛，為我們提供了很多便利。相對於 GPT-3，GPT-4 的最佳化之一在於它引入了人類的反饋，最佳化方向已經從增大參數量轉變為從資料最佳化和訓練方式的角度。但盧帥認為結構方面還沒有被充分挖掘。
盧帥及其團隊下一步的研究方向是如何讓神經網路模型更了解程序，而不是如何使模型變得越來越大。「我認為未來的發展趨勢是一面探討如何利用大模型來完成任務，另一方面則要思考如何進化它，以覆蓋更廣泛的智慧程式碼場景。」
AI 還需更進一步才能滿足程式設計師的需求
「在 2022 年之前，程式碼生成模型主要採用語言模型來訓練程式碼模型。而在 GPT-4 時代，一切都改變了。我們可以直接向程序提出需求，就像產品經理向程式設計師描述需求時一樣。」
aiXcoder 聯合創始人 郝逸洋
近一年，大型語言模型（LLM）對序列資訊建模的能力有目共睹，創建了像 ChatGPT、GPT-4 這樣驚人的產品。本次演講aiXcoder 聯合創始人郝逸洋圍繞如何利用 LLM 技術輔助程式碼開發為我們帶來精彩分享，並對互動式多模態LLM（如 ChatGPT、GPT-4 ）如何應用於智慧化軟體開發展開暢想。
首先，郝逸洋分享了自己對於 GPT-4 的認識。「當 ChatGPT 升級至 GPT-4 時，它可支持更長的序列，並在更多領域上進行了微調。相比於 GPT-3，GPT-4 的求解能力有了巨大提升。此外，GPT-4 還有一個未開放使用的能力，即理解圖片，但目前還未對外開放使用。」
為了進一步對 GPT-4 的能力邊界展開探索，他對程式碼進行了錯誤檢測和修復，這個功能非常強大，也是程式設計神器 Copilot 還不具備的功能——它只是一個程式碼補全模型。
GPT-4 反映出的第一個問題就是它速度較慢，因此無法響應很多實時場景；第二，上下文序列有限（最長 32,768 ），儘管GPT-4 的序列長度已經非常厲害，但是想要將整個項目的資訊全部放入其中仍然非常困難；第三，程式碼項目的上下文和網頁爬取的文字差距巨大。
同時，程序生成模型與 GPT-4 此類語言模型的模式仍有區別。
在實際場景中，寫程式碼所依賴的資訊量非常多。除了當前檔案的上下文資訊，它還依賴整個項目中其他檔案的資訊甚至其他項目的資訊。因此，這是個需要獨立設計的問題，普通語言模型很難處理如此複雜的需求。
第二大區別則體現互動模式。在創建程序生成模型時，一般有幾種模式可供選擇，包括填空、補全和排序，而對話語言模型其模式則是「續寫」與「問答」。「填空、補全和排序」三種場景都對實時性有要求，如果速度過慢，開發人員是難以接受的。
當一個程序生成模型創建完畢，就需要對補全率和生成率兩個指標進行測試，評估它的表現能力，郝逸洋以 HumanEval 為例，為大家展開了細節講解，同時他強調自動化測試使用者實際開發場景非常難，運用一些手動測試來配合驗證可能會更精準。
讓語言模型學會自己使用工具
「眾所周知，GPT-4 可以讓編寫簡單程式碼的過程更加輕鬆，但它在處理複雜的程式碼時仍然很困難。這意味著它不能降低程式設計的難度，但可以降低入門門檻，這也是生成式 AI 固有的侷限。」
華為雲 PaaS 技術創新 LAB 技術專家 申博
華為雲 PaaS 技術創新 LAB 技術專家申博為我們帶來了他《在 GPT-4 時代，重新思考 AI 程式設計》的精彩分享。
他認為工具的存在旨在提高程式設計師的開發效率，然而其質量也同樣重要。首先，生成的程式碼中可能存在未知的錯誤和漏洞。隨著生成的內容越多，其質量就越成為一個重要話題。其次，實際項目中往往涉及很多設計模式和框架，需要綜合多個檔案和不同層次的程式碼，同時掌握較強的專業和領域知識，才能了解程序的具體含義和功能。再者，自監督的預訓練方式是基於自然語言序列的順序性，但寫程式碼時並非如此，程式設計師往往會在多份程式碼中不斷跳轉和編輯，甚至進行全局的重構。如此一來，僅靠大規模語言模型很難覆蓋以上所有情況，即使強大如 GPT-4。
申博認為，互動與協同才是核心。互動與協同不僅指人與AI或工具之間的互動，也包括模型與現有工具之間的互動，以及現有工具之間可能存在的互動。
程式設計師需要大模型來運用這些工具，就涉及到類似於「 Toolformer 」（Tool+Transformer）的組合，即語言模型可以教自己使用工具。該思想的核心是讓模型具備人類的能力，讓它自主地學會決定應該使用哪些工具以及如何調用這些工具。在經過多輪的訓練後，模型可以具備此類能力，並在它生成的文字中插入 API 調用，將 API 返回的結果融合到預測中。
除了讓模型調用工具，將模型視為主流工具中的一個環節也是一種可行的思路。與 Toolformer 中讓模型調用工具不同，基於語言模型即服務（Language Model as a Service）的方式，使現有工具能夠調用模型，這是未來非常有發展潛力的方向。
來自北京大學的研究者們認為，軟體程式碼是程式設計師對這個世界的理解與表達，在這個過程中，一些個性化東西也被加入到程式碼中，國外許多開源項目的所有者把程式碼寫成了藝術。隨著AI程式設計的發展，現代化程式設計中機械化的東西越來越少，所以新程式設計師們需要更多地關注程式設計的藝術層面，例如設計架構以及最佳化演算法的優美性。華為雲推出了CodeArts 服務來幫助開發者們面向未來轉型，CodeArts 提供了一整套軟體開發流程，其中包括 CodeArts Snap 智慧程式設計助手，Snap 基於程式碼生成不侷限於程式碼生成，其最終目的是同時提高開發的效率和質量。
演講的尾聲，他總結道：從前我一直在思考 ChatGPT 這種互動方式什麼時候會被應用於 IDE，隨著 GitHub Copilot X 的發佈，現在 GPT-4 已經來到 IDE 中。因此我們需要重新思考 AI 程式設計，未來它一定會成為像IDE一樣的必備工具。像使用 IDE 一樣適應 AI 吧，AI 不會取代人類，但掌握 AI 技術的人將取代另一些人。
為了產業生態發展，開源程式碼生成模型
「近兩年有兩個重要的行業動態，一個是 AlphaCode 登上《Science》雜誌封面，證實了預訓練的程式碼生成模型可以達到參加程式設計競賽的程式設計師平均水準。另一個是 Copilot 問世，首次證實了在大量源程式碼語料上進行訓練，能取得遠超傳統方法的程式碼生成效果。但很遺憾，以上提到的技術全部來自國外，全部都是閉源的，只能被用於產品使用或調用 API 。
清華大學知識工程實驗室研究助理 鄭勤鍇
從程式碼提出之初起，便一直有人在考慮如何實現自動程式碼生成。如何實現大規模的程式碼生成模型？清華大學知識工程實驗室研究助理鄭勤鍇及其團隊去年花了整整一年時間做了深度實踐，他們將大規模預訓練模型應用到程式碼生成場景，並選擇在國產的硬體和平臺上實現此模型。
CodeGeeX 是一個具有 130 億參數的多程式語言程式碼生成預訓練模型，採用華為 MindSpore 框架實現，使用鵬城實驗室「鵬城雲腦II」平台中 1536 個昇騰 910 AI 處理器，在 20多 種程式語言的程式碼語料庫歷時兩個月訓練而成。開源開放，支持昇騰和英偉達平臺，具有高精度程式碼生成、程式碼翻譯等能力。
在此次大會上，他詳細從模型的資料收集、處理；模型架構搭建、模型訓練與最佳化、任務評估、程式碼生成外掛等幾大方面分享了實踐的細節。
目前來看，CodeGeeX 是在開源領域表現最佳的多語言程式碼生成模型，使用者超過 4 萬名，還在不斷最佳化中文等其他語言的表現。
考慮到每種程式語言被髮明出來時都有其更適用的特定場景，鄭勤鍇及其團隊分析了 CodeGeeX 的生成結果。綠色表示答案完全正確的結果，紅色表示通過編譯但答案錯誤的情況，橙色表示運行時錯誤，藍色則表示語法錯誤。可以看到，目前程式碼生成模型的難點並不在生成語法正確且可以運行的程式碼，而是需要更強的邏輯推理能力，保證輸出結果的正確性。
由於 Copilot 等類似技術都是閉源的，無論對於研究還是產業都非理想情況。鄭勤鍇將整個項目開源，目前已獲得了 3300 多個 Star，也邀請更多開發者一同參與最佳化。他表示當前階段並不著急將某些產品做得太細緻，而是應該進一步提高基礎模型的能力，之後也會加入對話功能，使其具備更強的互動能力，實現如程式碼修復之類的功能。
偶爾「不太專業」的大模型，對找 Bug 「剛剛好」
現在的大模型可能有些時候對開發人員來說有點「不太專業」，但對測試人員來說「剛剛好」。
中國科學院軟體研究所研究員、博士生導師 王俊傑
前面談到了許多如何利用大模型實現程式碼生成的問題，在自動化測試領域，大模型是否同樣有所助益？中國科學院軟體研究所研究員、博士生導師王俊傑為我們帶來了《基於LLM的自動化測試》的思考。
對開發人員而言，儘管大模型已非常強大，但其生成的程式碼仍然不能完全信任。雖然開發人員希望程式碼生成百分之百正確的，然而對於測試而言，這些問題對結果影響不大。測試本就是為了找出 Bug，即使無法找到，也能節省大量的人工工作量。
王俊傑及其團隊的工作是基於大型模型進行自動化測試。
近年來自動化圖形使用者界面（GUI）測試被廣泛用於幫助開發團隊確保移動應用程序的質量。然而許多 GUI 需要適當的文字輸入才能進入下一頁，文字輸入的質量成為影響測試覆蓋率的主要障礙。由於有效文字輸入（例如航班的出發地、電影名稱、使用者血壓資訊等）具有多樣性和語義要求的特點，實現文字輸入生成的自動化是一項具有挑戰性的任務，其難度主要體現在兩個方面，一是輸入時需要生成不同類型的特定值，例如地圖應用程序的街道地址；二是在同一 GUI 頁面內需要體現文字之間的關聯性，例如航班搜尋中出發和到達地需要是不同位置。如果文字輸入不恰當，自動化測試工具將無法進入下一個 UI 頁面，從而導致測試的充分性低下。
針對以上的挑戰，團隊提出了一種上下文感知的自動文字輸入生成方法 QTypist，即使用預先訓練的大型語言模型（LLM）來智慧地生成語義輸入文字，以增強移動 GUI 測試。其設計邏輯是，先給定一個帶有文字輸入的 GUI 頁面及其相應的視圖層次結構檔案，通過提取文字輸入的上下文資訊，來設計語言模式以生成提示作為 LLM 的輸入。同時，為了提高 LLM 在移動 GUI 中文字輸入的性能，團隊還開發了一種基於提示的資料構建和調優方法，以自動提取用於模型調優的提示和答案。
團隊對來自 Google Play 的 106 個應用程序進行了評估，結果顯示，該方法生成文字的通過率為 87 %，比最佳基線高 93 %。團隊還將文字生成方法與自動化 GUI 測試工具集成，與原始工具相比，集成後的工具可以多覆蓋 42 %的應用程序活動和 52 %的頁面，同時多檢測 82 %的 Bug，從而提升了自動化測試工具的測試覆蓋率和缺陷檢測效率。
在演講的結尾，她提出做大語言模型後續需要解決的四個問題，發人深思：
大模型如何與被測軟體互動？特別是複雜軟體，例如自動駕駛仿真測試這種；
Diversity/coverage 問題。對於程式碼生成任務而言，使用者希望得到最正確的一個結果即可，但對於測試任務，更希望達到 diversity and coverage，如何更好實現？
測試開發同步或者測試驅動開發；
未來軟體開發形態可能是面對使用者輸入，大模型直接產生可用的軟體，那如何保證大模型產出的軟體是安全可用的、滿足使用者需求的？又應該對大規模、以及基於大模型的應用進行測試和質量保障？
以上四個相對開放的問題，也非常歡迎大家在評論區探討。
圓桌部分：成就大模型時代的應用開發者
在 AI 程式設計分論壇最後一個環節，由論壇出品人、華為雲智慧化軟體研發首席專家王千祥主持，微軟亞洲研究院高級研究工程師盧帥，aiXcoder聯合創始人郝逸洋，華為雲 PaaS 技術創新 LAB 技術專家申博，清華大學知識工程實驗室研究助理鄭勤鍇，中國科學院軟體研究所研究員、博士生導師王俊傑圍繞「AI程式設計現狀與未來，成就大模型時代的應用開發者」，共論新時代開發者的新機遇與成長。
從左至右：王千祥 盧帥 郝逸洋 申博 鄭勤鍇 王俊傑
大型模型出現後，許多新的開發項目將隨之誕生，這對開發者而言是好是壞？需要在哪方面提升？華為雲 PaaS 技術創新 LAB 技術專家申博認為，此事對程式設計師的好處大於壞處。他們需要把自己的思維放在一個老闆的位置上，程式設計神器Copilot 會向你推薦出多種實踐方案，讓你去選擇與思考其中最佳。這不僅讓程式設計師享受到了使用者的便捷，同時也在倒逼他們提高程式設計能力。在這個過程中，程式設計師需要將其作為一個夥伴、一個老師，而不只是一個下屬，在於它平等對話的過程中，也能實現自身能力的提升。當你從「 Copilot 」變成「 Captain 」，你將成為自己的船長。
這是否意味著軟體開發人員將會迎來一次巨大的飛躍？微軟亞洲研究院高級研究工程師盧帥認為，飛躍進展應該會很大。但在這個領域還有一個待解決的問題，那就是測試。對於人類來說，短時間內可能很難完全相信人工智慧生成的東西，因此提高測試的效率對於人工智慧來說是有研究價值的。人工智慧會對整個軟體開發，特別是編寫程式碼這個環節的效率有非常大的提升。
但 aiXcoder 聯合創始人郝逸洋有不同觀點：根據他的落地實踐經驗，在短期內實現顯著的生產力提升是相當困難的。程式設計師並非將大部分時間都花在寫程式碼和開發新功能上，而是在調試 Bug，可能 90 %的時間都是如此。但如今卻沒有討論這個問題，原因在於目前的AI技術還沒有達到相應水平，無法協助程式設計師完成 deBug。如果它可以助你實現這一目標，才是真正的震撼，意味著突破來了。
那麼，對於未來的程式設計師而言，哪些技能的培養更為重要？清華大學知識工程實驗室研究助理鄭勤鍇認為：在將來，程式設計師需要具備一些更高級的技能和思維，比如 Geek （極客）思維，你需要了解問題在哪裡？哪些方面可能需要最佳化？如何提出這些問題？一個初級程式設計師很可能不知道問題在哪裡以及何處可以最佳化，所以你需要理解整個程式設計系統或架構的設計，這將幫助你獲得這種技能。目前 GPT 對程式碼的認識還不夠全面，這就需要開發者從一個更全面的角度出發，具體描述每個模組，確定哪些環節較薄弱，哪些可以進行最佳化。這種能力非常重要，開發者應該更加註重學習它。
對於 GPT-4 模型將推動哪些領域與技術革新，大家展開了大膽預測。
aiXcoder 聯合創始人郝逸洋表示：一般來說程式設計師寫軟體需要編寫程式碼，並在編譯後按照指令執行程序。現在我們已經可以讓 AI 直接生成程式碼，那麼為何不讓它直接生成機器指令並且去執行呢？如果 AI 作為作業系統可以直接控制硬體，當程式設計師下達一個指令後，AI 便會立刻執行，並不需要程式設計師的參與。那麼程式設計師是否可以將這些新技術和指令傳授給 AI，讓其掌握並獨立操作？如此一來他們就可以解放雙手去編寫驅動、作業系統和軟體或是研發新的硬體，這就是軟體 3.0 的圖景。
華為雲 PaaS 技術創新 LAB 技術專家申博考慮到：資料是否會遇到「資料荒」的問題。當模型越來越大，對硬體性能要求越來越高，而人類社會的語言文字、以及多模態資料都是有限的資源。我們現在擁有如此龐大的資料量，是多年的積累的成果。不能期望這種緩慢自我發展來產生資料，我們能否讓 AI 自我演進？這種自我演進的過程，正好符合人類自我創造和自我學習的機制。這個問題值很得研究。如果某些領域的資料相對較少，就可以考慮通過自我生成資料的方式學習，以達到與大資料同樣的效果。「自我創造智慧」是個有前途的方向。
中國科學院軟體研究所研究員、博士生導師王俊傑則希望看到大型智慧型應用能夠幫助更多使用不便的人，如老年人。大多數人認為非常方便易用的手機，可能對於年長一些的人並不友好，他們不知道要如何預訂機票或如何使用應用。有朝一日是否可以省略中間層，讓應用變得更加智慧、易用，讓老年人或不便者可以通過輸入指令輕鬆完成日常任務？此外，若干年後，當大型模型能夠達到自我意識，也會帶來一些令人擔心的問題。
除了上述問題，現場觀眾也積極提問，絕不放過向專家們取經的機會：對新手來說，如何評價AI大模型推薦的程式碼的優劣？
對程式碼自動化測試頗有研究的王俊傑接過了話筒：在理想情況下，如果有測試用例就能夠做到，但在現實情況下，很多時候並沒有測試用例，也不太知道自己能得到什麼樣的結果，因此還得在軟體完成之後的系統測試階段對它進行比較完整的測試。
這個場景非常具體，對於新手要如何評測自己是否採納AI推薦的程式碼，我們也沒有太豐富的經驗，在這裡僅和大家分享一點新的想法。早前人們使用傳統的機器學習演算法時，在推薦給出一些結果的同時也會給出其概率，未來大模型是否能參考前者，為生成的結果附上概率，幫助人們確定AI推薦的程式碼是否為自己所需，如果能有這樣的 Guideline，在選擇的時候就更有針對性。對於大模型顯示不太確定的內容，就增加人工審查力度，反之則減少人工審查工作量。
探索「新程式設計師」邊界，擁抱AI新紀元
至此，AI 程式設計技術論壇完滿落幕，但關於AI與程式設計的探討與創新不會停下腳步。
未來，程式設計師在人工智慧產品的協助下會明顯提升單兵作戰能力，技術團隊會有更多時間用於創新，很多程式設計師也會承擔起一部分產品經理甚至是老闆的責任。CSDN 也將與你一起持續探索「新程式設計師」的邊界。
不論你是否主動擁抱 AI，屬於AI的時代已經來臨，打不過那就加入吧！
