BossAgents你的知识资产正在“沉睡”——三招让2371条规则真正为你所用
想象一下：你的团队花了整整两年，积累了2371条业务规则、1205套模板、2817条提示词。这些数字听起来很漂亮，但现实是——它们被锁在一个本地SQLite数据库里，技术团队每次修改都要跑命令行脚本，业务部门想个性化调整却无从下手。
这不是个别现象。我们服务过的制造企业里，90%的知识资产都处于“沉睡状态”：要么存在某个工程师的电脑里，要么散落在不同系统的数据库中，要么——像今天要讲的故事一样——被“技术债”层层包裹，动弹不得。
从“一锅炖”到“三层楼”：知识资产的分层革命
传统的知识存储就像一个大杂烩：标准数据、用户个性化配置、临时修改，全挤在一张表里。这种架构在数据量小的时候还能凑合，但当规则数量突破2000条、模板超过1000套时，问题就暴露了：
- 修改标准数据时：分不清哪些是官方规则，哪些是用户自己改的
- 同步更新时：一个补丁下去，用户的个性化配置全没了
- 审核追溯时：谁在什么时候改了哪条规则，完全查不到
第一层：SCSAI标准库（官方“宪法”）
这层存储的是从PLM系统直接导入的原始数据。我们统计过，一个中型制造企业的标准库通常包含：
- 928个ItemType定义
- 40,854个属性定义
- 587个关系定义
- 191个生命周期映射
- 631个表单定义
import-aml-v2.js负责从XML文件批量导入，generate-operation-rules.js负责从这些原始数据中推导出规则、模板和提示词。整个过程是“离线+全量”的——就像出版一本宪法，一旦定稿，不会频繁修改。
第二层：本地缓存（高效“运行版”）
标准库的数据被缓存到本地SQLite数据库中，供前端应用实时调用。这层的核心价值是性能：
- 规则查询：毫秒级响应
- 模板加载：零等待
- 提示词生成：即取即用
第三层：用户私有库（个性化“便签”）
这是整个架构的亮点。用户可以在不修改标准库的前提下，对规则、模板、提示词进行个性化覆盖：
- 规则覆盖：某条标准规则太严格？用户可以加一条更宽松的覆盖规则
- 模板调整：标准模板的字段顺序不合理？用户可以创建自己的模板版本
- 提示词定制：不同业务场景需要不同的提示词？用户可以自由组合
技术落地：两条流水线，一座数据桥
听起来很复杂？其实核心就两条自动化流水线。
流水线一：数据生成（离线CLI）
import-aml-v2.js是数据生成的“总指挥”。它扫描PLM系统的XML文件，经过7个阶段处理，最终产出：
扫描目录 → 导入ItemType → 关联方法 → 跨文件链接 → 回填模板 → 生成规则 → 生成提示词 这个过程是“全量+增量”的：
--full：全量重建（适合首次导入或重大升级）- 默认：增量更新（适合日常维护）
流水线二：规则衍生（离线CLI）
generate-operation-rules.js是规则的“精炼厂”。它从基础数据中衍生出三类规则：
- 关系规则：从
relationships表中生成对象间关联规则 - 方法触发规则：从
methods表中生成自动编号、创建规则 - 校验规则：从
properties表中生成字段校验和默认值规则
数据桥：前后端API双线运营
后端提供了两套API：
aml.js：负责标准数据的管理（规则CRUD、模板读取、提示词管理）rule-engine.js：负责规则执行（规则校验、提示词预生成）
加载面板数据 → 选择ItemType → 读取模板和规则 → 前端验证 → 组装AML → 调用SCSAI 整个过程用户无感——他们只看到：选一个对象类型，填几个字段，系统自动生成完整的PLM对象。
审核提交：让每一次修改都有迹可循
三层架构的另一个核心能力是审核提交流程。当用户需要将自己的个性化修改提交为标准时，流程是这样的：
- 用户提交：在私有库中标记“申请标准化”
- 审核队列：管理员在后台看到所有待审核的修改
- 差异对比：系统自动对比用户修改与标准版本
- 一键审批：管理员确认后，修改自动合并到标准库
- 版本升级：标准库版本号+1，所有用户自动同步
你的知识资产，需要一个“三层别墅”
回到开头的问题：你的2371条规则、1205套模板、2817条提示词，还在“沉睡”吗？
BossAgents（左帮右臂）的这套分层存储方案，已经在多个制造企业落地验证：
- 数据同步效率：从小时级降到分钟级
- 个性化配置时间：从周级降到天级
- 审核追溯覆盖率：从0%提升到100%
你的知识资产，值得一栋“三层别墅”。
---
BossAgents（左帮右臂）——让企业的每一份知识，都成为可复用的资产。
