“用嘴編程”時代，百度Comate如何解放開發者？_風聞

開發者們苦代碼久矣。

不確定的開發週期，不斷拖延的上線時間，以及不時出現的Bug，儼然成了當下最卷的崗位之一。

但在一個月前的百度AI開發者大會上，百度創始人李彥宏在介紹完基於文心大模型的智能代碼助手Comate後表示：“自然語言將成為新的通用編程語言，只要會説話，就可以成為一名開發者；未來開發應用就像拍個短視頻一樣簡單。”

由此引出了這樣一個話題：“用嘴編程”的智能代碼助手百度Comate，可以為開發者們提供什麼樣的能力，能否讓他們從繁雜且瑣碎的任務中解放出來？

01 整體採納率46%，百度Comate是怎麼做到的

作為大模型最早落地的一批場景，“代碼助手”可以説是現階段最成熟的應用。

其中基於文心大模型的智能代碼助手百度Comate，已經在百度內部悄然上崗一年，並於2023年6月正式開放邀測，2023年10月24日全面對外開放，2024年3月正式升級到2.0版本。

不單單是百度在佈局，Github Copilot、Codeium、CodeWhisperer等產品也陸續上線。甚至有產品上線半年時間，估值就超過20億美元，再次刷新了獨角獸的誕生速度。

一個有趣的現象是，不少“代碼助手”在宣傳中往往採用這樣的話術：研發效率提升了XX%，幫助開發者節省了XX%的測試時間，代碼生成速度比人工提升了XX%……無不將效率提升作為產品賣點。

百度CTO王海峯在不久前舉辦的2024中關村論壇年會上對外公佈了一組不同的數據：“目前智能代碼助手Comate整體採納率達到了46%，新增代碼中生成的比例已經達到了27%。”

兩組數據的差別到底在哪？

先來回顧下“代碼助手”的常見功能，普遍集中在代碼補全、生成註釋、文檔閲讀等方面，在“提效”上有着不可小覷的想象空間。以模糊檢索為例，過去想要找到一個問題的答案，需要仔細閲讀三四篇博客，花費幾個小時的時間，如果將這項工作交給AI，可能只需要幾分鐘，呈現出了碾壓性優勢。

代碼的採納率卻另一個議題，比拼的不僅是生成速度，還關係到開發者羣體的核心痛點，生成的代碼有沒有缺陷，能不能採用，是否可以提升代碼的整體質量。打個比方的話，“代碼助手”要解決的不只是造輪子的問題，而是造出需求規格極為明確的輪子，並且不能出現漏氣、鼓包、斷裂等情況。

為何百度Comate可以做到46%的整體採納率？原因或許可以歸結為兩點：

一是文心大模型的能力。正如李彥宏在《人人都是開發者》的主題演講所談到的：“近幾個月來，文心大模型在代碼生成、代碼解釋、代碼優化等通用能力方面實現了進一步的顯著提升，達到國際領先水平。”相對應的，開發者只需要“動動嘴”，百度Comate就能完成推薦代碼、生成代碼註釋、查找代碼缺陷、給出優化方案等工作。

二是百度Comate的產品力。正如外界所熟知的，數據質量直接影響着模型的能力，百度Comate結合了百度積累多年的編程現場大數據和外部優秀開源數據，可以生成更符合實際研發場景的優質代碼，並且有着更好的適用性：支持100多種主流編程語言、所有主流IDE平台，覆蓋編程前、後、移動端、軟硬件等不同開發場景。

截止到目前，百度Comate已經服務了百度內部80%以上的工程師，並廣泛應用於喜馬拉雅、軟通動力、上海三菱電梯等上萬家企業。一場“用嘴編程”的革命，已經呈現出了星火燎原之勢。

02 開發者的提效神器，也是量身定製的私人助理

和其他代碼助手類產品不同的是，百度Comate更像是量身定製的私人助理。

在開發者的日常工作中，寫代碼只佔整個開發過程的40%，需求分析、架構分析、測試、運維等佔據着60%的精力。倘若只停留在代碼層面，對生產力的提升有着肉眼可見的天花板。百度Comate的答案並不複雜，簡單來説就是從需求文檔到版本管理在內的研發全流程進行提效。

直接的例子就是3月份的產品升級，百度Comate新增了兩個重磅能力，服務邊界進一步延伸到研發的更多環節。

一個是Comate+開放平台。

百度Comate生成的代碼，在百度新增代碼中的比例從2023年11月的20%提升到2024年4月的27%，一個不可或缺的操作在於，百度Comate結合了百度的技術選型和編碼規範，可以推薦更符合規範的代碼。Comate+開放平台的作用，就是將這樣的能力賦給每一個用户。

藉助Comate+開放平台的私域知識增強功能，可以輕鬆對接企業的私域知識。如果企業有特定的代碼規範或編寫方式，將這些知識上傳到Comate+平台，並與相關功能進行綁定，即可充分利用企業的私域知識進一步提升其準確率。以飛槳PaddlePaddle為例，應用私域知識增強功能後，代碼生成的準確率從60.5%提升到了81.5%。

除此之外，Comate+開放平台還能直接對接第三方服務或能力，包括GitHub、GitLab、Gitee等插件，可通過插件自動獲取當前項目變更內容，自動分析當前倉庫的issue列表，有效提升編程體驗與效率。

另一個是AutoWork私人研發助理。

Comate+開放平台打通了企業的私域知識，AutoWork則扮演了“私人研發助理”的角色，深入理解本地代碼庫和組織內部的私域知識，並以智能問答、結合私域知識生成代碼等方式為開發者服務。開發者只需要明確開發的“目標”和“意圖”，AutoWork便能自動檢索必要的背景知識、獨立分析產品需求，匹配最佳解決方案並生成代碼。

比如開發者需要掌握新代碼庫時，無需翻閲大量文檔去理解複雜邏輯，可以直接和代碼庫“聊天”，用問答的方式要求AutoWork梳理代碼架構，然後就會看到清晰完整的解釋，實現“哪裏不懂問哪裏”。

再比如開發者可以掛載指定的開發文檔、需求文檔、API 文檔等，通過文心大模型的能力對私域研發知識進行快速理解、分析和應用，讓“花費大量時間去翻閲文檔”成為一種過去時，開啓“一鍵式”高效編程的新體驗。

做一個總結的話，百度Comate正在塑造一種全新的人機協同範式，在保障數據安全的前提下，實現對企業私域知識連接和個性化需求的深層次滿足，就像量身定製的私人助理一樣，可以無縫集成到研發流程的各個環節，全方位提升開發者的體驗和效率。

03 三步安裝百度Comate，人人都可以“用嘴編程”

對於開發者而言，在“用嘴編程”的時代，想要不被淘汰，就要學會使用“新工具”。

很長一段時間裏，“程序員”都是高薪崗位的代名詞，以至於許多人歸因於代碼，掌握了代碼就相當於有了改變世界的能力，進而獲得相應的回報。

按照第一性原理解釋的話，“代碼”的作用只是解決問題的工具，開發者最有價值的技能並非是編寫代碼，而是分析問題並找到合適的方案解決問題。

沿循這樣的邏輯，諸如人工智能取代程序員的説法，本身就是一個偽命題。因為生產力的提升是無止境的，石器時代的斧頭，無法適應青銅器生產的需要；農業時代的耕牛，拉不動紡織廠裏的機器……

在人工智能無處不在的世界裏，“編寫代碼”將不再是開發者的首選工具，取而代之的是百度Comate代表的、幫開發者解決問題的“新工具”。

可能不少人還在存疑，但一些第三方報告，已經給出了確切的答案。

Stack Overflow的調查顯示，目前44%的軟件工程師已經在開發流程中使用AI工具，26%的工程師已經將AI工具列入計劃；權威諮詢機構Gartner預計，過半組織正在使用或已經部署AI驅動的編碼助手，預計到2028年將有75%的開發者離不開編程助手。

相對樂觀的是，百度Comate正不斷降低門檻，開發者和“新工具”的距離，已經被壓縮為三個步驟。

第一步，打開百度Comate官網，點擊“免費使用”或“下載安裝”；

第二步，根據官網上的提示安裝Comate插件，目前已支持Visual Studio Code、JetBrains IDEs、Xcode等三種方式；

第三步，安裝完成後登錄百度賬號，開啓智能代碼之旅。

因為快速上手的特性，以及百度Comate的產品體驗，收穫了國內外開發者的普遍好評。

有開發者在社區中分享了自己的使用心得：

從Comate整體表現來説，我是要給五星好評的，我最喜歡的就是自動提示後續代碼的生成。

為什麼這麼説，在我們寫代碼的時候往往要考慮後續的代碼編寫，Comate能給我們提示，直接採用之後只需要稍微改動就可以，真正的達到了提質增效的效果。

也有開發者和國外產品進行了橫向對比：

Comate帶給我有不錯的體驗感，相對於Continue + ollama + codellama:7b的生成速度是快很多的，並且代碼質量很好，給出的參考建議也是很合適。

最主要的是Comate不需要第二次提示就可寫出代碼！！！而且首月只需要1元，專業包年4開頭對比Copilot99美金年費也是很優惠！並且可以使用個人免費版。

對比其他使用的AI助手：

從代碼質量角度：Copilot = Comate >= Continue + ollama + codellama:7b

從生成速度角度：Comate > Copilot > Continue + ollama + codellama:7b

此外，在VSCode、Jetbrains等各大插件市場智能助手評分榜中，百度Comate分別以4.5和4.4位列第一，通義靈碼位居第二、第三， CodeGeeX、iFlyCode、aiXcoder、GitHub Copilot等跟隨其後。

再來理解李彥宏的觀點，“用自然語言編程”、“人人都是開發者”等觀點非妄斷。在百度Comate的幫助下，“開發”的含義不再是孤獨地敲打鍵盤，而是想出一個解決方案，並用簡單的日常語言表述它，然後在百度Comate的輔助下把它創造出來。

由此可以預見，“開發者”的概念將再次刷新，和“程序員”一詞漸行漸遠，演變為技術與商業、創意和實現之間的“擺渡者”。一個優秀開發者的衡量標準，不是編寫了多少行代碼，而是如何使用“新工具”把想法變成現實，如何使用“新工具”解決現實世界的複雜問題。

在人人都可以“用嘴編程”的時代，開發者不會被淘汰，但那些不會使用“新工具”的守舊派，將不可避免地被淹沒在時代的煙塵中。