在百度工作一年半成功升職,這位AI程序員做對了什麼|對話文心快碼
在百度工作一年半成功升職，這位AI程序員分享了這些晉升秘籍。
據瞭解，文心快碼已經參與了超過27%的代碼，協助了超過80%的工程師。
在最近的雲智大會上，它又get了新的技能——代碼架構解釋和代碼審查。
衡量自動化編程的關鍵指標是什麼？理想態AI編程產品的實現技術路徑會是什麼？AI編程產品的PMF將會在什麼時候出現？
量子位「365行AI落地方案」邀請到了百度智能雲技術委員會主席孫珂博士，我們一起聊了聊文心快碼最近的新升級，編程自動化時代距離我們還有多遠。
（以下內容根據直播對話整理）
量子位：前段時間，雲智大會上看到文心快碼有兩個能力的升級：一個是代碼架構解釋，一個是代碼審查。請先爲我們介紹一下這兩個功能，以及如何賦能企業開發工作流的呢？
百度孫珂：文心快碼的定位，就是賦能企業程序員開發的全工作流程。從這個出發點去看，我們能注意到程序員的日常工作狀態下，並不是完全在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等輔助能力。這是我們大致的生態構建情況。
量子位：最後您還有沒有補充分享給我們觀衆的呢？
百度孫珂：今天聊的很開心。整體就是想和大家聊一聊文心快碼這款產品，從商業化到具體功能實現，以及未來的發展規劃等。我們產品的迭代速度還是蠻快的，接下來一到兩個月內將有兩個版本的大升級，無論是效果還是功能都會有大幅度提升，會讓大家很驚喜。希望大家可以多多關注。
AI技術的落地應用不僅限於科技領域，它已經滲透到各行各業，成爲推動產業升級的重要力量。因此，“365行AI落地方案”主題策劃應運而生，我們尋找各行各業中成功應用AI技術的案例和方案，分享給更多的產業內人士。