上海交大斯坦福OR-Space：AI运筹学突破性解决方案

这项研究由上海交通大学、上海财经大学与斯坦福大学联合推进，论文发表于2026年5月，预印本编号为arXiv:2605.28158v1。读者可凭此编号在arXiv平台检索并获取完整论文内容。

从“解题机器”到“实战工程师”——AI工作能力的一次真实检验

假设你刚入职一家大型制造企业，担任运筹优化工程师。第一项任务是优化生产排班计划——但老板丢给你的并非一道规整的数学题。他把你领进一个杂乱的共享文件夹，里头混杂着业务需求文档（Word格式）、密密麻麻的Excel参数表、前任留下的半成品Python脚本，还有上周求解器跑出的日志文件。你需要从这堆信息碎片里梳理出逻辑主线，构建数学模型，求解最优方案，最后向不懂数学的管理层解释为何这套排班最为合理。

这才是真实的工作场景。

但现有AI测试题怎么做的？喂给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工具。