AI 編程十字路口:為什么說 Copilot 模式是創業陷阱?
「大模型的發展,更像一場籃球比賽才剛剛打完第一節。所有人都在用第一節的比分去判斷整場比賽的勝負,但我們認為,還有第二、三、四節要打。」蔻町智能(AIGCode)創始人兼 CEO 宿文用這樣一個比喻,為當前略顯擁擠的 AI 編程賽道,提供了一個不同的觀察視角。
自 2022 年底 ChatGPT 引爆全球以來,AI 編程被普遍認為是大語言模型最快、最確定能實現嚴肅商業化(PMF)的一個賽道。從 GitHub Copilot 的成功,到科技大廠和創業公司紛紛推出自己的編程助手,行業似乎已經形成一種共識:AI 是程序員的「副駕駛」,其核心價值在于提升代碼編寫效率。
然而,宿文和他的蔻町智能,正試圖證明這是對終局的誤判。在與機器之心的最近一次訪談中,宿文拆解了他對 AI 編程的三大「非共識」判斷。
非共識一:基座模型仍處「嬰幼兒期」
網絡結構創新是破局關鍵
在許多人眼中,大模型的基座之戰似乎已塵埃落定。后來者尤其是創業公司,只能在應用層尋找機會。宿文對此的看法截然不同:「我們認為大模型技術,或者說基座模型的發展,還處于嬰幼兒時期。」
他指出,現有以 Transformer 為基礎的模型架構,在學習機制和知識壓縮效率上存在根本性問題。「盡管 MoE 通過專家分工解決了部分計算效率問題,但其專家之間是 “扁平” 且缺乏協作的,整體上仍是一個依靠簡單路由機制的 “黑盒”。」
蔻町智能從成立第一天起,就選擇自研基座模型。他們的破局點,正是在于對模型網絡結構的持續迭代和創新。「我們在 MoE 的基礎上,繼續向后迭代,最終采用了在推薦搜索領域已經非常成熟的 PLE(Progressive Layered Extraction)架構。」
他解釋道,從 MoE 到 MMoE,解決的是專家的解耦問題;再到 PLE,則進一步解決了專家解耦后可能產生的沖突和信息損耗問題,實現了對任務共性與個性的精細化提取。
多任務學習(Multi-task Learning)網絡結構的演進,從簡單的底層共享(Shared-Bottom),發展到通過門控專家網絡(MMoE、CGC)與漸進式分層提取(PLE),以實現更精細地分離與融合任務的共性與個性信息。圖片來源:Gabriel Moreira@ Medium
宿文表示,網絡結構創新使他們的模型在知識壓縮和長邏輯鏈條的理解上,具備了與主流模型不同的潛力。
蔻町智能研發的新模型 AIGCoder 架構圖,通過解耦的專家模塊(De-coupled Experts)改良傳統模型,利用多頭專家感知注意力(MHEA)負責動態激活專家,定制化門控(CGC)負責精細整合信息,實現了在不增加計算開銷的前提下,通過架構創新應對大模型擴展時遇到的瓶頸。
實驗數據顯示,無論是單個關鍵模塊(左)還是整合后的完整架構(右),AIGCoder(橙色曲線)的訓練效率均比基線模型(藍色曲線)提升超過 1.3 倍。
非共識二:「避開大廠賽道」是個偽命題
在 AI 領域,創業者常常聽到一句勸誡——不要做大廠發展道路上的業務,否則會被輕易碾壓。
宿文卻認為這是個偽命題。「如果真的是一件大事,為什么大廠會不做?更精準的說法應該是,“避免去摘低垂的果實”。」
「真正的護城河,不在于選擇一個大廠看不上的 “縫隙市場”,而是在同一個領域里,解決比大廠更復雜、更深入的問題。」
「現在的許多 Coding 產品用工程化的方式集成各種 API,生成一個前端尚可的 Demo,這就是 “低垂的果實”。蔻町智能的策略,是通過底層技術創新,實現真正的 “All-in-one”。」
這種一體化的思路,也體現在宿文對 Agent 發展的看法上。他表示當前行業習慣性地將技術棧劃分為 Infra、基座、OS、Agent 等層次,「這很像是對上一代 PC 互聯網和移動互聯網的技術架構的簡單映射,這樣 “刻舟求劍” 式的對新技術做定義意義不大。」
他強調,在新范式下,各個技術環節是深度耦合的。「奔著解決問題的角度,我們就把它一體化地解決。在最終效果沒有出來之前,過早分工反而不利于提效。」
蔻町智能把 AI for Coding 劃分為 L1 到 L5 五個階段:
- L1:類似低代碼平臺,目前不是主流;
- L2:Copilot 產品,輔助程序員,根據提示生成代碼,代表產品有 GitHub Copilot、Cursor;
- L3:Autopilot 產品,能端到端地完成編程任務,不需要程序員介入;
- L4:多端自動協作,讓多個協作用戶能直接把軟件創意變成某個完整的產品;
- L5:能夠自動迭代,升級為成熟的軟件產品。
宿文表示:「目前大部分 AI Coding 產品集中在 L2 階段,而 AutoCoder 從一開始就定位在 L3。」
從 L2 到 L3,并非簡單的量變。「將編程助手做到極致,并不會自然而然地通向端到端軟件生成。」兩者需要解決的技術問題、優化的方向,基本上沒有大的重合:前者(Copilot)優化的是「寫代碼效率」,核心是上下文理解與精準補全;后者(Autopilot)解決「不寫代碼」的問題,核心是對復雜業務邏輯的理解、拆解與長邏輯鏈條的生成。
此外,L2 需要與 IDE(集成開發環節)深度融合,對大廠倆說有天然優勢,對創業公司而言,則可能是一條事倍功半的險路。
非共識三:個性化應用市場即將爆發,
新增需求遠超存量替代
堅持 L3 不僅是技術上的選擇,也是宿文和他的團隊對市場未來的判斷。盡管行業普遍認同 AI 編程的終極目標在于賦能每一個人,但在實現路徑上,由于 AI 技術瓶頸與普通用戶相關知識的缺失,主流看法認為,當下最現實的路徑,是先輔助程序員,解決存量市場的效率問題。
宿文則認為這恰恰是一種「戰略繞行」,因為 L2 無法自然演進到 L3,所以沿著 L2 走,不僅無法抵達終點,更可能錯失真正的藍海——那個被現有開發模式壓抑的、由海量個性化需求構成的增量市場。
「新增的需求遠遠大于存量的替代。程序員不會消失,但一個全新的、數倍于現有規模的市場會爆發。」
「很像是有了滴滴才有了網約車市場,有了美團才有了外賣市場,」他類比說:「以前人們打車、點外賣的大量潛在需求被高昂的成本和復雜的流程所壓抑,一旦有了低成本、高效率的供給方式,市場便會迎來爆發式增長。」
在軟件開發領域,對于大量的中小企業、創業者,甚至大企業的業務部門而言,都存在被壓抑的需求。宿文舉例,一個業務部門想為內部開發一套培訓系統,傳統模式下,從漫長的需求溝通、高昂的開發投入,到最終交付物偏離預期的風險,整個過程動輒數月,且試錯成本極高。
蔻町智能希望將這個流程重塑為:「只要上午能明確定義需求,下午就能看到一個可直接上線部署的產品。」
蔻町智能最新發布的端到端軟件生成產品 AutoCoder,定位「全球首款前后端一體化的應用與軟件完整生成平臺」,能夠同時生成高度可用的前端、數據庫和后端。例如,用戶輸入「幫我生成一個科技公司官網」,平臺不僅生成用戶可見的前臺頁面,也同步生成供企業員工管理網站內容和用戶數據的后臺系統。
AutoCoder 的受眾不僅包括產品經理、設計師等專業人士(Prosumer),更涵蓋了大量非技術背景的個人從業者、小型企業主(如咖啡店、健身房)、初創團隊的非技術創始人等。這些人有明確的數字化需求,但被傳統開發的高門檻擋在門外。
宿文引用了一個數據:海外一家類似理念的公司,其產品的月度訪問量,在短時間內已經達到了發展近 20 年的 GitHub 的十分之一,并且 GitHub 的數據本身并未下滑。這意味著一個新的、增量用戶的市場正在被激發。
當然,L3 這條路最直接的質疑就是——端到端生成的軟件出了 Bug 怎么辦?宿文的回應是:
「與其花費數小時去尋找一個 Bug,為什么不花幾分鐘重新生成一個正確的版本呢?」隨著軟件生成的邊際成本趨近于零,迭代和試錯的自由度將被前所未有地釋放。
結語
自研基座模型,選擇更難的端到端路徑,瞄準被壓抑的增量需求——這三個非共識但邏輯自洽的判斷,構成了蔻町智能的核心戰略和發展路徑。
當然,選擇一條少有人走的路,必然伴隨著質疑和不確定性。正如汽車在誕生之初,遠沒有馬車跑得快,甚至開幾公里就散架。蔻町智能的「汽車」能否在性能、穩定性和可靠性上,快速迭代到可以與成熟的「馬車體系」相抗衡甚至超越的階段,仍需時間和市場的檢驗。
但毫無疑問,這場關于 AI 編程的籃球賽才剛剛開始。一個挑戰者已經選擇用自己的方式,去打一場完全不同的比賽。從用戶的角度,我們也樂于期待一個軟件創造權力被徹底平權的未來。