凌晨一点登录节点的风扇声比白天安静得多。我盯着终端里那条报错CST的VBA宏在第七次试运行后又因为端口定义问题崩掉了。说实话这种场景对做电磁仿真的人来说太熟悉了——GUI里点两下能完成的事到了超算上就变成一长串脚本而脚本里的每个空格、每个编号都可能让你在深夜崩溃。随手把报错信息丢给ChatGPT几分钟后它给了我一份改好的脚本。这个瞬间让我突然意识到自然语言和电磁仿真之间可能真的可以打通一条路让“ChatGPT dot”这种命令行智能体直接在超算环境里干活。这篇文章记录的就是这次实践的完整过程包括怎么装、怎么配、怎么把一个仿真需求从一句话变成可提交的作业以及踩过的各种坑。先说明一下标题里的dot不是某个模型代号而是社区里对这种终端智能体工作流的叫法。你在命令行敲下codex命令本质上就是“点”了一下ChatGPT让它进入你的工程目录帮你读代码、改脚本、跑命令。配合电磁仿真的批处理脚本这个组合在超算上能省下大量重复劳动。如果你也在做计算电磁学或者对AI辅助CAE仿真感兴趣这篇内容应该能帮你少走不少弯路。1. 为什么要把电磁仿真交给自然语言1.1 电磁仿真在超算上的真实困境先说痛点。以CST Studio Suite为例这东西在本地工作站上有完整GUI你可以用鼠标拖一个波端口点两下设置边界条件再选个求解器。但超算节点上根本没有图形界面所有操作都得走脚本化批处理路线。CST的传统宏语言是VBA历史包袱很重后来出了Python API虽然现代一些但文档量依然庞大而且仿真项目里的专业概念——边界条件、网格策略、求解器容差、端口类型——全都映射到一段段代码里。我经常遇到的情况是几何模型建好了材料参数也对但脚本里某个边界设置写错仿真跑完一看S11曲线完全不对。回到脚本里排查花的时间比仿真本身还长。有一次为了改一个微带天线的馈电端口我在CST的VBA文档里翻了整整一个晚上。后来我才意识到这类问题本质上是“工程意图”和“代码表达”之间的翻译成本太高而这恰恰是大语言模型最擅长解决的事。1.2 自然语言交互带来的范式变化ChatGPT这类模型给电磁仿真带来的变化不是“自动跑仿真”而是把“查文档—写样板代码—改报错”这个循环压缩成对话。你告诉它你的天线类型、工作频率、基板材料它直接生成一段可运行的建模脚本脚本报错了把报错贴回去它定位问题并给出修正。这个流程在本地工作站上可能只是省点时间但在超算上意义更大——因为超算上的脚本作业一旦提交就是几个小时甚至几十个小时的队列等待脚本写错一次代价极高。所以自然语言交互的价值首先是提前消错。生成的脚本在提交之前就能通过一轮轮对话把参数、边界、端口定义全部确认清楚。其次是经验沉淀你跟AI对话时描述的那些约束条件、设计考虑本身就是一份结构化文档留档下来就是团队知识库。当然边界也很明确AI不保证物理正确性它给出的S参数初值计算、网格设置建议最终还是要靠工程师的判断来兜底。2. 超算环境里的codex落地记2.1 安装和登录比想象中更简单我用的工具是OpenAI的Codex CLInpm包名是openai/codex它和ChatGPT账号可以直接打通。超算环境里安装时要注意一点登录节点通常能访问公网但计算节点往往处于隔离网络所以安装和交互操作都在登录节点完成生成好的脚本再交给调度系统提交到计算节点。命令很简单npm install -g openai/codex codex login登录过程会让你在浏览器里打开一个授权页用ChatGPT账号确认授权就行。登录节点上如果只有命令行终端codex会输出一个设备码你在本地浏览器里输入这个码也能完成授权。整个过程比我想象的顺利没有遇到什么坑。装好之后有两种用法一种是交互式会话直接敲codex进入对话界面另一种是一次性任务用codex exec 你的需求直接生成结果。我在超算上更喜欢后者因为它可以配合tmux在后台跑也不会因为SSH断连导致会话卡死。2.2 拯救config.toml一场修复实录真正麻烦的是配置文件。codex的配置默认放在~/.codex/config.toml第一次启动如果文件有问题直接报“无法加载config.toml本次对话无法继续”。我第一次碰到时一点头绪都没有后来排查发现是model字段写了一个当前账号不支持的模型名就是网上很多人遇到的那条报错gpt-6.1-sol model is not supported when using codex with a chatgpt acc。这个报错的信息很明确你登录的是ChatGPT账号不是API账号所以codex默认用的那个模型在你的账号环境下不可用。解决办法是改config.toml把model换成账号实际支持的codex模型同时确认model_provider对应的是chatgpt而不是openai。我修复后的一个可用配置结构大致长这样# ~/.codex/config.toml model gpt-5.2-codex model_provider chatgpt temperature 0 [experimental] auto_execute false这里有几个细节值得讲一下。第一model_provider这个字段一定要跟你的登录方式匹配ChatGPT账号登录就写chatgpt如果你用API key就写openai写反了会出现鉴权类报错。第二我把temperature设成0是希望codex在生成脚本时尽量保持确定性和可复现性仿真脚本里任何一点随机性都可能导致结果波动。第三auto_execute我建议设成false后面细说原因。修复config.toml之后再启动codex就正常了。如果你是自己改坏了文件不确定键名怎么写可以用codex --help看看有没有恢复默认配置的命令或者直接把那个文件挪走让它重新生成一个。3. 一句话到仿真脚本完整拆解一次真实任务3.1 一个真实请求的全过程纸上谈兵没有意义直接上真实任务。我这次要做的是一个工作在2.45GHz的微带贴片天线基板用FR4介电常数4.4厚度1.6mm目标是在2.4到2.5GHz频段看到明显的S11谐振。按照传统流程我得在CST里手动建模或者写VBA脚本但这次我打算完全依赖codex。我的输入是这样一句话“用CST Python API建一个2.45GHz微带贴片天线的仿真脚本FR4基板介电常数4.4厚度1.6mm微带线馈电计算S11频率范围2.3到2.6GHz网格用自适应四面体。”codex的输出是一段两百多行的Python脚本整体结构是对的导入cst库、新建工程、定义基板材料、画地平面和贴片、设置频率范围、加波端口、跑离散化求解。但我检查之后发现两个问题。第一它把默认的边界条件设成了periodic这对贴片天线来说完全错误应该用open加space的辐射边界。第二它给的贴片尺寸是随手估计的没有按微带贴片天线的经典公式算。我直接在对话里回复把边界改成open贴片宽度和长度用公式计算。它几秒后就给出了修正版并且在代码里保留了公式推导过程。这里顺便说一下微带贴片的初步尺寸计算因为这是判断AI输出是否正确的基本功。贴片宽度W的经验公式是W c / (2f) × sqrt(2 / (εr 1))代入c3e8f2.45e9εr4.4可以算出W大约37.3mm。长度L要先算有效介电常数εeff和延伸量ΔL公式比宽度复杂一些算下来大概是28.8mm。这个数值和codex修正后的输出基本一致说明它的公式应用是对的。我把这几行算式放在这里是想强调一件事AI生成的数值你必须自己会验算否则它就算把公式写成天玛行空你也看不出来。3.2 让代码跑在超算上的配合操作脚本生成后还要交给超算调度系统。我们的集群用的是Slurm所以我让codex顺手帮我写了对应的作业提交脚本。这个确实省事几分钟就出来了#!/bin/bash #SBATCH --job-namepatch_s11 #SBATCH --nodes1 #SBATCH --ntasks-per-node8 #SBATCH --time02:00:00 module load CST_Suite cst -m macro -e patch_2450.py实际提交前我改了两个地方一是--time从默认的一小时改成了两小时因为自适应网格在2.4GHz这个频率下收敛可能需要一点时间二是加上了module load CST_Suite因为超算上软件环境都是通过环境模块加载的没有这一行提交后就会在计算节点上报找不到命令。codex当然不知道你们集群的模块名和队列策略但这些它生成后你顺手改一下就行比自己从零写还是快得多。整个任务从对话开始到脚本可以提交大概花了20分钟。前10分钟在确认天线参数和边界条件后10分钟在微调作业脚本。如果纯手写光查CST Python API里renormalize1 ...这类端口参数就要花掉同样多的时间。4. 实操中踩过的坑与排查实录4.1 会话、额度与连接问题用得越久越发现这事儿没有想象中那么丝滑。第一个遇到的是额度问题。用ChatGPT账号对接codex不是无限畅聊的有一个滚动时间窗口的限制网上常说的“5小时额度”就是指这个——连续高强度对话到一定量后codex会提示额度用尽让你等窗口刷新。我在做参数扫描方案时刚好赶上额度窗口刷新对话停在半路非常难受。后来我改变策略不在codex里连续聊非常多轮而是先在本地把一个完整的prompt想清楚一次性丢给它让它集中完成一个阶段的目标然后立刻退出会话把结果落地到文件。这样既省额度也逼着自己把需求想明白。第二个坑是端口或服务冲突。有几次codex突然报类似“无法启用远程控制请确保仅有一个ChatGPT实例在运行”的错误排查后发现是登录节点上有之前残留的codex进程没退干净两个实例抢占了同一套本地控制通道。这个在超算上很常见大家一起用登录节点tmux挂了很多会话很容易留下僵尸进程。解决方式就是找到并清理残留进程只保留一个codex实例。还有一次遇到10013这类网络绑定相关的报错是在Windows本地工作站上跑codex时发生的要么是端口被其他程序占了要么是权限设置问题把占用端口的进程关掉或者用管理员权限启动就能解决。第三个坑是SSH断连导致会话中断。超算上你不可能一直挂在前台SSH一断交互式会话就没了。后来我学乖了所有codex交互都放进tmux里跑断连了重新登录再tmux attach就能恢复现场这个习惯比什么都管用。4.2 模型能力边界能改代码不等于能完成仿真任务还有一件值得单独说的事就是模型能力边界。我后来也试过把模型切换成一些侧重代码编辑的模型比如社区里讨论很多的deepseek-v4-flash。在“帮我改一下这段脚本里的端口设置”这种单步代码调整任务上它表现非常稳定甚至有时候比默认模型还利索。但只要任务变成多阶段流程比如“从几何建模开始自动设置求解器跑完仿真再根据结果自动优化网格”它就明显跟不上——上下文一长会忘记前面的约束或者在某一步突然做了一件完全偏离需求的事。这正是我前面把auto_execute设成false的原因。很多AI coding工具宣传的“全自动执行”模式在超算场景下风险太大它可能会去执行你没仔细看过的命令可能在一个不能动的目录里乱改文件。我的经验是让AI负责生成脚本和修改代码但所有命令执行、作业提交、结果判读这些关键动作一律由人来确认。你可以把它当成一个非常聪明的实习生它能帮你写报告但签名必须你自己来。下面把这几类常见问题整理成一个速查表方便大家直接对照现象常见原因处理办法无法加载config.toml模型名或provider配置错误检查model字段和model_provider字段改回当前账号支持的模型模型不支持报错账号类型和配置模型不匹配确认登录方式选择账号对应的codex模型5小时额度提示连续对话触发了时间窗口限制任务分阶段执行减少无效轮次重要对话先写好prompt仅允许一个实例运行残留进程抢占本地控制通道清理旧codex进程只保留一个实例SSH断连会话丢失交互进程依附于登录会话使用tmux或screen挂载交互进程长流程任务偏离方向模型上下文或任务规划能力不足拆分任务每个阶段人工确认后再继续5. 效率对比、心得与后续扩展5.1 与传统方式对比用了一段时间之后我整理了一份对比数据不算严谨的测试但基本能反映真实效率。以这次微带天线S11仿真为例环节传统手动方式自然语言codex方式建模脚本编写约60分钟大量查文档约10分钟对话生成边界条件和端口设置约30分钟依赖经验约5分钟对话修正作业脚本和提交约15分钟受集群配置影响约5分钟生成后人工微调排错和迭代不确定可能数小时报错回贴通常10分钟内给出方向总体下来单次任务的脚本准备时间大概能压缩一半以上而且排错效率的提升是最明显的。我不需要再对着CST文档逐条查API只要能把报错信息和代码片段解释清楚codex基本能定位到问题。但这不意味着它可以替你完成所有事情。物理概念、仿真结果是否合理、网格收敛性判断这些都是AI给不了的。5.2 几条可以带走的心得最后分享几条我觉得值得沉淀下来的经验。第一跟codex对话时一定要把工程上下文喂给它包括项目路径、材料库名称、单位制、频率范围、集群模块名。它的输出质量高度依赖于你提供的上下文完整度给的信息越准确生成的脚本离可运行越近。第二把每次成功的对话和脚本沉淀下来。我现在的做法是一个仿真任务跑通后把最终脚本和关键对话记录存到项目里的docs/ai-sessions目录下次做类似天线就基于这些历史再扩展效率又能上一个台阶。第三永远用物理直觉去校验AI的输出。它可能把边界类型写错可能用错单位可能给出一个看起来漂亮但完全不符合实际的网格设置。这种校验不是不信任AI而是工程师的基本职责——工具负责生成人负责判断。如果你也想试试这个工作流我的建议是从一个你已经会写脚本的简单仿真任务开始不要一上来就让AI全自动设计一个复杂阵列天线。先让它帮你写几何建模、参数设置这些样板化的工作你负责检查物理细节一步步积累经验再扩大到更复杂的任务。这个内容后续还能往几个方向扩展比如把团队内部仿真规范做成检索库喂给codex让它生成脚本时自动遵守你们的命名规则和网格标准或者用对话记录自动生成仿真报告把材料参数、边界条件、收敛情况汇总成文档。这些都是同一套思路的延伸。说到底自然语言驱动电磁仿真真正解放的不是计算本身而是那些反复折腾脚本的夜晚。