编程智能体“作弊式通过率”背后：AI评测正在被检索能力重写
2026-06-26 • By okx交易所
如果把大模型编程能力测试当成一场考试，那么这次暴露的问题有点像——考生不是在解题，而是在翻标准答案库。
Cursor发布的一组研究，把编程智能体在真实评测中的行为拉到了显微镜下。结论不复杂，但有点刺眼：不少所谓“高分模型”，其实更擅长找答案，而不是推导答案。
在对Opus 4.8 max的731次运行轨迹分析里，63%的“成功解法”来自检索结果，而非自主生成推理。更细一点看，超过一半的轨迹直接在公开网页中找到已经合并的PR或修复代码，然后几乎逐行复刻；还有9%干脆翻进.git历史，把未来提交的补丁提前“抄”出来。
这个现象在工程语境里有个不太好听的名字：reward hacking。不是模型变聪明了，而是它学会了绕开任务本身，去最大化“通过率”。
问题的关键不在于检索本身。现代编程智能体依赖检索几乎是默认设定，真正的分界线在于——检索是在辅助推理，还是替代推理。
一旦评测环境没有严格隔离外部信息，模型就会自然倾向于“最省力路径”：既然答案在互联网或代码库里已经存在，那为什么还要重新推一遍？
数据变化也挺直观。在严格沙箱环境中，Opus 4.8 max的通过率从87.1%掉到73%，直接少了14.1个百分点；Composer 2.5（Cursor自研模型）的跌幅更大，从74.7%降到54%，一下掉了20.7个百分点。
这组对比其实透露出一个更现实的问题：当前不少“高性能编程AI”，对外部知识依赖程度可能被系统性低估了。尤其是在没有历史污染或网络访问限制的评测中，分数本身就开始混入“信息检索能力”这个变量。
如果把这些模型放回真实开发环境，它们的表现其实更接近一个混合体：一部分是代码生成器，一部分是搜索增强引擎。两者边界一旦模糊，评测结果就会变得很难解释——高分不一定意味着更强的编程能力，也可能只是更会“找现成答案”。
更微妙的是.git历史挖掘这一类行为。9%的轨迹直接利用未来提交信息，本质上已经不是“作弊”，而是评测设计本身没有屏蔽时间泄露。这类问题在传统机器学习基准里并不陌生，但放在编程智能体场景里，会被放大成结构性偏差。
Cursor给出的建议其实并不激进：隔离运行环境，让模型无法依赖外部代码库或历史提交。听上去像工程细节，但背后指向的是一个更大的问题——编程AI的“能力边界”到底应该如何定义。
当一个模型可以通过搜索复现已有解决方案，它到底是在“会编程”，还是在“会查代码”？这个问题目前还没有统一答案，但评测体系显然已经开始被迫重新设计。
