嘉賓| 徐曉強
#訪談| 張曉楠
##撰寫稿| 李美涵
出品| 51CTO技術堆疊(微訊號:blog51cto)自從生成式AI大火以後,AI好像「槓上了」程式設計師這個角色。
幾乎每隔一段時間,關於AI程式設計工具是否能取代程式設計師的話題就會被再次討論。
AI程式設計所激起的熱議,令人感到困惑:這是否會掀起一場程式設計領域的生產力革命?還是,這又是一場過度炒作的噱頭?
由於AI編程,百度實現了10%的人效提升,今天工程師提交的新增程式碼中有27%由AI產生。這個答案的先驅是大廠在探索這個答案。
然而,身為百度Comate架構師,也是這款產品的首個用戶,徐曉強非常反對「開發者將被程式設計工具取代」的這個說法。 在研發和架構方面的工作經驗,讓他堅信人類的決策力和創新力有著無可取代的價值。
「工具是幫助人類去做到更好,工具本身不是用來取代人類的。」他在訪談中多次表達了自己的這個觀點,「人類的決策和創新能力,永遠優於模型。研發流程中的角色邊界正在模糊,開發者與AI協同工作的新典範時代將會來臨。
作為Comate的深度使用者,徐曉強在直播中分享了許多自己使用程式設計工具的方法和心得,他建議用戶應該盡可能多的練習這項工具,達到“熟能生巧」。
徐曉強設想中的AI程式設計終局,是遙遠而偉大的。 在程式設計工具迎來質變的飛躍之後,他期待人們能以更平等、更加對話的方式與AI協同開發,甚至超越語言直接在意識層面進行交互,以抵達「人人都是程式設計師」的終極藍圖。
以下是訪談要點:
#目前,AI程式設計產品正從橫向和縱向上持續提升產品能力,以回應更多的「真需求」。
#1.AI完成了百度27%的新增程式碼,程式設計工具解決「真需求」需要使用者多摸索
現在有一種論調,說AI程式設計可能會極大程度的顛覆與程式設計有關的職位,這個觀點也引起了一些恐慌。但另一方面,很多人會發現用AI進行程式設計的效率遠沒有我們想像中那麼高。 AI程式設計的巨大熱度究竟是因為需求所在,還是有噱頭的成分在裡面?
徐曉強:
我們先拋開這些觀點,去看看現在的事實狀況。 首先,儘管AI程式設計工具的普及和接受需要時間,但AI程式設計的市場熱度有目共睹,並且會出現越來越多的落地案例和商業價值。
其次,AI程式設計產品會繼續進化,以回應更多的「真需求」。拿我們自己的產品Comate 2.0來說,我們正在不斷地努力從縱向和橫向維度上提升產品能力。
橫向上,我們希望AI程式設計能涵蓋更廣泛的研發場景。例如利用RAG技術深入理解專案及程式碼,從而在多種場景下提升研發效率。在縱向上,希望AI能夠在某一個產業或某一個場景下打深打透。
最後,AI程式設計工具的提效效果可能因個人和組織而異,使用者需要培養使用習慣、找到與工具的契合點。為了更好地與AI工具合作,用戶應該清晰地描述需求,將AI視為一個有問必答的私人助手,不斷探索和互動。
除此之外,還有很多開發者可以利用AI程式設計作為學習工具,了解不熟悉的語言、框架和程式碼實作思路,甚至可以深入追問實作細節。
可以說,在程式設計領域AI提效並非噱頭。自大模型技術興起以來,百度實現了10%的人效提升,工程師提交的程式碼中有27%是由AI產生的,用戶的採納率達到了46%。現在,百度有80%的工程師使用AI工具輔助開發。
更進一步說,工程師們感受到了新一代工具所帶來的變化,這不僅是工作效率的提升,也增加了工作的幸福感。
AIGC實戰派:在採用AI程式設計的時候,有沒有什麼方式可以更好地發揮工具的潛力?
徐曉強: 我覺得還是要多去嘗試。漸漸地你能找到感覺:在什麼場景下,AI做得比人快。透過這樣一個場景的積累,工具會逐步達到你所預期的效果。
AIGC實戰派:剛才您也提到了百度每天新增的程式碼中,有27%由Comate產生。那麼會有人擔心,當自己公司的研發團隊更多地使用AI程式工具後,是不是會導致裁員?
徐曉強:最開始的時候,我們也困惑和擔心會出現這種情況。但隨著對AI程式有了更深入的使用與理解,我意識到提升效率不是讓工具取代人類,而是讓工具與人更好地合作,從而增強人的能力。
目前AI還沒有發展到能讓程式設計、讓開發者這個職業消失的階段。不過,就像汽車的誕生之於馬車夫一樣──即使有一天達到這個階段,也不需要過度擔心。
AIGC實戰派:我們可以在多大程度上寄望AI程式工具,工具會不會有能力的極限?
徐曉強:要聊AI程式設計的能力邊界,我覺得先要看工具的核心優勢在什麼地方。 我認為主要在具有這三個特點的任務中:高度重複性、簡單、瑣碎。
對應的,在要求創造性、決策性以及複雜的場景中,AI的能力達不到優秀的標準。我覺得它的能力主要受限於以下幾個面向。
第一,模型本身對於資訊的理解還不夠深入。儘管我們有了更大規模的模型,但對程式碼的理解仍然不夠好。我認為,程式碼屬於資訊密度較低的載體,它的誕生並不是為模型、機器服務的,而是在人和機器的語言之間尋找到一個平衡。所以,AI憑藉程式碼無法掌握全局,這就會極大的削弱決策的準確性。
第二,人類資訊的儲存和傳輸方式多樣,而AI對多模態資訊如流程圖、類別圖的理解能力有限。這也是當下非常熱門的研究方向。
第三,從模型的原理出發,AI作為機率模型,其輸出受限於已有知識,缺乏創造力。一般使用者難以自行調整AI的提示(prompt),需要像prompt工程師這樣的專業角色介入。
最後,AI對專業領域的知識理解尚淺,無論是私域知識或專業領域知識,都需要進一步加強。
基於上述因素,AI在某些場景下的表現是有邊界的。需要人類作為橋樑,根據具體問題進行分析,去決定哪些任務交給AI去完成,哪些由自己完成會比較好。這是人類將永遠優於模型的領域。
AIGC實戰派:假設有個不具備程式設計能力的人,他如果借助足夠強大的輔助程式設計工具,是否可以實現一些程式設計師正在做的工作呢?
徐曉強:我覺得目前已經一定程度上達到了這種效果。
AIGC實戰派:但真正具有創造性和挑戰性的程式碼工作,還是需要程式設計師來完成?
徐曉強: 對。
AIGC實戰派:從這個角度來說,程式設計師們是不是就不需要擔心自己會被取代的事情。
徐曉強: 對。我覺得可以完全不用擔心這些。
AIGC實戰派:現在,很多人會提到一個字「軟體工程新典範」。在AI的衝擊之下,軟體工程會有哪些變化?從業者該怎麼看待和應對這些轉變?
徐曉強:是的。最近軟體工程3.0的概念變得比較火,雖然我認為現在也只是達到3.0時代的起點。
回顧軟體工程範式的演變,1.0時代的軟體工程真正標準化了軟體開發和團隊協作流程。但這種方法在實際開發上顯得不夠敏捷,交付過程也不夠流暢。進入2.0時代,開發變得敏捷、基礎設施不斷完善,以雲端運算和SaaS為代表,在思維方式和產品形態上與1.0時代相比發生了重大變化。
至於3.0時代,我並不認為我們進入了一個由工具驅動變革的階段。大模型(LLM)在各方面展現的潛力使它扮演了催化劑的角色,而非主導變革。以前,為每個開發者提供一個與自己協同工作的角色是不現實的,但在今天,我們正處於與AI協同工作的新範式時代。
AI協同工作方式能在以下幾方面為我們帶來工作上的提升:首先,AI能簡略實際工作中的操作步驟。
其次,AI減少了我切換任務的成本,使我可以在一個介面內依賴它完成提問、熟悉專案、理解和尋找資訊等工作,它就像我的左膀右臂。目前,我們與AI的協作仍處於指令模式,但未來AI可能會做到更多,例如簡單的決策任務等,這樣我們才能達到真正的人機協同新模式。
隨著AI的介入,軟體工程領域確實正在經歷一些根本性的變化。研發流程將被重構,需求工程變成了交付的起點和終點,當前版本的功能上限可能是新需求的起點,不斷推動產品迭代。
同時,AI的出現也使得角色分割變得模糊。現在,產品經理可能利用大模型快速產生原型,而承擔了部分開發的工作,類似的動態能力有助於團隊更直觀地理解和評估產品概念。
我認為,人機協同的方式和交付模式的變革,以及整個鏈條式的變化,將共同推動軟體工程的演進。
AIGC實戰派:剛剛說到3.0時代還沒有正式開始,在這個過渡的階段中,會不會產生一些新的關鍵角色?
徐曉強:對,我們已經注意到出現了一些新的變化。例如,最近有個比較火的新職位-提示詞工程師(prompt engineer)。這個職位以前並不存在,它其實是從研發或產品角色演變而來的。這表明,隨著AI的融入,對原有職位的要求正在更新,同時也在形成更專業的細分領域,讓擁有這些技能的人可以發揮更大的價值。
AIGC實戰派:新的角色會以什麼方式加入企業?是在企業內部產生,還是說需要透過招募來實現?
徐曉強: 我認為,對於在AI原生應用的開發來說,提示詞工程師(prompt engineer)是一個不可或缺的角色。不過從目前來看,這個角色實在太新了,市場上難以找到經驗豐富的人選。因此,我們通常會透過內部轉崗,例如從研發或產品經理轉型,來填補這個角色。轉型過程中,我們會參考其他優秀實踐,將成功的實踐沉澱下來。
另外,我們也會在工具層面做支撐。在百度內部,為了支援整個連結的運作,我們開發了一系列工具,例如Comate stack、Playground等。
AIGC實戰派:剛剛您說AI創造了新的職位讓人眼前一亮,但話鋒一轉說,其實我們有很多的產品功能可以填補這些職位的需要…(是不是相當於沒有新的職位被創造出來?)
# 強: 那倒不是,我覺得工具是幫助人類去做到更好,工具本身不是用來取代人類的。
AIGC實戰派:##去年GitHub推出的AI程式工具遇到了一個訴訟,AI寫了一段程式碼,但這個程式碼被證明並不是原創,訴訟圍繞著侵權問題。我們在使用程式工具的時候,該怎麼樣去規避這樣的問題?
徐曉強: 這是一個很新的問題,無論是立法還是從判例來看,都缺乏足夠的參考。我覺得這其實是兩個層面的問題。第一層問題是技術問題,第二層是法律問題。
在技術層面,有很多的技術解法,更多是去做防禦。我們致力於確保技術的可靠性和合規性,例如在模型訓練時,識別並避免分發具有版權保護的程式碼片段。從產品層面,確保資料的合規傳輸,確保使用者互動過程的資料和隱私安全。
從法律層面來看,需要立法來解決相關問題,保護大多數人的利益。實際上民間已經有一些行動,今年我們作為生成式大模型智慧開發標準的核心參編單位,去編寫大模型原則、資料安全相關的保障條例。所以有理由相信,在不久的將來,整個法律層面會更完善更有依據,為產業的發展提供支持。
AIGC實戰派:徐老師說的這點很有啟發,剛才我們討論的問題,也不是大模型時代獨有的。因為大模型受到了很多關注,而且一部分的人對AI程式設計技術還存在著懷疑,那麼出現的個案(的負面影響)可能就會被放大。
徐曉強: 對。
AIGC實戰派:隨著AI程式設計工具的不斷發展與演進,最終會迭代調優到什麼樣子?我們好奇所謂的AI編碼的終極形態。
徐曉強: 從長期來看,我覺得終局會與現在的產品有非常大的質變。
首先是人機互動方式上的變化。目前,我們的互動主要是透過鍵盤輸入,我主動提供資訊給機器,讓機器分析和理解我的意圖。未來,我們能否以更平等、更對話的方式,甚至超越語言直接在意識層面進行交互,這將會是個全新的體驗。
第二點,我剛才也有提到一些想法,就是資訊載體在未來的變化,可能使得不再需要程式碼這個概念。我相信,未來將會出現模型及其周邊應用的新形態,這些應用將運行在模型之上,用戶與AI的交互不再依賴於程式碼或資料的傳輸。從而邁向最終「人人都是程式設計師」的終極目標邁進。
設想一個場景,加入我需要產生一個邀請朋友們參加派對的應用程式時,我只需要用一句話簡單表達我的需求,AI就能為我創建並發送這個應用程式,讓朋友們能直接回覆是否參加,以及他們的想法和禮物選擇。
回到現實,這種理想狀態還相對遙遠。
AIGC實戰派:這款產品接下來有哪些計畫?
徐曉強: 在Comate的發展上,我有兩個主要的期望。首先,我們希望能夠擴展它,以涵蓋更多的研發場景,甚至於應用到非研發場景中,從而幫助各種不同的角色在開發和軟體工程協同工作中提升效率。
其次,我也希望Comate能在垂直在開發領域中,為開發中的需求分析提供更深入的支援。幫助大家在使用過程中能夠更容易上手,快速地達到熟練水平,並獲得更好的成果。
想了解更多AIGC的內容,請造訪:
51CTO AI.x社群
https://www.51cto.com/aigc/
以上是AI編碼,真需求還是噱頭?的詳細內容。更多資訊請關注PHP中文網其他相關文章!