今天小編分享的科學經驗：在百度工作一年半成功升職，這位AI程式員做對了什麼，歡迎閱讀。
在百度工作一年半成功升職，這位 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 端用戶，更關心的是功能好不好用、能不能用。比如某個功能的點擊路徑是否足夠少，能不能用最簡潔的方式操作，像有些程式員會有很極客的執念，比如我規定自己寫程式不能動滑鼠，一定要保證雙手都在鍵盤上，只用快捷鍵解決問題。
用戶實際上關心的是每個功能是否能更高效，用更少的點擊和更少的操作達到解決問題的目的。他們也許不會把研發環節定義得這麼細致，但他們每天都在處理類似的事情。他們能夠用大模型處理每天事情中的八、九成，也許最後每一個操作都有大模型在輔助，我認為這基本就是個人程式員用戶最期望得到的了。
量子位：如何平衡滿足個人程式員和企業程式員之間不同的需求呢？
個人和企業用戶的差異點，實際上就是大家到底在關心什麼問題。在企業内部，需要更多地深度結合企業知識，關注與企業相關規範、研發流程等的深度結合和挂鉤。
對于公有雲版本的個人用戶，他們更關心能否快速獲取開源網站上的示例代碼并适配到自己的程式中，以及是否可以在文心快碼框架内解決編程過程中遇到的問題。
我們還可以看到一個訴求差異，就是代碼語種的分布不同。比如企業中 java 等語言使用更多，公網域裡除了 java 外，對 python 等 AI 相關的語言，也有更多的訴求。但其實兩者沒有衝突。
如果能同時滿足兩者的需求，那麼當企業的程式員摘掉工牌在家做自己喜歡的事情時，就可能成為公有雲用戶。整體體驗的一致性是很重要的。
量子位：在面向企業端的時候，是否有構建企業生态這方面的相應措施？
百度孫珂：我們是期待有更多企業參與到整個服務生态中。有的交付企業會希望自己将文心快碼與自身企業内部做深度整合，要求我們只保留服務端、插件端等，其他的重新根據他們自身 ID 重新打造一套。對于這些訴求，我們都是會通過企業生态的方式來構建和推廣。
比如我們會給生态企業提供只有後端服務能力、沒有插件的版本和接口，相關插件代碼及向外推廣的服務都可以由生态企業來完成。此外，我們還有更靈活的版本，将產品封裝成一體機形态，也交由生态企業對外推廣和售賣。
我們也有面向程式員教育的生态建設。要知道，中國有 700-800 萬正式程式員，還有近十倍的在學程式的人。我們會與很多教育機構合作。面對這群用戶，我們會有一些不同之處，比如不僅幫他們續寫代碼或理解項目，還會提供調試 bug 等輔助能力。這是我們大致的生态構建情況。
量子位：最後您還有沒有補充分享給我們觀眾的呢？
百度孫珂：今天聊的很開心。整體就是想和大家聊一聊文心快碼這款產品，從商業化到具體功能實現，以及未來的發展規劃等。我們產品的迭代速度還是蠻快的，接下來一到兩個月内将有兩個版本的大更新，無論是效果還是功能都會有大幅度提升，會讓大家很驚喜。希望大家可以多多關注。
關于 365 行 AI 落地方案
AI 技術的落地應用不僅限于科技領網域，它已經滲透到各行各業，成為推動產業更新的重要力量。因此，"365 行 AI 落地方案 " 主題策劃應運而生，我們尋找各行各業中成功應用 AI 技術的案例和方案，分享給更多的產業内人士。
