嘉賓| 徐曉強
#訪談| 張曉楠
##撰寫稿| 李美涵
出品| 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中文網其他相關文章！
