用Codex驱动STAR-CCM+，我把汽车外流场仿真做成了可复用流程

导读：你有没有过这种经历“一个汽车外流场算例明明跑通了，可换个人接手，光是搞清楚几何在哪、边界叫什么、网格怎么设、结果导没导出，就得花大半天。仿真工程师的时间，常常不是耗在求解上，而是耗在这些"跑通了却交不出去"的琐碎里”。大家好，我是仿真秀专栏作者——梁松月。从 2025 年开始，我一直在琢磨一件事：怎么让 AI 真正走进仿真工程师的日常，而不是停留在 demo 演示里。至今我已经在仿真秀官网推出了 10 套 AI 驱动 CFD 的系列课程，很多工程师朋友说学完就能上手用。

今天这篇文章，我想聊聊我最近做的一个具体实践——用 Codex 驱动 STAR-CCM+，把汽车外流场仿真从"一次性算例"做成"可复用流程"。你会看到一条完整的链路：从 CAD 导入、边界命名、自动网格、稳态求解，到进度跟踪、结果检查和报告输出——每一步都有配置、有状态、有痕迹。如果你也在思考"AI 到底怎么帮仿真工程师提效"，这篇文章里的思路也许能给你一些启发。

我先把这张速度与压力场图放在开头（见下图），因为它代表一次仿真最容易被看见的结果，而我真正想解决的是结果背后的整条链路。

一、先从一个跑通了，却不容易交接的算例开始

我第一次认真考虑仿真自动化，不是因为 STAR-CCM+ 不能完成汽车外流场计算，而是因为一次计算完成之后，仍然有太多事情需要人工重新确认。几何有没有正确导入，区域和边界有没有按约定命名，入口速度是否被正确写入，网格是不是按预期生成，求解究竟停在了哪一步，结果文件是否真的导出，这些问题往往比点下“运行”更耗时间。

在整理这套汽车算例时，我看到了一条很适合被重新组织的工作链。目录里有汽车几何 car.x_t，有 STAR-CCM+ 的自动化配置，有 BuildRunExport.java，有运行日志、progress.json、result-check.json，也有最终导出的压力图、速度图和 reports.csv。它们原本是分散的文件，放在一起之后，我开始把它们看成一次仿真的完整记录。

我给自己定下的目标很具体：STAR-CCM+ 继续负责物理模型、网格和数值求解，Codex 负责把任务读懂，把工程动作按顺序组织起来，把运行状态写出来，把结果文件收齐，再把仍然需要工程师判断的地方明确标出来。我想要的不是让 AI 猜一个流场，而是让它帮助我把已经知道的流程稳定地执行一遍。

图 1  汽车与外流场计算域

二、先把容易被忽略的约定写进配置

我没有从一段很长的自然语言提示开始，而是先整理 simulation-task.yaml。它像一份给智能体和仿真软件共同使用的任务单，记录了 CAD 路径、输出目录、STAR-CCM+ 运行环境、区域名称和边界名称。汽车区域叫 CAR，入口叫 INLET，出口叫 OUTLET，车身、地面和车轮相关边界分别写在 BODY、DOWN、WHEEL HEAD、WHEEL TAIL 中，SIDE、SYMMETRY、UP 则作为对称边界保存下来。

这样写的好处是，Codex 不需要根据截图猜哪一面是入口，也不需要根据默认名称猜 STAR-CCM+ 里哪个对象可以继续使用。宏在读取这些名称时，如果找不到区域或边界，就会在对应阶段报错。错误会停在一个可以定位的位置，而不是等到最后只留下一张看不出原因的空白云图。

同一份配置还记录了这次运行的工况和出口规则：入口速度是 33.33 m/s，出口静压是 0 Pa，最大步数是 300，每 10 步更新一次运行状态，结果需要保存 sim 文件、报告 CSV 以及压力和速度场图片。对我而言，这一步的意义不在于把参数集中到一个文件里，而在于把“这一次到底要做什么”从聊天语句变成了机器和人都能检查的约定。

图 2  BuildRunExport.java 的执行入口

三、让 Macro 负责执行，也让它留下过程痕迹

BuildRunExport.java 是这条链路里最接近 STAR-CCM+ 的一层。它先读取任务属性，创建输出目录和日志目录，然后写下 starting 状态。接着导入 car.x_t，根据几何部件创建 CAR 区域，再按配置中的名称寻找 INLET、OUTLET、BODY、DOWN、WHEEL HEAD、WHEEL TAIL、SIDE、SYMMETRY 和 UP，并分别设置入口、压力出口、壁面和对称边界。

我特意保留了按名称查找和分阶段写状态的做法。自动化不是把所有点击压缩成一段不可读的代码，而是让每一步都能说明自己正在做什么。只要日志里出现 boundaries completed，我就知道边界设置已经完成；如果状态停在 mesh 或 physics，我就不必从头猜测失败发生在哪里。

  物理设置也由配置驱动。当前这条基线是稳态、三维、单组分气体路线。由于任务模型包含 ideal gas，宏实际启用了 Coupled Flow、Ideal Gas 和 Coupled Energy，同时加入 RANS 湍流、k-epsilon、Rke Two-Layer 以及 All y+ 壁面处理。它是为了让流程先稳定跑通而选的自动化基线，不代表所有汽车外流场工况都应该使用同一套模型。模型的适用性，仍然要由我结合速度、温度、马赫数、近壁分辨率和验证数据来判断。

图 3  按名称读取边界并设置类型

图 4  自动网格流程

四、把长时间求解变成一条可以跟踪的状态流

过去我启动一次求解后，常常要等一段时间再回到 STAR-CCM+ 窗口确认它到底有没有继续运行。为了摆脱这种等待，我让宏先清理旧解、初始化新解，再用分段 step 的方式推进。当前设置是总共 300 步，每 10 步写一次 progress.json。文件里不只记录完成了多少步，还记录当前阶段、状态、进度比例和最新消息。

这件事看起来不像网格或物理模型那样“硬核”，却直接改变了我和 Codex 的协作方式。Codex 可以先读取 progress.json，再决定是继续等待、检查日志，还是进入结果检查。它不必用一个进程是否存在来推测仿真状态，我也不必把屏幕截图当成唯一证据。图 5 展示的就是这条状态更新路径，仿真从一个不可见的后台任务，变成了可以被读取和解释的过程。

图 5  运行状态更新示意

这次运行最后在 progress.json 中留下了 completed、300/300 和 All outputs were exported。这个结果说明流程走完了，但我没有把“走完 300 步”直接等同于“所有工程问题都已解决”。它只说明自动化执行到了预定终点，接下来还要看输出文件和定量报告。

五、没有把一张云图当成仿真结论

求解结束后，我让 Codex 继续读取 result-check.json、reports.csv、starccm.log、automation.log，以及压力和速度场图片。result-check.json 给出的状态是 complete，car.sim、两类日志、progress.json、reports.csv、pressure.png 和 velocity.png 都存在并通过了文件检查，missingOrSmall 为空。对自动化流程来说，这一步很重要，因为“求解器停止”与“结果已经按约定交付”并不是同一件事。

reports.csv 中保存了五项结果。入口平均压力为 32.5899817 Pa，出口平均压力为 0 Pa，入口质量流量为 -620.6363088 kg/s，出口质量流量为 620.6393988 kg/s，按入口和出口报告相减得到的压降为 32.5899817 Pa。result-check.json 同时给出了质量流量绝对不平衡 0.0030900352 kg/s。这个数字可以帮助我做基础守恒核对，也能提醒我检查报告方向和边界选取是否一致。

压力图和速度图则是另一类证据。压力图让我先看车身附近的高低压分布，速度图让我先看车辆后方的尾迹和计算域内的流动组织。看完图之后，我还要回到边界、网格、求解步数和监视器证据上做判断。当前自动化输出没有把阻力、升力、风阻系数或网格无关性研究纳入报告，所以我不会把这些压力和流量数值包装成整车气动性能定型结论。对研发故事来说，能够准确说明已经验证了什么、还没有验证什么，同样是自动化的一部分。

图 6  自动导出的压力场

图 7 速度与压力联合视图

六、最后留下的，不只是一个 sim 文件

回看这次工作，我最满意的变化不是少点了多少次鼠标，而是仿真从一个“做完了就结束”的动作，变成了一条可以交接的研发流程。有人拿到 car.x_t 和任务配置，可以知道输入是什么；有人打开 BuildRunExport.java，可以看懂动作如何进入 STAR-CCM+；有人读取 progress.json，可以知道运行走到哪里；有人查看 result-check.json 和 reports.csv，可以复核结果文件是否齐全、基础守恒是否通过。

在这条分工里，我没有把 Codex 描述成数值求解器。STAR-CCM+ 仍然负责网格、物理模型、边界条件和迭代求解，Codex 负责读取任务、调用 STAR-CCM+ 相关 Skill、维护配置和宏、组织运行、监视状态、检查文件并汇总结果。AI 的价值不是替我做出一个未经确认的工程决定，而是把我已经明确的判断条件和检查顺序执行得更稳定。

这次汽车外流场算例让我更确信，AI 接入仿真的第一步不是追求一句话生成全部模型，而是先建立一条小而完整的闭环：输入有约定，动作有顺序，过程有状态，结果有文件，结论有边界。等这条链路稳定之后，我再把阻力和升力报告、y+ 检查、局部网格对比、移动地面、旋转轮胎和多工况扫描逐项接入。每增加一种能力，我也会同时增加对应的检查规则。这样做出来的自动化，才真正能服务于研发，而不是只留下一个看起来很聪明的演示。

📺 顺便预告一下：9 月10日19时30分，我会在仿真秀主办的“2026研发仿真开学季第四期讲座做 《Codex 驱动 STAR-CCM+ 汽车外流场自动化仿真实战》，会把本文的流程完整演示一遍，从配置文件到宏执行再到结果核验，现场跑给你看。感兴趣的朋友可以先预约：

2026研发仿真开学季是仿真秀面向研发工程师推出的主题活动月，9月1日至10月31日以"从工具到智能——让AI接入仿真研发"为主线，覆盖结构、流体、电磁、多物理场和AI驱动仿真五个方向。仿真秀力邀企业资深研发工程师，围绕LS-DYNA、Workbench、Abaqus、Star-CCM+、HyperWorks、Maxwell、Fluent、CST、Flotherm、SolidWorks、ANSYS等主流软件，演示如何用LLM、Agent、Codex、Claude、DeepSeek等大模型能力打通建模、求解、后处理与优化全流程，让仿真从"手工操作"升级为"AI驱动"；

此外仿真秀精选100余门研发仿真精品视频课限时秒杀1元起售，并叠加专属券，秒杀课程覆盖从基础到前沿的完整学习路径；活动期间，仿真秀还发起案例征集，以"我的研发仿真故事——从工具到智能的进阶之路"为题，面向工程师征集攻坚实录、工具进化、AI接入、成长与团队四类真实故事，图文或视频，通过即获“满意现金稿酬和百人千万"内容扶持计划，优秀作品还将在仿真秀APP、官网、公 众号、视频号四端专题展示并邀请连麦直播。整个主题月既是一场系统化的技术充电，也是工程师用AI重塑研发工作流的一次集中练兵。