由上海交通大学、上海财经大学与斯坦福大学联合开展的研究成果，于2026年5月正式发表，论文预印本编号为arXiv:2605.28158v1。对该研究感兴趣的读者，可通过该编号在arXiv平台查阅完整论文内容。

从“解题高手”到“实战工程师”——一场关于AI真实工作能力的深度探索

想象您刚刚入职一家大型制造企业，担任运筹学工程师。首个任务是优化工厂的生产排班，但老板交给您的并非一道清晰的数学题目——他带您进入一个杂乱无章的文件夹，里面包含描述业务需求的Word文档、密密麻麻的Excel参数表、前任工程师留下的半成品代码，以及上周求解器运行后的大量日志文件。您需要在这堆繁杂信息中理出头绪，构建数学模型，求解最优方案，并最终向不懂数学的领导解释为何该排班最为合理。

这才是真实的工作场景。

然而，现有的人工智能测试题是如何设计的呢？提供给AI的是一道表述清晰、参数完整、自带答案框架的“课本例题”。当AI正确解答后，人们便惊叹：“哇，AI会解运筹学问题了！”这就像一个只会答卷的学生，一遇到真实岗位便束手无策。

为填补这一巨大的评估空白，上海交通大学、上海财经大学和斯坦福大学的研究团队联合打造了一套全新的测试体系——OR-Space。其核心思路十分简明：将AI置于真实的工作环境中，而非仅让它在考场内解题。

一、何为真实工作环境？OR-Space的核心设计理念

运筹学（Operations Research，简称OR）是一门运用数学方法解决资源分配、路径规划、生产调度等现实问题的学科。物流公司如何规划快递路线、工厂如何安排生产以最大化利润、医院如何调度手术室——这些都是运筹学的典型应用领域。

过去的AI评测，提供给AI的是诸如“一家工厂有三台机器，每台机器每小时产能如下，请写出最优生产计划”这类直接给出所有条件的题目。而OR-Space则将这一过程还原为真实工作场景：业务文档（一份描述工厂运营背景与需求的Markdown文件）、参数数据（一张或多张CSV格式的电子表格）、代码骨架或历史脚本（前任工程师编写的Python代码）、求解器运行日志（上次模型运行的输出结果）——这些分散在不同文件中的信息共同构成一个“工作区”（Workspace），AI必须自行寻找、阅读、理解并整合这些信息。

研究团队用一个简洁的数学公式定义了该工作区：W = {D, P, S, E, M}，其中D代表文档、P代表参数文件、S代表代码、E代表运行环境（一个Docker沙箱，可执行代码并调用求解器）、M代表评分标准（仅评测系统可见，AI无法查看）。这一设计借鉴了工业界常用的代数优化系统（如AMPL、Pyomo）中模型与数据分离的思路，但更进一步，将求解器的执行状态与评分信号也纳入评测体系。

更重要的是，OR-Space并非仅考察单一能力，而是全面评估工程师日常工作中的三个关键阶段，分别对应三种任务模式。

二、三种任务模式：构建、修改与解释

第一种任务名为“构建”（Build）。向AI提供业务文档与数据文件，代码文件为空。AI需要从头理解需求、对齐数据字段，并编写出一个完整可运行的优化模型。这考验的是AI能否从分散的文字和数字中还原出数学问题的完整结构。

第二种任务名为“修改”（Revise）。这次并非从零开始——工作区内已包含一个基于原始问题的历史代码实现，但业务需求发生了变化（例如新增一个约束条件，或改变了目标函数）。AI需在不破坏原有正确逻辑的前提下，准确修改模型。这考验的是AI能否区分“哪些是可复用的有用遗产，哪些是不可照搬的旧包袱”。该任务还设有三个细分版本：仅提供代码的“Revise-code”、仅提供数学公式描述的“Revise-model”，以及两者都提供的“Revise-all”。

第三种任务名为“解释”（Explain）。AI将获得完整的工作区，包括求解器运行后的日志（例如哪个约束是“紧约束”，对偶变量是多少，松弛量是多少），随后需要回答业务层面的问题，例如“为什么产能约束是瓶颈？如果放宽此约束，目标值将如何变化？”这考验的是AI能否将数学结果翻译成具有实际意义的业务洞察，而非凭空编造答案。

这三种模式共同构成了一个工程师在实际项目中必然经历的完整生命周期。

三、题目来源：一条严谨的生产流水线

OR-Space的100道基础题源自一个名为IndustryOR的工业级优化问题数据库。研究团队将每道题目扩展为构建、修改、解释三种版本，最终形成300个测试实例。

然而，这300道题目并非从原始题目简单复制而来。研究团队设计了一套严格的“题目生产流水线”。

在生成构建题时，团队先撰写一个干净、完整的问题规格，再将其“改装”成真实的工作区格式——将数字参数拆分至CSV文件，将业务描述改写为包含行业术语、口语化冗余、格式不一致的Markdown文档（如同真实的业务文档那样“并非完美”），并将求解代码拆分为主文件加工具函数的形式。

在生成修改题时，团队设计了一套“需求演化”机制，专门引入那些“牵一发动全身”的复杂修改——例如同时新增一种变量、删除一个旧约束、修改目标函数，且新添加的业务规则会影响到原有的约束关系（而非独立添加）。每道修改题均需通过两道关卡：首先由一个AI模型写出修改方案，随后由另一个独立的AI模型仅根据文档和数据（不查看代码）重新建模。两者的目标值需在0.1%误差范围内吻合，否则该题目将被弃用。

在生成解释题时，团队从已验证的求解结果中提取真实的数学信号——对偶变量、紧约束、松弛值、大M的紧绷程度、LP松弛界——并围绕这些信号设计需要“多跳推理”的业务问题。何为多跳推理？即必须先查看文档理解业务背景，再查看数据找到参数值，再查看代码理解变量定义，再查看求解日志确认数学事实，将这四步串联起来才能给出正确答案。

所有生成的题目均需经过具有运筹学背景的研究人员人工审核，确保业务描述、参数文件、求解状态与评分标准之间不存在矛盾。

四、评分机制：严格而公平的评估体系

构建与修改任务的评分十分客观：AI编写的代码能成功运行，求解器返回“最优”状态，且目标函数值与参考答案的相对误差在1%以内，即视为通过（得分为1），否则为失败（得分为0）。所有代码均通过统一的PuLP接口提交，评测系统在运行时再将具体求解器（如Gurobi、COPT、HiGHS等）挂载上去，从而确保模型的正确性与所用求解器无关。此外，评测系统还会记录失败的类型，例如“运行出错”、“结果为空”、“目标值错误”、“API异常”等，便于后续分析。

解释任务的评分则更为复杂，采用“AI担任裁判”的方式，但同时附加了许多限制，以防止AI随意评分。每道解释题均附带一张核查清单，一部分为“精确匹配”项（如变量名、约束名、CSV列名、数值），由程序自动评分；另一部分为“AI判断”项，由独立的裁判模型根据明确的评分标准逐条评判。

最终，解释任务的分数为一个五维度的综合得分（满分100分）。第一个维度名为“精确覆盖”，占35分，考察AI的答案是否包含所需的具体事实，例如正确的变量名、具体的数字、准确的单位。第二个维度名为“推理质量”，同样占35分，考察AI是否正确地将这些事实串联为有意义的优化逻辑，例如“因为这个约束是紧约束，所以放宽它能改善目标值”。第三个维度名为“证据落地”，占20分，考察AI的解释是否真正基于工作区内的具体材料，而非凭空发挥通用OR知识。第四个维度名为“答案质量”，占10分，考察答案是否简洁、直接、表述清晰。最后还有一个“幻觉惩罚”，最多扣12分，专门惩罚那些编造工作区内根本不存在的约束、参数或数学事实的行为。

五、测试了哪些AI？结果如何？

研究团队测试了20个不同的大语言模型，涵盖了当前最主流的选择，包括来自Google的Gemini系列、来自Anthropic的Claude系列、来自OpenAI的GPT系列，以及开源阵营的DeepSeek系列和阿里云的Qwen系列。每个模型均在100道题目上各运行一遍，采用低随机性设置（temperature ≤ 0.1），代码生成最多使用32768个token，每次提交在独立的Python解释器中运行，限时120秒。

结果显示出了几个非常有趣的规律。

在构建任务上，表现最佳的是Gemini 3.1 Pro，通过率为72%。大多数顶级模型的通过率在53%至68%之间。换言之，即便是当前最强大的AI，在处理这种需要从分散文件中自行查找信息并建模的任务时，仍有近三分之一的情况会出错。这些题目的数学拓扑结构与原始IndustryOR数据集相同，区别仅在于不再将所有信息压缩为一个干净的提示词，而是分散于文件系统中——仅仅是这一变化，就使得通过率大幅下降。

在修改任务上，一个有趣的现象出现了：强模型往往能从历史代码中获益，而弱模型则常常被历史代码“毒害”。Gemini 3.1 Pro从构建任务的72%提升至修改任务的81%，GPT-5.4从59%跃升至79%，Claude Sonnet 4.5从53%上涨至78%——这些模型能从旧代码中提取有用的结构信息（如变量的粒度、数据的join方式、时间周期的索引方式），同时避免照搬不应照搬的部分。但Gemini 3-Flash却从68%大幅下跌至45%，Qwen3-32b从32%跌至20%——这两个模型似乎被旧代码搞乱，将一些不相关的导入包或变量名原封不动地搬进了新代码，导致运行出错或数学逻辑错误。

研究团队还计算了一个更精细的指标：每多看一千个token的历史代码，模型的准确率会变化多少？GPT-5.4的结果是每千token +11.9个百分点，Claude Sonnet 4.5是+11.3，而Gemini 3-Flash是-11.9，Qwen3-32b是-7.0。同样的信息，对不同模型而言，一个成为燃料，另一个则成为毒药。

在解释任务上，出现了最令人意外的分离现象：GPT-5.4获得了86.52的高分，但Gemini 2.5 Pro在修改任务上通过了69%的题目，解释得分却仅为32.2分；Gemini 2.5 Flash修改通过率为66%，解释得分只有13.79分。这说明“能写出正确的优化代码”与“能解释清楚优化结果的业务含义”是两种完全不同的能力。研究团队计算了三个任务之间的相关性：构建与修改的相关系数高达0.82（高度相关），但解释与构建的相关系数仅为0.16，解释与修改的相关系数仅为0.28（几乎不相关）。换句话说，如果只测试模型编写代码的能力，完全无法预测其解释结果的能力。

六、文件系统 vs. 将所有内容压缩为一个提示词——是否存在差异？

为弄清“工作区形式”本身（而非问题难度）对结果的影响，研究团队进行了一项对照实验：将完全相同的工作区内容以两种方式呈现给AI。一种是默认的文件系统方式，AI能看到分散的文件；另一种是“压平”方式，将所有Markdown、CSV、Python文件的内容拼接为一个大型JSON格式提示词喂给AI，无需AI自行查找文件。

结果显示，对于需要生成代码的任务（构建与修改），文件系统方式平均使通过率分别降低了8.2个百分点和12.2个百分点。对于GPT-4o，构建任务的差距高达19个百分点；对于Qwen3-Max，修改任务的差距为15个百分点。这说明“文件发现”、“路径拼写正确”、“字段名核实”这些看似琐碎的操作，实际上是真实工作场景中非常重要的能力来源，而不仅仅是界面上的微小差异。

但对于解释任务，将内容压平几乎没有帮助，平均仅变化了+0.3分。这是因为解释任务的难点不在于查找文件，而在于将文档、数据、代码、求解日志这四种性质完全不同的信息整合为一个连贯的解释——这个整合难题在任何界面形式下都存在，仅去掉目录结构并不能让任务变得更简单。这也解释了为何解释任务在文件系统和压平两种条件下的表现相近，而构建与修改任务则对界面形式非常敏感。

七、形式化公式是否有用？修改任务的上下文实验

研究团队还追问了另一个问题：给AI看历史代码是一种帮助，那么如果给AI看的不是代码，而是数学公式描述（例如LaTeX格式的变量定义和约束表达式），效果会如何？

答案是：两者不能互相替代，但结合使用效果最佳。

仅提供代码（Revise-code）在Gurobi求解器上的平均通过率为57.4%，仅提供数学公式（Revise-model）为59.0%，两者都提供（Revise-all）为64.8%。这说明代码和公式提供的是不同类型的信息：代码告诉你数据如何加载、索引如何构造、实现细节如何；公式告诉你数学结构如何、变量之间的约束关系如何。强模型能同时利用这两种信息，将其整合为一个比单独使用任何一种都更准确的答案。

但有一个例外：HiGHS求解器上，Revise-all的通过率比Revise-code反而低了3.5个百分点。这暗示不同求解器的接口差异，以及模型对不同求解器的熟悉程度，都会影响此类上下文整合的效果。

对于轻量级模型（参数量较小的模型），仅提供公式（Revise-model）在所有四个求解器上的表现都弱于仅提供代码（Revise-code）。公式能帮助强模型恢复数学结构，但对弱模型而言，公式反而可能成为噪声，因为它们没有足够的能力将抽象的数学符号翻译为正确的代码实现。

八、哪种求解器测得的结果更可靠？

为避免结论依赖于某个特定求解器，研究团队在Gurobi、COPT、PuLP（使用CBC求解器）和HiGHS四种后端上均运行了完整测试。

四种求解器测出的排名大致一致，但绝对分值与任务难度分布存在明显差异。Gurobi的综合目标任务平均分最高（57.2），解释任务平均分也最高（64.9）。PuLP在修改-代码任务上表现最佳，可能是因为测试中的历史启发式代码本身就是用PuLP编写的，上下文对齐度更高。COPT对强模型而言表现接近Gurobi，但对轻量级模型而言大幅下降，可能是因为训练数据中关于COPT接口的代码示例远少于Gurobi。HiGHS的任务间差异最小（极差仅为9.9），说明其表现更“均匀”，但整体水平也较低。

Gurobi与COPT的排名相关性为0.73，说明两个求解器选出的“最强模型”基本一致，但个别模型在两个求解器上的绝对差距可能很大。这意味着，使用单一求解器评测可能会遗漏一些重要信息——一个模型可能非常擅长使用Gurobi编写代码，但对COPT的接口不熟悉，更换求解器后便可能表现失常。

九、失败分析：AI究竟在何处犯错？

研究团队对失败案例进行了详细的分类分析，这部分内容极具价值，因为它揭示了“AI看起来聪明，但实际在哪些地方非常脆弱”。

在所有修改任务的20×100=2000次提交中，19.1%的失败是“运行成功但目标值错误”，18.2%是“运行时出错”。这说明大量失败并非代码崩溃，而是代码成功运行了一个错误的数学问题——AI自认为解对了，但实际上解的并非题目要求的内容。

修改任务还引入了一类新错误：从历史代码中继承了不应继承的内容。例如，在修改任务中，“找不到模块”（module_not_found）这类错误从构建任务的0.4%上升至2.8%，而“变量名未定义”（NameError）从0.2%上升至2.2%。这些错误的根源在于AI将旧代码中导入的某些Python包（如`scipy`或`numpy`）原封不动地搬进了新代码，但这些包在新的求解框架中完全不需要，甚至可能产生冲突；或者将旧代码中的启发式变量名当成了PuLP决策变量使用，但实际上并未重新声明。

研究团队还对表现最好的构建模型（Gemini 3.1 Pro）的28个失败案例进行了逐一人工分析。结果出人意料：仅有21.4%的失败是真正的“数学建模错误”，例如约束写错或目标函数搞反。而高达39.3%是“数据映射错误”——AI将CSV中的某个字段对应到了错误的数学含义上。另有28.6%是“幻觉约束”——AI在工作区内根本找不到依据，凭空发明了一个约束。

这三类错误均与经典的“课本题评测”无关——如果题目将所有参数清清楚楚地写在提示词中，AI根本不会出现数据映射错误；如果所有约束都明确列出，AI也没有空间去幻觉一个约束。这正是OR-Space所揭示的新型失败模式。

一个具体的案例非常能说明问题。在一道关于飞行员培训计划的题目中，工作区数据文件里包含a1=10（第一年战斗机数量）、a2=15（第二年战斗机数量）、training_capacity_per_jet=5（每架飞机每年可培训的飞行员数量）。正确答案应为5×(10+15)=125名飞行员。但Gemini 3.1 Pro编写的代码引入了一个名为“战斗机”的变量C1和C2，将training_capacity_per_jet误用于仅第一年的训练机才能带动第二年产能的限制，最终得到的目标值是25而非125。代码能运行、求解器返回“最优”、结果听起来也是一个数字——但它优化的实际上是一个AI自己发明的错误问题，与业务需求完全不符。如果这是一道将参数直接写入提示词的课本题，这种错误根本不会发生。

总而言之，这项研究告诉了我们什么？

归根结底，OR-Space所做的是：将AI的测试场从“考场”转移到了“工厂车间”。这一转移暴露了一批之前完全看不见的问题——并非AI不会数学，而是AI不太擅长在一堆乱糟糟的真实文件中找到正确信息、理解其含义，并且在修改一个旧系统时知道什么该动、什么不该动、什么该解释清楚。

对于普通人来说，这意味着什么？如果您是一家企业，正在考虑使用AI来帮助运营团队进行优化决策，那么您需要知道：让AI在一个干净整齐的Demo中解一道算好的题目，与让AI在您真实混乱的业务系统中工作，完全是两回事。OR-Space这套测评框架可以帮助您更准确地预判AI在实际工作环境中的表现。

目前表现最好的模型（如Gemini 3.1 Pro、GPT-5.4、Claude Opus 4.6、DeepSeek V4 Pro）在真实工作区场景下的通过率大约在60%到80%之间，还远未达到“可以完全自主工作”的程度。解释能力与建模能力之间的巨大鸿沟，则意味着即便一个AI能帮您建出正确的优化模型，它未必能将结果向领导解释清楚——这两件事需要分开衡量。

研究团队已将所有数据集和代码公开发布，有兴趣深入了解的读者可通过arXiv编号2605.28158查阅完整论文，或通过论文中提供的GitHub和HuggingFace链接获取相关数据和代码。

Q&A

Q1：OR-Space测试系统与此前的运筹学AI评测有何根本区别？

A：此前的运筹学AI评测通常将所有信息（业务背景、参数、约束）整合为一个干净的文字提示词喂给AI，AI只需进行数学建模。而OR-Space则将这些信息分散到多个文件（业务文档、CSV参数表、历史代码、求解日志）中，AI必须自行寻找、阅读并整合这些文件，更接近工程师的真实工作场景。这一变化导致平均通过率下降了约8到12个百分点，暴露了AI在数据字段对齐和跨文件推理上的明显弱点。

Q2：为何AI模型在OR-Space的解释任务上表现与建模任务存在如此大的差异？

A：建模能力与解释能力考察的是两种截然不同的技能。建模要求AI将文字和数字转化为数学结构；解释则要求AI读懂求解器的输出（例如对偶变量、松弛量），再用业务语言清晰说明“为什么这个约束是瓶颈”。Gemini 2.5 Pro的修改任务通过率为69%，但解释得分仅为32.2分，两者的相关系数仅为0.28，说明这两项能力几乎相互独立。

Q3：OR-Space的测评结果对企业选择AI工具有何参考价值？

A：OR-Space使您能够在更接近真实工作场景的条件下比较不同AI模型的能力。如果企业关注的是AI能否自主建立优化模型，可参考构建任务的通过率；如果关心的是AI能否在已有系统上进行需求变更，可参考修改任务；如果关心的是AI能否向非技术人员解释决策依据，则需要重点查看解释任务的得分，而不能仅看建模分数。不同任务的强模型并不完全一致，企业需根据实际需求场景选择合适的AI工具。