币安交易所官网

AI写代码这件事，已经从“能不能写出来”，悄悄转向“能不能被真正合进生产仓库”。

Cognition最新发布的智能体代码评测集FrontierCode，正是围绕这个变化展开的。它不再停留在传统的单元测试或代码补全准确率，而是把核心指标压在一个更工程化的问题上：AI生成的代码，是否具备“可合并性”（mergeability）。

这个词听起来有点朴素，但在真实软件开发流程里，它比生成速度、代码长度甚至正确率都更接近终点指标。

FrontierCode的设计方式也明显更贴近真实开发环境。评测集由36个开源项目维护者参与，包括Celery、Budibase、Uppy、Mattermost等，任务不是人工拼凑的题库，而是基于真实项目演进中提炼出来的修改需求。每一道任务平均投入超过40小时打磨，有点像把GitHub里的PR历史重新结构化成测试场景。

体系被分成三层：Extended（150项）、Main（100项）、以及最难的Diamond（50项）。层级划分并不只是难度递进，更像是从“可运行代码”一路推到“工程级可维护变更”。

真正让结果变得有点刺眼的是Diamond层的表现。

目前主流模型在这一层几乎集体掉队：Claude Opus 4.8为13.4%，GPT-5.5降至6.3%，Gemini 3.1 Pro约4.7%，开源模型Kimi K2.6则在3.8%。这些数字放在传统benchmark里可能还能解释为“挑战较大”，但放在“真实可合并代码”这个标准下，更像是工程可用性的一次压力测试。

问题并不在于模型不会写代码，而在于代码是否能进入真实协作系统。

在现代软件开发流程里，一段代码要被接受，需要通过的不只是语法和功能测试，还包括风格一致性、依赖兼容性、边界影响评估、甚至团队既有架构约束。这些因素叠加后，AI生成内容往往会在“看起来正确”和“可以被接受”之间产生断裂。

FrontierCode试图量化的，就是这条断裂带。

为了避免模型“刷题式优化”，评测引入了反向测试与修改限制机制。简单理解，就是不允许模型针对测试环境做过拟合式调整，同时增加变更传播路径的约束，模拟真实仓库中的连锁影响。

开发团队还引入了一个叫Mutagent的工具，用来校准评估误差，据称可以将误判率压缩到Swe-bench Pro的五分之一。这个改动看似技术细节，实质上是在解决一个老问题：AI评测本身是否可靠。

因为当模型开始参与代码生产，评测系统本身就变成基础设施的一部分。

如果说过去的AI coding benchmark更像考试，那么FrontierCode更像代码审计。它不关心你写得多漂亮，只关心你写的东西能不能进主干分支、不会把系统拖垮。

这个转变背后，其实是AI coding市场的结构变化。

早期产品竞争集中在“生成能力”，Cursor、Copilot一类工具靠的是效率提升；但随着模型能力趋同，竞争开始下沉到工程链路的后半段——集成、审查、合并与维护成本。谁能降低PR rejection rate，谁就更接近生产力工具的终点形态。

FrontierCode的出现，更像是在提醒行业一件事：代码生成只是入口，真正的瓶颈在代码被接受之后。

当评测标准开始从“正确性”转向“可合并性”，AI coding的竞争也就不再是模型之间的对比，而是整个开发系统如何接纳AI的问题。

而这一步，显然比生成一个函数要难得多。