上交大&斯坦福联手打造"OR-Space"：让AI真正学会像工程师一样解决运筹学问题

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

**从"做题家"到"真正的工程师"——一个关于AI工作能力的故事**

假设你刚入职一家大型制造企业，成为一名运筹学工程师。你的第一个任务是优化工厂的生产排班，但老板给你的不是一道干净的数学题——他把你拉进一个乱糟糟的文件夹，里面有描述业务需求的Word文档、密密麻麻的Excel参数表、前任工程师留下的半成品代码，还有上周求解器跑出来的一堆日志文件。你需要在这堆乱麻中理清头绪，搭建数学模型，跑出最优方案，再向不懂数学的领导解释为什么这个排班最合理。

这才是真实工作。

然而，当研究者们用现有的AI测试题去评估大语言模型（就是GPT、Claude这类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工具。