BossAgents从298到470：一个PLM系统如何用AI把“半成品”变成“完整骨架”
你有没有遇到过这样的场景：花了大价钱上线的PLM系统，用起来却像买了一辆只有外壳的跑车——引擎盖打开，里面空空如也。业务部门催着要模板，IT团队加班加点手动配置，结果数据还是对不上，流程跑不通，系统越用越乱。
这不是个别企业的困境。在制造业数字化转型的过程中，PLM系统的“模板荒”和“规则乱”几乎是通病。核心对象没有可用的模板，数据提取不完整，规则系统形同虚设……这些问题就像水管里的沙子，平时看不见，一用水就堵。
最近，我们的技术团队完成了一次对SCSAI PLM系统的三层架构优化。简单来说，就是把一个“半成品”系统，变成了一个拥有470个完整模板、3489条分级规则、46个业务提示词的“完整骨架”。更重要的是，整个过程不是靠人工堆砌，而是靠AI驱动的自动化流水线。
痛点：为什么你的PLM系统总像“毛坯房”？
在动手优化之前，我们做了全面的“体检”。结果触目惊心——问题清单排了整整一页：
核心类型无模板（P0级）：Part、Document、ECR、Project、Vendor这些最最基础的对象，居然一个可用的模板都没有。这意味着什么？意味着业务人员每次创建新零件，都要从零开始填字段，没有标准格式，没有必填项约束，没有关联关系指引。
数据提取不完整（P0级）：系统只扫描了298个XML文件，却遗漏了大量独立Property文件中的属性定义。就像你去图书馆找书，只翻了第一个书架就以为找全了。
模板质量差（P1级）：好不容易找到的模板，里面只有简单的占位符，没有属性约束、没有关系定义、没有生命周期状态。说白了，就是个空壳子。
规则系统是空表（P1级）：规则表、提示词表、模板表，三张核心数据表全部为0条记录。规则系统形同虚设，系统无法对数据质量做任何校验。
数据库路径错误（P0级）：更离谱的是，系统的数据库路径指向了一个不存在的目录，每次启动都在创建一个空库。这就像你家水表的管道接错了，水一直在流，但就是流不到你家。
多进程冲突（P1级）：每次启动创建新实例，6个进程同时抢端口，系统动不动就崩溃。
这些问题叠加在一起，结果就是：系统上线了，但没人用；数据录入了，但没法用；流程配置了，但跑不通。
解法：从298到470，我们做了什么？
数据提取：从“只扫一个目录”到“全量递归扫描”
原来的数据提取只扫描了Import/ItemType/目录下的298个文件，遗漏了大量独立Property文件中的属性定义。我们的解决方案是开发了一个v3版本的提取器extract-all-itemtypes.js，它做了三件事：
- 1. 全量递归扫描
- 2. 去重合并
- 3. 嵌套属性提取
效果立竿见影：
- 扫描文件数：从298个增加到7,706个（25倍提升） - 提取属性数：从约2,821个增加到6,720个（2.4倍提升） - 模板总数：从298个增加到470个（58%增长） - 核心类型模板：从0增加到20个核心类型模板
以最常见的Part类型为例，之前没有模板，现在Part模板包含27个属性，AML模板文件大小达到1,846字符。Document模板22个属性，ECR模板25个属性，Project模板更是达到了47个属性、3,284字符。
规则系统：从“空表”到“三级分级+九大分类”
之前的规则表是空的，3489条规则没有任何治理字段。我们做了三件事：
- 1. 分级
- 2. 分类
- 3. 活跃控制
同时，我们从JSON文件批量导入了全部3,489条规则，让规则系统从一个空壳变成了一个完整的“交通指挥系统”。
提示词系统：从“0条”到“470+46条”
提示词系统是连接用户意图和系统生成的桥梁。原来这个系统也是空的。我们做了：
- 对象提示词
- 业务提示词
每个提示词的结构都包含四部分：对象信息、属性定义、关联关系、生成规则。这样，当用户输入“创建一个新的零件”时，AI能准确理解需要生成什么、有哪些约束、要关联哪些对象。
后端API：从“不可用”到“完整服务”
我们修复了数据库路径错误、多进程冲突、路由不可达等基础设施问题，并新增了完整的API服务：
/api/aml/sciot/templates
/api/aml/sciot/prompts
/api/aml/sciot/rules
/api/aml/sciot/rules/stats
/api/aml/sciot/business-prompts
/api/aml/assemble
- 以及验证、统计、索引等辅助API
前端界面：从“空白”到“5个Tab”
我们开发了完整的PLM三层架构管理界面，包含5个Tab：
- 元模型层
- 对象模型层
- 业务系统层
- 规则管理
- 模板/提示词
核心：AML组装流水线是如何工作的？
这次优化的核心是建立了一条完整的AML组装流水线。它的工作流程是这样的：
用户输入 → LLM生成 → 解析LLM输出 → 合并模板 → 规则验证 → 补全系统字段 → 标准AML XML输出 这条流水线解决了两个关键问题：
1. 给LLM什么，不给LLM什么
我们发现，很多失败的AI应用是因为“给太多”或“给太少”。在这条流水线中，我们明确划分了边界：
- 给LLM
- 不给LLM
2. 怎么保证生成质量
流水线中的每个环节都有明确的职责：
parseLlmOutput()
mergeWithTemplate()
validateWithRules()
fillSystemFields()
buildAMLXml()
这样，LLM生成的内容不再是一堆混乱的文本，而是经过模板约束、规则验证、系统补全的“合格产品”。
遗留问题与未来方向
当然，这次优化不是终点。我们识别了以下几个遗留问题：
1. assemble路由响应超时（P1）：内联handler能正常解析但请求挂起，可能是sql.js多实例冲突导致。建议用better-sqlite3替代sql.js。
2. 核心类型必填字段为0（P2）：Part等类型的is_required均未被标记，需要排查V2提取逻辑。
3. 性能优化：随着模板增加到470个，查询和匹配的性能需要持续优化。
落地：BossAgents能为你做什么？
这次优化不是一次性的技术升级，而是一个可复用的方法论。作为BossAgents（左帮右臂）智能体公司，我们专注于将这种“从混乱到有序”的能力带给更多企业。
具体来说，我们可以：
1. 系统体检与诊断：像这次优化前做的那样，对现有PLM系统进行全面体检，找出P0/P1/P2级别的核心问题
2. 模板与规则自动化：利用AI驱动的提取和生成技术，快速补齐模板、规则、提示词三大核心数据资产
3. 组装流水线搭建：为企业搭建从用户输入到标准输出的完整AML组装流水线，实现“一句话生成一个标准对象”
4. 持续优化与治理：建立规则分级分类、模板版本管理、提示词迭代优化的持续治理机制
5. 多系统集成：将这套方法论扩展到其他企业系统，如ERP、MES、CRM等，实现跨系统的数据标准化
这次优化证明了一件事：AI不是用来替代人的，而是用来完成那些人力无法完成的海量、重复、精细的工作。从298到470，从0到3489，从0到46，这些数字的背后，是AI让一个“半成品”系统变成了真正的“生产力工具”。
如果你的PLM系统也面临着类似的问题——模板不全、规则缺失、数据混乱、流程跑不通——不妨想想：也许不是系统不行，而是少了一个“AI助手”来帮你把骨架搭好。
BossAgents，让你的系统从“能用”变成“好用”。
