AI 终于对工业仿真软件下手了!Codex、Cursor、Claude Desktop 直接驱动 Abaqus 建模求解,浏览器里看云图

一句话就能跑仿真？先看看到底发生了什么

5 月 1 日，X 用户@QingQ77（Geek Lite）发了一条推文，没有长篇大论，就一段话加一个 GitHub 链接：

“用 AI 客户端（Codex、Cursor、Claude Desktop）通过 MCP 协议驱动 Abaqus/CAE 进行仿真建模与求解，并在浏览器中交互式查看仿真结果云图、模型树和动态帧。”

▲ @QingQ77 的种子推文，13 赞 / 10 收藏 / 近千次浏览

看起来平平无奇？

但懂行的人一眼就知道，味道完全变了。

因为 Abaqus 不是什么网页小工具。它是达索系统旗下的重量级有限元分析软件，全球航空航天、汽车、能源行业的工程师拿它做结构强度、碰撞、热力学仿真。操作门槛极高，学习曲线陡峭，license 费用不菲。

而现在，有人把它变成了 AI 可以直接调用的工具。

拆开来看：这条链路到底怎么跑通的

这个项目叫Text-to-CAE，GitHub 仓库 `Cai-aa/text-to-cae`，已经拿到69 颗星和 15 个 fork。

▲ text-to-cae 仓库主页，69 stars，README 写得非常清晰

整条链路分四步：

第一步：你在 AI 客户端里说人话。打开 Codex、Cursor 或 Claude Desktop，用自然语言描述你要做的仿真任务——比如”建一个悬臂梁，施加端部集中力，跑静力分析”。

第二步：AI 通过 MCP 桥接层调用 Abaqus。这里的关键中间件叫Abaqus MCP，它把 Abaqus/CAE 的能力——执行脚本、读模型信息、提交 Job、查 ODB 结果、截取 viewport——全部暴露成 AI 可调用的工具接口。

第三步：Abaqus/CAE 真刀真枪地建模求解。几何建模、材料定义、边界条件、网格划分、Job 提交、ODB 输出——这些全是 Abaqus 在干，不是 AI 在”假装”。

第四步：结果直接在浏览器里交互查看。项目自带 viewer，打开 `127.0.0.1:4178` 就能看到云图、模型树、动态帧，支持交互式操作。

有人看完这条链路，六个字总结得很到位：

“AI驱动CAE仿真，自然语言输入到浏览器交互，无缝闭环。”

▲ @QT9277 的评论——”无缝闭环”四个字抓住了核心

MCP：让 AI 从”嘴炮”变成”动手”的那座桥

整条链路里最关键的技术节点，是Abaqus MCP Plugin v4.0。

▲ abaqus-mcp 仓库，54 stars，已迭代到 v4.0

MCP（Model Context Protocol）的作用说白了就是：把一个只能人手动点的 GUI 软件，变成 AI 能调用的工具系统。

这个插件通过文件式 IPC 通信，给 AI 客户端暴露了一组明确的能力：

• execute_script
  
  ：执行 Abaqus Python 脚本
• get_model_info
  
  ：查询模型几何、载荷、边界条件
• list_jobs / submit_job
  
  ：管理和提交求解任务
• get_odb_info
  
  ：读取 ODB 结果文件的元信息
• get_viewport_image
  
  ：截取当前 viewport 画面
• abaqus://status
  
  ：实时查看插件状态

“A plugin that enables communication between Abaqus/CAE and external AI assistants (or any MCP client) via file-based IPC.”

「一个通过文件式 IPC 让 Abaqus/CAE 与外部 AI 助手通信的插件。」

这意味着什么？AI 终于可以形成“观察→执行→再观察→再执行”的闭环。以前大模型对 Abaqus 的帮助停留在”我建议你写这样一段脚本”，属于纯嘴炮。现在它可以自己发指令、看结果、判断状态、继续下一步。

这个仓库早在2026 年 1 月 20 日就创建了，4 月 8 日推出 v4.0 大更新，加入 Job 管理、ODB 检查、viewport 截图等核心能力。作者花了三个多月打磨这座桥，才有了 5 月 1 日的公开演示。

和”AI 帮你写脚本”完全两码事

可能有人会说：让 ChatGPT 帮忙写一段 Abaqus Python 脚本，这事儿早就有人干过了，有什么稀奇？

区别在于：一次性吐个脚本，和把整个软件变成 Agent 可以反复操控的工具系统，完全是两个量级。

让 AI 写段脚本 = 你问一句，它答一句，复制粘贴，跑不跑得通全靠运气。

Text-to-CAE 这套链路 = AI 可以连续操作：写脚本→提交→看状态→读结果→发现问题→改脚本→再跑。

前者是单回合问答，后者是代理式工程循环（Agentic Engineering Loop）。

而且，text-to-cae 不只是”跑通就完事”。README 里列了一组真实仿真案例：

• 悬臂梁（cantilever）
• 带孔板（hole-plate）
• 模态分析（hole-plate-modal）
• 球冲击（sphere-impact）
• 三维铣削（milling-3d）
• 弹体侵彻（bullet-plate）

这些都是 CAE 工程师日常真会遇到的经典问题，可不是什么玩具 demo。

别急着吹：这件事的边界在哪里

说完让人兴奋的部分，必须把边界讲清楚。

第一，这还是本地运行的工具。README 写得很明确：Text to CAE 是一个本地 Abaqus 仿真工作区。你得有 Abaqus 环境、商业 license、Python/Node 运行时、MCP 配置——全套齐了才能跑。这更像一个工程师的增强系统，离零门槛的云端产品还很远。

第二，Demo 很强，但泛化能力还没被证明。悬臂梁、带孔板这些案例确实说服力十足，但复杂接触、多材料非线性、收敛调参这些真正折磨工程师的活儿，还没有公开的第三方验证。

第三，社区讨论还在早期。种子推文 13 个赞、近千次浏览，仓库 69 颗星——这远远算不上”全网疯传”。目前还处在工程圈小范围扩散的阶段。

但这恰恰是最有意思的地方：热度不炸，信号却极强。

真正该害怕（或者兴奋）的事

如果回头看 AI 过去两年的进化路线：

• 第一阶段：帮你写一小段代码
• 第二阶段：帮你改整个 repo
• 第三阶段：作为操作层，直接驱动真实软件系统干活

Text-to-CAE 刚好踩在第三阶段的门口。

而 CAE 还只是起点。想想看——如果 Abaqus 可以被 MCP 工具化，那：

• CAD 呢？
  
  SolidWorks、CATIA、Fusion 360
• EDA 呢？
  
  Cadence、Synopsys
• CFD 呢？
  
  ANSYS Fluent、OpenFOAM
• GIS 呢？
  
  ArcGIS、QGIS
• BIM 呢？
  
  Revit、Tekla
• 医疗影像工作站呢？
• 实验仪器控制台呢？

一旦专业软件被接口化，AI 客户端就不再只是”写建议”的角色——它会变成操作入口。

过去，AI 在程序员的工作台上打工。现在，它正在走进工程师的工作台。

这条路会走多远，没人能确定。但 text-to-cae 这个项目，已经把第一个真实的脚印踩了下去。

— END —