一条完整的连接链路要让 WorkBuddy 真正驱动 PrePoMax必须打通六个环节服务端开启、令牌生成、客户端配置、配置重新加载、工具枚举以及当前会话验证。任何一个环节停留表面状态都可能造成“配置已经保存但工具无法调用”的假象。整个链路可以概括为启动 PrePoMax → 开启自动化服务 → 生成访问令牌 → 记录服务地址 → 修改 WorkBuddy 的 mcp.json → 禁用并重新启用服务 → 信任服务 → 枚举工具 → 确认目标会话 → 检查模型状态 → 查询真实 API → 初始化单位制与项目文件 → 执行单项操作 → 验证模型与历史这不仅是连接步骤也是一条状态转换链。只完成服务端配置说明地址和令牌存在只重新启用服务说明客户端开始使用新配置只有枚举到工具才说明鉴权通过只有确认活动会话和模型状态才能开始建模。每一步都有自己的成功标准不能合并为“服务已连接”。第一步在 PrePoMax 中开启自动化服务打开 PrePoMax v3.0.0 窗口进入自动化设置。不同版本的菜单路径可能略有差异通常位于Tools → Settings → Automation进入设置后建议勾选Start with the application这样后续每次启动 PrePoMax自动化服务都会随程序打开。如果只进行单次测试也可以在当前会话手动启动服务但从长期使用的角度看手动启动很容易成为下一次连接失败的原因。进入设置页面后首先记录服务地址。常见地址为http://127.0.0.1:8756/mcp具体地址必须以当前 PrePoMax 设置页面显示的信息为准。不要凭经验把端口写成 8080、8000 或其他常见端口也不要因为曾经连接过另一台电脑或另一个版本就直接套用旧地址。接着在访问令牌区域单击右键选择Generate the access token生成后妥善保存令牌。令牌应只保留在本地 WorkBuddy 配置中不应复制到群聊、在线文档、代码仓库或共享项目。它控制的不是普通信息查询而是对当前 PrePoMax 会话的实时操作权限。PrePoMax 的自动化服务不会允许通过命令行任意启动也不会以明文形式把令牌直接展示在普通日志中。首次运行新解压版本时旧令牌可能被清除此时必须重新生成并同步更新 WorkBuddy 配置。只更新软件端而不更新客户端是连接失败的常见原因。第二步检查 WorkBuddy 的现有配置打开 WorkBuddy 的 MCP 配置文件~/.workbuddy/mcp.json检查是否已经存在prepomax服务。常见情况有三种服务不存在需要新增配置服务已经存在但地址、请求头或令牌过时服务已经存在配置也完全一致但客户端尚未重新加载。其中第三种最容易造成误判。用户可能认为配置已经正确却忽略 WorkBuddy 仍在调用旧版本配置。因此不能根据文件内容倒推客户端当前状态而要通过工具列表确认实际结果。如果配置文件中存在其他 MCP 服务修改时应只调整prepomax对象不要破坏现有 JSON 结构。保存前尤其要检查逗号、引号和大括号避免因为一个语法错误导致整个配置文件失效。第三步配置正确的服务地址和鉴权头在mcp.json中添加或修正 PrePoMax 服务配置{mcpServers:{prepomax:{type:http,url:http://127.0.0.1:8756/mcp,headers:{Authorization:Bearer kDftOvNdp36s...}}}}最容易出错的字段是鉴权头。错误写法通常表现为直接写入令牌Authorization:kDftOvNdp36s...正确写法必须保留标准前缀Authorization:Bearer kDftOvNdp36s...如果 WorkBuddy 版本要求显式声明传输格式可以补充接受类型{mcpServers:{prepomax:{type:http,url:http://127.0.0.1:8756/mcp,headers:{Authorization:Bearer kDftOvNdp36s...,Accept:application/json, text/event-stream}}}}这里的令牌只是占位示例必须替换成 PrePoMax 自动化设置页面中生成的实际值。地址、令牌和请求头前缀需要同时正确缺一项都可能导致连接失败。第四步重新加载并信任服务保存配置文件后进入 WorkBuddy 的连接器 → 自定义连接器 → 配置 MCP找到prepomax服务按照以下顺序操作禁用或关闭服务 → 保存 → 重新启用 → 执行信任操作 → 检查工具列表只刷新当前聊天页面通常不能触发重新连接。客户端可能仍然使用旧地址、旧令牌或缺少Bearer前缀的请求头。因此“禁用—启用—信任”不是形式主义而是让新配置真正进入运行中的客户端。如果 WorkBuddy 版本没有type字段而是提供图形化连接设置可以按以下方式填写服务名称prepomax 服务类型HTTP 服务地址http://127.0.0.1:8756/mcp 鉴权方式Bearer Token 访问令牌kDftOvNdp36s...无论使用 JSON 还是图形界面最终都要确认令牌前缀。图形界面如果自动添加Bearer就不要再手工重复如果界面只提供原始请求头则需要自行填写完整内容。第五步枚举工具并识别失败原因连接完成后不要立即要求 WorkBuddy 创建几何或划分网格而应执行三项只读检查调用 get_guide 调用 get_status 调用 list_sessions如果返回操作指南、会话状态和会话列表说明连接已经建立。随后检查 WorkBuddy 工具面板确认能够看到 PrePoMax 提供的 15 个工具类别工具查询与读取get_guide、list_sessions、get_status、describe_api、read_model、read_topology、get_history、get_job执行与修改run_python、eval_expression、run_job、screenshot长任务管理get_call、cancel_call会话控制exit_session这 15 个工具构成了一条从查询到执行的完整链路。读取指南可以获得版本对应的操作规范查询状态可以确认会话是否空闲读取模型与拓扑可以获得当前几何查询 API 可以避免调用不存在的对象执行 Python 可以真正改变模型查询任务状态可以知道求解是否结束截图则可以返回当前视图。它不是一个单纯生成代码的接口而是能够持续观察并控制 PrePoMax 的实时通道。如果工具面板仍然为空应按以下顺序排查确认 PrePoMax 是否正在运行 确认自动化服务是否开启 确认服务地址是否完全一致 确认令牌是否与当前会话匹配 确认 Authorization 是否包含 Bearer 前缀 确认 mcp.json 的 JSON 格式是否有效 确认 WorkBuddy 是否重新加载了服务 确认服务是否已信任并启用 确认本机防火墙或代理没有拦截请求。其中服务开启但缺少Bearer前缀会导致地址可以解析、会话却无法通过鉴权。此时 WorkBuddy 表面上存在连接信息实际却不能枚举工具。鉴权问题与网络中断不同不能仅凭“无法访问”判断还要检查服务返回的具体状态。第六步确认当前会话PrePoMax 的自动化服务可以识别当前实例因此连接成功后必须确认控制目标是否正确。调用list_sessions以后重点检查当前会话是否标记为isThisSession: true同时确认实例版本、进程标识和连接地址。这次会话返回的信息包括会话协议1.0 PrePoMax 版本3.0.0 实例数量1 当前会话isThisSession 为 true 服务地址http://127.0.0.1:8756/mcp当只有一个 PrePoMax 实例时通常不需要切换会话。但如果系统中存在多个实例就必须确认当前操作究竟作用于哪一个窗口。否则即使 API 调用成功用户也可能在错误的模型中寻找结果。第七步检查模型是否具备执行条件连接成功只代表通信链路打通不代表模型已经可以安全修改。get_status在这次会话中返回了以下关键状态isRunningtrue isIdletrue isReadOnlyfalse 当前模型Model-1 fileName空 modelSpaceUndefined unitSystemUndefined 视图模式geometry 当前长调用无这些字段共同构成连接完成后的第一次事实检查。会话正在运行说明服务可用会话空闲说明当前没有任务占用模型可写说明具备修改权限但单位制与模型空间未定义、文件也未保存说明模型仍缺少执行工程操作所需的基础条件。其中最重要的不是错误提示而是unitSystem和modelSpace均为Undefined。自动化 API 中的数字通常不带单位服务也不会自动判断 10 究竟代表 10 毫米、10 米还是 10 英寸。如果在这个状态下直接创建几何或设置材料后续尺寸、弹性模量、密度、载荷和应力都会缺少共同基准。可以通过一张状态表检查完整连接流程。表中每个节点都有自己的验证动作不能仅凭界面提示替代阶段关键动作成功标志常见失败原因服务准备开启自动化服务并生成令牌页面显示服务地址和令牌服务未开启、旧版本重新解压客户端配置修改或新增prepomax服务JSON 格式正确、地址一致端口错误、令牌错误、缺逗号鉴权配置设置Authorization请求头请求头包含Bearer前缀直接写入原始令牌配置加载禁用后重新启用服务客户端读取新配置只刷新聊天页面服务信任在连接器页面信任服务服务处于启用状态仍停留在未信任状态工具连接调用get_guide、get_status和list_sessions返回指南、状态和会话列表鉴权失败、地址不一致会话确认检查isThisSession和版本信息确认控制的是正确窗口存在多个 PrePoMax 实例状态检查读取isIdle、isReadOnly、unitSystem和fileName会话空闲、可写状态和文件边界明确单位制未定义、文件未保存环境查询调用describe_api获得真实 API 结构调用教程中的旧函数名模型执行执行run_python命令历史中增加预期操作参数、单位或对象名称错误结果验证调用read_model、get_history或screenshot模型状态与执行目标一致只检查代码是否运行长任务管理保存callId并调用get_call回收任务结果重复提交相同请求任务中断调用cancel_call停止不再需要的任务把中断当成常规流程流程复用保存连接和验证步骤下次能够按节点定位问题只保存零散代码这张表的意义在于把“连接成功”从一个笼统判断拆解成多个可检查状态。用户不能再笼统地说“MCP 已经配置好”而要明确回答服务是否开启、地址是否正确、令牌是否有效、客户端是否重新加载、工具是否枚举、会话是否匹配、模型是否空闲、单位是否定义、操作是否验证。完整连接流程还可以表示为以下链路开启服务 ↓ 生成并记录令牌 ↓ 确认服务地址 ↓ 配置 mcp.json ↓ 检查 Authorization 前缀 ↓ 禁用并重新启用服务 ↓ 信任并启用 prepomax ↓ 枚举 15 个工具 ↓ 调用 get_guide ↓ 调用 list_sessions ↓ 确认当前会话 ↓ 调用 get_status ↓ 检查空闲、只读和单位制 ↓ 调用 describe_api ↓ 确认真实对象与成员 ↓ 初始化单位和项目文件 ↓ 执行单项操作 ↓ 读取 read_model ↓ 检查 get_history ↓ 进入网格、边界条件和求解流程箭头方向代表依赖关系而不是推荐速度。上游状态没有被确认时下游操作的风险会快速累积。反过来只要状态表中的每个节点都能独立验证即使某个环节失败也能快速定位而不必推翻整个流程。第八步查询真实 API 后再执行代码连接工具并不等于了解 API 结构。最稳健的做法是先调用describe_api确认当前版本真正支持的对象和成员describe_apipmx describe_apipmx.model describe_apipmx.model.steps describe_apipmx.selection这里查询的不只是函数名称还包括当前会话中可调用对象的结构。外部教程、旧版文档或语言模型记忆中的函数名可能与当前 PrePoMax 版本不一致。如果先猜 API再依靠报错反推错误就会进入命令历史并增加撤销成本。通过describe_api查询后再编写候选代码代码执行后使用get_history检查实际记录随后通过read_model验证模型状态。这样形成的不是一次性脚本而是一种带反馈的自动化流程每一次执行都能验证上一次假设。第九步先初始化单位制、模型空间与项目文件在正式建模前应先明确单位制例如毫米、吨、秒、摄氏度体系。常见物理量包括长度单位mm 力单位N 质量单位ton 应力单位MPa 温度单位°C在材料参数方面例如普通钢的参考值可能为弹性模量210000 MPa 泊松比0.3 密度7.85e-9 t/mm³但这些数值只能作为候选参数不能由自动化接口自行假设。真正进入模型前仍应由用户确认材料牌号、工作温度、单位体系和允许误差。同时应把未命名的Model-1保存为具体文件例如D:\PrePoMax\work\beam_test.pmx或者创建一份独立的验证副本。这不仅是备份也是把当前会话中的修改限定在明确边界内。否则一旦连续执行多个动作用户将难以判断模型究竟处于哪个阶段。第十步从规则块开始验证完整建模链建议第一个自动化模型选择规则块例如长度100 mm 宽度20 mm 高度20 mm规则块不是最简单而是最容易验证。它具有明确的尺寸、方向、源面和扫掠路径适合检查单位制、几何创建、面选择、六面体网格、边界条件和结果输出。执行顺序应当是初始化单位制与模型空间 → 创建或保存项目文件 → 创建规则块 → 调用 read_model → 调用 read_topology → 预览目标面 → 确认面、边和顶点 → 创建源面集合 → 执行拉伸、旋转或扫掠网格 → 检查网格状态 → 设置材料 → 设置边界条件 → 设置载荷 → 写出求解文件 → 启动分析任务 → 轮询任务状态 → 截图并检查结果每一步都应单独验证。不要在一个脚本中同时创建几何、划分网格、设置载荷、提交计算和截图。虽然这样看起来自动化程度更高却会把多个不确定因素叠加在一起一旦失败就很难定位原因。第十一步正确处理长任务网格划分、文件导入和复杂计算可能超过单次请求时限。如果返回running callId说明任务正在后台执行不应重复提交相同指令。正确做法是记录callId再通过get_call回收结果读取 callId → 等待合理时间 → 调用 get_call → 检查执行结果 → 必要时继续轮询只有当任务明显卡死、需要立即停止或不再需要结果时才使用cancel_call。该操作可能直接中断正在运行的网格划分器因此属于异常处置不是常规流程节点。相比重复点击长任务状态更值得关注的是幂等性。相同请求提交两次并不等于进度加快而可能造成两个任务同时修改模型、争用资源或生成冲突结果。因此自动化任务必须记录任务标识和状态不能只依赖用户判断“是否已经完成”。第十二步建立连接后的安全边界完成连接以后WorkBuddy 已经不只是聊天助手而是获得了实时控制 PrePoMax 的权限。每次run_python调用都会作用于当前活动模型并进入命令历史。因此执行前应确认三件事目标会话是否正确 当前模型是否空闲 待执行操作是否可逆。涉及几何、网格、材料和载荷的复杂任务应先保存副本。涉及六面体网格、边界条件和分析任务时应先执行只读检查再执行单一修改最后查询执行结果。exit_session也体现了会话权限边界。它能够关闭无窗口的隐藏会话却会拒绝关闭用户桌面上可见的实例。自动化接口不应悄无声息地关闭用户正在观察的窗口这不是功能缺陷而是安全保护。不同失败状态也应区别处理Busy等待当前任务结束 Read only解除只读限制后再修改 API error检查对象名称、参数和调用方式 PromptRefused重新审视操作范围 Authentication error重新检查令牌与 Bearer 前缀 Network error确认服务地址与本地网络状态。把这些状态统一视为“连接失败”会掩盖真正的错误原因。只有先分类才能采取正确的恢复动作。第十三步从一次成功连接走向可重复流程一次成功的接入最终应沉淀为一份可复用流程而不是一串临时命令。其最小结构包括环境检查 服务配置 鉴权配置 客户端重载 工具枚举 会话确认 模型状态检查 API 查询 单项执行 结果验证 错误分类如果某一步失败只需定位具体状态而不必从头猜测。例如配置能够保存但工具为空应重点检查服务与鉴权工具已经枚举但模型无法修改应检查只读状态代码能够运行但参数异常应检查单位制网格划分无响应应检查长任务状态边界条件错误应回到拓扑选择和预览环节。这套流程的核心不是追求操作速度而是确保每一步都具有明确事实和可验证结果。PrePoMax 的 15 个 MCP 工具已经提供了读取、执行、中断和查询能力WorkBuddy 的价值则在于把这些能力组织成一条稳定的工程工作流。连接不是终点模型状态才是执行起点在这次会话中最关键的发现并不是工具数量而是模型状态本身。get_status显示当前会话正在运行协议版本为 1.0PrePoMax 窗口可见一个 MCP 客户端处于活跃状态当前模型为Model-1会话空闲且非只读。但模型的unitSystem与modelSpace均为Undefined文件名也是空的。这意味着模型虽然可以被修改却还没有形成完整的坐标、单位和物理量定义。单位制在 PrePoMax 自动化中不是一个可以在执行时顺便补上的显示参数。API 输入的数字通常不带单位服务也不会替用户猜测 10 代表 10 毫米、10 米还是 10 英寸。如果模型处于Undefined状态后续创建几何、设置材料、定义载荷和检查网格尺寸都会缺少共同基准。尤其在毫米、吨、秒、摄氏度体系中钢的弹性模量约为 210000 MPa泊松比约为 0.3如果错误地套用纯 SI 国际单位数值模型就可能从一开始就偏离预期。因此正式自动化建模的第一步应当是确认或设置单位制与模型空间而不是立即创建零件。模型命名并保存到本地文件也应早于复杂修改。若fileName为空一旦程序异常退出、误操作覆盖或版本保存失败用户可能失去验证依据。先保存为beam_test.pmx之类的明确文件不只是为了形成备份也是为了让后续每一步都有可追溯的项目边界。这一顺序也揭示了人工智能辅助工程软件的基本规则可执行不等于可以执行。工具能够运行 Python只代表权限已经打通只有当单位、模型空间、文件路径和当前状态都清楚时操作才具备物理意义。几何选择必须从猜测转向验证有限元自动化最容易翻车的环节往往不是求解器而是几何选择。在图形界面中工程师可以旋转视图、放大边缘并逐个人工确认面、边和顶点在脚本中如果对象编号、选择范围或法向假设错误程序则可能安静地选中错误区域并把错误传播到网格、约束和载荷。模型的几何尺寸可能看似正常但边界条件已经施加在错误的面上。PrePoMax 的read_topology能够返回面、边、顶点及其编号、尺寸、质心和法向selection.preview()则可以在正式提交前验证选择范围。两者结合起来构成了自动化建模中的安全护栏。工程师不应要求人工智能根据自然语言直接选定“左端面”而应让它先读取拓扑再通过预览确认候选对象是否符合位置、尺寸或法向条件最后才把选择结果固化到集合、约束或载荷中。这种差异本质上是从“描述几何”转向“验证几何”。人工智能并不需要拥有视觉也能够根据质心、法向、尺寸和邻接关系进行推理。例如对于一个规则块一侧面的法向可以提示其大致朝向面的尺寸可以帮助区分端面与侧面顶点和边则可以构成局部坐标线索。只要先读取拓扑并预览选择人工智能就能从“替用户点击屏幕”升级为“根据模型事实作出可验证的判断”。六面体网格不是一次魔法操作而是一条条件链PrePoMax 在新版本中加强了结构化网格能力。对具有 5 个或 6 个面、边界由三边或四边面构成的实体可以生成超限六面体网格对能够沿一个方向扫掠的实体则可以生成扫掠六面体网格。这些能力显著减少了单元数量、提高了应力结果质量也改善了接触压力分布。但自动化工具并不会自动把任意 CAD 几何变成优质六面体网格。规则块之所以适合作为第一个验证对象不是因为它最简单而是因为它的几何条件最容易满足。100 mm × 20 mm × 20 mm 的长方体具有清晰的源面、目标面、扫掠路径和方向便于验证尺寸、选择面和网格层数。相比之下薄壁件、复杂倒角、多连通域、不规则孔洞和缺少分割的实体可能需要先进行几何分割。如果人工智能在信息不完整时直接承诺“自动生成六面体网格”那么所谓自动化实际上只是把失败推后到网格器内部。正确的执行链应当拆分为多个独立步骤。第一步只创建几何并保存模型第二步读取read_model和read_topology确认单位制、零件和几何状态第三步通过selection.preview()验证源面第四步再执行拉伸、旋转或扫掠第五步检查网格质量并保存结果。每一步都应有独立的成功标准不能把几何创建、网格划分、边界条件和提交计算合并成一个脚本。这样即使某一步失败用户也能定位问题而不会面对一个被连续修改、无法撤销的复杂模型。长任务还要遵循专门的回收机制。网格划分或文件导入如果超过单次请求时限服务可能返回running与callId。此时不应重复提交相同指令而应调用get_call获取结果确实需要中断时才使用cancel_call。cancel_call可能直接中断正在运行的网格划分器因此它是一项紧急控制能力而不是常规流程节点。对自动化任务而言重复提交往往比任务缓慢更危险因为它会把单一问题放大为多个并行状态冲突。run_python必须被视为实时控制而不是普通代码生成run_python与普通代码助手最大的区别在于它会直接驱动桌面上正在运行的 PrePoMax 活动模型。代码一旦执行就会进入命令历史并可能改变零件、网格、材料、载荷和视图状态。因此用户不能把 WorkBuddy 理解为后台代码生成器而应把它看作一个获得授权、能够操作图形界面背后模型的代理。这种代理需要边界。正式建模前最好保存原始模型或在副本中验证流程一次只执行一个独立动作涉及单位、材料和载荷时必须确认单位制对几何选择应先预览再提交对计算任务则通过run_job启动再使用get_job轮询状态。run_job不阻塞会话重复点击并不会加快求解只会制造重复任务和状态混乱。exit_session也体现出会话权限的边界。它能够关闭无窗口的隐藏会话却会拒绝关闭用户桌面上可见的 PrePoMax 实例。这不是功能缺陷而是有意为之的保护机制。远程自动化接口应当能够管理任务但不应悄无声息地关闭用户正在观察的软件窗口。类似地只读请求、繁忙状态、只读模式、API 错误和拒绝提示应当分别处理不能一概视为连接失败。人工智能更适合充当自动化翻译器而不是工程决策者PrePoMax 的自动化指南要求工程师先确认单位制优先使用selection.preview()验证几何通过describe_api查询准确调用并区分不同种类的错误。这套规则恰好划定了人工智能在有限元自动化中的合适位置。人工智能擅长连接自然语言需求与工具调用例如把“创建一根梁并划分六面体网格”拆解为状态检查、单位确认、几何创建、拓扑读取、面选择、网格划分和结果检查它也擅长解释工具返回信息把 JSON 中的状态、单位制、会话标识和错误信息转译为执行建议。但它不应当替用户决定材料参数、安全系数、边界条件或求解方案除非这些依据已经明确提供。run_python也改变了代码验证方式。人工智能可以先在本地编写候选代码通过describe_api检查对象结构再在 PrePoMax 中执行执行后通过get_history回看实际命令并依据read_model验证模型状态。这实际上形成了一种反馈式编程代码不是一次性交付物而是根据真实会话不断校正的操作记录。一个成熟的接入流程应当从事实检查开始PrePoMax 接入 WorkBuddy 后推荐的第一次操作并不是创建复杂模型而是依次调用get_guide、get_status和list_sessions。这三步分别对应系统规则、当前事实和可用会话。get_guide说明应该如何操作get_status说明当前模型处于什么状态list_sessions则确认是否存在多个实例以及是否连接到目标会话。如果list_sessions显示多个 PrePoMax 实例就需要确认当前连接是否指向正确窗口如果会话繁忙则应等待或使用相应状态查询而不能强行提交代码如果模型处于只读模式则需要先解除限制如果unitSystem为Undefined则必须先明确单位体系。只有当会话空闲、模型可写、单位明确且文件路径已知时才可以进入几何创建阶段。随后一个完整但克制的初始化流程应当是通过describe_api查询真实 API确认单位制和模型空间创建或保存模型文件读取模型与拓扑必要时预览选择执行单一修改检查历史与状态确认无误后再进入网格划分和分析阶段。这个流程牺牲了一部分表面上的“自动化速度”却换来了结果可解释、操作可撤销、错误可定位和可重复执行。结论WorkBuddy 接入 PrePoMax 的核心不是找到一个神奇命令而是完成四件事把服务地址、协议和 Bearer 鉴权配置正确通过重新启用服务使配置真正生效让客户端枚举并信任实际工具再根据实时状态组织可验证的执行流程。其中任何一步不完整都可能出现“配置存在但工具不可用”的假象。更深一层看PrePoMax 的 15 个 MCP 工具把有限元建模拆成了可观察、可执行、可中断、可查询的闭环。人工智能要发挥价值就必须先读取事实再决定行动而不是根据常识替工程模型补全参数。当前会话中unitSystem和modelSpace均为Undefined正是一次重要提醒自动化的首要条件不是代码能够运行而是数字具有明确含义几何选择具有验证依据模型文件具有清晰边界。因此最合理的下一步不是立即创建复杂几何而是查询pmx、pmx.model和pmx.model.steps的真实成员结合get_status与read_model的返回结果先初始化单位制、保存项目文件再从规则块开始验证几何创建、面选择、六面体网格和分析流程。只有这样WorkBuddy 才不只是“会聊有限元的助手”而会成为能够安全控制 PrePoMax 的实时自动化代理。
