马斯克砸100亿买数据：AI编程模型竞争的关键，为何必须自建编码产品？

月初，OpenAI的两大对手Anthropic和马斯克终于放下分歧，正式结盟。在此之前，双方关系紧张：今年2月，马斯克在X账号上指责Anthropic“觉醒”“邪恶”“反人类”，称其“仇视文明”。

事后看，这次攻击并非马斯克个性使然，而是Anthropic的某些做法触及了他的底线。此前，xAI内部使用Cursor工作，但年初员工发现，Claude模型在xAI的Cursor企业账号中突然无法使用。当时仍在xAI的联合创始人吴宇怀在全员信中写道：“Anthropic更新了政策，要求Cursor不得向主要竞争对手提供Claude模型调用能力。”后来，xAI整个联创团队解散，实体与SpaceX合并，成为“SpaceXAI”。但当时，吴宇怀在信中写下了一句耐人寻味的话：“这是坏消息也是好消息。我们的生产力会受影响，但这也促使我们开发自己的编码产品和模型。”为何xAI高层认为自建编码产品至关重要？

后续发展众所周知：xAI联创团队全部离开，马斯克一怒之下对Cursor动用“钞能力”。上月底，SpaceX和Cursor共同宣布，将在编程和知识类AI模型训练上展开前所未有的战略合作；SpaceX还获得了以600亿美元收购Cursor的权利，或支付100亿美元合作费用。注意“编程”这个关键词，后面会再次提及。

最近，我观看了Cursor早期投资人、Anthropic批评者、T3创始人Theo Browne的一条视频。原以为他会抨击Anthropic和SpaceX的勾当，却意外发现了一个关于SpaceX+Cursor合作的另类但极合理的分析：不谈600亿收购，只说100亿合作费——Theo在视频中表示，他认为“哪怕只是交换到Cursor的用户数据，这100亿也值了”。

那么，是什么数据？如果你也看了Theo的视频，他会讲得很清楚。但为了节省时间，我们简单概括：我们与AI的对话是交互式的——你提出问题/需求，它给出解答；coding agent同理，只是返回的是代码。

一次高质量对话，包括用户提示、模型思考、agent规划、输出代码、验证——所有这些组合起来，形成一个完整的Agentic Loop——就成了高价值的训练数据，再喂给模型进行强化学习，就能提升模型在实战场景中的表现。

Cursor拥有的，SpaceX想要的，正是这些数据。这些数据从何而来？答案很简单：作为模型厂商，这种高质量数据最直接的来源，只能是自己开发的coding agent产品——比如Anthropic的Claude Code、OpenAI的Codex、Kimi的Kimi Code。现在你明白了，为何被Anthropic“封号”后，吴宇怀会在全员信中提出开发xAI自己的coding产品和模型。xAI当时已看清：没有自己的编码产品，就没有高质量的强化学习数据；没有高质量数据，就训练不出真正实战能力强的coding模型。虽然有些极端，但我们可以点题：模型厂商要想做出真正能打的编程模型，自建coding agent产品是唯一路径。

大语言模型像水晶球，用全网语料训练，似乎能解答万物，但并非在所有问题上都能给出高质量答案。用GitHub上数十亿代码条目训练，当然也能训练出coding模型。这是“学习结果”的逻辑，也没问题——毕竟编码任务的结果可验证：代码能否运行、测试能否通过，结果摆在那里。但通往结果的过程，是一个涉及多步骤决策、错误纠正、意图对齐的复杂链条。每次用户的接受、拒绝、补全、撤销、追问，甚至模型多次搞错时的辱骂——都是这一链条上的过程信号。

强化学习有两种监督方式：结果监督，只关注最终是否跑通；但结果监督会催生“奖励黑客”现象——模型为跑通可能写出冗余、脆弱、有逻辑漏洞的代码，但因测试通过，模型误以为学对了。另一种是过程监督，对推理路径上的每一步打分。上述过程信号，只有在coding agent运行环境中才能产生。GitHub仓库只有结果，即使查看提交历史或PR，也找不到有效的过程信号。在缺乏有效、自主获取的过程信号时，一些模型厂商采用“蒸馏”方式，这大家应该已经知道。蒸馏的逻辑很简单：给定相同输入，老师模型输出什么，学生模型就学着输出什么。但通过蒸馏，即使能获取思维链，得到的更像结果，而非被蒸馏老师模型内部的概率分布。一旦学生在推理中偏离老师轨迹，哪怕一个token不符，都可能发生偏离。

这背后是强化学习的基础限制：策略梯度定理要求，优化样本最好由当前优化的模型自己生成。这种数据叫on-policy数据。而通过蒸馏别家模型、在别人产品中产生的数据来训练自己模型，都属于off-policy数据。模型当然能学到东西，但学不到老师模型内部的概率分布信息。而像Cursor这样本身就是coding agent产品的公司，掌握着最真实、有效、高质量的训练数据。Cursor产品本身，就是coding模型在实战环境中的最佳训练场。我们可以通过Cursor年初的“翻车”来证明这个逻辑。

APPSO读者应该记得，年初Cursor发布了Composer 2，号称“下一代专用编程模型”，技术报道相对保守，自称是新模型，未提供具体模型底座信息。

结果很快，网友在公开代码片段中发现了Kimi的模型ID，截图传遍开发者社群，逼得Cursor副总裁Lee Robinson出面澄清：“Composer 2确实从开源底座出发。最终模型大约只有1/4的算力来自底座，剩下3/4是我们自己训练的。”几小时后，Cursor联创Aman Sanger也发了一条道歉：“一开始没提Kimi底座是个失误。”

五天后，Cursor放出完整Composer 2技术报告，显示底座是Kimi K2.5，授权方是Firworks AI，大致流程是在K2.5上训练，再继续大规模强化学习（RL）。但关键在于，Composer 2的RL运行在真实Cursor会话中，使用与生产部署完全相同的工具和harness。Cursor将这套流程称为“实时强化学习”（real-time RL），即将模型checkpoint直接部署到Cursor生产环境，观察用户响应，收集数据，聚合奖励信号，最快每5小时迭代一次模型版本，再部署到Cursor中，循环往复。最极致的案例是Cursor的自动化代码补全功能Tab，每天处理超过4亿次请求。每当用户输入字符、移动光标时，模型预测下一步动作；若预测置信度高，则显示建议；用户按下Tab即接受自动补全。该功能采用在线强化学习，在行业内极具特色。Cursor能以极高频率（最快每1.5到2小时）更新Tab模型能力给用户，直接在产品内收集on-policy数据进行训练。这种高频、近乎实时的反馈回路，让Tab能学习到极其微妙的用户意图。Cursor透露，这种方法使Tab建议的拒绝率降低21%，接受率提高28%。回到Composer模型本身。事情搞清楚后，一些Kimi员工删除了之前吐槽的推文，Kimi官方账号发表祝贺。一家估值600亿美元（基于马斯克给出的数字），不做自己模型基座的coding agent应用层公司，仍能通过产品自身的数据飞轮，RL出超越基座模型的专有编程模型。因此，与其说Cursor翻车，不如说这反而是coding agent产品重要性的绝佳例证。

Cursor在另一篇关于实时RL的文章中写道：“（训练编程模型）最大的困难在于建模用户。Composer生产环境中不只有执行命令的计算机，还有监督和指导它的人。模拟计算机容易，模拟使用它的人却很难。”这句话正逐渐成为编程模型前沿模型厂商之间的共识。如果你看benchmark榜单和用户普遍评价，会发现头部厂商都在发力做自己的coding agent/编程产品。区别只在于谁离用户更近。以SWE-bench、LLM-Stats等相对权威的榜单为例，Claude、GPT、Gemini、Kimi等模型基本霸榜前十，清一色是有自己开发coding agent产品（包括CLI、IDE、集成coding agent的桌面客户端）的模型厂商。部分榜单上会出现少数反例，如Meta（Muse Spark）、Minimax、DeepSeek等，没有开发自己的coding agent。但你会发现，这些反例模型在更接近真实场景、避免污染的权威benchmark上就很难上榜。以DeepSeek为例，它在SWE-bench bash only上分数为70%，排名第九；但在SWE-bench Pro上分数却掉到约15%。OpenRouter的真实流量数据可解释这种反差：该平台2025年报告显示，Claude token消费80%以上用于编程和技术任务，而DeepSeek token消费主要集中于闲聊和角色扮演。没有自家coding产品的厂商，在某些coding任务benchmark上能挤进头部，但在更难的真实工程benchmark上，在用户用token消费投票的真实流量中，都会原形毕露。不仅是Cursor，Anthropic在2025年11月发表的一篇论文中也明确透露自己在做一模一样的事情：“我们在Anthropic自家的真实生产编程环境上做训练。”即Anthropic将自己员工使用Claude Code的交互数据，反哺给Claude模型用于训练。

在AI演进历程中，生产要素的定义发生了深刻位移。传统三大核心要素——算力、研究、训练数据，虽然总量持续增长，但结构上已出现严重失衡。今天各大AI巨头显著提高了算力资本支出（CapEx），使算力基建成为主旋律。但实际上，特别是在编程范畴内，随着GitHub仓库、StackOverflow等互联网公开代码数据被基模厂商“竭泽而渔”式利用，模型在代码生成与逻辑推理上的边界开始逐渐显现。这也是为什么，行业共识正逐渐转向一个冉冉升起的新战略高地：对于任何希望掌握顶级代码能力的模型厂商而言，建立自有的coding agent产品早已不是可选的商业路线，而是确保底层模型持续进化的核心生命线。正如APPSO前面论证的那样，单纯学习公开数据等于只学习成功者的结局，却无法了解成功的路径，这绝非正确的成功学。在真实编程环境中，知道发生了什么错误、如何发生、如何正确理解和高效实践需求——了解正确过程的价值，远超得到正确结果本身。

只有拥有自己的编码产品，模型厂商才能获取高质量的“过程监督”信号，从而在编码/推理能力的下一阶段竞争中，确保技术护城河——否则就不得不像SpaceXAI那样，花钱与coding agent产品公司合作。然而并非所有模型厂商都像马斯克那样有钱，2026年开始的巨头势力划分、结盟与领地争斗将更加激烈；当一家缺乏自主coding产品的模型厂商终于醒悟时，恐怕已没有足够合作伙伴可挑选，合作价格也将水涨船高。美国模型巨头的情况大家普遍熟悉，在此不赘述。APPSO也注意到，国内主流模型厂商和AI巨头中，绝大部分已在coding agent产品上有所布局。国内巨头公司主要以原生AI IDE或IDE插件思路推进：字节跳动去年很早布局了TRAE，阿里巴巴的Qoder，腾讯的CodeBuddy，百度的文心快码Comate等。AI小龙公司中，月之暗面是最早开发独立coding agent产品的公司，主要以CLI界面的Kimi Code为主——不过Kimi此前透露，在原生编程产品上，CLI不会是终局。

另一种实现思路是模型厂商自行提供API服务、Coding Plan。这样，无论用户使用何种AI开发环境，模型厂商都能通过服务器端API记录获取最大程度接近原生coding产品的过程数据。但这只是接近，并非完全相同。核心在于，服务器端API的请求-响应日志，与深度继承的产品交互轨迹相比仍有很大差距。自建产品的厂商（如Cursor、Claude桌面端、Codex）拥有最直接的显式反馈信号，而API侧是相对模糊的隐式推断。简单来说，API侧能看到用户请求和响应，但用户最终是否采纳这段代码、代码能否跑通、引发何种bug，API侧对此一无所知。他们无法了解用户最终行为这一关键标签，从而无法实现最高质量的强化学习。形而上来讲，语言即世界，代码即方案。代码能表达世界上绝大多数任务，代码也会成为头部的放大器，让最顶尖的人才放大数倍生产力。只有最顶尖的coding模型才配得上最顶尖的人才。如果领先的模型厂商不重视coding，势必会掉出第一梯队。当然，事实上每家模型厂商都不会不重视coding——而是说，在新的范式下，那些没有自主可控的原生coding agent产品的厂商，极有可能逐渐落后于有产品的厂商。就在前几天，MiniMax也发布了桌面客户端产品的重大更新：带有全新多agent编排架构的Mavis功能，并让客户端显著改善了对coding任务的支持。此前MiniMax只推出了桌面端，但未加入原生coding和agent功能。

紧接着，5月15日，阿里巴巴正式发布了Qoder 1.0——这个产品从IDE形态正式升级为完整Agent产品（阿里官方叫法为智能体自主开发工作台）。

与此同时，xAI的Grok Build CLI也终于正式推出。没错，就是xAI年初被Anthropic和Cursor封号后，自己捣鼓出来的coding agent。

这不，又多了好几个现成案例。看来，大家都认为Cursor、Codex和Claude桌面端走在正确道路上。

把话题从coding扩展到agent本身，情况也一样。编码任务的轨迹数据在公开语料中还能找到一些（比如GitHub提交记录/PR，尽管质量不高）。但agent任务的轨迹数据，包括移动和点击鼠标、操控触屏、填写输入框等，无法在公开语料中找到。所以我们会看到，即使在agent操作的最小实现路径——浏览器插件上，即便这么个看起来不高端的东西，几乎每家模型厂商都会做自己的。OpenAI早在2025年1月就做了Operator——与其说它是“AI自动操作浏览器”的产品，不如说本质上是一个大规模数据收集装置。每位试用Operator的用户，都在免费为OpenAI提供on-policy数据。后续OpenAI还衍生出ChatGPT Agent以及新版Codex桌面端；Anthropic也是如此；最近Kimi不声不响地也做了一个叫WebBridge的项目，其实就是浏览器插件。

即便是在过去两年里动作最克制的中国模型巨头深度求索，最近也开始展露对Agent的兴趣。CEO梁文锋此前接受采访时曾提到：数学和代码是AGI天然的试验场，有点像围棋，是一个封闭的、可验证的系统，有可能通过自我学习就能实现很高的智能。这句话的潜台词是，DeepSeek一直把coding、Agent当研究试验场，而非商业化方向。但在今年3月，DeepSeek一次性放出了十几个Agent相关岗位，包括首次出现的模型策略产品经理（Agent方向）等。当时的JD职责涵盖“主导Agent评测体系以及训练数据方案的设计”，要求包括“深度使用Claude Code、Manus”等产品。APPSO注意到，近期深度求索发布了Agent产品经理、Harness产品经理等职位招聘信息——显然，DeepSeek要做独立、原生的Coding/Agent产品了。

此前资料显示，DeepSeek V3.2的训练过程中引入了近两千个合成的Agent训练环境和八万多条复杂指令。但看来，靠合成训练数据只能带DeepSeek走到这里，剩下的是合成不出来的部分：真实用户在真实环境中的真实成功和失败，必须靠自家agent产品才能拿到。DeepSeek以极度克制的方式做了三年模型及模型产品（直到上个月才终于在官网加入了多模态能力）。但今天来看，在编码类任务上，DeepSeek拿SOTA越来越难了，即便此前拿到也会很快被超越。当助理依靠研究的路径支撑不住飞轮时，DeepSeek终于行动了。

最后，我们回到开篇故事。据The Information援引知情人士报道，在接受马斯克600亿收购/100亿美元合作的同时，Cursor表示不会与xAI合作开发新模型，而是仍聚焦于优化自己的Composer模型。这意味着，即便被马斯克买通甚至收购，Cursor仍要保留自己数据飞轮的主体性。数据归属本身，是最关键的隐藏博弈点。当所有顶级模型厂商都做了自己的产品，所有顶级产品也开始训练自己的模型，“模型公司”和“产品公司”本就模糊的界限似乎越来越不存在了……这场博弈也才刚刚开始。

参考资料：
Theo – t3.gg: www.youtube.com/watch?v=3pkz-Ie_k_c
Composer 2 技术报告：cursor.com/cn/blog/composer-2-technical-report
Anthropic 论文：arxiv.org/abs/2511.18397
结果监督 vs 过程监督：www.emergentmind.com/topics/process-vs-outcome-supervision
强化学习的信号误差：https://openreview.net/pdf?id=TDfrN1TbGH
关于自建或购买过程数据的讨论：https://www.reddit.com/r/AI_Agents/comments/1snc116/the_overlooked_trend_of_building_custom_ai_agents/