一凡 發(fā)自 凹非寺
量子位 | 公眾號 QbitAI

AI Coding，終于開卷協(xié)同作戰(zhàn)了。

我最近實測阿里Qoder「專家團模式（Experts Mode）」后，發(fā)出了上述感慨。在「專家團模式」下，Qoder直接給我組織了一支賽博工程團隊，我就負責看，專家團負責干。

它幫我自動解析需求，分配任務，調(diào)配前端、后端、測試、運維等不同職責的“工程師”，驅(qū)動多個智能體同時推進任務，直接讓我躺著當了回CTO。

這背后體現(xiàn)了AI Coding的新趨勢，氛圍編程正在走向多智能體協(xié)同編程，AI讓開發(fā)者變成了Agent管理者，而AI IDE也正在成為智能體管理工具。

Qoder專家團帶我速通個人博客

打開Qoder后在Editor模式下，點擊右上角“切換AI側欄”，然后再點擊中間下方切換模式按鍵，就能使用「專家團模式」了。

為了快速檢驗專家團的能力，我選擇從0開始，做一個簡單的個人博客項目。在我輸入項目需求后，專家團的「指揮官」Team Lead自動將我的需求拆解為8個任務，然后分派給了不同的賽博工程師

Team Lead首先派出的是通用工程師Nick，他并不負責具體的開發(fā)，因為我目前只有一個空文件夾，也缺少項目需要的環(huán)境，所以需要Nick先幫我安裝依賴，以及搭建基本的項目結構，進行項目初始化。

在這一過程中，Nick還遇到了一些問題，它自己就克服了。

最終Nick順利完成任務，給我匯報了工作。

接著Nick就把工作交棒給他的“同事”——后端工程師Jimmy。但和人類后端工程師既負責后端開發(fā)，又負責數(shù)據(jù)庫不同，Jimmy只負責初始化數(shù)據(jù)庫，從這也能看出「專家團模式」的分工很細致。

Jimmy建完數(shù)據(jù)庫后，項目就可以正式開工寫代碼了，Team Lead按模塊，把工作分給了5位工程師，他們分別負責前端頁面、中間件和后端API的開發(fā)工作，非常全面。

看上去這似乎是個線性過程，但其實在開發(fā)時出現(xiàn)了多名工程師同時推進項目的情況。這無疑加快了開發(fā)效率，同時也是專家團模式下，多智能體協(xié)作編程的優(yōu)勢之一。

等前面7位“同事”完成開發(fā)后，項目指揮官Team Lead還安排了測試工程師Chris進行完整流程驗證

Chris會直接打開瀏覽器，輸入賬號密碼，登錄網(wǎng)站，然后完整測試一遍整個增刪改查邏輯。

同時自動保存關鍵頁面的截圖，展示測試結果。

測試工作完成后，項目開發(fā)還沒結束，我又讓系統(tǒng)評審了一下代碼質(zhì)量，于是Team Lead又追加了一個專家代碼評審員Mark，Mark找到了多個系統(tǒng)漏洞，還按嚴重程度分好了等級

我接著就讓專家團修復漏洞，專家們沒有直接逐一修復，而是先分析情況，然后發(fā)現(xiàn)兩個任務互相沒有依賴關系，可以獨立開發(fā)，于是兩個專家并行完成了任務，這樣顯然效率更高。

至此開發(fā)和測試工作全部結束。在Qoder專家團8位專家的幫助下，我只花了16分鐘就擁有了一個個人博客網(wǎng)站。它具有完整的增刪改查邏輯，擁有前臺展示頁面和后臺管理頁面。

但目前技術架構還比較簡陋，沒有實現(xiàn)前后端分離，我決定上點難度，考驗一下專家團的重構能力，讓其用Spring Boot（Java開發(fā)框架）和MySQL（關系型數(shù)據(jù)庫）重構一下后端。

專家團組團重構，用AI開發(fā)AI工具

我首先依然是將我的需求告訴了Team Lead，Team Lead對這些需求進行可行性分析后，問了我?guī)讉€問題，每個問題都提供了三個選項，我做出決策后，Team Lead接著為我派遣了一名新專家Alex。

Alex是一名調(diào)研員，負責分析我目前的項目結構和代碼接口，然后制定完整的重構計劃，并將其寫成了markdown，以指導后續(xù)的規(guī)約開發(fā)。

有了重構計劃后，Team Lead開始指揮工程師團隊干活了，新角色又出現(xiàn)了：運維工程師Nick，他負責為我安裝MySQL。

本地裝好MySQL后，我擔心不同組件之間會有版本沖突，所以我在此時介入提出了內(nèi)心的疑問，系統(tǒng)給出了讓人放心的回答。這也是Qoder專家團模式的特點，開發(fā)者可以隨時介入流程，提出問題或者改變需求

這個設計可以說是非常真實了，畢竟哪個開發(fā)沒被產(chǎn)品追加過需求呢（doge）。

接下來就是正常推進項目和自動Debug了，中間多次出現(xiàn)前后端同時推進的情況，最終高效重構了項目，改寫了技術棧。

但我并沒有止步于此。AI Coding做的軟件，怎么能沒有AI，我又要求專家團給我接入Qwen API，設定主題，以后讓AI幫我直接寫文章。真不是為了以后能摸魚哈。

接到我的需求后，Team Lead創(chuàng)建了新的任務，同時安排前后端工程師交付了功能。

從開發(fā)到重構，我動動嘴就拉來了13個程序員，完成多達30個任務。

縱觀整個流程，對比其他AI IDE，Qoder的專家團模式展現(xiàn)出許多獨到之處。那么，為什么我們現(xiàn)在需要一個「AI Coding專家團」？

因為AI Coding正在迎來新的范式轉(zhuǎn)變。

為什么需要「AI Coding專家團」？

“從去年12月開始，AI Coding已質(zhì)變”，大神卡帕西的這段發(fā)言，最近引起了行業(yè)熱議。

卡帕西曾一手提出并帶火了“Vibe Coding”概念，現(xiàn)在他又一次洞察到AI編程風向的轉(zhuǎn)變。卡帕西認為，AI編程智能體現(xiàn)在的能力遠超以往，可以攻克大型項目和長期任務了

這意味著AI編程已從Vibe Coding轉(zhuǎn)向了Agentic Engineering，AI不再只是簡單地補全代碼，而是開始通過智能體的形式，完整地構建項目。

AI編程迎來新的范式，也引發(fā)了新的問題。

一方面是代碼質(zhì)量問題，目前很多主流AI Coding工具仍以單智能體為主，處理簡單任務還行，一旦面對復雜任務，比如多輪迭代或者重構項目，其上下文長度可能就扛不住了，最終導致開發(fā)就像狗熊掰玉米，做著手頭的功能，忘了前面的任務，邏輯鏈條零散，最后代碼質(zhì)量堪憂。

另一方面則是效率存在提高空間。大型項目非常復雜，涉及方方面面的工作，比如前端UI、后端開發(fā)和數(shù)據(jù)庫設計，一些任務明明可以分開執(zhí)行，現(xiàn)實團隊也往往是這么安排的，但單智能體編程的情況下，還是要被迫等待。

Qoder專家團模式正好可以解決質(zhì)量和效率這兩大痛點。從前面實測體驗來看，專家團并不是簡單地堆砌智能體數(shù)量，它是一個真正的多智能體系統(tǒng)。因為它給我分配的專家具有不同特長，據(jù)介紹他們其實是在各自獨立的上下文工作，互相協(xié)同之下，顯然能應對更多的交互輪次。

針對上下文問題，Qoder還特意打造了工程知識引擎，這是一套可以使用多維數(shù)據(jù)源的代碼認知系統(tǒng)，它能整合你的代碼文件、提交歷史、RepoWiki、記憶，優(yōu)化專家們深度理解上下文的能力。

此外，實測時我還多次發(fā)現(xiàn)，多名專家同時推進工作的場景，在這種情況下專家們分別寫不同頁面，或者分別開發(fā)前端和后端，這無疑加快了項目推進速度。

這是目前我已感知到的特點，據(jù)說專家團的智能體還會自主學到新的Skills，自我進化，越用越聰明，越用越懂我?，F(xiàn)在新模式剛上線，我暫時還沒發(fā)現(xiàn)這個特性，后面有機會我再和大家分享。

總的來看，「專家團模式」加快了開發(fā)效率，提高了代碼質(zhì)量。Qoder采用內(nèi)部復雜任務基準對「專家團模式」進行了代碼質(zhì)量測試，結果顯示專家團模式得分較自身智能體模式提升67%，領先Claude Code Agent Teams 16%

顯然，Qoder「專家團模式」正在開啟一個新的階段。

開啟多智能體協(xié)同編程時代

氛圍編程和智能體編程之后，AI Coding正在轉(zhuǎn)向多智能體協(xié)同編程時代

這背后是用戶需求變化，他們不再滿足于簡單的AI寫代碼，而是希望AI能高效交付軟件，軟件質(zhì)量也要有保證。單智能體顯然已無法滿足這種需求，那么邁向多智能體協(xié)同編程就成為必然。

多智能體協(xié)同編程進一步放大了個人能力，讓個人擁有了一支隨時待命、持續(xù)進化、不只懂編程更懂工程的數(shù)字軍團。

這一轉(zhuǎn)變也要求AI IDE也從簡單的編寫代碼和組織文件，轉(zhuǎn)向組織智能體。這也符合卡帕西的預判，即AI Coding時代人們依然需要IDE，甚至需要一個更龐大的IDE，用它來管理智能體。這就是IDE未來的發(fā)展方向

現(xiàn)在，實測Qoder專家團模式后，我已經(jīng)從中看到了AI Coding和AI IDE的未來。