嘉賓 | 張濤

采訪&撰稿 | 云昭 

出品 | 51CTO技術棧（微信號：blog51cto）

“程序員的飯碗被AI惦記”，早已不是新鮮事。李彥宏說未來不需要程序員，黃仁勛說未來不要再讓孩子學編程！

Coding這個行業會消失？要回答這個問題，AI編程工具的研發者最有發言權。

近日，商湯科技小浣熊出圈，我們在AIGC實戰派中邀請到小浣熊背后的主導開發者，商湯科技Copilot應用技術負責人張濤。

“那些仍需要人精心地去跟機器溝通的部分，以前叫Coding、現在叫Coding，以后還是叫Coding！”

從模糊語義的人類語言到精確運行的機器指令，這個Gap會一直需要Coding來彌合。

在張濤看來，我們不妨換另一種角度去思考AI編程的意義。AI讓我們不再局限于傳統的代碼編寫，而是致力于讓人類能夠通過更自然、更直觀的方式與機器交流。張濤認為，消滅Coding并非目標，人們真正的愿景是提升編程的效率和直觀性，讓更多人能夠參與到創造未來的行列中來。

“現在的AI，是一種新的交互形式，它能與很多垂域的產品結合起來?！?/p>

之前的產品開發，往往會從場景需求出發，然后去收集各種各樣的一些軟件組件，或者是一些技術實現方案來實現自己原來想定義的產品。

而一旦想要往已經成熟的產品加入AI，或者在產品初期引入AI時，那么即使它不是個AI Native的產品，也需要提前把AI的局限性納入到考慮里面來。

值得注意的是，引入AI并沒有那么簡單，或許引入AI的方式并不起眼，它可能是一個一個小小的按鈕，或者是融入到一個不可見的整體流程，但這背后都是各種各樣的場景和需求。

“你要去照顧大模型來做產品，因為你的核心feature是由大模型提供的。這是AI Native產品帶來的一個明顯的思路改變?！?/p>

然而，讓軟件編程者去主導一個大模型應用的產品，并不是一個水到渠成的事情。

正如張濤在提到自身角色轉變時所說的，只懂大模型遠遠不夠，還有很多，比如產品思維，但最重要的，還是需要具備相應的領域知識和行業認知。

“我們不能過分自信地認為，懂大模型就可以把一切都做了。”

以下為訪談要點：

• AI產品不會消滅程序員，反而會促進程序員這個行業良性的發展。
• 實際上大家現在做這兩件事：第一，克服現在大模型的若干個缺點，第二，激發大模型更多的思考能力。
• AI提效工具類的產品，更多是讓它能夠處理人類慢思考能夠解決的事情。
• 爽點就在于，一個事情如果沒有什么成就感，但又一定要做，機器可以直接幫我完成。
• 不能過分自信地認為，懂大模型就可以把一切都做了。否則，可能全世界只需要Open AI的那700多人，其他的人都不需要來做軟件了。
• 對于正確性有高要求的場景而言，SFT的成本比較高，而且可操作性也是受限的，不如直接外掛一些知識庫的方法。

采訪內容如下：

一、Coding會一直存在，刷題怪可能會消失

51CTO《AIGC實戰派》：最近李彥宏、周鴻祎、黃仁勛都就程序員這個職業是否會消失發表了觀點，你對這個問題怎么看？

張濤：

程序員還會存在，只是工作方式不一樣了。程序員群體是對技術抱有好奇心的，肯定嘗試過各種各樣的AI輔助編程產品。從體感上看，目前已有的AI編程工具，大都是以Copilot的形式存在，去替代開發者去完成簡單枯燥的程式化的工作，加速開發效率。最重要的一點是，它可以讓你的Coding思路更加流暢絲滑。

如果說哪部分人會被取代，“背答案”或“刷題怪”可能危險了。從另一個角度看，AI產品不會消滅程序員，反而會促進程序員這個行業良性的發展。

一方面，大家不必再去投入太大精力去考察已有的經典算法或古怪的代碼中的奇技淫巧。更多地還是回到編程思想，溝通協作、解決問題的能力上來。另一方面，這也會讓開發者更積極的能投入到關鍵技術的探索里面，同時也能參與進產品的開發體驗和設計之中。比如我之前就是個程序員，現在其實有一半的精力在做產品相關事情。所以說，AI時代，會讓一個代碼實現的勞動者轉變成一個思考者的角色。

51CTO《AIGC實戰派》：

Coding本身這件事會被消滅嗎？

張濤：

我認為還是消滅不了的。消滅Coding的意義就在于，大家希望通過“人和人”交流的方式去和機器打交道，也就是用自然語言來做編程，但是這兩者之間是天然有一個鴻溝。

之所以稱之為自然語言，是因為它還是有一些模糊語義和需要澄清的部分。它和嚴格的形式化語言，比如說像數學公式、代碼等，天然有一個gap，即：沒有哪一個數學家，他會純用自然語言去闡述自己的數學發現。

至于說Coding中可以被AI取代的部分，是那些成組織的、有既定任務的部分，那些仍需要人和機器去精心溝通的部分，以前叫Coding，現在叫Coding，以后還是叫Coding。

51CTO《AIGC實戰派》：

Coding效率變高，是不是企業需要的程序員會變少？

張濤：

確實存在這個問題。一部分既定任務或者CRUD，其實這些是AI可以通過人的簡單指令，就能做到，甚至可能做的比人更好，而且不知疲憊。程序員這個職業自身的技術或者能力成分可能會發生一些變化。

之前，程序員的傍身之技，更多在于編程，比如對某一個編程語言特別的熟悉，理解一些編程的思想，此外還有一些落地實踐經驗。后續可能就會轉變到留出更多的時間來發掘新算法，更多地思考新的產品特性，比如，思考AI時代之后會給編程領域帶來怎樣的新的交互方式、產品形態，我就是個例子。

二、讓大模型坦承自己做不到

51CTO《AIGC實戰派》：AI編程類產品是否已經成熟，有哪些待改進之處？

張濤：

如果不考慮現在模型能力的限制，可以說趨于成熟了?，F在，比較關鍵的大模型限制主要有兩個。一個是context length（上下文長度），還有一個就是幻覺問題。現在大家都是采用一些工程手段來解決這兩類問題。雖然這樣不是說徹底解決，但是可以把它解決到一個使用的狀態，比如RAG，它本質上精排了一些優質數據和信息去增大里面的信息的密度，去解決這個問題。

另外還有prompt engineering、SFT的方式，讓大模型自身來抑制幻覺，讓其遇到一些未知的知識的時候，就坦誠的表示“不知道”。這些都是在大語言模型在落地的過程中非常重要的一個配套工程。

但目前還沒有達成一個既定的行業標準的成熟狀態，大家現在還是在摸索?？赡苈窂缴鲜乔逦模菍嶋H的技術棧上，還沒有形成真正的共識，比如上面提到的這些事情，langchain能不能做，也能做，但是可能用AutoGen更快，更容易。針對不同的場景，大家會采用一些不同的方式。總結來說，實際上大家現在做這兩件事：第一，克服現在大模型的若干個缺點，第二，激發大模型更多的思考能力。

三、聊一聊AI編程產品思路

51CTO《AIGC實戰派》：在激發大模型能力方面，小浣熊家族有著怎樣的產品路徑？

張濤：

小浣熊家族目前已經完成了兩款產品，分別是編程和辦公場景。這兩個產品從底層邏輯上，其實它是一個繼承的關系。AI提效工具類的產品，更多是讓它能夠處理人類慢思考能夠解決的事情。

而慢思考、邏輯推理，這些工作可能不是直接靠這個大模型“next token prediction”就可以做到的。那怎么辦？

第一，先給產品一個特定的、最適用于大模型的能力。代碼能力是大模型一個非常強大的內在能力，因為大模型本身就跑在計算機里。我們可以將其內化，強化大模型的編程能力。

第二，驗證可行后，憑借代碼能力可以做更多，去解決之前純靠大模型解決不了的事情：比如一些數據分析、數據可視化等任務。這就對應為辦公小浣熊這個場景。其中，除了強化代碼能力之外，還需要結合沙盒的執行反饋，來強化大模型的多輪反思能力。后續該系列產品還計劃通過、websearch、知識庫、多Agent等方式來激活大模型更多的能力。

AI編程產品形態方面，目前以代碼能力為出發點，自然會想到以插件形式集成到開發者經常使用的IDE內，這是一個最自然的形態。剩下的一些編程相關的工作，比如前端，對著一張高保真的圖像來實現復刻代碼，其實也可以給大模型直接做，這是多模態大模型所擅長的。

51CTO《AIGC實戰派》：

從用戶角度看，AI產品的痛點和爽點在哪里？

張濤：

從國內外類Copilot產品的數據來看，開發人員的接受度很高。爽點就在于，一個事情如果沒有什么成就感，但又一定要做，機器可以直接幫我完成。

舉個例子，開發者在寫代碼的過程中，有很多任務，思路很簡單，且有很多既定方法，但又沒有API，卻需要花時間去敲。這類工作交給AI，代碼寫到那里一停，小浣熊就可以直接給出后面十來行的函數。這對于程序員來講就是一個很大的爽點。

針對開發者平時搜索技術文檔方面，Devin是個值得借鑒的方法，可信度不能僅依靠大模型自身的反省能力。更好地一個方式是采用RAG或Web搜索而來的強參考信息，這些信息是有來源標注的，大家可以review。

除了幫你寫代碼，還有和你對話聊天，解決編程過程中遇到的一些問題，你可以直接針對代碼某些技術點進行提問。

四、角色轉變：懂大模型遠遠不夠

51CTO《AIGC實戰派》：從開發者到AI產品的打造者，有著怎樣的變化？

張濤：

之前自己主要是程序員的角色，現在主要在做代碼產品，所以在產品思維上會有更多的要求。但并不是完全轉向了產品角色。

之所以選擇代碼產品，是因為垂類AI產品是需要具備這個領域的知識和行業認知。

我在這里的角色并不是一個大模型專家，反而更多是一名產品所在行業的從業者——一名程序員。我們不能過分自信地認為，懂大模型就可以把一切都做了。否則，可能全世界只需要Open AI的那700個人，其他的人都不需要來做軟件了。

51CTO《AIGC實戰派》：

跟開發之前非大模型產品相比，流程上有哪些變化？

張濤：

之前的產品更多從場景出發，然后來收集一些軟件組件，或者是一些技術實現方案來實現自己預先定義的產品。而一旦想要往已經成熟的產品加入AI，或者在產品初期引入AI時，那么即使它不是個AI Native的產品，也需要提前把AI的限制局限性納入到考慮里面來。

之前大家可能從需求設計來出發，而現在大家可能有一定的考慮，需要去照顧大模型來做，因為如果產品的一些核心feature是大模型提供的，思路就需要轉變。

比如代碼產品中，我們先有代碼場景，然后在大模型放進來的第一時間就要考慮到大模型是如何起作用，如何揚長避短，在準備階段和一次次打磨過程中，讓大模型更好地為編程場景工作。

五、AI產品打磨，需要工程和模型雙側配合

51CTO《AIGC實戰派》：打造一款AI產品，有哪些棘手的挑戰？

張濤：

目前，AI產品的棘手問題挺多。比如，如何讓大模型更實用，剛才我們提到的RAG方案其實就需要做很多工作，怎樣保證性能效果有提升。雖然說它是“精選數據加入到提示”的方法，但是這里的精選數據也是一個模糊定義，所以他真正對模型的理解到底是加buff還是損失或者噪音，這里都需要大量研究工作。再比如，對于正確性有高要求的場景而言，SFT的成本比較高，而且可操作性也是受限的，不如直接外掛一些知識庫的方法。此外，工程和模型的配合的視角上面也要做很多大量實驗的工作，流程上目前也不能做到很精確的定義。以上這些都需要工程側和模型側一起解決。

本文轉載自 ??51CTO技術棧???，作者：云昭