SWE-Bench 通过率超过一半，意味着 AI 编程时代提前到来了吗？Cognition 没忍住，泼了一盆冰水：那些测试里“通过”的代码，很多在真实世界里就是不能碰的垃圾。他们搞了个新基准叫 FrontierCode，用的尺子就一把——一位有经验的开源项目维护者，审完代码后愿不愿意点下那个“合并”按钮。结果呢？最强的 Claude Opus 4.8，在最难的那档任务上，通过率只有 13.4%。这意味着，即便是最顶尖的模型，每写 10 段代码，有近 9 段都会被一位老手毫不犹豫地打回重写。
尺子换了一把，世界就变了
从“能跑”到“能维护”：一个残酷的飞跃
过去的 AI 编程评测，核心逻辑是“提交的代码是否解决了 issue 并通过测试”。这就像评价一个厨师，只看他做的菜能不能吃，而不问厨房是不是一团乱麻、食材是不是浪费成山、菜谱写得是否让人看得懂。SWE-Bench 的部分成功就源于此，它测的是功能正确性。但FrontierCode 的发起者们说，这远远不够。一个真正的贡献，是能让项目在半年后、一年后，甚至被另一个陌生人接手时，依然健康运转的代码。它考量的是设计、是文档、是风格一致性、是对项目上下文的深刻理解——这些，恰恰是当前大模型最欠缺的“工程素养”。
“人”作为终极标尺
这个基准最狠的地方，在于它把“人”的判断作为唯一度量衡。那 150 个任务，不是随便造的，而是由 20 多位顶级开源项目的维护者亲手设计。每个任务背后，是他们平均 40 个小时的精心构思和陷阱设置。评估标准也不是一堆自动化脚本，而是他们从长期维护项目中提炼出的 3000 多条心法，涵盖代码风格、安全性、可测试性、API 设计等方方面面。维护者审核时，用的就是他们平时审查真实 PR 的眼神和标准。这等于说，FrontierCode 模拟的是 GitHub 上最真实、最严苛的战场。
13.4% 的真相：AI 编程的“工程赤字”
顶尖选手的尴尬成绩单
让数字说话。在“奥赛级”难度（Olympiad）的任务上，Claude Opus 4.8 交出了 13.4% 的通过率，已然是全场最佳。GPT-5.5 只有 6.3%。其余一众模型，挣扎在 1% 到 5% 的区间。这组数据撕开了一个口子：我们欢呼的 AI 编程能力，在面对一个对代码质量有洁癖、对项目未来有责任感的维护者时，近乎失效。问题不再是“它能不能写出来”，而是“它写出来的东西，谁敢用”。
垃圾代码是怎样炼成的
为什么不可用？FrontierCode 的规则库暗示了答案。模型生成的代码，可能在逻辑上完成了任务，但往往伴随着严重的“工程债”。比如，它可能为了走捷径，使用了一个项目早已废弃的内部函数；或者它新增了一个公共函数，却没有考虑向后兼容性；又或者，它的代码改动如同打补丁，破坏了原有的模块清晰度。对于需要长期维护的项目来说，这种代码不是资产，是负债。它通过了测试用例，却通不过有经验工程师的“直觉审查”，这种直觉正是多年踩坑后积累的、对代码可维护性的深层感知。
泡沫破裂之后，路在何方
评测范式的启示
FrontierCode 不是在否定 AI 编程的价值，而是在重塑我们对它的期望。它告诉行业，以往那种“发布一个新模型，然后在某个旧基准上刷个高分”的庆祝方式，可能意义有限。真正的突破，不在于让 AI 解更多的算法题，而在于让它学会如何在复杂的软件工程上下文中，写出人类队友愿意并肩作战的代码。未来的评测，必将更强调代码的生命周期成本，而不仅仅是初始功能。
Coding Agent 的必修课
对于正在开发 Coding Agent（AI 编程助手）的团队，这份报告是一份珍贵的体检单。它指明了模型能力的短板不在“智力”，而在“职业素养”。下一步的训练和优化，必须超越单纯的代码生成，深度融入软件工程的最佳实践。这意味着需要更多高质量、体现“良好维护”模式的代码数据来训练模型，甚至需要模型在训练中学习“反模式”——什么样的代码会被一个苛刻的维护者一票否决。这不再是纯粹的机器学习问题，而是一个深刻的工程学问题。
人机协作的新契约
最终，FrontierCode 描绘了一幅更务实的未来图景：AI 不是即将取代程序员的超级黑客，而是一个潜力巨大但急需“职业培训”的初级工程师。它能快速产出代码草稿，但每一份草稿都需要资深工程师的严格审查和重构。行业的效率提升，将来自于这个更紧密、更高质量的人机协作循环，而非 AI 的单方面自动化。接受这份“不足 15%”的现实，或许才是 AI 编程真正走向成熟、创造巨大价值的起点。
