視點 發自 凹非寺
量子位｜公眾號 QbitAI
在百度工作一年半成功升職，這位AI程式設計師分享了這些晉升秘籍。
據了解，文心快碼
已經參與了超過27%的程式碼
，協助了超過80%的工程師
。
在最近的雲智大會上，它又get了新的技能——程式碼架構解釋和程式碼審查。
衡量自動化編程的關鍵指標是什麽？理想態AI編程產品的實作技術路徑會是什麽？AI編程產品的PMF將會在什麽時候出現？
量子位「365行AI落地方案」邀請到了百度智慧雲技術委員會主席孫珂博士
，我們一起聊了聊文心快碼
最近的新升級，編程自動化時代距離我們還有多遠。
亮點概述
現在，大家下班後可以將程式碼交給大模型來批次審查，第二天上班時再針對修正建議進行修改，提升了效率和品質。
我們更關註的是在每千行程式碼裏，到底有多少程式碼是被大模型處理過的
。
現在的套用形態分為兩種大趨勢：一種趨勢是指助手或Copilot的邏輯
，程式最終的執行和交付由程式設計師來主導的；另一種趨勢就是像程式碼直譯器這種
，整個程式的最終執行和交付是由大模型自己主導的。
我更期待什麽時候能夠出來一款由大模型完全主導的、自動化生成的、能夠穩定執行並且實用化、商業化的套用。我認為這款套用將代表誕生了第一個實作PMF的產品。
可能未來有一天，我們只需要一個對話方塊告訴網站接下來要幹什麽事情
，大模型就能生成按鈕出來，點一下，這個任務就完成了。
…
（以下內容根據直播對話整理）
與其開會，不如直接讓大模型來審查程式碼
量子位
：前段時間，雲智大會上看到文心快碼有兩個能力的升級：一個是程式碼架構解釋，一個是程式碼審查。請先為我們介紹一下這兩個功能，以及如何賦能企業開發工作流的呢？
百度孫珂
：文心快碼的定位，就是賦能企業程式設計師開發的全工作流程。從這個出發點去看，我們能註意到程式設計師的日常工作狀態下，並不是完全在Coding（編程）。實際上在工作流的開始，比如新進一個計畫組，或者剛開始啟動計畫時，需要對計畫的程式碼架構，有個整體性的理解。
我本人也是幹了快20年的程式設計師，特別不喜歡突然接手了別人幾萬行或者幾十萬行的程式碼，這種需要一點點地對著PRD和註釋來梳理整個程式碼的邏輯脈絡。我過去覺得幹這個事情還挺痛苦的。
在大模型出現後，我們註意到大模型能夠幫助閱讀程式碼、幫寫註釋等等。除了寫程式碼，我們是不是可以考慮讓大模型更早期地參與計畫，讓大模型快速地把程式碼架構梳理出來。相信在企業客戶裏會有非常多程式設計師，面臨著和我類似的痛苦經歷。我們就是基於這樣的考慮，提供了第一個升級點——程式碼架構解讀
。
另一個升級點，就是程式碼審查
。這也是我們日常開發標準化流程的一部份，很常見也很重要，叫做Code Review。程式設計師在前期開發、偵錯完程式碼後，在正式釋出前，會邀請到公司裏的資深程式設計師組成評審小組，來審查最終完成的程式碼，檢查程式碼是否合乎規範等等，主要目的就是提升程式碼品質。
在我們和企業研發負責人的溝通中發現，這個非常常見的研發環節，在研發流程中靠後，而且需要耗費很多精力去完成。同時我們也註意到，大模型其實還挺擅長幹這件事的。它可以直接閱讀企業內部的開發規範，再基於規範稽核程式碼，稽核後還可以標註出違反規定的地方、提出修正建議。
現在可以有這樣的解決方法：大家下班後將程式碼交給大模型來批次審查，第二天上班時再針對修正建議進行修改，提升了效率和品質。
量子位
：那麽文心快碼是否已經在百度內部，或者其他服務的企業中，實作了怎麽樣的效率提升呢？
百度孫珂
：百度是一個擁有大量程式設計師和研發工作的公司。我們這款產品的前瞻功能，都會優先在百度內部用起來。
其實文心快碼在百度內部，已經推廣了快兩年的時間。現在超過27%
的程式碼都是由文心快碼生成或者輔助撰寫的，百度內部有超過80%
的工程師都在使用文心快碼。在百度內部，這也是非常強的提效工具，能夠把全域的研發效率提升10%以上。
除此之外，像喜馬拉雅也在使用文心快碼。文心快碼輔助他們程式設計師開發的程式碼，大概占了公司總體新增程式碼的三分之一。而且對工程師的覆蓋率也很高，差不多有90%。所以可以看到，文心快碼對於程式設計師coding密集型的公司，是一個很有效果的提效神器。
量子位
：現在有更多開發者和我們反饋說，在日常工作流中已經在使用大模型來提高開發效率了。之前也有第三方機構調查說，可能五年之後，使用AI程式碼助手的工程師能達到75%。您覺得現在AI編程的發展，對開發者的能力提出了什麽樣的新要求呢？
百度孫珂
：這是個很有意思的問題。大模型技術在做的，就是把我們從日常繁瑣的工作中逐步解放出來。比如程式碼助手可以幫你讀程式碼、寫程式碼、審程式碼等等，也能寫註釋、寫單元測試，這些都是每一個程式設計師的基礎能力。我認為大模型會逐漸替代這些工作。
還有像被稱為固定手勢的，比如非常熟練地啪一下寫出好幾行的for迴圈。這些重復敲幾百上千次的指令，大模型如果能逐漸幫我們省略掉，還是很值得期待的。所以大模型對於程式設計師來說，主要還是減負的效果。
在我看來，未來程式設計師更重要的能力是偏架構性的
。也對應著高級別程式設計師的頭銜，架構師。
這意味著基礎的工作逐漸被大模型節省掉，那麽程式設計師可以花更多精力在更精髓的點上，比如這個程式架構如何設計，如何安排函式之間的互相呼叫關系，如何拆分功能等等這一系列更有決定性意義的工作。這也是對未來程式設計師能力的要求。
量子位
：我們看到文心快碼從去年入職百度AI程式設計師，過了一年後晉升為了AI架構師，這個職級的升級，百度是怎麽定義的呢？
百度孫珂
：我們內部對工程師的要求是，架構師要能處理一些更宏觀的任務，比如跨檔、跨計畫的任務。我們對文心快碼的定義也是類似的。
文心快碼一開始，也是僅僅處理當前頁面、某段程式碼的續寫，就像是一個普通的小RD一樣，每天只是幫忙續寫敲程式碼。再往後，隨著大模型能力的提升，我們可以讓文心快碼幫我們駕馭更多計畫級檔間的依賴關系。
文心快碼在處理任務時，不僅僅在看當前頁面，也能看到計畫甚至公司裏所有相關知識和檔的依賴。你會發現它越來越像個架構師了。
量子位
：相當於文心快碼整合了整個企業私域的知識，然後去處理一些計畫級任務。
百度孫珂
：是的。這也是我們這次很重要的升級，文心快碼增強了對企業知識整體的閱讀和使用能力。你會發現當把文心快碼這樣的產品放到企業中套用時，會讓你的程式碼生成得更得心應手，而且貼合企業的使用習慣。
量子位
：在產品升級上，會更多圍繞企業的需求，還是依賴現在大語言模型的能力呢？這兩者的優先級是什麽樣的？
百度孫珂
：說實話，我們做決定的時候，更多還是考量客戶的訴求。
之前很多客戶反饋說，程式碼輔助的工具很好，但是寫出來的東西和自己企業的知識庫或者已有開發出來的東西關系不大。這意味著把面向公共的程式碼輔助產品推廣到企業內部使用的時候，需要結合企業已有的程式碼知識庫，包括像介面之類的結合。
量子位
：是不是可以說，這種要讓企業用起來的定位，是文心快碼的優勢和獨特性？
百度孫珂
：我們對於文心快碼的定位很簡單，就是期望企業能把它很好地用起來。包括我本人就是RD出身，一般想東西都很樸素，就是希望把能最直接立刻幫到我們的功能，提供給企業客戶。我們也確實看到了，能夠結合企業的知識、企業的研發流程，以及未來更多與研發工程師深度結合的功能，會是我們產品相比較有優勢的地方。
量子位
：結合咱們的經驗，您認為應該怎樣打造定位為企業級的編程產品呢？
百度孫珂
：首先要定義清楚邊界。我們的產品不會面向過多的角色拓展功能，比如暫時不會涉及過多產品經理相關的PRD等功能。主要還是聚焦於RD這個工種上，順著RD的研發工作流去規劃我們的功能，從計畫建立、研發、偵錯、到測試等每個環節上都要實作部署。當然實際實作上會有先後順序和技術成熟的問題。
我們現在的一個基本判斷是，現在文心快碼還是定位在偏輔助形態的工具，我們會在每個研發環節上挖掘對程式設計師有價值的功能，希望能讓工程師能立刻用起來。我們也在努力探索的另一個方向是，未來還會更加面向自動化的計畫建立和編程。
量子位
：現在文心快碼已經從AI程式設計師升級到AI架構師了，那接下來有可能擔任什麽樣的職位呢？
百度孫珂
：這個架構師的職位已經是很高了（笑）。再往上走可能沒辦法給他更高的頭銜了，不然就是CTO了。
但是在功能上它會有更多的變化。比如從續寫升級到程式碼的輔助生成能力，能夠把大模型結果和程式設計師正在寫的程式碼結合起來。在審查能力上，我們也會去做更多的事，除了程式碼規範，還有安全性的檢測等。
更近一些的升級，是我們還會增強單元測試等測試環節的能力，未來一到兩個月就會釋出。
所以接下來可能不是用架構師來形容，而是可以稱為全棧工程師
，能夠從前到後都解決很多問題。這是我們的預期。
關鍵指標是大模型生成程式碼的滲透率
量子位
：我們也看到咱們未來的計劃有，實作直接從文字到套用這樣端到端的生成。現在端到端也是很重要的一個趨勢，不知道這個會是什麽時候實作呢？
百度孫珂
：沒錯。大模型就是大語言生成式模型，我們能看到的主流的大模型套用方法或者生成方向，都是用大模型直接生成文字，這也是C端產品比較主流的使用方式。你還可以用大模型去做任務上的規劃，或者生成一系列跟程式碼相關的內容。這個過程中也衍生了非常多的套用形態，包括剛才提到的所謂從文字生成套用這種端到端的方式，也有現在我們正在聊的程式碼助手。
還有一種，是大模型現在具備的程式碼直譯器的能力。它的運作方式是先讓大模型生成一段程式碼，更進一步把程式碼的執行包裹到解決方案裏；不僅生成程式碼，還把程式碼放到執行環境裏執行，再返回結果。這步執行後，有時候直接返回結果，有時候還會利用大模型的反思和偵錯能力，進一步修正結果。
這意味著，你可以看到現在的套用形態分為兩種大趨勢：一種趨勢是指助手或Copilot的邏輯
，程式最終的執行和交付還是由程式設計師來主導的；另一種趨勢就是像程式碼直譯器這種型別
，整個程式的最終執行和交付是由大模型自己主導的。
這兩種趨勢之間很有意思的區別是，程式設計師主導的可以寫一些正式的商業化程式，需要保證穩定性、規模和整體架構的可控性。而純粹由大模型主導生成的程式，生成一個較小的套用是沒問題的，效果比較穩定的話大概是50-100行程式碼的套用。
那麽我認為，這兩種趨勢會逐漸向同一個方向靠攏。也就是說，程式設計師主導的助手類套用可能會從提供一兩行的程式碼，到推薦一整個函式，讓程式設計師能夠無腦確認並穩定執行。大模型主導的套用則會寫越來越多的程式碼，在這個過程中保證去生成一個更復雜的、端到端的任務，讓程式自動執行。未來有一天也許兩種方式會達到交匯。
我看到不少創業計畫，已經在嘗試這種交匯的方式。但走這條路，需要嘗試解決很多規劃性問題，來保證整個程式、整個結構的規劃穩定，還要做大量的反思動作。實際上往前走的每一步，可能都要花費數倍於之前的token去解決相關問題。
按照第一種趨勢，產品需要設計跟使用者深度互動的能力，在互動過程中收集使用者的真實反饋和人類的checking行為，幫助大模型把越來越復雜的程式碼生成能力進一步最佳化。而第二種趨勢，會是一種很好的探索產品形態的路徑。
我更期待的，是什麽時候能夠出來一款由大模型完全主導的、自動化生成的、能夠穩定執行並且實用化、商業化的套用。我認為這款套用將代表誕生了第一個實作PMF的產品，從這個時間點開始後續產品的發展會加速。
這款產品也許最長不過三年的時間就會出現，我對它的形態有很多的暢想，我們也想看有沒有機會先做一款出來。到了那一步以後，有了使用者驗證和商業化的反饋，產品就能夠高效地進行深度叠代，也能夠極大激發這個方向快速地成長。
可能未來有一天，我們的網站上不需要按鈕，也不需要提前寫什麽功能，我們只需要一個對話方塊告訴網站接下來要幹什麽事情
，大模型就能生成按鈕出來，點一下，這個任務就完成了。我還是挺期待這樣的一天的。（笑）
量子位
：Karpathy曾經提到說自動化編程也可以像自動駕駛劃分為L1到L4的發展階段。您是如何看待程式碼生成的L1到L4的階段的呢？
百度孫珂
：我心中有一個L2，也有一個L4，但我沒有劃分中間的L3。我認同我們一定能走到 L4，而且甚至覺得這一天不會太遙遠。
這和剛才提到的一樣。程式設計師主導的產品需要解決數據收集的問題，透過很好的產品設計和產品互動來收集人的行為，特別是要收集到人類解決問題中的判斷。大模型主導的產品，就是按理想態做端到端的產品形態，對模型進行深度打磨，這就非常需要前面收集到的數據。所以兩條路需要同時往前走，而且缺一不可。
就像現在的自動駕駛，所有新能源車上都裝備的是L2，但已經有正在研發的L4了，L2可以反哺L4的技術的。我們也很期待兩條路合攏的時候，也許意味著真的到了解放雙手的時候。
量子位
：文心快碼的團隊也是兩條路線並列嗎，還是有更加註重的一條路線？
百度孫珂
：百度作為一家非常AI導向的公司，我們肯定是要去做很多潛在的技術布局的。同時，我們也在致力於去把這些技術能夠快速的落地，交付到所有使用者手上。所以，可以認為兩條路它一定是會都存在的，而且我們永遠不缺乏向前探索的、聰明的工程師正在日夜奮戰，往那個理想路徑上前進。
量子位
：現在市面上已經有很多的編程產品，您覺得現在有什麽比較關鍵的指標可以用來評估這些產品？
百度孫珂
：這是一個很好的話題。業內現在大家比較常用的，也是對編程輔助這類產品的普遍認知，更多的是停留在「我光標到這了，開始給你寫」。所以一個非常通行且常用的指標就是寫出來後采不采納，我們稱之為采納率
。這個指標我們也會用，並且也在努力對其進行最佳化。
但我作為一個做了多年策略的人，會覺得這個指標不太能完整地衡量我們對整個研發過程的提效。所以，我們也做了很多其他的指標，會根據不同的功能，有各種各樣的指標邏輯，當然也會很瑣碎。
我們還在做一個端到端的指標衡量。我們註意到，程式設計師不管怎麽寫程式碼，最終都會有一個check in的動作，也就是送出程式碼。現在我們衡量的是，在單位時間裏，程式設計師生成的程式碼數量是否有提升，以及在單位時間內，程式設計師每千行程式碼裏有多大比例是由機器生成或修正的。
這個數據意味著大模型在多大程度上，把它的能力滲透到了程式設計師開發過程的方方面面。所以，我們更關註的是在每千行程式碼裏，到底有多少程式碼是被大模型觸碰過的
。
量子位
：有沒有一個理想的數值，比如大模型滲透到百分之多少，能代表這個能力是有效的？
百度孫珂
：其實每滲透一點進去，都能滿足我的預期。像剛才說到，百度有百分之二三十的程式碼已經由大模型生成了，這可以認為是我的基線。短期一到兩年內，我們會認為百分之50到70的比例，是一個不錯的水平。
但在我心目中，我認為這個比例越高越好。也許未來的所有的程式碼實作，都是由大模型生成的，程式設計師只需要把需求提供給大模型就OK了。所以這個比例在我心中是沒有上限的。
保證企業和個人使用者的體驗一致很重要
量子位
：企業的程式設計師和個人開發者，對於文心快碼的關註點和需求是否有什麽不同嗎？
百度孫珂
：這是一個很有意思的問題。其實我剛才提的指標，基本上都是企業比較關心的事。
對於個人程式設計師，其實並不會真的仔細衡量自己的效率，他們更像是日常的C端使用者，更關心的是功能好不好用、能不能用。比如某個功能的點選路徑是否足夠少，能不能用最簡潔的方式操作，像有些程式設計師會有很極客的執念，比如我規定自己寫程式不能動滑鼠，一定要保證雙手都在鍵盤上，只用快捷鍵解決問題。
使用者實際上關心的是每個功能是否能更高效，用更少的點選和更少的操作達到解決問題的目的。他們也許不會把研發環節定義得這麽細致，但他們每天都在處理類似的事情。他們能夠用大模型處理每天事情中的八、九成，也許最後每一個操作都有大模型在輔助，我認為這基本就是個人程式設計師使用者最期望得到的了。
量子位
：如何平衡滿足個人程式設計師和企業程式設計師之間不同的需求呢？
百度孫珂
：文心快碼有兩個版本，一個是面向公有雲的，在公域透過baidu.com可直接搜尋到並免費下載使用，高級功能也有一些限免策略；另一個是面向企業的，會提供相關售賣服務以及企業部署。
個人和企業使用者的差異點，實際上就是大家到底在關心什麽問題。在企業內部，需要更多地深度結合企業知識，關註與企業相關規範、研發流程等的深度結合和掛鉤。
對於公有雲版本的個人使用者，他們更關心能否快速獲取開源網站上的範例程式碼並適配到自己的程式中，以及是否可以在文心快碼框架內解決編程過程中遇到的問題。
我們還可以看到一個訴求差異，就是程式碼語種的分布不同。比如企業中java等語言使用更多，公域裏除了java外，對python等AI相關的語言，也有更多的訴求。但其實兩者沒有沖突。
如果能同時滿足兩者的需求，那麽當企業的程式設計師摘掉工牌在家做自己喜歡的事情時，就可能成為公有雲使用者。整體體驗的一致性是很重要的。
量子位
：在面向企業端的時候，是否有構建企業生態這方面的相應措施？
百度孫珂
：我們是期待有更多企業參與到整個服務生態中。有的交付企業會希望自己將文心快碼與自身企業內部做深度整合，要求我們只保留伺服端、外掛程式端等，其他的重新根據他們自身ID重新打造一套。對於這些訴求，我們都是會透過企業生態的方式來構建和推廣。
比如我們會給生態企業提供只有後端服務能力、沒有外掛程式的版本和介面，相關外掛程式程式碼及向外推廣的服務都可以由生態企業來完成。此外，我們還有更靈活的版本，將產品封裝成一體機形態，也交由生態企業對外推廣和售賣。
我們也有面向程式設計師教育的生態建設。要知道，中國有700-800萬正式程式設計師，還有近十倍的在學程式的人。我們會與很多教育機構合作。面對這群使用者，我們會有一些不同之處，比如不僅幫他們續寫程式碼或理解計畫，還會提供偵錯bug等補助熱量力。這是我們大致的生態構建情況。
量子位
：最後您還有沒有補充分享給我們觀眾的呢？
百度孫珂
：今天聊的很開心。整體就是想和大家聊一聊文心快碼這款產品，從商業化到具體功能實作，以及未來的發展規劃等。我們產品的叠代速度還是蠻快的，接下來一到兩個月內將有兩個版本的大升級
，無論是效果還是功能都會有大振幅提升，會讓大家很驚喜。希望大家可以多多關註。
關於365行AI落地方案
AI技術的落地套用不僅限於科技領域，它已經滲透到各行各業，成為推動產業升級的重要力量。因此，「365行AI落地方案」主題策劃應運而生，我們尋找各行各業中成功套用AI技術的案例和方案，分享給更多的產業內人士。
