你有没有想过一个问题：一个能写代码、能通过律师资格考试、能画出以假乱真的图片的AI，为什么到现在都没办法帮工程师画一张合格的机械图纸？
这不是危言耸听。2026年,一群研究者做了一个挺"损"的实验:他们把当今最顶尖的几个AI模型,比如GPT、Claude、Gemini这些,扔进真实的工程师工作环境里,让它们用AutoCAD画图、用Abaqus做仿真、用KiCad画电路板。结果呢?表现最好的模型,满分100分只拿到了44.3分。而当任务需要在多个软件之间切换协作时,成功率直接跌到了3.6%。
这个结果多少有点打脸。毕竟这几年AI在写代码、聊天、画画上的进步有目共睹，怎么一到专业工程软件这儿就集体"翻车"了?这篇论文的价值,就是把这个问题第一次系统地摆在了台面上。
为什么之前没人发现这个问题
其实不是没人测过AI用电脑的能力。像OSWorld、Spider2-V这些基准测试,早就在评估AI操作各种软件的水平了,评估的方式通常是看AI最后交出来的文件和"标准答案"长得像不像。
问题就出在这个"像不像"上。
工程软件的产出物,光靠表面相似度根本判断不了对错。
一个CAD模型可能渲染出来看着挺像那么回事,但内部可能存在非流形几何结构
非流形几何：指的是那种在现实世界里根本不可能造出来的形状,比如两个面共享一条边却没有实体连接,这种模型在3D打印或者数控加工时会直接报错
或者根本不满足力学约束,一压就塌。这就好比你让一个不懂建筑的人临摹一栋房子的照片,他画得再像,你也不知道这栋房子的承重墙到底稳不稳固。如果不做结构验证,单靠"看起来对不对"来打分,那所有偷工减料的设计都能蒙混过关。
除了评判标准的问题,之前的基准测试还有两个明显的短板。第一个是交互深度不够。像Text2CAD这类工作基本是"一句话生成一个模型",属于单轮对话;后来CADWorld虽然引入了图形界面操作,但步数上限只有100步。可现实中的工程任务往往需要维持几百步的连贯逻辑,前面一个尺寸标错了,后面所有的加工步骤都会跟着报废。
第二个短板是反馈机制太单薄。以前的AI智能体大多只能看到文本反馈,比如程序报错信息,但真正的工程师做设计,靠的是仿真收敛曲线、渲染出来的实际效果、设计规则检查报告这些"活"的反馈信息去不断调整方案。
这就好比学开车,如果教练只在你考试结束后甩给你一张"不合格"的纸条,而不是在你压线的那一刻立刻提醒你,你永远学不会怎么修正方向盘。
ENGIWORLD:把整个设计闭环搬进考场
针对这些问题,研究团队搞出了一个叫ENGIWORLD的基准测试系统。这个名字听着挺大,但它想干的事情其实很朴素:模拟真实工程师一天的完整工作流程,而不是抽取其中一个孤立的环节来考核。
具体来说,ENGIWORLD覆盖了六个工程领域,CAD
CAD:计算机辅助设计,就是画图纸、建三维模型的软件,比如AutoCAD、SolidWorks
、CAE
CAE:计算机辅助工程,专门用来做仿真分析的,比如你想知道一个零件受力会不会断裂,就得靠这类软件,代表有Abaqus、ANSYS
、CAM
CAM:计算机辅助制造,负责把设计图转换成机床能理解的加工指令,常见的有FreeCAD Path、SolidCAM
、BIM
BIM:建筑信息模型,盖房子用的软件,能把建筑的几何结构、材料、能耗都整合在一个模型里,代表软件是Revit、ArchiCAD
、EDA
EDA:电子设计自动化,专门画电路板和芯片的,像KiCad、Altium Designer这些电路设计师天天在用的工具
,以及3D可视化。整个基准包含1301个由专家精心设计的任务,横跨26款专业软件,同时支持图形界面
GUI:就是我们平时用鼠标点点点、拖拖拖的那种可视化操作界面
和命令行
CLI:通过敲代码指令来操作软件,不需要图形界面,类似程序员在终端里写命令
两种交互方式。
这里最关键的设计,是六种任务类型的划分。研究者没有简单地丢给AI一堆孤立的题目,而是按照真实设计流程的不同阶段来设置考题:有的任务考察AI能不能看图建模
也就是给AI一张参考图片,让它照着建出对应的三维模型
;有的任务考察AI会不会"选工具",比如给出几个候选软件,让AI自己判断用哪个更合适来完成一个BIM任务;还有单软件任务考验精细操作能力,多软件协作任务考验跨工具传递数据的能力,量化设计任务考验它能不能拿出一个数值上真正达标的方案,最后还有一类开放式任务,直接给一台空白电脑和一句需求描述,让AI自己决定用什么工具、怎么干。
这六种任务连起来,恰好构成了一个完整的工程设计闭环。
如果只测单一软件的操作能力,你测出来的只是AI会不会用鼠标点菜单,测不出它能不能真正完成一件工程作品。
这就像考驾照,如果只考"会不会挂挡"而不考"能不能从A点安全开到B点",那考出来的司机上了真实道路照样出事。ENGIWORLD想验的正是这条完整的路。
怎么给AI的答卷打分:artifact-centric评估
光有任务还不够,更难的部分在于怎么客观地给AI的作品打分。研究团队提出了一套叫artifact-centric
artifact-centric:直译是"以产出物为中心",意思是评判一个任务做得好不好,不是看AI操作过程顺不顺,而是直接检查它最后交出来的文件本身是否满足工程要求
的评估方法,核心思路是建一套统一的领域验证器
domain-verifier:一套自动化程序,能够重新打开AI提交的文件,像STEP格式的三维模型、网表、G代码这些,提取出关键的工程参数,然后按照严格的公差标准逐条核对
对于像"这个零件的尺寸对不对"这种是非分明的任务,验证器会检查所有必须满足的条件,只要有一条不达标,这个任务就判定为失败,没有中间地带。
但工程里有大量任务是没有唯一标准答案的,比如"设计一个尽量省材料的支架"或者"优化一下电路板的布线让走线更短"。对付这类量化设计任务,评估方法分成两步走:先做一次硬性的可行性检查,如果设计本身违反了物理定律或者几何约束,直接判零分;通过了这一关之后,再根据设计质量给出一个0到1之间的连续分数,越接近专家给出的参考方案,分数越高。
举个论文里的实际例子会更直观。有个任务是让AI优化KiCad里的电路板布局,Gemini交出的方案把评估器计算出的综合成本从64.2降到了3.2,走线长度也从53毫米缩短到40毫米,最终拿到了0.982的高分,离满分只差一点点,这一点差距其实就是走线长度还没压缩到理论最优值的那一部分成本。这种打分方式的好处是,它不会因为一个方案"差一点点没做到完美"就直接一棍子打死,而是老老实实地告诉你,这个方案到底优化了多少。
七个顶尖模型上考场,谁赢了
研究团队找来了七个当下最主流的AI模型同台竞技,包括GPT-5.6 Sol、Claude Opus 5、Kimi K3、Gemini 3.7 Flash、Qwen3.8系列以及DeepSeek V4.1。为了控制测试成本,他们从1301个任务里挑出了300个具有代表性的样本进行实测。
结果显示,Claude Opus 5拿到了最高的44.3分,GPT-5.6紧随其后拿到38分。但要注意,这依然是个不及格的成绩。更扎心的是,在这300个任务里,有128个任务是所有七个模型全部拿零分的,占比超过四成。
拆开来看不同任务类型的表现会发现更多细节。单软件任务里,Claude能完成大约一半;看图建模任务它甚至能做对三分之二。但一旦涉及多软件协作,168次尝试里只有6次成功,成功率不到4%。软件选择任务也是重灾区,Claude在这类任务上的正确率只有四分之一。
这个落差说明了一件事:AI操作单个软件的能力,和它能不能串联起一整套工作流程,完全是两码事。
这就好比一个厨师,能把每道菜单独做得色香味俱全,但让他同时兼顾开胃菜、主菜、甜点的上菜节奏和味道搭配时,整桌菜的协调性立刻崩了。
单点能力强不代表系统调度能力强,而工程设计恰恰是最考验系统调度的活儿。如果不专门去测多软件协作能力,单靠单点测试的高分,会让人误以为AI已经能独立完成整个工程项目,这是个危险的错觉。
不同模型在不同领域的表现也很不均衡。Claude在CAD、CAE、EDA、BIM四个领域领先,但Qwen3.8 Max却在3D可视化领域反超。CAM(加工制造)对所有模型来说都是最难啃的骨头。
执行效率方面也有意思的分化。GPT用的交互步数最少,平均54.9步就能给出结果;Claude虽然分数最高,但花的API成本几乎是GPT的两倍。DeepSeek和Gemini拿到的分数差不多,但DeepSeek的成本只有Gemini的不到一半,原因是DeepSeek每一步输出的文字量特别大,定价机制不同导致最终花费差异悬殊。
失败原因大起底:AI到底卡在哪儿
研究者把所有失败的案例归了类,发现绝大多数失败都落在两种模式里。
第一种是AI自己宣布"完成了"
DONE:AI在任务流程里发出的终止信号,表示它认为自己已经完成任务
,但验证器一检查,发现产出物根本不达标。这种情况在GPT和Claude身上格外突出,分别占到它们失败案例的87%和73.9%。
这暴露出一个很根本的问题:AI能"看起来"把活儿干完,但它没有能力像真正的工程师那样,在提交作品前自己核实一遍是否真的合格。
换句话说，如果这个软件不逼着AI去跑一遍验证程序，它自己是意识不到错误的。这就像一个学生写完作业直接交卷,却从来不会主动对答案检查一遍,他不是不会做题,而是压根没有"核对"这个动作的意识。
第二种失败模式是决策轮次耗尽,也就是任务还没做完,允许操作的步数就用光了。这种情况在Gemini、两个Qwen模型和DeepSeek身上更常见,而且在图形界面任务里比命令行任务里出现得更频繁,占比分别是55.3%和36.6%。这说明鼠标点击式的操作路径本身效率就更低,一步一步试错的成本远高于直接写代码或敲命令。
论文里还给出了几个具体的失败案例,读起来挺有画面感。比如在一个从SolidWorks传数据到Abaqus做仿真的任务里,AI设置了一个负压力载荷,数值上换算出来大约相当于1千牛的拉力,看似做对了,但评估器要求的是直接指定"力"或"位移"这种参数类型,而不是压力换算过来的等效值,导致这个方案被判定不合格。这种细节上的"表面正确、实质不符"，恰恰是当前AI在工程领域最容易踩的坑。
还有一个案例更让人哭笑不得:AI在准备图纸时,原本想编辑一段文字,结果误操作按下了全选加删除,把整张绘图画布清空了,重新打开文件后发现关键的窗口元素全部丢失,最终这个任务只能以失败告终。这种低级失误说明,即便是最先进的AI,在处理图形界面这种需要精细空间感知和操作意图判断的场景时,依然会犯人类新手都不太会犯的错误。
观察窗口的形状,会不会影响AI的判断
研究团队还做了一系列细致的消融实验,来看看给AI的"观察方式"做些调整,会不会改善表现。
比如把参考图纸直接放进任务描述的文字里,而不是让AI自己去环境里翻找,GPT在图形界面任务上的分数直接从15分跳到31.7分,提升非常明显。但有意思的是,这种改进并非对所有模型都友好,Kimi在命令行任务上反而因为这个改动分数下降了。
这说明同一个"喂料方式"的调整,对不同模型的消化能力完全不一样,没有放之四海而皆准的最优解。
这就好比给不同的人推荐菜谱,有人喜欢把食材提前切好摆在案板上,直接开炒效率最高;但也有人反而喜欢边看菜谱边现场准备,如果强行给他切好的食材,他可能因为不熟悉这套流程而手忙脚乱。给AI提供辅助信息,同样存在"因材施教"的问题,不能一刀切地认为多给信息总是好事。
屏幕分辨率的实验也很说明问题。用原始的1920×1080分辨率,三个模型的表现都是最好的。把分辨率降到0.6倍虽然能省不少成本,但对Kimi来说,精度损失带来的性能下滑非常明显,而GPT则相对更能扛得住这种压缩。这说明分辨率这种看似"物理层面"的参数,实际上也在悄悄决定AI能不能看清那些密集排列的电路引脚或者细小的标注文字。
这场考试给我们的启示
看完这些实验结果,你可能会有点悲观:AI在专业工程软件上的表现居然这么拉胯?但换个角度想,这恰恰说明了工程设计这件事的门槛,远比我们想象中要高。
一张合格的工程图纸,背后要同时满足几何精度、材料力学、加工工艺、成本预算这些互相牵制的约束条件,任何一个环节出错,整个方案都可能报废。这种"牵一发而动全身"的复杂性,恰恰是当前AI最不擅长处理的。它们擅长的是模式匹配和局部推理,但工程设计需要的是长链条的因果推演和持续的自我验证,这两种能力目前还没能很好地统一在同一个模型里。
ENGIWORLD这套基准的价值,不在于证明AI不行,而在于它第一次把"AI到底哪里不行"这个问题量化成了可以追踪的数字。有了这套标尺,后续的研究者才知道该往哪个方向使劲,是该加强跨软件的数据传递能力,还是该给AI装上一个"自我核查"的习惯,又或者是该重新设计图形界面操作的反馈机制。
写在后面
读完这篇论文,最让我意外的一点是,失败案例里出现频率最高的居然不是"AI不会用软件",而是"AI以为自己做对了,其实没做对"。这个发现比单纯的低分数更值得琢磨。
因为这意味着问题不在于工具使用能力,而在于判断力,或者说,在于AI有没有一种类似人类工程师那种"不放心,再检查一遍"的习惯。人类工程师在交付一份图纸之前,会下意识地对照规范、量一量尺寸、甚至请同事帮忙复核。而目前的AI智能体,完成动作之后就直接宣布"完成",中间缺了这一道自我怀疑的工序。
这让我联想到,或许AI在专业领域真正需要补上的,不是更强的建模能力,而是一种"知道自己可能错了"的谦逊感。这种谦逊感,恰恰是经验丰富的老工程师身上最珍贵的品质,他们不是从不犯错,而是永远保持着复核的习惯。
如果有一天AI真能在提交答案前,像老师傅那样眯着眼睛对图纸多看两眼,那可能才是它真正配得上"工程师"这个称呼的时刻。
Q&A
Q1：ENGIWORLD是什么？
A：ENGIWORLD是首个围绕完整设计闭环构建的工程AI能力测试基准，覆盖CAD、CAE、CAM、BIM、EDA和3D可视化六大工程领域，包含1301个专家设计的任务和26款专业软件，用来评估AI智能体在真实工程软件环境中的表现。
Q2：AI在专业工程软件测试中表现如何？
A：表现整体不理想，表现最好的Claude Opus 5也只拿到44.3分（满分100），而涉及多个软件协作的任务成功率仅有3.6%，说明AI在跨软件工作流协调上存在明显短板。
Q3：AI在ENGIWORLD测试中最常见的失败原因是什么？
A：最常见的两种失败是AI自称完成任务但产出物不达标（缺乏自我验证能力），以及在规定操作步数内没能完成任务，这两类占了失败案例的九成以上。
