AI 编程十字路口：为什么说 Copilot 模式是创业陷阱？

tayun

机器之心原创

作者：闻菲

当整个人工智能行业都在为「如何给程序员打造更快的马」而疯狂投入时，一支特立独行的团队选择「直接去造汽车」。

「大模型的发展，更像一场篮球比赛才刚刚打完第一节。所有人都在用第一节的比分去判断整场比赛的胜负，但我们认为，还有第二、三、四节要打。」蔻町智能（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 编程的篮球赛才刚刚开始。一个挑战者已经选择用自己的方式，去打一场完全不同的比赛。从用户的角度，我们也乐于期待一个软件创造权力被彻底平权的未来。


来源：网易