EngiWorld 把 AI 放进工程软件,检验交付能力

EngiWorld 基准测试涵盖 1301 个任务，横跨 CAD、CAE、CAM、BIM、EDA 和 DCC 六大专业工程领域。Claude Opus 5 得分最高 44.7，但大多数模型在 129 个任务上表现为零分。跨软件协作任务成功率仅 3.6%。这件事揭示了"AI 会用工具"和"AI 会交付工程成果"之间存在巨大鸿沟。

一个非常完整的覆盖面。

第一，CAD（计算机辅助设计）。第二，CAE（工程仿真）。第三，CAM（制造）。第四，BIM（建筑信息模型）。第五，EDA（电子设计自动化）。第六，DCC（数字内容创作）。这六条——"工程"和"内容"两条"线"都在"里面"。

这四条——说明"这个"基准"覆盖"的"是""真实"的"专业"工作流"，不"是""玩具""。

二、散热板案例：一个真实的任务链

一个非常具体的例子。

第一，"先在 AutoCAD 绘图，再用 SolidWorks 建模，最后交给 Abaqus 做热分析"。第二，"AI 需要在软件切换后保持尺寸、单位和物理条件正确"。第三,""它"要"能"交付通过工程验收的成果吗？"。第四,""这"是"三"个"软件"、"三"次"切换"、"无"数"个"状态""。

这四条——揭示了"工程交付"的"本质"是"跨工具的状态一致性"。

三、44.7 分与 129 个零分

一组非常刺眼的数字。

第一，"Claude Opus 5 在测试中获得最高分 44.7，处于领先地位"。第二，"大多数模型在大量任务（如 129 个）上表现为零分"。第三,"'零分'——"不是"错"，是"完全"没"完成""。第四,""这"是"二元"的"结果"——"要么"交付"了"，要么"没"有""。

这四条——说明"工程"场景的"评分"是"全"或"无"的。

四、跨软件协作：3.6% 的成功率

一个非常低的数字。

第一，"在 24 个跨软件协作任务中，成功率仅为 3.6%"。第二，"'3.6%'——"24"个"里"不到""一"个"。第三,""这"揭示"了"AI"在""不同"工具"间"保持"数据"一致性和"处理"复杂"逻辑"链"的能力"依然"薄弱""。第四,""这"是"整"个"基准"的"核心"结论""。

这四条——说明"瓶颈"被"精确定位"到了"跨工具""状态"传递"。

五、物理一致性与尺寸精度

两个非常具体的短板。

第一，"物理一致性"。第二，"尺寸精度"。第三,""在"散热板"案例"中，AI"虽然"能"完成"基础"操作"，但"在"软件"切换"后"会"出现"比例"等"物理"错误""。第四,"'比例错误'——"这"是"最"典型"的"跨工具"bug""。

这四条——说明"错误"不在"做"，在"接续"。

六、1301 个任务的意义

一个关于基准设计的观察。

第一，"涵盖 1301 个任务"。第二，"'真实'工程'流程'"。第三,""这"是"第一"批"把"智能体""放"进""真实""专业""软件"里"测"的"基准""。第四,""这"和"上一"篇"讲"的""PaperBenchX"是"同一"条"路"——"从""真实"科研""推到""真实"工程""。

这四条——揭示了"评测"正在"从""沙盒""走向""真实""工作流""。

七、我的评价

这个基准最让我看重的是它没有停在"模型能不能画图"，而是问"能不能交付一个通过工程验收的东西"。这两件事之间隔着整个工程行业最核心的东西：状态一致性。你在 CAD 里画了一条线，转到 SolidWorks 建模时单位是毫米还是英寸？转到 Abaqus 做热分析时载荷边界条件还在不在？这些问题人类工程师靠几十年的肌肉记忆和 SOP 文档解决，AI 靠的是"上一句话的输出是这一句话的输入"——而一旦中间隔着一次软件切换，状态就断了。

这件事的更深意义在于——3.6% 这个数字，和"上一"篇"讲"的"a7"（数采员的动作变形率）、"a5"（钢缆机器人的自适应爬行）揭示的是同一个规律：AI 在"标准化"、"连续"的任务上进展飞快，一旦任务需要"跨介质保持状态"，就会断崖式下跌。 而"工程"、"科研"、"制造"这些领域，恰恰是由无数个"跨介质"组成的。 这"也"说明""Agent""时代"的"下一个""硬"骨头"，不在"更"强"的"模型"，在"更"可靠"的"状态"管理"——"上一"篇"讲"的""OpenViking"分层记忆"、"a2"（CobbleDB 的"读写"解耦），本质"都"是"这个"问题"。

八、给做 Agent 的四条建议

第一，""跨工具""状态"必须"显式"维护""——"不"能"靠"上下文"隐式"传递""。第二,""每个"状态"转换"都要"有"校验""——"比例"、"单位"、"边界条件""。第三,""评分"要"用"真实"交付"标准""——"全"或"无""。第四,""先"攻"跨软件"协作""——"那"是"最"接近"真实""交付"的"瓶颈""。

这四条——是能直接用的。

九、潜在挑战

不过这类基准也有它的边界。第一，""1301 个任务"是"一个""团队"的"选择""——"任务""分布"会"影响"结论""。第二，""真实"工程"和"企业""真实"工程"还有"距离""——"企业"还有"遗留"系统"和""非"标准"流程""。第三,""成功"率"的"定义"很"关键""——"3.6%"是"完全"交付"，"还是""部分"正确""。第四,""这个"基准"可能会"很快"被"刷穿""——"和"上一"篇"讲的"一样"。

十、反面观点

不过这个判断也可能过于悲观。第一，""44.7 分"是"最"好"模型"的"成绩"，"不"是"平均""——"最"好"的"和""中位"的"差距"很大""。第二,""3.6%"是"当前"能力"，"不"是"原理"上限""。第三，""跨软件"协作"在"人"类"工程"里"也"很"痛""——"这"说明"这"是"一个"真"问题"，不"是""傻"问题""。第四,""专业"领域"的"标准"不"适合"所有"场景""——"做"产品"的"AI"Agent"不"需要"过"这个"坎""。## 十一、为什么「跨软件」比「单软件」更难

一个更本质的归因。

第一，"单个"软件"里的"操作"，是"有""确定"的"输入输出"的"。第二，""跨软件"时，"你"必须"把"上一个"软件"的"隐含"状态"，翻译"成"下一个"软件"的"显式"参数"。第三,""这"就是"为什么""单位"、"比例"、"坐标"系"会"丢""。第四,""这"是"一个""翻译"问题，不"是""智能"问题"。

这四条——揭示了"跨软件"的"本质"是"接口""语义"的"翻译"。

十二、给做工程软件 Agent 的四条建议

第一，"把"每个"软件"的"调用"都"抽象"成"显式"状态""——"别"依赖"上一个"的"隐式"上下文""。第二,""在"切换"点"做"硬校验""——"单位"、"量纲"、"坐标系""。第三,""用"真实"工程"案例"做"回归"测试"——"散热板"这"类"案例"就是"天然的"测试集""。第四,""承认"目前"的成功率""——"3.6%"不"是"失败"，是"地图""。

这四条——是能直接用的。