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 程式設計的籃球賽才剛剛開始。 一個挑戰者已經選擇用自己的方式，去打一場完全不同的比賽。 從使用者的角度，我們也樂於期待一個軟體創造權力被徹底平權的未來。
本文來自微信公眾號 「機器之心」（ID：almosthuman2014），作者：聞菲，36 氪經授權發佈。
