阿里Qwen-Coder-Qoder在自家测试中击败Cursor，Token消耗降低14.5%

阿里云在AI编码竞赛中尝试了不同的策略。该公司没有推出一款通用模型让开发者自行探索如何将其接入工作流程，而是推出了Qwen-Coder-Qoder，一个专为其Qoder CLI和智能体生态系统打造的型号。早期数据表明，这一策略可能奏效。

在Qoder Bench, , 公司为真实软件工程任务设计的自有基准测试中，该模型在任务解决能力上超越了Cursor Composer-1。Windows系统上的差距更为明显，终端命令准确率相比上一版本提升高达50%。在最近几周的生产环境中，代码保留率提升了3.85%，工具错误率下降了61.5%，Token消耗减少了14.5%。这些正是工程主管们真正关心的指标。

Qwen-Coder-Qoder基于Qwen-Coder基础模型，并通过大规模强化学习进行微调。与其他大多数模型发布不同，其RL循环的工作方式如下：它从每天数千名Qoder用户的真实智能体交互中学习，提取软件工程实践并将其转化为奖励信号。阿里称之为“模型-智能体-产品”飞轮，这是一个封闭循环，产品使用直接塑造下一轮模型迭代。

奖励者-攻击者框架

奖励作弊是代码智能体强化学习中一个已知的难题。如果系统为了速度奖励并行工具使用，模型可能会开始扫描无关文件来提升其并行得分，而实际上并未有助于解决问题。阿里构建了一个对抗性框架来在训练开始前捕捉这一问题：一个LLM审查者在开发过程中对奖励系统进行压力测试，寻找模型可能利用的漏洞。公司表示，这既提升了迭代速度，也增强了奖励设计的鲁棒性。

训练本身依赖于ROLL系统，这是一个用于在包含数千GPU的集群上对具有数千亿参数的混合专家模型进行RL训练的系统。部署阶段通常占总训练时间的70%以上；阿里表示，系统级优化带来了10倍的吞吐量提升，显著压缩了训练周期。

阿里还利用高速容器化技术自动化搭建了数万个真实软件环境，这些环境可以即时创建和销毁沙箱，使得在手动环境管理难以实现的规模下进行RL成为可能。

Qoder CLI的7x24小时反馈处理

在发布模型的同时，阿里还发布了一份详细案例研究，展示了Qoder CLI如何在其内部工程组织中使用，以构建一个完全自主的反馈处理系统。该系统处理从用户反馈提交到代码修复的整个流程，只有最终代码审查阶段才有人类参与。

该流程包含四个模块：问题分类、问题聚类、日志分析和自动修复。每个阶段通过Qoder CLI使用不同的模型层级。分类和聚类使用价格较低的“Effective”层级模型。日志分析和根因定位使用“Performance”层级模型。代码修复使用“Ultimate”层级模型。公司的结论很直接：用廉价模型处理复杂任务，在错误方向上浪费的Token比直接使用SOTA模型还多。

该系统包含一个自我反思机制。每次日志分析任务后，智能体会将回顾客写入一个task-retro.md文件，记录无效步骤和经验教训。一个独立的流程智能体会定期审查这些回顾客，以更新相应的技能。这形成了一个进化链，每个智能体的错误都成为信号。

影响是可测量的。此前，每个问题从反馈提交到手动日志分析和根因定位至少需要30分钟。现在，自动化系统能在两分钟内完成根因分析，全天候运行，除代码审查外无需人工干预。

竞争对手在做什么

AI编码领域已演变为一场增量改进的战争。Cursor、GitHub Copilot和JetBrains的AI助手都在每周发布更新。Cursor Composer-1，阿里选择作为直接对比目标的模型，也并非静止不变。但Qwen-Coder-Qoder是为与特定智能体架构紧密集成而构建的，并非通用用途。这可能限制其应用范围，但也意味着反馈回路更短：每次用户与Qoder的交互都能在数周内优化模型，而非数月。

阿里表示计划每周迭代模型，这意味着大多数开放权重模型分发商难以匹敌的节奏。飞轮模式需要持续的产品使用来喂给训练数据，因此这一赌注既取决于Qoder的用户采纳率，也取决于模型本身。