我用Vibe Coding手搓一个仿真任务调度系统(PBS)

导 语

仿真团队想把任务、算力和结果文件管起来，过去通常会想到两条路：买一套专门软件，或者上一套更完整的 HPC / 作业调度平台。这些方案当然有价值，尤其适合大团队、大规模集群和严格权限管理的场景。

但在很多中小团队里，需求往往没那么大：只是想先把几台工作站管起来，让任务有入口、状态能看见、结果能追溯。而有了 AI 之后，不一定需要再花钱购买这类工具，仿真工程师完全可以根据自己的工作流，先 vibe 出一个够用的 app。

这篇文章和大家分享我们Vibe coding实现的PBS应用，联动我们自己开发的仿真需求提交App, 在实际业务流程中极大提升了仿真任务管理的效率。

一、什么是 PBS，它解决什么问题

PBS 可以简单理解为一套作业调度系统：用户提交计算任务，系统根据节点状态分配任务，再把运行状态和结果记录下来。

在仿真场景里，它对应的是一个很实际的问题：几台工作站放在那里，哪台空闲、哪台负载高、哪个任务还在跑、结果文件放在哪里，最好不要全靠人工记忆和微 信群消息。

成熟的 PBS / HPC 平台可以把这类事情做得很完整。但很多团队并不是一开始就需要完整平台。比如内部只有几台 Windows 工作站，求解器、许可证、脚本和历史项目都已经在这些机器上，真正想先解决的可能只是几件小事：

• 提交任务有一个统一入口；

• 节点在线状态和资源占用能看见；

• 任务运行过程有状态记录；

• 结果文件能和 case 对应起来。

这些需求很基础，但很常见。过去它们经常卡在“太小，不值得单独立项；太具体，通用软件又不一定贴合”这个位置。

AI 的出现，让这类长尾工具多了一种新做法：先由最懂流程的工程师，把需求讲清楚，再让 AI 帮忙搭一个内部可用的版本。

二、AI 改变的是工具生成方式

AI 还不能替代仿真工程师解决核心仿真问题。材料模型、边界条件、网格收敛、结果可信度，仍然需要工程判断。

但它确实降低了“做一个工程小工具”的门槛。

过去要做这样一个内部 PBS，通常要写需求、排资源、找前后端协作。现在，如果并不是一个非常大型的仿真团队，搭建这样的应用，流程可以轻很多，Vibe Coding 带来一种新的工程协作方式：工程师负责定义流程、边界和验收标准，AI 负责把大量普通但耗时的软件工作先搭起来。

三、这个 PBS 小工具大概长什么样

这个小 app 的结构很简单：一个 Web 页面，一个中心服务，几个部署在工作站上的 Agent。

Web 页面负责提交任务和查看状态；中心服务负责保存任务、接收心跳、分发任务；工作站 Agent 负责在本地执行仿真或 Python 任务，并把状态和结果回传。

   

Dashboard 监控看板：展示不同节点的在线状态、系统信息、CPU、内存、磁盘和 GPU 资源。

Dashboard 先解决“看见”的问题：现在有几台节点在线，资源是否紧张，任务有没有积压。

   

Nodes 节点管理：集中查看计算节点名称、标签、CPU、内存、在线状态、连接状态、最后心跳和 Agent 版本。

Nodes 页面解决“机器谁在管”的问题：节点是否在线、Agent 是否更新、CPU 和内存是否异常，至少有一个统一入口。

   

Jobs 任务管理：展示任务总数、排队、运行、完成、失败、CPU 需求，以及具体任务状态和输入文件。

Jobs 页面解决“任务怎么追”的问题：任务有编号、有状态、有节点、有输入文件、有输出目录，也可以和 Case 信息关联起来。

这里不需要展开每个模块。真正重要的不是这个 app 现在有多少功能，而是它把一个原本靠人工协调的仿真流程，变成了一个可以被系统记录、追踪和继续迭代的对象。

四、这类工具适合从“小而真”的需求开始

AI 辅助开发时，最适合的起点往往不是“大而全”的内部平台，而是那些具体、重复、确实每天会遇到的小问题。

比如：

这些需求单独看都不算起眼。

但它们加起来，就是一个团队真实的工程效率。

AI 在这里的作用，不是替工程师做出一个完美平台，而是让第一版内部工具的成本降下来。先把真实流程跑顺，再决定要不要继续做深、做稳，或者接入更成熟的平台。

最后说一句

这次小实验带来的启发是，AI + CAE 不一定只盯着“大模型能不能直接求解物理问题”。

还有一个更贴近日常的方向：AI 能不能帮助仿真工程师，把自己的工作环境改造得更顺手。

任务提交、算力分配、结果追溯、报告生成，这些看起来不像核心算法，但它们决定了一个团队每天的工作效率。

过去这类事情往往需要买软件、等开发、排资源。现在，在边界清楚、风险可控的场景里，可以先用 AI 快速搭一个内部工具，把流程跑起来。它不一定完美，但能跑、能改、能服务自己的工作流。