基于大语言模型辅助的 SimLab 热流道网格压印自动化开发实践

实 践 对 象　模流分析软件 SimLab 热流道区域网格压印自动化

开 发 工 具　TRAE 编程智能体（承担代码实现）

完 成 时 间　2026 年 10 月 16 日起，历时 2 天

关 键 词　大语言模型；软件二次开发；模流分析；网格压印；自动化

归 档 记 录　原始记录 19 页演示文稿（含操作录屏）

摘要与关键词 1

Abstract 1

1 引言 1

2 问题描述与自动化对象评估 1

2.1 目标操作的形式化描述 1

2.2 自动化对象的筛选准则 1

2.3 预期收益 1

3 开发方法 1

3.1 三个阶段的总体设计 1

3.2 阶段一：录制脚本的自主改造 1

3.3 阶段二：通用对话式 AI 工具的代码生成 1

3.4 阶段三：以录制脚本为输入基线的迭代开发 1

3.5 零代码迭代流程 1

4 结果 1

4.1 交付成果的量化指标 1

4.2 脚本执行链路 1

4.3 需求迭代过程 1

4.4 最终形态与成果分发 1

5 讨论 1

5.1 两次失败的共性归因 1

5.2 输入基线的决定性作用 1

5.3 工程人员能力要求的重新定位 1

5.4 方法论提炼 1

5.5 局限性 1

6 结论 1

参考文献 1

附录 A 试验记录摘要 1

摘要

模流分析前处理中的网格局部加密操作长期依赖人工完成，存在重复度高、效率低、难以标准化的问题。本文以热流道区域网格压印这一典型场景为对象，报告了一次由工程技术人员主导、利用大语言模型（Large Language Model, LLM）辅助完成的软件二次开发实践。

实践经历了三个阶段：早期基于录制脚本的自主改造尝试、以通用对话式 AI 工具直接生成代码的尝试，以及引入专用编程智能体后以录制脚本为输入的迭代式开发。分析表明，前两次失败的共同原因在于缺乏对生成结果的验收能力，而非生成能力本身不足；第三次成功的关键在于以真实录制的操作脚本作为输入基线，使需求的表达从抽象描述转为可验证的参照。最终交付的脚本共 924 行，人工编写代码为 0 行，从工具安装到稳定运行历时 2 天，自动化后单次操作仅需 3 次人工点选。本文进一步提出三条可复用的方法论原则，用于指导工程领域内类似自动化任务的选题评估、输入准备与能力要求设定。

关键词：大语言模型；软件二次开发；模流分析；网格压印；自动化；零代码

Abstract

Mesh refinement operations in mold-flow pre-processing have long been performed manually, characterized by high repetitiveness, low efficiency, and poor standardization. This paper reports a software secondary-development practice led by an engineer and assisted by a Large Language Model (LLM), targeting the circular-mesh imprinting operation in hot-runner regions.

The practice comprised three stages: an early attempt at self-modifying a recorded script, an attempt to generate code directly through general-purpose conversational AI tools, and an iterative development approach using a dedicated coding agent with the recorded script as the input baseline.

Analysis shows that the two earlier failures shared a common cause — the absence of capability to validate generated output, rather than insufficient generation capability — whereas the third attempt succeeded because using a genuinely recorded operation script as input transformed requirement description from abstract instruction into verifiable reference.

The delivered script comprises 924 lines with zero lines hand-written, achieved in 2 days from tool installation to stable operation, and reduces the automated operation to 3 manual selections. Three reusable methodological principles are proposed for task selection, input preparation, and competency requirement definition in similar automation efforts within engineering domains.

Key words: Large Language Model; secondary development; mold-flow analysis; mesh imprinting; automation; zero-code

1 引言

模流分析（mold-flow analysis）的前处理阶段需要对浇注系统周边区域进行网格局部加密，以保证热流道附近的温度场与压力场具备足够的计算精度。在本文所用软件环境中，该操作通过“圆圈压印”功能实现：先在模型上选取热流道所在的面，再于该面上绘制圆形范围并执行压印，最后设定加密区域的网格尺寸。整个过程不包含任何工程判断，其操作序列在每一次执行中完全一致。

然而，该操作具备两个使其难以依靠人工消化的特征：一是单次操作耗时 1～3 min，一个项目往往包含多个热流道位置，累计耗时随位置数量线性增长；二是操作步骤分散在软件的多个功能入口，使用者需要反复在菜单与工具栏之间切换。上述特征使得该任务成为软件二次开发中优先级较高的自动化对象。

在通用意义上的“以脚本替代人工”讨论之外，本文关注一个更具体的问题：非编程背景的工程技术人员，在大语言模型辅助下完成此类二次开发时，其成败的决定因素是什么。围绕这一问题，本文完整记录了一次实践的三个阶段，分析两次失败与一次成功的共性与差异，并据此提炼可迁移的方法论。

本文的工作范围限定于单一商业模流软件的一个具体功能点，属工程实践报告而非受控对比实验。文中全部量化数据来自作者本人的测试记录，原始记录以演示文稿形式归档。

2 问题描述与自动化对象评估

本节对目标操作作形式化描述，并在此基础上给出自动化对象的筛选准则与预期收益模型。

2.1 目标操作的形式化描述

将单个热流道位置的网格压印过程表示为固定序列 S = ⟨s1, s2, s3, s4⟩：

• s1（选面）：在模型上选中热流道所在的面；

• s2（画圆）：按预设规则手动绘制圆圈范围；

• s3（压印）：调用圆圈压印功能生成加密区域；

• s4（设定尺寸）：输入加密区域网格尺寸并确认。

该序列具备三个性质：操作对象与操作顺序在项目之间不变；同一功能入口在不同项目中均可复用；执行过程中不含任何需要工程判断的决策环节。

2.2 自动化对象的筛选准则

基于上述性质，本文在启动开发前采用如下准则评估候选操作是否值得自动化：

判据：同一操作能否连续重复十次而无需任何决策。

该判据同时排除了两类不适合自动化的任务——规则不固定导致每次都需要重新判断的任务，以及单次执行耗时极短以致自动化收益不足以覆盖开发成本的任务。圆圈压印在两个维度上均满足要求，因而被确定为本次实践的目标对象。

2.3 预期收益

按项目典型热流道位置数量估算，原手工模式的总耗时为 Tmanual = n · t，其中 n 为位置数、t 为单次操作耗时（1～3 min）。自动化后预期总耗时为 Tauto = tsetup + k · tsel，其中 tsetup 为脚本启动开销，k 为单次运行所需的人工交互次数。这一预期在第 4 节的实测结果中得到验证。

3 开发方法

本次实践跨越三个阶段。各阶段在输入形态、人机分工与失败模式上存在系统性差异，构成了本文分析的核心对象。

3.1 三个阶段的总体设计

三个阶段的时间、工具形态、输入形态、人机分工与结果对照如表 1 所示。

表 1　三个阶段的总体设计与结果对照

阶段	时间	工具形态	输入形态	人机分工	结果
阶段一	早期	软件自带录制功能	录制脚本	人读懂并改写代码	失败
阶段二	2025 年	通用对话式 AI 工具	自然语言描述	人验收 AI 输出	失败
阶段三	2026 年 10 月 16 日起	专用编程智能体	录制脚本 + 自然语言	人描述需求与验收，AI 改写	成功

3.2 阶段一：录制脚本的自主改造

第一阶段的想法是利用软件自带的功能录制一段完整的压印操作，将得到的脚本改写为参数化工具。录制本身是成功的，所得脚本结构完整、可以执行。

改造的难点出现在将脚本重构为可复用工具的过程中。该重构要求使用者理解 Python 的类组织方式、异常处理机制与模块导入规则。测试者不具备相应的编程基础，数次尝试后放弃该路径，回归手工操作。

阶段结论：路径本身可行，失败原因在于不具备阅读与修改代码的能力，而非路径设计有误。

3.3 阶段二：通用对话式 AI 工具的代码生成

第二阶段转向通用对话式 AI 工具（如 DeepSeek、豆包），以自然语言描述需求，试图直接生成可运行的压印脚本。

该路径的失败模式与第一阶段不同：AI 能够输出代码，但输出结果的错误率较高，反复重试后仍难以直接运行。更关键的是，使用者无法判断输出结果的正确性——一旦报错，只能从头重来。

阶段结论：AI 具备生成代码的能力，但缺乏验收能力时，该能力无法转化为可用成果。

3.4 阶段三：以录制脚本为输入基线的迭代开发

第三阶段于 2026 年 10 月 16 日启动。方法上未做根本改变，仍是“描述需求、由 AI 改写”，但调整了三项关键设定。

设定一：以录制脚本为输入基线。 测试者先完成一次真实的压印操作并录制，将录制所得脚本连同自然语言描述一并提交给编程智能体。这一调整使需求表达从抽象描述转变为可验证的参照：AI 无需推测操作序列，测试者也无需在描述中穷举每一个界面细节。

设定二：放弃直接改写代码的尝试。 全程未打开代码编辑器，代码的编写与调试交由 AI 完成。测试者的职责收缩为问题描述与结果验收。

设定三：确保结果可当场验证。 压印后的网格形态是否符合预期、应选取何种类型的节点作为压印圆心，这些判断依赖模流分析领域的既有经验，可在运行后立即完成。判断依据因此完全来自使用者自身。

在此设定下，测试者于两天内完成全部工作，全程未人工修改一行代码。第二次尝试即基本可用。

3.5 零代码迭代流程

阶段三采用的迭代流程由五个环节构成，构成一轮；未跑通则重复第三、四环节，直至无需人工补位。

1. 录制操作脚本：录制一段真实的手工压印全过程，作为 AI 的输入基线；

2. 提交给 AI：将脚本与自然语言描述一并提交，说明改造目标；

3. 测试运行：实际执行脚本，暴露报错、选不中、顺序错误等问题；

4. 提示修正：以日常语言描述问题，由 AI 自行定位并修正；

5. 重复至成功：重复第三、四环节，直至无需人工介入。

第四环节是整个流程的关键。该环节对表达精度的要求低于编程要求——例如“完成后压一下圆圈网格”“自适应 Node、直接选节点坐标”等表述均不含代码术语。真正需要使用者投入的是把问题描述得足够具体，使 AI 能够定位到需要修改的位置。

4 结果

本节从交付成果的量化指标、脚本执行链路、需求迭代过程与最终交付形态四个方面，给出本次实践的实测结果。

4.1 交付成果的量化指标

表 2　交付成果的量化指标

指标	数值	说明
脚本总行数	924 行	从录制片段演化为可复用工具
人工手写代码	0 行	开发期间未修改代码
开发周期	2 天	从工具安装到稳定运行
自动化运行的人工交互	3 次点选	整条链路其余环节自动执行
原手工单次操作耗时	1～3 min	选面、画圆、压印、设定尺寸

以项目含 5 个热流道位置为例，原手工模式总耗时为 5～15 min，自动化后为一次脚本运行加 3 次点选，量级差异明显。

4.2 脚本执行链路

最终脚本的执行链路包含六个环节，其中仅三个需要人工交互。

表 3　脚本执行链路与交互方式

步骤	动作	交互方式
01	运行脚本	人工点选
02	弹窗提示选择面	人工点选
03	弹窗提示选择节点	人工点选
04	自动压印圆圈网格	自动执行
05	弹窗提示重划分网格尺寸	人工点选
06	网格重划分结束	自动执行

第三步的节点选择支持两类输入：手动创建的孤立节点（分析前单独建点，用于定位压印圆心）与模型上已存在的网格节点（直接选取现成坐标）。脚本通过官方 API 自动判定节点类型，操作者按提示点选即可。

实现上遵循两项原则：其一，仅在需要工程判断的环节引入弹窗交互，其余环节全部自动执行；其二，每一步输出日志，可在软件窗口中查看执行进度，API 调用失败时回退 tkinter 界面，不中断主流程。

4.3 需求迭代过程

功能并非一次成型。开发过程中共完成四轮需求迭代，每轮均在实际运行验证通过后才提出下一轮。

表 4　需求迭代过程与验证结果

版本	目标	需求内容	验证结果
V1	能跑	将“网格节点”与“孤立节点”各写一份独立脚本	两个脚本分别运行均正常，先确认可执行性
V2	一次判断	合并为一份脚本，中间由人工确认节点类型	合并后运行正常；统一调用入口，以一次人工确认换取可维护性
V3	零判断	不再人工确认，由脚本自动判定节点类型	自动识别后运行正常，操作者无需理解类型判定逻辑
V4	零门槛	封装为软件菜单项与工具栏按钮	无需查找脚本文件、无需记忆参数，可直接投入使用

该迭代序列呈现出清晰的递进逻辑：从“可执行”到“少交互”再到“无需理解内部逻辑”，每一轮的改造目标均由上一轮的实际运行结果引出。需求由使用者拆分并描述，代码由 AI 修改，每轮以实际运行结果作为验收依据。

4.4 最终形态与成果分发

最终交付形态为软件内置功能：菜单栏新增“SimLab 二次开发工具集”作为统一入口，工具栏新增“热进浇点”按钮实现一键直达。使用者无需知道脚本的存在，即可完成调用。

在此基础上，成果进一步被打包为单个安装程序（EXE）。二次开发功能与其依赖脚本一并封装，接收方双击安装程序即按提示完成安装，无需配置 Python 环境或依赖库；在未安装过该功能的计算机上，双击 EXE 即可完成装入并直接调用。

该步骤的意义在于将成果的适用范围从“作者本地可用”扩展为“他人可用”。自动化工具的价值往往在其交付分发时才充分兑现——因为工具的真正成本不在于开发，而在于使用者的接入门槛。

5 讨论

本节对三个阶段的结果作归因分析，说明输入基线与能力要求各自的作用，并据此提炼可迁移的方法论原则与适用边界。

5.1 两次失败的共性归因

阶段一与阶段二的失败原因表面上不同：前者需要理解代码而测试者不具备该能力，后者能够获得代码却无法判断其对错。合并考察后可归并为同一判断：两次失败均发生在“验收能力缺失”这一环节，而非“生成能力不足”这一环节。

阶段一中，脚本由测试者自行录制并改造，问题出在改造所需的编程能力；阶段二中，代码由 AI 生成，问题出在判断结果正确性的能力。两次尝试都要求测试者同时承担“实现”与“验证”两项超出其能力范围的任务。而在阶段三中，实现任务被完整地移交给 AI，测试者仅保留验证任务——而验证恰好是领域经验可以直接支撑的部分。

这一解释与阶段三的实测结果一致：同一使用者、同一操作对象、同一软件环境，仅调整人机分工方式即改变了结果。

5.2 输入基线的决定性作用

阶段三相对前两次的另一个关键差异在于输入形态。阶段二以自然语言为唯一输入，AI 须依靠推测重建操作序列，任何对界面细节的误判都会导致生成结果不可用；阶段三以真实录制的脚本为输入基线，AI 面对的是已验证可执行的参照物，需求表达则退化为对该参照物的改造说明。

这一差异可推广表述为：当工程操作本身可以被录制时，录制结果比语言描述更精确、更廉价、也更易于验收。语言描述需要使用者具备将隐性经验显性化的能力，而录制则直接捕获了已发生的操作。

5.3 工程人员能力要求的重新定位

本文实践所依赖的核心能力并非编程能力，而是结果判断能力。具体而言，包括：判断应选取何种类型的节点作为压印圆心、判断压印后生成的网格形态是否符合预期、判断脚本的自动化边界是否合理。

这些判断无法由 AI 替代，因为它们依赖对模流分析对象与数值计算结果的领域理解。AI 在本次实践中承担的是代码实现工作，而全部工程决策仍由人完成。

由此可以提出一个关于效率来源的判断：本次实践获得的效率提升，其来源是需求描述与持续反馈，而非编程能力本身。该路径不要求编码能力，但要求能够判断输出是否符合预期。

5.4 方法论提炼

综合三个阶段的经验，可提炼出三条可复用的原则。

原则一：优先选择规则明确、重复度高的操作。 判断标准为同一操作能否连续重复十次而无需决策。本例的圆圈压印满足该条件。

原则二：以录制的真实操作为起点。 前两次失败与第三次成功的差别主要在此。口头描述需求只能由 AI 推测；以录制脚本为输入，起点明确，首次尝试即接近可用。

原则三：结果判断能力比编码能力更关键。 起作用的是领域经验形成的判断力。代码由 AI 编写，判断仍由人完成。

5.5 局限性

本文报告的是单一软件、单一功能点上的个人实践，存在以下局限：其一，样本量为 1，所得结论的普适性有待更多案例检验，尤其缺少与专业开发者路径的对照数据；其二，各项耗时数据为作者自行记录，未采用仪器化计时；其三，脚本在作者所用环境与版本下验证，其他版本或环境下的适用性未作考察；其四，本文不涉及代码质量的工程评价维度，924 行的规模是否适合长期维护尚无判断依据。

6 结论

本文报告了一次非编程背景工程技术人员主导、由大语言模型辅助完成的模流分析软件二次开发实践。实践历时 2 天，交付脚本 924 行，人工编写代码 0 行，自动化后单次操作仅需 3 次人工点选。

实践表明，此类任务的成败决定因素并非 AI 的代码生成能力，而是两项被分离出来的工作：能否为 AI 提供可验证的输入基线，以及能否对输出结果作出专业判断。据此，本文提出以录制操作为输入基线、以结果判断能力为核心要求的开发范式，并给出用于筛选自动化对象、准备输入与设定能力要求的三条原则。

对工程领域而言，这一实践的意义不在于“AI 可以写代码”，而在于它重新划定了工程人员与技术实现的分工边界：AI 承担实现，工程师承担判断。对模具与模流这类领域经验密集、规则相对固定的工作，该分工具有现实可行性。

参考文献

1. Python Software Foundation. Python documentation: tkinter — GUI programming[EB/OL].

2. SimLab. SimLab 官方帮助文档：网格操作与脚本接口说明[EB/OL].

3. TRAE. TRAE 编程智能体产品文档[EB/OL].

4. 中华人民共和国国家质量监督检验检疫总局, 中国国家标准化管理委员会. 信息与文献 参考文献著录规则: GB/T 7714—2015[S]. 北京: 中国标准出版社, 2015.

附录 A 试验记录摘要

本附录汇总正文引用的实测数据，原始记录以演示文稿形式归档，共 19 页，含操作录屏。

表 A.1　试验记录摘要

记录项	数据
开发工具	TRAE 编程智能体
起始日期	2026 年 10 月 16 日
结束状态	2 天跑通，脚本稳定运行
脚本规模	924 行
人工手写	0 行
原手工单次耗时	1～3 min / 位置
自动化后人工交互	3 次点选 / 次运行
迭代轮次	4 轮（V1 至 V4）
失败路径	2 次（录制脚本自主改造、通用对话式 AI 直接生成）
交付形态	菜单项 + 工具栏按钮 + 单文件 EXE 安装包