GPT-4要革 程式設計師的命？智慧開發的理想與現實 | 愛分析調研

 

“生成式人工智慧（AIGC）將在三年內終結程式設計。”

——Matt Welsh，前哈佛大學電腦科學教授、Google 工程主管

 

GPT-4 也許還不完美，但智慧開發時代真的來了

 

美國時間3月14日，OpenAI 正式釋出 GPT-4，在 ChatGPT（GPT-3.5）的基礎上，進一步升級了影像識別功能和高 級推理技能，單詞處理能力達到25000個，是 GPT-3.5 的8倍，並可以使用幾乎所有流行的程式語言編寫程式碼。

僅僅一週之內，OpenAI 的最大股東微軟先後宣佈將用 GPT-4 武裝升級 Bing 搜尋引擎、Edge 瀏覽器和 Office 全家桶，其旗下程式碼託管平臺 GitHub 更是釋出重磅“炸 彈”：推出 Copilot X 計劃，將 GPT-4 整合到 IDE。在 Copilot X 中，使用者只需“動動嘴”，機器就能寫出程式碼，也能幫助使用者解釋程式碼片段，還能直接完成 Debug 工作。

在人們驚歎於 AIGC 程式設計強大能力的同時，軟體從業者也陷入了對於“飯碗”的深深擔憂：當 GPT 比人更會寫程式碼，程式設計師還能幹什麼？在 Matt Welsh 看來，由於 GPT-4 大模型的出現，程式設計正處於從人類工作轉變為機器人工作的轉折點，程式設計師這一職業很快將被人工智慧所取代。

回顧軟體工程的發展歷程，技術進步持續推動了軟體開發的正規化革命，今天的 GPT-4 將成為軟體工程進入智慧開發時代的催化劑。

上世紀中葉，《人月神話》所描述的軟體危機迫使人們努力尋找危機的內在原因和解決方案，1968年 NATO 在聯邦德國召開會議，正式提出了“軟體工程”這一概念，希望用工程化方法構建和維護有效、實用和高質量的軟體，標誌著軟體開發正式成為一門工程學科並得以持續發展（軟體工程1.0）。

進入21世紀，受到網際網路、開源軟體運動影響，人們對於軟體工程的認識和理解不斷加深，2001年釋出的《敏捷宣言》正式提出了以人為中心的軟體開發方法，進而形成了建立在 Cloud 、SaaS、敏捷開發模式之上的軟體工程2.0版本。

今天，GPT-4 的出現讓人們真正開始認識到智慧開發時代即將到來，未來的軟體開發將會使用自然語言作為交流方式，讓人工智慧理解開發者交待的任務並自主完成軟體開發，如理解需求、自動生成 UI、自動生成程式碼、自動生成測試指令碼等。隨著開發方式的改變，開發者的使命也將發生根本性變化，軟體工程3.0版本即將正式開啟。

Matt Welsh 對於程式設計師前途的預言引發了軟體開發行業的震動，但現在就斷言 AIGC 程式設計將全面取代程式設計師仍然為時尚早，對於複雜的企業級應用開發而言，具備了強大程式設計能力的 GPT-4 也還存在相當嚴重的侷限性。

首先，大模型基於公開資料集完成訓練，缺乏企業級應用所必需的行業和業務 know-how。眾所周知，企業級應用的開發極為複雜，除了需要開發者具備良好的程式設計能力，更要求開發者能夠形成對於行業和業務場景的深入理解，從而建立業務和程式碼之間的有機連線，這部分知識是公開資料集所無法囊括的。今天包括 GPT-4 在內的大模型均基於公開資料集（主要包括維基百科、書籍、期刊、Reddit 連結、Common Crawl、GitHub 開原始碼等）進行訓練，這就意味著無法有效建立行業和業務 know-how，以致於難以應對面向企業級應用的複雜開發需求。

其次，AI 程式設計依賴於提示詞（Prompt），程式碼質量存在極大的不確定性。與傳統程式設計過程中透過程式語言呼叫特定的 API 不同，AI 程式設計需要開發者透過提示詞讓大模型理解開發需求，這就像產品經理與程式設計師之間的溝通一樣，資訊量越豐富，對方的理解就越深入。百度 CEO 李彥宏曾經談及提示詞和智慧湧現，“大模型本身的能力放在那，誰能把它用好完全靠提示詞來決定。提示詞寫得越好，智慧湧現的能力就越多，反饋的結果就更有價值。提示詞不好，出來的東西就是一本正經胡說八道。”這種程式碼質量的不確定性顯然與追求結果確定性和計算準確性的企業級應用背道而馳。

更重要的，具備開放特性的大模型難以滿足企業級應用對於安全性的要求。3月下旬，據 SBS 等韓媒報導：三星剛引入 ChatGPT 還不到20天，就發生了3起機密資料洩漏事件，其中涉及三星半導體裝置測量資料、產品良率等資訊。根據 OpenAI 官閘道器於 ChatGPT 的 FAQ，其確實指出與 ChatGPT 的對話可能會用作訓練資料。三星事件讓摩根大通、花旗集團、高盛、德意志銀行等越來越多的企業因擔心機密資料外洩而禁止員工訪問 ChatGPT，義大利個人資料保護局也在3月31日宣佈從即日起禁止使用 ChatGPT，並限制 OpenAI 處理義大利使用者資訊。

誠然，今天的 GPT-4 仍存在著這樣那樣的侷限，但其當下已經展現出的能力和快速迭代的腳步已經足夠讓人們對於其前景滿懷期待，智慧開發的浪潮正在不可逆轉地奔湧而來。

 

只知道 GPT-4？智慧開發時代不止一個主角

 

從蒸汽機到電力，從計算機到網際網路，任何一次新的技術浪潮，往往能夠讓生產力得到極大程度的解放，突破固有的效率瓶頸，解決過去難以調和的矛盾，推動社會的持續發展。網際網路時代，軟體已成為社會發展的重要基礎設施，然而隨著業務需求的快速迭代，軟體開發行業正面臨著越來越難以調和的矛盾和痛點：

• 專案成本高——一線城市稍有經驗的工程師動輒三、五十萬的年薪，成本高不說，一旦碰上團隊核心成員出走，輕則讓專案延期，重則導致苦心研發的產品中途流產。
• 開發週期長——開發週期過長，帶來一系列的問題，尤其是大型專案，開發測試環節多、測試耗時長，過程中各項成本需要持續投入、交付慢回款也就慢，公司現金流捉襟見肘。
• 程式碼質量低——技術選型依賴開發人員，而他們通常只會選擇自己擅長的，而不是最適合公司需求的技術棧，一旦出現錯誤，對業務的影響是災難性的。再加上每個人寫程式碼的水平參差不齊，極易導致開發和檢查效率低下，經常一個環節出問題，導致整個專案延遲交付。
• 團隊管理難——現在的開發主要還是依賴人力，突然接到大專案，來不及第一時間招到合適的人來做，而且每個人水平背景參差不齊，在流程、技術、安全規範各方面總是出現各種各樣的問題。

 

GPT-4 能夠引起軟體開發從業者如此程度的關注，背後恰恰反映出今天軟體開發行業所面臨的挑戰是多麼嚴峻，進而催生出整個行業對於軟體開發正規化變革的迫切需求。人們一方面熱切期盼 GPT-4 能夠改變傳統工作流，給生產效率帶來10倍、100倍的提升，另一方面也開始擔憂行業生產力的提升將改變固有的生產關係，也正是 Matt Welsh 提出的程式設計師“飯碗”問題。

時代車輪滾滾向前，唯 一不變的只有變革本身。在軟體開發行業，引起程式設計師對於“飯碗”擔憂的，GPT-4 並不是第一個，也絕對不會是最後一個，近年來方興未艾的低程式碼平臺、全棧式全自動開發都曾是此類話題的焦點。

低程式碼平臺、全棧式全自動開發與 GPT-4 的願景相通，均立足於透過技術創新為軟體開發團隊帶來生產力提升，從而改變傳統的軟體開發正規化，解決行業當前面臨的諸多痛點。但從產品能力而言，全棧式全自動開發與更為人們所熟知的低程式碼平臺存在不小的差異：

• 應用場景——大部分低程式碼平臺基於 BPM 流程引擎實現，本質上只能解決簡單的工作流，以設計表單為驅動，無法實現複雜功能和邏輯；全棧式全自動開發則不僅支援不同業務場景下定製化的小型應用開發，還能夠支援如電商平臺等複雜的大型應用系統開發。
• 流程覆蓋——低程式碼平臺大多基於指令碼類語言設計，提供表單、流程、報表，供使用者拖拽式生成應用，核心解決前端開發的視覺化；全棧式全自動開發則提供基於 Java 語言的視覺化開發能力，能夠覆蓋前端+後端的視覺化+配置化，同時支援全自動測試和全自動運維，實現軟體開發流程的全棧式覆蓋。
• 質量安全——使用低程式碼平臺構建的應用通常與平臺繫結，導致很多特性需要依託於特定的低程式碼平臺才可以實現，使用者對系統質量、安全和智慧財產權的掌控無法得到保證；全棧式全自動開發則將開發成果的“所有權”完全交給使用者，解決客戶對於安全性和智慧財產權的擔憂，同時提供系統質量保證。

透過對比不難發現，相較傳統低程式碼平臺，全棧式全自動開發更加適合應用架構複雜、涉及眾多流程環節、對系統質量和安全均有極高要求的企業級應用開發場景。與此同時，與當下火熱的 AIGC 程式設計相比，全棧式全自動開發在 GPT-4 的核心侷限性問題上也能夠給出令人滿意的答案。

• 專業性方面，除了全棧式全自動開發廠商提供的通用性元件和模型，使用者和廠商可以共同基於自身長期積累的大量行業和業務 know-how，搭建個性化元件和模型並進行持續迭代，從而產出最貼近業務需求的應用。
• 可靠性方面，相比於具備高度不確定性的 GPT-4，全棧式全自動開發的重要特性即是現實軟體開發的標準化，從“人治”到“法治”，對人為變數進行最大限度約束，確保產品質量高度可靠。
• 安全性方面，全棧式全自動開發廠商允許客戶根據需求靈活選擇程式碼的儲存和部署方式，私有化部署的支援能夠從根本上打消客戶對於安全性和智慧財產權的顧慮。

用實戰說話，全棧式全自動開發讓智慧開發照進現實

 

智慧開發因為此次 ChatGPT 熱潮而備受矚目，但其實早在數年之前，低程式碼平臺、全棧式全自動開發等一系列對智慧開發的探索就已經開始。

自2014年 Forrester Research 提出“低程式碼”概念後，低程式碼平臺的發展快速起步，除 OutSystems 和 Mendix 等低程式碼廠商外，微軟、谷歌等巨頭也紛紛開始佈局低程式碼。2015年前後，低程式碼概念進入中國，奧哲、ClickPaas 等一批本土低程式碼品牌迅速崛起，阿里、騰訊、金蝶、用友等雲廠商和傳統軟體廠商也先後入局。基於對近30個本土低程式碼產品和上百個應用實踐案例的評估，愛分析認為國內的低程式碼產品仍處於發展早期階段，但許多廠商已經具備了比較完整的產品專案和成功的實際應用案例落地，根據 IDC 資料，預計到2025年中國低程式碼市場規模將超過10億美元。

低程式碼平臺和 GPT-4 起源於西方，而全棧式全自動開發的概念則來自於中國企業的自主創新，飛算科技就是其中的傑出代表。飛算科技於2020年釋出了全球首 款全棧式全自動開發工具——SoFlu 軟體機器人，透過自動化、標準化和工具化，改變傳統軟體工程生產正規化，幫助企業實現全鏈條 IT 生產力提升。

SoFlu 軟體機器人基於“業務即圖，圖即程式碼”的核心理念打造，提供 Java 視覺化開發及執行日誌、豐富的元件庫、模擬測試等核心技術工具，幫助開發者自動完成包括前端開發、後端開發、測試、運維在內的全棧式軟體開發工作，真正實現“軟體開發，十倍提效”，大大降低企業開發成本。

SoFlu 軟體機器人的能力已經在金融、醫療、高階製造、區塊鏈等八大行業的上百次企業級應用專案實戰中得到驗證。在中石油旗下大型電商平臺重構專案中，中石油開發一個大型電商平臺時由於開發人員有限，他們聘請了外部廠商進行開發，但系統上線後，隨著使用者數量的增加和具有企業特色的功能需求不斷提出，原有的平臺架構在功能、效能和擴充套件性方面已經不能滿足商城的發展需求，同時系統改造還依賴於外部廠商進行開發，龐大的投入支出和不斷延長的開發週期給中石油資訊化團隊帶來了很大的困擾。如果要進行商城的重構，傳統模式下至少需要27人，開發300多天才能完成。中國石油資訊化團隊在使用了SoFlu軟體機器人後，9人小團隊在5個軟體機器人的協助下，僅用45天就完成了商城的重構及上線，並且在保障系統強壯度和安全性的同時從源頭上降低系統維護難度。中石油的專案負責人事後感嘆，團隊利用 SoFlu 做到了以前無法想象的事情。

據瞭解，以“打造中國原創、全球領先的軟體工程共創平臺”為使命願景的飛算科技，下一步會持續構建開發者生態，吸引更廣泛的開發者貢獻高質量元件，覆蓋企業業務需求的“最後一公里”。同時，借鑑 GPT-4 創新理念，SoFlu 軟體機器人也已初步完成產品 AI 能力的搭建，“自然語言生成需求表述”、“自動繪製流程圖”、“程式碼實時生成”等產品能力將成為開發者提升效率的強大助力。

回到 Matt Welsh 所關心的問題，SoFlu 軟體機器人的目標絕不是讓程式設計師丟掉“飯碗”，而是將開發者從日常簡單重複的“寫程式碼”中抽離出來，能夠有時間站在更高的角度深入思考問題，從“程式設計師”變成“架構師”，從“寫程式碼”變成“設計程式”，徹底釋放每個開發者的創新潛能。

 

結語

正如英偉達 CEO 黃仁勳所說，GPT-4 開啟了人工智慧領域的 iPhone 時刻，無數行業將因為 AIGC 技術發生改變甚至顛覆。作為資訊化時代的重要基礎設施，軟體工程領域在這場變革中首當其衝，智慧開發浪潮蓄勢已久，現在正由 GPT-4 將它推向臺前。

長期以來，中國在軟體工程等基礎學科領域的創新步伐一直落後於西方，而過去幾年發生的中美貿易戰、科技戰再次讓我們認識到基礎學科創新的必要性與緊迫性。無論是奧哲、ClickPaas 等低程式碼平臺，還是以 SoFlu 為代表的全棧式全自動開發工具，以及百度“文心一言”、阿里雲“通義千問”等 AI 大模型，無不是中國科技企業面向智慧開發的奮力嘗試與探索。與此同時，軟體工程的自主創新離不開政策的大力扶持、使用者的積極採納以及社會各界的廣泛關注，相信在所有國人的共同努力下，智慧開發將不僅僅是軟體開發的又一次技術變革，更將成為中國軟體工程崛起的重要契機。