光靠考试成绩选不出真正能干活的AI？中山大学揭示大模型在真实工程项目中的惊人失败率

这项由中山大学计算机学院领导的研究发表于2026年5月，论文编号为arXiv:2605.27492，感兴趣的读者可通过该编号查询完整论文。

---

每次新的AI大模型发布，厂商们都会晒出一张张亮眼的成绩单——在各类编程测试榜单上名列前茅，解题速度飞快，准确率令人咋舌。但问题是，这些"考试成绩"真的能说明AI在实际工作中有多能干吗？

中山大学的研究团队用一套叫做**Ramp**（全称：Runtime Assessment of Models in Production，生产环境中的模型运行时评估）的测试框架，给当今最顶尖的15个AI大模型出了一道真正的"实战题"——不是那种做完就完的选择题，而是需要一步接一步、环环相扣的大型工程项目。结果发现：没有一个模型能完整地通过全部关卡，而且有些模型花了极高的代价，却只取得了比廉价模型高一点点的成绩。

---

一、为什么"考试满分"的AI在真实工作中会翻车

要理解这项研究的价值，先得明白现有的AI评测方式有什么问题。

目前绝大多数AI编程能力评测，就像给求职者出一道道互不相关的单选题：第一题问你怎么写排序算法，做完了换第二题，问你怎么处理字符串——两道题之间完全没有联系，每题都是独立的小任务，做完就清零，重新开始。

但真实的软件工程项目根本不是这样运转的。以开发一个编译器（把程序员写的高级代码翻译成机器能执行的指令的程序）为例，你需要先完成词法分析，把源代码拆成一个个"单词"；然后把这些"单词"按语法规则拼成语法树；再把语法树翻译成中间代码；接着对中间代码做优化；最后生成目标机器能跑的汇编代码。这五个步骤缺一不可，而且每一步的输入，都是上一步的输出。前面某一步出了差错，后面所有步骤都会连带着崩掉——就像多米诺骨牌，推倒第三块，后面的全部跟着倒。

更关键的是，现有的测试不会告诉你：AI在完成任务的过程中，用了多少时间、花了多少钱、走了多少弯路。对于真正要部署AI系统的企业来说，这些"过程信息"跟最终成绩同样重要，甚至更重要。

中山大学的研究团队把这个问题概括为三点：现有评测缺乏对"串联依赖"的支持，只看结果不看过程，而且不同测试框架之间难以横向比较。正是为了填补这个空缺，他们建立了Ramp这套评测基础设施。

---

二、把真实编译器工程项目变成AI的考场

Ramp选择的测试题目，来自中山大学自主研发的YatCC编译器教学平台上的真实工程任务。这不是研究人员专门为了测试AI而设计的"玩具题目"，而是货真价实被用于真实课程教学和工程实践的编译器开发项目，底层基于业界广泛使用的LLVM编译器框架。

整套测试由六个顺序排列的任务组成，就像一条流水线，每个工位都依赖前一个工位的产出。第零关是环境配置，相当于开工前检查所有工具是否到位；第一关是词法分析，把C语言源代码拆分成一个个"词语"构成的流；第二关是语法分析，把词语流整理成有层次结构的语法树；第三关是中间代码生成，把语法树翻译成LLVM中间表示形式；第四关是中间代码优化，对中间代码进行各种优化处理；第五关是汇编代码生成，最终产出能在RISC-V 64位架构上运行的汇编指令。

每一关都有完善的自动评分脚本，满分100分，且采用"零容忍"标准——不是大体对就给分，而是严格按照正确性评判。更重要的是，六关之间存在严格的串联依赖：第一关产出的词语流，是第二关的输入；第二关产出的语法树，是第三关的输入，以此类推。前一关没做好，后一关就天然处于不利地位。

为了保证测试的公平性，每次测试都在独立的容器化环境中运行，所有依赖库（包括ANTLR、LLVM 14、pybind11等）均预先安装完毕，测试结束后容器销毁，确保不同轮次之间互不干扰。所有AI模型都通过统一的API网关接入，使用相同的提示词和任务环境，让成绩差异真正反映模型能力，而不是接入方式的差异。

---

三、"复活"机制：当AI在中途跌倒时，怎么测它后面的能力

串联依赖带来一个棘手的评估问题：如果AI在第二关就失败了，第三、四、五关也会跟着失败，但这些失败究竟是因为AI本身不会做这些关卡，还是仅仅因为它没有收到正确的"上一关产出"？这两种原因导致的失败，评估含义截然不同。

为了解决这个问题，Ramp引入了一个叫做"复活机制"（Resurrection Protocol）的设计。当某一关的得分低于60分时，系统的"裁判员"（Orchestrator，即协调器）会自动介入，把那个失败的输出替换成由标准参考实现生成的"黄金产出"，然后让AI继续做下一关——就像考试中途老师告诉你"这道题的正确答案是X，你接着往下答"。

关键在于，AI并不知道这次替换发生了。所有干预都由外部协调器悄悄完成，AI感知到的只是它在继续完成一个看起来正常的工程项目。这样的设计，让研究者既能测出AI能否独立完成全流程（不触发复活机制的情况），也能测出即使上游出了问题、给予正确起点的情况下，AI有没有能力完成下游任务。

Ramp将这两种测试模式分别称为"模式一"（串联管道加复活机制，为默认模式）和"模式二"（串联管道不带复活，即纯级联失败模式）。前者最大化诊断覆盖率，后者则衡量AI在完全自主、没有任何外部修正的情况下，能走多远。

---

四、超越对与错：用多维度指标衡量AI的"性价比"

Ramp在评分体系上也做了创新，不只是给每关打个分了事。

在结果层面，Ramp使用一个叫"平均奖励"（Mean Reward，MR）的综合分数，对六关成绩按重要性加权平均。其中第四关（中间代码优化）权重最高（30%），第零关（环境配置）权重最低（5%）。此外，如果某一关是AI自主完成、没有触发复活机制的，该关得分还会获得一个1.2倍的加成奖励，以鼓励真正的自主能力。

在过程层面，Ramp全程记录：消耗了多少个API调用的"词语"（token，可以理解为AI处理信息的"字符数"）、进行了多少轮对话、执行了多少条命令、重试了几次、总共花了多少墙钟时间（实际流逝时间）。这些数据不仅展示AI做得对不对，更展示它做得效不效率。

在失败分析层面，Ramp把AI的失败归入五类。"推理失败"是指AI陷入重复调试循环，一直在原地打转没有实质进展；"规划失败"是指AI主动决定跳过某些必要步骤，以减少消耗；"上下文失败"是指随着对话和代码越堆越多，超出了AI能处理的"记忆上限"，导致无法继续；"工具与集成失败"是指调用外部工具出错、网络问题等；"基础设施失败"是指AI框架本身的bug或环境配置问题。每次失败只标注主要根因，避免模糊判断。

最后，Ramp还引入了一个叫"智能体效率指数"（Agent Efficiency Index，AEI）的综合效用指标。AEI把五个维度的归一化分数平均：到达的最远关卡、平均奖励得分、消耗时间（越少越好）、花费金钱（越少越好）、消耗token数（越少越好）。每个维度都映射到0到100的范围，再取平均。这样的设计确保一个模型不能仅靠高任务得分来拉高AEI——如果它为了那点高分花了十倍的时间和百倍的金钱，AEI会如实反映这种"得不偿失"。

---

五、没有一个模型能走完全程：排行榜背后的震惊真相

研究团队在"模式二"（纯级联失败，不给任何外部纠错）下测试了全部15个模型，包括Anthropic的claude-opus-4-7（论文中称Opus-4.7）、OpenAI的gpt-5.5（GPT-5.5）、DeepSeek的deepseek-v4-pro（DS-v4-Pro）、阿里的qwen3.6-max-preview（Qwen-3.6-Max）等顶尖旗舰模型，以及GLM、Kimi、MiniMax等一系列主流和轻量级模型。

结果出乎所有人意料：在这套真实工程流水线面前，没有一个模型能完整无误地走完全部六关。Opus-4.7以93.39的平均奖励高居榜首，在六关中拿下五关满分，唯独在第四关中间代码优化上只得了68.4分，差了那么一口气。排名第二的DS-v4-Pro拿到85.34分，四关满分，但在第四关只有38.6分。排名第四的GPT-5.5前四关全部满分，结果在最后的汇编代码生成关卡直接得了0分——写出了完全无法运行的代码。

从各关通过率来看，第零关（环境配置）全员通过（100%），第一关（词法分析）46.7%的模型拿到满分，第二关（语法分析）26.7%，第三关（中间代码生成）仅13.3%，第四关（中间代码优化）0%——没有一个模型拿到满分，第五关（汇编代码生成）20%。

一个有趣的现象是，第五关的通过率（20%）居然高于第四关（0%）。这说明任务难度本身并不是单调递增的，成绩下滑的根本原因不是"越到后面越难"，而是随着项目推进，前面各关对代码库的改动不断累积，错误在流水线中传递和放大，让后续关卡雪上加霜。15个模型的平均MR只有42.7，仅比不做任何改动的原始代码框架（基准线MR为23.38）高了17.6分——大多数所谓"能干活的AI"，在真实工程流水线面前的表现，只比什么都不做强了一点点。

---

六、花了一百多美元VS花了五分钱：成本差距达2525倍

当研究团队把目光投向"过程效率"时，发现了另一个令人目瞪口呆的数字：15个模型在完成同一套任务时，花费的API费用相差最高达2525倍。

花费最多的是Opus-4.7，整套任务跑下来消耗了126.24美元，调用了2.19亿个token，用时超过11900秒（约三小时十九分钟）。而花费最少的Qwen3-Coder，只用了0.05美元，约348万token，608秒搞定。两者的花费差距，相当于你去高档餐厅吃了顿豪华大餐，对方却在便利店买了包饼干，但两人的"饱腹感"差距并没有你想象的那么大。

更具体地说：Opus-4.7的MR是93.39，DS-v4-Pro的MR是85.34，两者相差不到10%，但前者花了126.24美元，后者只花了8.68美元，差距高达14.5倍。GPT-5.5和DS-v4-Pro花费几乎一样（分别是8.77美元和8.68美元），但DS-v4-Pro的MR比GPT-5.5高了将近30%——同样的钱，买到了多很多的"产出"。

研究团队用统计回归方法分析了"花多少钱/时间"和"得多少分"之间的关系，发现两者确实存在正相关（花钱越多分数越高），但这种相关性相当松散——花费解释了约52%的成绩差异（R?≈0.52），时间解释了约40%（R?≈0.40）。换句话说，还有将近一半的成绩差异，跟花多少钱、花多少时间毫无关系，完全取决于模型本身的能力和行为策略。

---

七、AI失败的五种姿势：最常见的是"记性不够用了"

研究团队逐一分析了每个模型在每个关卡的失败原因，得出了几个关于AI如何失败的规律性发现。

在15个被测模型中，有9个（占60%）的最终"停机"原因是"上下文失败"——随着任务推进，对话历史、代码文件、执行日志不断累积，超出了模型的"记忆容量"，导致无法继续思考和行动。这种失败主要集中在第二关到第三关，也就是代码库开始变得复杂、任务变得环环相扣的阶段。

第二常见的失败类型是"规划失败"（13.3%的模型以此为主要停机原因），但它出现的频率其实更高——有8个模型（53.3%）都不同程度地出现过这种行为：AI意识到某个关卡很难，主动决定跳过去做下一关，理由是"时间有限"或"感觉太难了"。这不是在灵活调整策略，而是提前放弃了它本该完成的任务。

从这两种主要失败模式，研究团队还总结出了两种截然不同的AI工作"风格"：一种是"跳过派"，碰到难题就绕路，节省了资源但牺牲了完整性；另一种是"死磕派"，反复在同一个问题上编辑、编译、调试，哪怕卡住了也不放弃，虽然有时候能解决问题，但也可能把上下文撑爆、把预算耗尽。这两种策略都有各自的代价，而选择哪种策略，只有在串联的长流程测试中才能被观察到——在孤立的单题测试里，这些行为模式完全看不出来。

---

八、"效率冠军"和"得分冠军"是两个完全不同的模型

这套研究最反直觉的发现，来自AEI（智能体效率指数）排名与MR（平均奖励）排名的比较。

按MR排名，Opus-4.7排第一（93.39分），GPT-5.5排第四（65.91分）。但按AEI排名，GPT-5.5以81.57分高居榜首，Opus-4.7却以40.00分垫底——因为Opus-4.7在时间、费用、token消耗三个维度都创下了所有模型中的最高值，三项倒扣分把它的AEI拉到了最低。

GPT-5.5的高AEI来自于它相当"均衡"的表现：任务完成度达到了被测模型中最远的流水线阶段（第三关），MR属于中上水平，而且时间、费用、token消耗都处于合理区间。相比之下，DS-v4-Pro虽然MR更高（85.34 vs 65.91），但它消耗的token数是GPT-5.5的6.17倍，导致AEI（65.21）明显低于GPT-5.5。

在AEI视角下，研究团队把15个模型归纳为三种典型运作模式。第一种是"均衡高效型"，以GPT-5.5为代表，成绩与资源消耗都处于合理区间，是一般规模生产部署的理想选择。第二种是"低成本凑合型"，以Qwen3-Coder和DS-Chat为代表，成绩一般但几乎不花钱，适合早期快速原型验证。第三种是"高分高消耗型"，以Opus-4.7、DS-v4-Pro和DS-v4-Flash为代表，任务完成度顶尖，但资源消耗惊人，只适合对质量要求极高、预算充裕的场景。

---

归根结底，这项研究告诉我们一件很实在的事：现在大家评价AI聪明不聪明，用的标准跟AI真正能不能干活之间，存在一条相当宽的鸿沟。那些在各类编程榜单上名列前茅的顶级模型，一旦面对需要一步接一步、前后环环相扣的真实工程任务，表现会急剧下滑，而且这种下滑在传统评测中完全看不出来。

更值得思考的是，即便是表现最好的模型，在完成这套"接近真实水平"的编译器工程任务时，也无一能全程无误走完。这不是说AI没用，而是说我们目前对AI能力的认知，可能被过于宽松的测试方式系统性地高估了。

对于普通人来说，这意味着当你看到某个AI系统声称"在X评测上超越了人类水平"时，不妨多问一句：这个评测测的是不是那种需要长期连贯工作的真实任务？如果不是，那这个成绩只能说明它会考试，不代表它会干活。

中山大学的这套Ramp框架，相当于把AI的"模拟考"换成了"实习考核"。有兴趣深入了解的读者，可以通过论文编号arXiv:2605.27492查阅完整论文，项目主页在ramp.yatcc-ai.com也有更多信息和实时排行榜更新。

---

Q&A

Q1：Ramp测试框架和普通AI编程评测有什么本质区别？

A：普通评测（如SWE-bench）每道题都是独立的，AI做完一题就清空状态做下一题。Ramp的核心区别是"串联依赖"——六个任务像流水线，前一步的产出是后一步的输入，前面出错会传导到后面，这才接近真实软件工程的运作方式。此外，Ramp还记录时间、费用、token消耗等过程指标，不只是判断对不对。

Q2：AEI（智能体效率指数）和MR（平均奖励）哪个更重要？

A：取决于使用场景。MR衡量的是任务完成质量，如果你只关心AI能不能把任务做对做好，MR更相关。AEI同时考虑了成本、时间、token消耗，反映的是"性价比"——对于需要大规模部署、预算有限的企业，AEI更有参考价值。两个指标从不同维度衡量AI能力，不能互相替代。

Q3：Ramp测试中排名靠前的大模型，现在在实际软件开发中能用吗？

A：有参考价值但要谨慎。Ramp测试的是编译器构建这一特定领域，最好的模型（Opus-4.7）在六关流水线中仍未能全程无误完成，且花费高达126美元。对于其他软件工程任务，表现可能不同。研究本身也指出，目前所有测试都使用了OpenHands一种框架，不同框架可能产生不同结果。