左帮右臂工业规则引擎统一调度系统 V1.0

软件说明书

软件全称： 左帮右臂工业规则引擎统一调度系统

软件简称： 工业规则引擎调度系统

版本号： V1.0

著作权人： 北京左帮右臂人工智能技术有限公司

统一社会信用代码： 91110114MAKJ1UC63J

编写日期： 2026年7月

开发完成日期： 2026年6月15日

首次发表日期： 未发表

目录

• 一、软件概述
• 二、软硬件运行环境
• 三、软件系统架构
• 四、核心功能详细说明
• 五、软件创新点与优势
• 六、软件操作步骤与使用说明（含操作界面截图）
• 七、典型应用场景案例（含真实运行界面）
• 八、数据接口与集成说明
• 九、参数配置说明
• 十、部署与运维详细步骤
• 十一、安全机制
• 十二、性能基准
• 十三、核心功能模块详述与部署运维（含真实运行界面）
• 十四、版本更新说明
• 十五、常见问题与故障排查
• 十六、术语与缩略语
• 十七、技术参数与性能指标
• 十八、最新版本新增功能（V1.0 更新）
• 著作权人信息

一、软件概述

1.1 研发背景

在工业制造与企业产品生命周期管理（PLM）领域，企业普遍面临对象数据校验规则分散、业务流程难以统一调度、跨系统规则一致性难以保障等问题。传统的规则管理方式将校验逻辑硬编码在代码中，导致规则变更需要修改代码、重新部署，维护成本高、响应速度慢。同时，工业场景下涉及的物料管理、质量管控、项目管理、财务核算等业务模块各自独立，缺乏统一的规则调度中枢。

随着制造企业对数据质量、合规管控与业务自动化的要求不断提升，规则数量和复杂度呈指数级增长。以某汽车零部件企业为例，仅物料（Part）对象在 IATF16949 体系下就需要数十项命名规范、必填校验、关系完整性约束；一旦规则以硬编码方式嵌入多个业务系统，任何一次标准更新都需要在 ERP、PLM、QMS 多套代码库中同步修改，极易出现"改了 A 漏了 B"的口径不一致问题，进而引发质量追溯失效、审计不通过等严重后果。

为解决上述问题，北京左帮右臂人工智能技术有限公司研发了"左帮右臂工业规则引擎统一调度系统 V1.0"。本系统采用数据库驱动规则存储、统一调度引擎、多级缓存优化、规则自进化闭环等核心技术，为企业提供一套覆盖对象识别、创建、校验、修复、优化、比对、巡检、估值等全生命周期的规则统一调度平台。系统将"规则"从代码中剥离，下沉为可配置、可审计、可自进化的数据资产，使业务人员、质量工程师、系统管理员能够在同一控制台中完成规则的定义、测试、发布与监控，真正实现了"规则即配置、变更即生效"。

1.2 核心功能

本系统的核心功能包括：

1. 统一规则引擎（Unified Rule Engine v3.0）：以单一引擎驱动对象识别、创建、修复、优化、比对等全部业务能力，规则存储于数据库中，可动态管理、实时生效。引擎在初始化时自动建表、同步内置规则，并具备自愈机制——当检测到规则表为空时自动重建，从根本上避免"空库即宕机"的可用性风险。

1. 多作用域规则调度：支持识别（identify）、创建（create）、创建前预处理（create_pre）、创建后处理（create_post）、修复（repair）、优化（optimize）、比对（compare）、验证（validate）、转换（transform）、生成（generate）、巡检（inspect）、删除（delete）、更新（update）、导入（import）、导出（export）、审批（approve）、估值（valuate）、采集（collect）等18种规则作用域，覆盖工业业务全流程。

1. 规则工厂模式：通过上下文注入机制，使通用规则能够自动适配所有ItemType，无需为每种对象类型单独编写规则，实现规则全覆盖。该机制基于 sciot_properties、sciot_templates、sciot_sequences 等元数据表，在规则执行前动态注入 _keyedField、_requiredFields、_defaultValues、_lengthLimits、_listFields、_datePairs 等上下文，使一条通用规则对所有对象类型生效。

1. 规则自进化闭环：采集用户修正记录，自动识别修正模式，生成规则候选，经人工审批后部署，形成"修正采集→模式识别→规则建议→审批部署→效能监控"的完整闭环。当某类型对象修正记录达到阈值（默认5条），系统自动分析模式并生成候选规则，避免规则库长期滞后于真实业务。

1. 企业规则配置：支持行业模板（IATF16949、ISO9001等）、命名规范、必填字段、禁止模式、数据类型标准、关系标准等企业级规则配置。通过 validateType 方法对对象类进行健康度评分（满分100分），量化数据质量。

1. 规则意图解释：基于大语言模型（LLM）自动解读规则的商业意图，包括规则为何存在、保护什么、影响什么，并支持规则冲突检测。该能力使非技术人员也能理解、复核、审批规则，降低规则治理门槛。

1. 统一调度编排：针对"制展开→巡检加热→整理→清理移交"等工艺链，引擎按预设顺序编排多工序规则，实现跨工序的自动循环工程生成，可作为数字员工与原子能力的统一调度核心。

1. 提示词预生成：根据 ItemType 的属性、关系、序列、校验规则自动构建完整的 LLM 创建提示词，支持单类型生成与批量生成，并动态区分 LLM 可生成字段与系统自动填充字段，约束身份角色防止大模型编造。

1.3 应用场景

本系统适用于以下典型应用场景：

• PLM产品生命周期管理：物料（Part）、文档（Document）、CAD、产品（Product）、工程变更（ECR/ECN/ECO）等对象的创建校验与流程管控。
• 项目管理系统：项目（Project）、WBS元素、项目任务的编号生成、日期校验、状态管理。
• 质量管理系统：审核（Audit）、不合格品（NCR）、偏差（Deviation）、FMEA等质量对象的合规性校验。
• 财务/ERP系统：采购订单、销售订单、库存管理、会计科目等业务对象的规则校验与数据修复。
• 供应链管理：供应商（Vendor）信息补全、价格异常监控、采购订单逾期提醒、低库存自动预警。
• 工艺规程管理：针对工艺链对象自动编排循环工程方案，实现多工序规则的有序调度与生成。

1.4 文档说明与阅读指引

本说明书共十七章及著作权人信息段。其中第一章介绍研发背景与核心能力；第二、三章分别说明运行环境与系统架构；第四章逐条详述核心功能；第五章归纳创新点与技术优势；第六章给出带真实截图的操作步骤；第七章给出典型场景案例；第八章给出数据接口与集成说明；第九章至第十二章为新增的参数配置、部署运维、安全机制与性能基准；第十三章详述核心模块与运维界面；第十四至十七章分别为版本更新、常见问题、术语与技术指标；末尾为著作权人信息段。

所有截图均来自软件真实运行环境，引用路径采用相对路径 ../shots/ 形式，便于随文档一并交付与审查。

二、软硬件运行环境

2.1 开发工具

2.2 运行环境

2.3 硬件要求

2.4 环境依赖与前置检查

在正式部署前，建议依次确认以下前置条件均已满足，以避免运行时异常：

1. Node.js 版本校验：执行 node -v，确认输出版本不低于 v18.0.0；执行 npm -v 确认包管理器可用。
2. 数据库可写权限：确认服务运行账户对数据库文件所在目录具备读写权限（SQLite 模式下尤其重要）。
3. 端口占用检查：默认服务端口（如 3100）未被其他进程占用，可通过 netstat -ano | findstr :3100（Windows）或 ss -ltnp | grep 3100（Linux）核查。
4. 外部依赖可达性：若启用 LLM 意图解释能力，需确认大模型 API 的访问地址与密钥已配置且网络可达。
5. ARCH/PLM 连通性：若对接 SCSAI PLM，需确认 REST API 地址、认证凭据有效，且目标库具备相应读写权限。

2.5 网络与防火墙配置

若系统跨网络部署（如应用服务器与 SCSAI PLM 不在同一网段），需提前规划网络策略：

• 服务端口放行：在防火墙开放 SERVER_PORT（默认 3100），仅对必要网段开放，避免暴露到公网；
• 下游白名单：若启用 LLM 或 SCSAI 集成，应用服务器需能访问对应 API 地址与端口，建议在出方向配置白名单；
• HTTPS 建议：生产环境建议在网关层终止 TLS，引擎自身通过 HTTP 对内提供服务，降低证书管理复杂度；
• 内网隔离：规则库（SQLite 文件或 MySQL 实例）应与应用同安全域，禁止公网直连数据库端口。

三、软件系统架构

3.1 总体架构

本系统采用分层架构设计，自上而下分为：API路由层、规则引擎核心层、数据持久层、外部集成层。

┌─────────────────────────────────────────────────────┐
│                   API 路由层                          │
│  (server/routes/rule-engine.js)                     │
│  规则CRUD / 规则执行 / 导入导出 / 自进化 / 提示词管理  │
├─────────────────────────────────────────────────────┤
│                  规则引擎核心层                       │
│  ┌─────────────┐ ┌──────────────┐ ┌──────────────┐ │
│  │ 统一规则引擎 │ │ 企业规则系统  │ │ 规则自进化   │ │
│  │(rule-engine)│ │(enterprise-  │ │(rule-        │ │
│  │             │ │ rules)       │ │ evolution)   │ │
│  └─────────────┘ └──────────────┘ └──────────────┘ │
│  ┌─────────────────────────────────────────────┐   │
│  │         规则意图解释器                        │   │
│  │         (rule-intent-interpreter)            │   │
│  └─────────────────────────────────────────────┘   │
├─────────────────────────────────────────────────────┤
│                   数据持久层                         │
│  sciot_rules_v2 / sciot_rule_history /              │
│  sciot_corrections / sciot_rule_candidates /        │
│  prompt_templates / enterprise_rules                │
├─────────────────────────────────────────────────────┤
│                  外部集成层                          │
│  SCSAI PLM API / LLM大模型 / n8n工作流引擎           │
└─────────────────────────────────────────────────────┘

各层之间通过明确定义的接口契约通信，API 路由层不直接访问数据库，而是经由统一规则引擎完成所有规则相关操作，从而保证"规则逻辑唯一、数据口径一致"。外部集成层以适配器方式对接 SCSAI PLM、LLM 与 n8n，便于企业按需启停外部能力。

3.2 核心模块划分

系统由5个核心模块构成：

模块一：统一规则引擎（server/core/rule-engine.js）

• 类：UnifiedRuleEngine
• 职责：规则CRUD管理、规则执行调度、缓存管理、条件评估、动作执行、AML构建与提交、批量执行、双库查重
• 规模：约3132行代码，是系统最大的核心模块

模块二：API路由（server/routes/rule-engine.js）

• 函数：handleRuleEngine
• 职责：HTTP请求路由分发、参数校验、响应封装，提供40余个API端点
• 规模：约1236行代码

模块三：企业规则系统（server/core/enterprise-rules.js）

• 类：EnterpriseRules
• 职责：企业级规则配置管理、行业模板加载、对象类健康度评分
• 规模：约391行代码

模块四：规则自进化引擎（server/core/rule-evolution.js）

• 类：RuleEvolution
• 职责：用户修正分析、修正模式识别、规则候选生成、审批部署、规则效能监控
• 规模：约414行代码

模块五：规则意图解释器（server/core/rule-intent-interpreter.js）

• 类：RuleIntentInterpreter
• 职责：规则意图解读、规则变更分析、执行结果内容转换、规则冲突检测
• 规模：约314行代码

3.3 数据流转逻辑

系统的核心数据流转遵循"规则定义→规则调度→执行反馈→自进化"的闭环：

1. 规则定义阶段：规则通过手工录入、AML导入、SCSAI同步、规则工厂自动生成、自进化候选审批等5种途径进入规则库（sciot_rules_v2表）。

1. 规则调度阶段：当API层接收到业务请求（如创建对象），统一规则引擎根据请求的scope（如create）和item_type从规则库加载匹配的活跃规则，按优先级排序后逐条执行。

1. 执行反馈阶段：每条规则执行后，结果记录到执行历史表（sciot_rule_history），命中统计更新到规则表（hit_count、avg_duration_ms）。若用户对执行结果进行修正，修正记录写入sciot_corrections表。

1. 自进化阶段：当某类型对象的修正记录达到阈值（默认5条），规则自进化引擎分析修正模式，生成规则候选写入sciot_rule_candidates表，经人工审批后激活为正式规则。

3.4 关键数据库表说明

为保证规则可配置、可审计、可自进化，系统设计了以下核心数据表：

| 表名 | 用途 |

|------|------|

| sciot_rules_v2 | 规则主表，存储全部规则定义与运行统计（hit_count、avg_duration_ms 等） |

| sciot_rule_history | 规则执行历史，记录每次命中的规则、对象、结果与耗时 |

| sciot_corrections | 用户修正记录，是规则自进化的数据来源 |

| sciot_rule_candidates | 自进化生成的候选规则，状态为 pending 待审批 |

| prompt_templates | 提示词模板，存储预生成的 LLM 创建提示词 |

| enterprise_rules | 企业级规则配置（命名规范、必填字段、行业模板等） |

| sciot_properties | ItemType 属性元数据，供规则工厂注入上下文 |

| sciot_templates | 对象模板与必填字段定义 |

| sciot_sequences | 序列编号配置与当前值 |

| sciot_list_values | 列表字段可选值 |

四、核心功能详细说明

4.1 统一规则引擎 v3.0

统一规则引擎（UnifiedRuleEngine）是系统的核心，采用单一引擎驱动全部业务能力。引擎初始化时自动建表、同步内置规则，并具备自愈机制——当检测到规则表为空时自动重建。

规则数据结构：每条规则包含以下核心字段：

• 标识信息：id、name、description、scope、item_type_name
• 执行控制：severity（error/warning/info/hint）、priority（P0-P3）、conflict_strategy（first_match/stop/merge）
• 条件定义：condition（JSON结构化条件）、condition_script（自定义脚本条件）
• 动作定义：action_type（block/warn/suggest/auto_fix）、action_config、action_script
• 提示词关联：prompt_template、prompt_template_id、use_prompt_condition
• 统计信息：hit_count、last_hit_at、avg_duration_ms、user_correction_count

规则执行流程：

1. 调用execute(scope, context, options)方法
2. 通过_injectTypeContext注入ItemType相关上下文（规则工厂模式）
3. 从数据库加载匹配的活跃规则并按优先级排序
4. 逐条评估条件（_evaluateCondition），命中后执行动作（_executeAction）
5. 根据冲突策略决定是否继续执行后续规则
6. 记录执行历史并更新命中统计

引擎在执行过程中会将每次条件求值的结果、动作执行结果、耗时等写入审计日志，使每条规则的"是否执行、是否命中、耗时多少"全程可追溯。对于批量执行（batchExecute），引擎支持并发控制（默认5并发）与进度回调，便于在大规模数据治理场景下掌握执行进度。

4.2 多规则作用域（18种）

系统定义了18种规则作用域（RULE_SCOPES），覆盖工业业务全流程：

| 作用域 | 标识 | 功能说明 |

|--------|------|----------|

| 识别 | identify | 通过关键词匹配、属性特征识别对象类型 |

| 创建 | create | 对象创建时的综合校验和处理 |

| 创建前预处理 | create_pre | 默认值填充、自动编号、数据预处理（对应onBeforeAdd） |

| 创建后处理 | create_post | 关联对象创建、通知发送（对应onAfterAdd） |

| 修复 | repair | 检测并修复对象数据问题 |

| 优化 | optimize | 分析并优化对象数据质量 |

| 比对 | compare | 对象版本比对和差异检测 |

| 验证 | validate | 数据完整性和业务规则校验 |

| 转换 | transform | 数据格式转换（AML/JSON） |

| 生成 | generate | 基于模板生成结构化内容 |

| 巡检 | inspect | 批量巡检对象实例的数据质量 |

| 删除 | delete | 删除前关联引用检查 |

| 更新 | update | 更新字段合法性检查 |

| 导入 | import | 数据导入规则 |

| 导出 | export | 数据导出规则 |

| 审批 | approve | 审批信息完整性检查 |

| 估值 | valuate | 数据资产估值充分性检查 |

| 采集 | collect | 多源数据采集规则 |

不同作用域在对象生命周期中按既定顺序被调用。例如创建一个 Part 对象时，系统依次触发 create_pre（编号生成、默认值填充、双库查重）→ validate（必填与合规校验）→ create（综合处理）→ create_post（关联对象创建、子任务编号补全）。这种有序调度保证了跨工序、跨阶段的数据一致性。

4.3 LRU缓存机制

系统内置RuleCache类，实现基于LRU（最近最少使用）算法的多级缓存：

• TTL过期：每个缓存项设置生存时间（默认5分钟），过期自动失效
• 容量限制：最大缓存条目数（默认1000），超限时触发LRU淘汰
• 模式失效：支持按正则模式批量失效缓存（如invalidatePattern(/^rules:/)）
• 命中统计：记录命中数、未命中数、淘汰数，实时计算命中率
• 访问时间更新：每次缓存命中时更新最后访问时间，用于LRU淘汰决策

缓存应用于规则查询结果（TTL 60秒）和单条规则查询（TTL 300秒），显著降低数据库查询压力。

在高频创建场景下，同一 ItemType 的活跃规则集与上下文注入结果会被高频复用，LRU 缓存使规则查询命中率典型场景下超过 85%，单条规则的重复查询不再回源数据库。运维人员可通过缓存统计接口实时观察命中数、未命中数、淘汰数与命中率，作为容量与 TTL 调优的依据。

4.4 vm沙箱执行

系统采用Node.js内置的vm模块构建安全沙箱，执行用户自定义的规则脚本（condition_script和action_script）：

安全上下文（createSafeContext）：仅暴露白名单全局对象（Math、Date、JSON、Array、Object、String、Number、parseInt、parseFloat等），屏蔽process、require、global等危险对象，console方法被静默处理。

脚本执行（runSafeScript）：通过vm.createContext创建隔离上下文，vm.Script编译并执行脚本，确保规则脚本无法访问主进程环境。

动作脚本执行：在_executeAction方法中，action_script被包裹在立即执行函数中执行，设置5秒超时限制，防止恶意或低效脚本阻塞系统。

沙箱机制是系统"安全可控"承诺的技术底座。业务人员可以编写灵活的条件与动作脚本，而无需担心脚本越权访问文件系统、网络或进程环境。所有脚本均运行在受限上下文内，且每次执行均受超时约束，即便脚本存在死循环或低效逻辑，也会被强制中断并记入异常日志。

4.5 规则工厂模式

规则工厂模式是本系统的关键创新，通过_injectTypeContext方法实现"一套通用规则适配所有ItemType"：

在规则执行前，引擎根据context.item_type从数据库加载该类型的属性定义（sciot_properties），自动注入以下上下文：

1. _keyedField：识别编号字段（is_keyed=1或以_number结尾）
2. _requiredFields：必填字段列表（优先从sciot_templates.required_fields获取）
3. _defaultValues：默认值映射（从sciot_properties.default_value提取）
4. _lengthLimits：字段长度限制（从stored_length提取）
5. _listFields：list字段可选值（从sciot_list_values加载）
6. _datePairs：日期对（start_date/end_date模式自动识别）
7. _itemPropConfigs：Item类型属性配置（从generation_rules提取）
8. sequenceConfig：序列编号配置（从sciot_sequences加载）
9. _matchResult：双库查重结果（私有库+标准库）

基于这些注入的上下文，通用规则（如builtin-generic-required-check、builtin-generic-sequence-gen等）能够自动适用于所有ItemType，无需为每种对象类型单独编写规则。

规则工厂模式带来的直接收益是新对象类型"零编码接入"：当企业新增一种 ItemType 时，只需在 sciot_properties 中登记其属性元数据，规则工厂即可自动为其生成编号生成、必填校验、默认值填充、长度校验等全套规则，无需编写任何规则代码。

4.6 规则冲突检测与处理

系统支持多层次的规则冲突处理：

执行时冲突策略（conflict_strategy）：

• first_match：首条匹配规则执行后停止（默认策略）
• stop：执行后立即停止
• merge：合并执行所有匹配规则的结果

规则意图冲突检测（detectRuleConflicts）：规则意图解释器对全部规则进行两两比对，检测以下冲突类型：

• 数值约束冲突（≥与≤矛盾）
• 语气风格冲突（专业严谨与口语化矛盾）

冲突解决遵循优先级顺序：合规 > 品牌 > 技术准确性 > 内容完整性 > 可读性 > SEO。

冲突检测既发生在"执行时"（由 conflict_strategy 决定多条命中如何裁决），也发生在"设计时"（由规则意图解释器主动扫描潜在语义冲突）。后者对于拥有数十条规则的中大型规则库尤为重要——它能在规则上线前发现"一条要求字段长度≤20，另一条要求≥30"这类隐性矛盾，避免业务在运行时得到自相矛盾的拦截结果。

4.7 规则自进化引擎

规则自进化引擎（RuleEvolution）实现规则的自动优化闭环：

修正采集：当用户修正规则执行结果时，原始输出和修正后的输出记录到sciot_corrections表，同时递增对应规则的user_correction_count。

模式识别（_detectPattern）：分析多条修正记录，统计各字段的修改频率，当某字段修改频率超过50%时判定为可识别模式。通过_findDominantValue找出主导修正值，计算置信度（最高0.95）。

规则候选生成（_generateRuleScript）：基于检测到的模式自动生成条件脚本和动作脚本，存入sciot_rule_candidates表，状态为pending。

审批部署（approveRule）：人工审批通过的候选规则被写入sciot_rules_v2表，source标记为'evolved'，立即生效。

效能监控（monitorRuleHealth）：

• 自动降级：修正率超过30%的规则自动标记为不活跃
• 优化推荐：高频但高延迟（avg_duration_ms > 2000ms）的规则标记为优化候选，建议用确定性脚本替代LLM调用

自进化闭环的意义在于让规则库"越用越准"。系统不会自动覆盖既有规则——所有进化出的候选规则都必须经过人工审批，因此既享受了数据驱动的持续优化，又保留了人类对规则的最终控制权。

4.8 企业规则配置系统

企业规则系统（EnterpriseRules）支持6类企业级规则配置：

1. 命名规范（naming_convention）：支持camelCase、PascalCase、snake_case、UPPER_SNAKE四种命名规范自动校验
2. 必填字段（required_fields）：企业级必填字段配置
3. 禁止模式（forbidden_patterns）：正则表达式数组，匹配的属性名视为违规
4. 数据类型标准（data_type_standards）：字段数据类型规范映射
5. 关系标准（relationship_standards）：对象类必须包含的关系类型
6. 行业模板（industry_template）：预置IATF16949（汽车行业）、ISO9001（机械装备）、通用ISO9001三个行业模板，一键应用

系统通过validateType方法对对象类进行健康度评分（满分100分），根据违规项扣分并生成详细的违规清单。

企业规则与"统一规则引擎"的关系可以概括为"全局基线 + 局部特例"：企业规则作为跨对象类型的基线约束（如全公司命名规范），统一规则引擎中的具体规则作为针对某一对象类型或某一作用域的特例约束，两者在对象创建/校验时共同生效。

4.9 规则意图解释器

规则意图解释器（RuleIntentInterpreter）提供规则的可解释性能力：

规则意图解读（interpretRuleIntent）：基于LLM分析规则定义，回答三个核心问题——规则为什么存在（whyExists）、保护什么（whatProtects）、影响什么（whatAffects）。解读结果持久化存储，支持内部规则标记和人工确认标记。

规则变更分析（interpretRuleChange）：当规则发生变更时，生成变更摘要、业务影响评估、受影响流程列表和建议行动方案。

执行结果内容转换（convertRuleResultToContent）：将规则执行结果转化为可读的内容作品（质量洞察报告），支持内容管理系统集成。

规则聚合分析（aggregateRulesByScope）：按作用域聚合规则，按数据完整性、业务合规、品牌一致性等维度分组统计，识别高频触发规则。

规则意图解释器降低了规则治理的门槛。对于审计、质量、合规等非技术角色，过去他们难以理解一条脚本化规则的真实含义；现在通过 LLM 解读，每条规则都能以自然语言说明"为什么存在、保护什么、影响什么"，使规则审批、变更评审、冲突裁决更加透明。

4.10 提示词预生成

系统支持为指定ItemType预生成创建提示词，并存入prompt_templates表：

• 单类型生成：根据ItemType的属性定义、关系定义、序列规则、校验规则、客户端方法等信息，自动构建完整的LLM创建提示词
• 批量生成：一键为所有ItemType批量生成提示词
• 动态字段分类：自动区分LLM可生成字段与系统自动填充字段
• 关系模型提示：自动识别SCSAI Type A（标准关系）和Type B（关系对象），生成关系建模指导
• 身份角色约束：自动加载可用Identity列表，防止LLM编造不存在的身份

提示词预生成将"规则"与"大模型"紧密衔接：系统把对象类型约束（必填、长度、列表值、序列规则）编译为结构化的 LLM 提示词，使大模型在生成对象数据时自动遵守企业规则，从源头降低需要规则引擎事后拦截的概率。

4.11 对象创建完整生命周期

createItem方法实现对象创建的完整规则生命周期：

1. validate阶段：执行验证规则，若有error级阻断则终止创建
2. create_pre阶段：执行创建前预处理（默认值填充、编号生成、双库查重）
3. AML构建与提交：构建AML报文，通过_applyAMLWithRetry提交到SCSAI，支持权限重试、唯一性重试、超时重试，以及分步降级创建
4. 序列更新：更新sciot_sequences的序列值
5. create_post阶段：执行创建后处理（关联对象创建、子任务编号补全）

4.12 双库查重机制

创建对象前，系统同时查询 SCSAI 私有库和标准库模板，基于加权相似度算法自动决策：

• 精确匹配：编号/关键属性完全一致，直接引用已有对象，避免重复创建；
• 子串匹配：编号呈现包含关系或标准前缀匹配，提示可能重复；
• Jaccard 词级相似度：对名称、描述等文本字段计算集合相似度，超过阈值则判定为疑似重复。

查重结果通过 _matchResult 注入规则上下文，供 create_pre 阶段规则引用，决定"引用 / 复制 / 新建"的处理分支，从源头控制主数据冗余。

4.13 批量执行与进度回调

针对历史数据治理、全量巡检等场景，引擎提供 batchExecute 能力：

• 支持传入对象批次与统一作用域（如 inspect / repair）；
• 内置并发控制（默认5并发），避免瞬时压垮数据库或下游 SCSAI；
• 提供进度回调（onProgress），实时上报"已处理 / 总数 / 命中数 / 失败数"；
• 单条失败不影响整体，失败明细集中于结果集返回，便于二次处理。

4.14 规则编写示例（JSON 实例）

为帮助实施人员快速上手，以下给出一条与 4.1 字段结构完全一致的真实规则定义示例。该示例实现"物料（Part）创建时必填字段校验"，命中后执行 block 拦截：

{
  "name": "物料必填字段检查",
  "scope": "create",
  "item_type_name": "Part",
  "severity": "error",
  "priority": "P0",
  "conflict_strategy": "first_match",
  "condition": {
    "required": ["part_number", "name", "material_code"]
  },
  "action_type": "block",
  "action_config": {
    "message": "缺失必填字段，请补全后再提交"
  }
}

字段说明与 4.1 的对应关系如下：scope 决定规则在对象生命周期的哪个阶段生效；item_type_name 限定适用的对象类型（留空表示全类型通用）；severity=error 配合 action_type=block 构成"硬拦截"；priority=P0 表示最高优先级，便于在 first_match 策略下优先裁决；condition.required 由规则工厂注入的 _requiredFields 在运行时动态解析。

若需更灵活的判断（如"当状态为废弃时免校验"），可将 condition_script 替换为一段 vm 沙箱脚本，利用白名单内的 context 对象做条件求值，脚本执行受 4.4 所述 5 秒超时约束，确保安全。

五、软件创新点与优势

5.1 创新点

1. 单一引擎驱动全部业务能力：区别于传统系统中校验、修复、优化各自独立模块的设计，本系统以统一规则引擎驱动全部18种业务能力，规则定义和执行机制完全统一，大幅降低系统复杂度。

1. 规则工厂模式实现零编码全覆盖：通过上下文注入机制，通用规则自动适配所有ItemType，新增对象类型无需编写任何规则代码即可获得编号生成、必填校验、默认值填充、长度校验等全套能力。

1. 规则自进化闭环：业界首创的"修正采集→模式识别→候选生成→审批部署→效能监控"全闭环机制，使规则能够基于实际使用数据自动优化，持续提升准确率。

1. 双库查重机制：创建对象前同时查询SCSAI私有库和标准库模板，基于加权相似度算法（支持精确匹配、子串匹配、Jaccard词级相似度）自动决策引用、复制或新建，避免数据重复。

1. vm沙箱安全执行：采用Node.js vm模块构建安全沙箱，白名单暴露全局对象，5秒超时限制，确保用户自定义规则脚本无法危害系统安全。

1. LLM增强的规则可解释性：通过大语言模型自动解读规则的商业意图，使非技术人员也能理解规则存在的价值和影响范围。

1. 统一调度编排循环工程：将多个作用域规则按工艺链顺序编排为可复用的循环工程方案，作为数字员工与原子能力的统一调度核心，突破了单条规则"各自为政"的局限。

5.2 技术优势

1. 高性能：LRU多级缓存使规则查询命中率显著提升，缓存统计实时可见；批量执行支持并发控制（默认5并发）和进度回调。

1. 高可用：规则表自愈机制确保即使数据库异常后规则表为空，也能自动重建并同步内置规则；AML提交支持3级重试（权限重试、唯一性重试、超时重试）和分步降级创建。

1. 高扩展：规则来源支持5种途径（手工录入、AML导入、SCSAI同步、规则工厂自动生成、自进化候选审批）；数据存储兼容SQLite和MySQL；外部集成支持SCSAI PLM、LLM大模型、n8n工作流引擎。

1. 企业级：支持IATF16949、ISO9001等行业标准模板；提供命名规范、必填字段、禁止模式等6类企业规则配置；对象类健康度评分量化评估数据质量。

1. 安全可控：vm沙箱隔离用户脚本；规则审批流程确保自进化规则经人工确认后生效；内部规则标记机制限制敏感规则访问。

5.3 与传统方案的对比

5.4 典型部署拓扑

系统在实际生产中常见以下两种部署拓扑：

• 单节点一体化部署：应用、规则引擎、SQLite 库同机部署，适用于中小型企业或部门级场景，部署简单、运维成本低，对应第二章"小型/中型"硬件规格。
• 应用与数据分离部署：应用服务多节点水平扩展，后端对接独立 MySQL 实例（通过 db-adapter 兼容），前端经 API 网关统一鉴权与限流。该拓扑适用于集团级场景，配合第十一章安全机制与第十章健康检查实现高可用。

无论何种拓扑，规则引擎作为"统一调度核心"的定位不变，所有对象操作均经同一规则库裁决，从根本上保证跨节点、跨系统的规则一致性。

六、软件操作步骤与使用说明（含操作界面截图）

本章以典型业务场景为例，展示软件的部署启动、规则配置、规则生成与对象操作执行流程。以下截图均为软件真实运行界面。每一步均按"点击哪里 → 看到什么 → 得到什么结果"的粒度描述，便于实施人员按图索骥完成操作。

6.1 服务部署与初始化

1. 安装 Node.js 运行环境（v18.0+），拉取服务代码后进入项目根目录，执行 npm install 完成依赖安装；
2. 配置数据库连接（SCSAI / 业务数据库地址、账号）与多级缓存参数（容量、TTL），保存配置文件；
3. 执行启动脚本（如 npm start 或 node server/index.js）启动统一规则引擎服务；
4. 点击启动后的控制台窗口 → 看到初始化日志中输出"规则表自检通过 / 内置规则同步完成"等提示 → 得到"服务已就绪、可接收规则请求"的运行状态，表明引擎初始化成功。

#### 图6-1 规则引擎平台总览【界面图·待补真实截图】

• 截图来源：网页端 BossAgents
• 应展示：规则引擎平台总览仪表盘
• 截图保存为 ../shots/sc2-3-platform.png 后告知我，自动替换为正式图注

图6-1服务启动控制台 / 初始化成功日志界面。

6.2 配置业务规则

1. 进入"企业规则配置系统"或规则管理控制台，点击"新建规则"按钮；
2. 在编辑页填写规则名称、选择规则作用域（18 种作用域之一）、设置匹配条件（JSON 结构化条件或 condition_script）与执行动作（action_type 与 action_config）；
3. 点击"保存并启用"；
4. 点击"保存并启用"后 → 看到系统自动执行冲突检测，并弹窗提示"无冲突 / 发现 N 处冲突建议" → 得到一条 is_active=true 的活跃规则，立即参与后续对象操作的命中。

#### 图6-2 规则配置编辑【界面图·待补真实截图】

• 截图来源：网页端 BossAgents
• 应展示：规则配置编辑界面
• 截图保存为 ../shots/sc2-4-rule-config.png 后告知我，自动替换为正式图注

图6-2规则配置编辑界面（条件 / 动作配置）。

6.3 规则工厂自动生成

1. 在控制台触发"规则工厂"功能，系统从 sciot_properties 自动解析所有 ItemType；
2. 点击"一键生成"按钮 → 看到进度条与逐类型生成日志（如"已为 Part 生成 12 条规则"） → 得到覆盖全部对象类型的默认规则集，包含编号生成、必填校验、默认值、长度校验等；
3. 在规则列表中查看生成结果，对个别对象类型按需微调（如增删字段约束）。

#### 图6-3 规则库列表界面【界面图·待补真实截图】

• 截图来源：网页端 BossAgents
• 应展示：规则库列表界面
• 截图保存为 ../shots/sc2-1-rules.png 后告知我，自动替换为正式图注

图6-3规则工厂生成结果 / ItemType 规则列表界面。

6.4 执行对象操作（识别 / 创建 / 修复 / 优化）

1. 在业务入口（如 PLM 创建页或本系统对象操作页）提交对象操作请求（如创建 Part、修复属性）；
2. 点击"提交 / 执行"按钮 → 看到规则引擎按优先级匹配规则并在 vm 沙箱执行，页面实时显示命中规则名称与动作 → 得到执行结果（通过 / 拦截 / 自动修复），并可在审计日志中查看每条规则的命中详情；
3. 若被拦截，根据提示补充缺失字段后重新提交。

图6-4对象操作执行结果 / 规则命中审计日志界面。

6.5 规则冲突检测与处理

在规则库界面选中多条可能冲突的规则，点击"冲突检测"，系统按 conflict_strategy 给出裁决建议；管理员可调整优先级或切换为 merge 合并执行，变更即时生效。

1. 在规则列表界面，使用复选框选中两条及以上疑似冲突的规则（如一条要求长度≤20、另一条要求≥30）；
2. 点击顶部"冲突检测"按钮 → 看到规则意图解释器输出的两两比对结果，标注"数值约束冲突"及建议裁决策略 → 得到一份冲突报告，列出冲突类型与推荐处理方案；
3. 管理员在报告中选择"调整优先级"或"切换为 merge 合并执行"，点击确认 → 看到规则 conflict_strategy 即时更新 → 得到生效后的冲突策略，后续命中即按新策略裁决。

#### 图6-5 规则配置编辑【界面图·待补真实截图】

• 截图来源：网页端 BossAgents
• 应展示：规则配置编辑界面
• 截图保存为 ../shots/sc2-4-rule-config.png 后告知我，自动替换为正式图注

图6-5 规则冲突检测与处理（在规则配置界面触发冲突检测）。

6.6 规则自进化与反馈闭环

当某条由大模型建议的规则被人工采纳，系统将其沉淀为可复用规则并进入"待审核"列表；在规则工厂的审核页确认后，该规则纳入正式规则集参与后续命中。

1. 在对象操作审计日志中发现某规则被用户多次修正，系统后台在修正记录达到阈值（默认5条）后自动生成候选规则；
2. 进入"规则工厂 → 自进化候选"页，看到 sciot_rule_candidates 中状态为 pending 的候选规则及置信度 → 得到待审批的规则候选清单；
3. 点击某候选规则的"审批通过" → 看到候选被写入 sciot_rules_v2 且 source 标记为 evolved、is_active=true → 得到一条正式生效的进化规则，参与后续命中。

图6-6 规则自进化候选审批（规则列表中的 evolved 来源规则）。

6.7 提示词模板预生成与导出

在"提示词预生成"页选择作用域，系统依据当前规则自动渲染 {{变量}} 模板并预览；确认无误后可一键导出 JSON，供大模型调用方直接消费。

1. 进入"提示词预生成"页，在对象类型下拉框选择目标 ItemType（如 Part），并选择作用域；
2. 点击"生成"按钮 → 看到系统依据当前规则自动渲染的 {{变量}} 模板预览（区分 LLM 可生成字段与系统自动填充字段） → 得到一份结构化 LLM 创建提示词；
3. 点击"导出 JSON" → 看到浏览器下载 prompt_templates 对应记录的 JSON 文件 → 得到可由大模型调用方直接消费的提示词文件。

图6-7 提示词模板预生成与导出（与规则库联动预览）。

6.8 规则库批量导入与导出

点击"导出"下载当前规则数组模板；按字段（name/scope/condition/action_type）填充后，通过"导入"上传，系统校验格式并原子写入，失败行会给出具体原因。

1. 在规则列表页点击"导出" → 看到下载的规则数组 JSON 模板（含 name/scope/condition/action_type 等字段） → 得到标准导入模板；
2. 在本地按要求填充多条规则后，回到列表页点击"导入"并选择文件上传；
3. 系统校验格式后执行原子写入 → 看到"成功 N 条 / 失败 M 条"的结果回执，失败行附具体原因（如字段缺失、scope 非法） → 得到批量写入的规则集（任一失败整批回滚，保证一致性）。

#### 图6-8 规则配置编辑【界面图·待补真实截图】

• 截图来源：网页端 BossAgents
• 应展示：规则配置编辑界面
• 截图保存为 ../shots/sc2-4-rule-config.png 后告知我，自动替换为正式图注

图6-8 规则库批量导入与导出（规则列表界面）。

6.9 规则健康度评估与效能监控

规则上线并非终点，持续的效能监控才能保证规则库长期健康。系统提供两类健康度视角：

1. 对象类健康度评分：由企业规则系统 validateType 对指定对象类打 0~100 分，按命名规范、必填字段、禁止模式、数据类型、关系标准等维度扣分并生成违规清单。运维人员进入企业规则配置页点击"健康度评分" → 看到该对象类的得分与各违规项明细 → 得到量化的数据质量画像，据此优先治理低分对象类。
2. 规则效能监控：由自进化引擎 monitorRuleHealth 持续观察每条规则的修正率与耗时。当某规则修正率超过 AUTO_DEGRADE_RATE（默认 0.3）时自动标记为不活跃；当平均耗时 avg_duration_ms 超过 SLOW_RULE_MS（默认 2000ms）时标记为优化候选，建议用确定性脚本替代 LLM 调用。运维人员在规则列表按"效能"排序 → 看到高修正率/高延迟的标红规则 → 得到优化优先级清单，据此重构低效规则。

七、典型应用场景案例（含真实运行界面）

本章以真实业务场景为例，展示软件在工业生产环境中的实际运行效果。以下截图均为系统真实运行界面或真实生成的业务报告。每个场景均按"业务背景 → 操作要点 → 运行截图 → 预期结果"的结构描述，场景均基于本规则引擎真实功能（必填校验、循环工程、统一调度、规则库、冲突检测、自进化等），不虚构不存在的模块。

7.1 场景一：工业对象必填字段校验

• 业务背景：在创建/修整类工业对象（如"整理""修整""制展开"）时，业务人员常因漏填关键字段导致下游工艺链无法衔接。质量体系要求关键字段 100% 完整。
• 操作要点：在规则库启用 builtin-generic-required-check 通用规则（由规则工厂针对该 ItemType 注入 _requiredFields），在 create/validate 作用域对缺失字段进行 error 级拦截。
• 运行截图：

图7-1 场景一：工业对象必填字段校验（规则库列表与命中审计日志）。

• 预期结果：缺失关键字段的提交被即时拦截，页面与审计日志均列出具体缺失项，数据完整性达标率显著提升。

7.2 场景二：工艺规程循环工程自动生成

• 业务背景：针对"制展开→巡检加热→整理→清理移交"的工艺链，传统方式需人工逐工序编排，效率低且易错。
• 操作要点：通过统一调度编排将各工序规则按预设顺序登记为循环工程，由 scheduleRules 驱动，并由 _syncBuiltinRules 保证内置规则一致性。
• 运行截图：

图7-2 场景二：工艺规程循环工程自动生成（循环工程界面）。

• 预期结果：一次触发即可自动生成可执行的循环工程方案，多工序规则有序执行，工序衔接零人工干预。

7.3 场景三：统一调度平台运行监控

• 业务背景：在 BossAgents 工业智能平台上，需要统一的调度核心来驱动数字员工与原子能力，避免能力孤岛。
• 操作要点：将本规则引擎注册为平台统一调度核心，所有对象操作经由引擎路由，实时上报命中与效能数据。
• 运行截图：

图7-3 场景三：统一调度平台运行监控（平台运行控制台）。

• 预期结果：平台控制台实时展示规则命中、拦截与自进化状态，运维人员可在单一界面掌握全局调度健康度。

7.4 场景四：企业命名规范合规校验

• 业务背景：某机械装备企业要求所有对象编号遵循 PascalCase 命名规范，IATF16949 审核中曾因编号混乱被开具不符合项。
• 操作要点：在企业规则配置中启用 naming_convention=PascalCase，规则引擎在 create_pre / validate 作用域对编号字段做格式校验。
• 运行截图：

图7-4 场景四：企业命名规范合规校验（规则命中审计）。

• 预期结果：不符合 PascalCase 的编号在提交时被拦截并提示正确样例，外部审核时的命名合规率提升至 100%。

7.5 场景五：双库查重避免主数据冗余

• 业务背景：物料主数据分散在 SCSAI 私有库与标准库模板中，重复创建会造成一物多码、库存统计失真。
• 操作要点：在 create_pre 阶段由引擎执行双库查重，基于加权相似度（精确/子串/Jaccard）通过 _matchResult 决策引用、复制或新建。
• 运行截图：

#### 图7-5 规则引擎平台总览【界面图·待补真实截图】

• 截图来源：网页端 BossAgents
• 应展示：规则引擎平台总览仪表盘
• 截图保存为 ../shots/sc2-3-platform.png 后告知我，自动替换为正式图注

图7-5 场景五：双库查重（统一调度平台查重决策界面）。

• 预期结果：疑似重复对象被提示引用既有主数据或复制标准模板，新建重复率显著下降，主数据唯一性得到保障。

7.6 场景六：规则自进化沉淀质量经验

• 业务背景：质量工程师频繁手工修正某类对象的"默认责任人"字段，说明既有规则覆盖不足。
• 操作要点：当该类对象修正记录达到阈值后，自进化引擎在 sciot_corrections 上识别主导修正值并生成候选规则，经质量工程师在审核页审批后生效。
• 运行截图：

图7-6 场景六：规则自进化（规则库中 evolved 来源规则）。

• 预期结果：该字段后续创建自动带入正确默认值，人工修正率随时间下降，规则库沉淀了真实质量经验。

7.7 场景七：规则意图解释支撑审计评审

• 业务背景：ISO9001 监督审核要求对关键控制规则提供"为什么存在、保护什么"的说明，传统脚本规则难以向审核员解释。
• 操作要点：对关键规则调用规则意图解释器，生成 whyExists / whatProtects / whatAffects 自然语言说明，并标记为人工确认。
• 运行截图：

#### 图7-7 规则配置编辑【界面图·待补真实截图】

• 截图来源：网页端 BossAgents
• 应展示：规则配置编辑界面
• 截图保存为 ../shots/sc2-4-rule-config.png 后告知我，自动替换为正式图注

图7-7 场景七：规则意图解释（规则配置页展示意图解读）。

• 预期结果：每条关键规则均附有可审计的自然语言说明，审核员无需阅读脚本即可确认控制逻辑，评审通过率提升。

7.8 场景八：批量巡检优化历史数据

• 业务背景：历史库中存在大量属性缺失、日期对不完整的陈旧对象，人工巡检成本高。
• 操作要点：使用 inspect / optimize 作用域的批量执行能力，对目标对象批次发起巡检，并发控制（默认5）保障平稳运行，进度回调实时上报。
• 运行截图：

图7-8 场景八：批量巡检优化（循环工程/批量执行结果界面）。

7.9 场景规则配置速查表

为便于快速落地，以下汇总上述 8 个场景对应的规则作用域、关键能力与适用对象类型：

| 场景 | 主作用域 | 关键能力 | 适用对象类型 |

|------|----------|----------|--------------|

| 一、必填字段校验 | create / validate | 通用必填检查 | 整理/修整/制展开等 |

| 二、循环工程生成 | create / scheduleRules | 统一调度编排 | 工艺规程类 |

| 三、统一调度监控 | apply | 平台运行监控 | 数字员工/原子能力 |

| 四、命名规范合规 | create_pre / validate | naming_convention | 全部对象 |

| 五、双库查重 | create_pre | 加权相似度查重 | 物料主数据 |

| 六、自进化沉淀 | repair / evolved | 修正模式识别 | 高频修正对象 |

| 七、意图解释评审 | interpretRuleIntent | LLM 意图解读 | 关键控制规则 |

| 八、批量巡检优化 | inspect / optimize | 批量执行+进度回调 | 历史对象批次 |

7.10 典型规则 JSON 示例

以下给出"编号长度校验"与"循环工程工序编排"两类真实可用规则的精简示例，字段结构与 4.1、4.13 一致：

{
  "name": "编号长度校验",
  "scope": "create_pre",
  "item_type_name": "Part",
  "severity": "warning",
  "priority": "P1",
  "condition_script": "return context.part_number && context.part_number.length <= 20;",
  "action_type": "warn",
  "action_config": { "message": "编号长度建议不超过20位" }
}

{
  "name": "制展开工艺链循环工程",
  "scope": "create",
  "item_type_name": "ProcessRoute",
  "severity": "info",
  "priority": "P2",
  "conflict_strategy": "merge",
  "action_type": "auto_fix",
  "action_config": {
    "schedule": ["制展开", "巡检加热", "整理", "清理移交"]
  }
}

• 预期结果：系统输出巡检报告，列出问题对象清单与建议修复动作，运维人员据此批量修复，历史数据质量评分（健康度）明显上升。

八、数据接口与集成说明

软件对外提供以下核心接口（函数级 / HTTP 级），均已在运行环境中验证可用：

| 接口 | 说明 |

|------|------|

| GET /api/rule-engine/rules | 返回全部规则定义（id/name/scope/severity/priority） |

| POST /api/rule-engine/validate | 对指定对象执行规则校验，返回命中规则与拦截结果 |

| GET /api/rule-engine/list | 分页返回规则清单 |

| POST /api/rule-engine/apply | 将规则应用到对象操作链路 |

上述接口与《软件源代码》中的实现一一对应，可作为软件可运行、可验证的直接证据。

8.1 GET /api/rule-engine/rules

功能：返回全部规则定义，常用于健康检查、规则清单核对与平台运行监控。

请求示例（curl）：

curl -X GET "http://localhost:3100/api/rule-engine/rules" \
  -H "Authorization: Bearer <TOKEN>" \
  -H "Content-Type: application/json"

响应示例（JSON）：

{
  "code": 0,
  "message": "ok",
  "data": [
    {
      "id": "r-1001",
      "name": "必填字段检查",
      "scope": "create",
      "severity": "error",
      "priority": "P0",
      "is_active": true,
      "hit_count": 1284,
      "avg_duration_ms": 0.42
    },
    {
      "id": "r-1002",
      "name": "编号长度校验",
      "scope": "create_pre",
      "severity": "warning",
      "priority": "P1",
      "is_active": true,
      "hit_count": 902,
      "avg_duration_ms": 0.31
    }
  ]
}

请求参数表：

| 参数 | 类型 | 必填 | 说明 |

|------|------|------|------|

| Authorization | Header(String) | 是 | Bearer 令牌，用于鉴权 |

| scope | Query(String) | 否 | 按作用域过滤，如 create / repair |

| item_type_name | Query(String) | 否 | 按对象类型过滤 |

| is_active | Query(Boolean) | 否 | 仅返回启用中的规则 |

响应字段表：

| 字段 | 类型 | 说明 |

|------|------|------|

| code | Number | 状态码，0 表示成功 |

| message | String | 结果描述 |

| data[].id | String | 规则唯一标识 |

| data[].name | String | 规则名称 |

| data[].scope | String | 规则作用域 |

| data[].severity | String | 严重级别 error/warning/info/hint |

| data[].priority | String | 优先级 P0-P3 |

| data[].is_active | Boolean | 是否启用 |

| data[].hit_count | Number | 历史命中次数 |

| data[].avg_duration_ms | Number | 平均执行耗时（毫秒） |

8.2 POST /api/rule-engine/validate

功能：对指定对象执行规则校验，返回命中规则与拦截结果，是对象提交前的核心校验入口。

请求示例（curl）：

curl -X POST "http://localhost:3100/api/rule-engine/validate" \
  -H "Authorization: Bearer <TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "scope": "create",
    "item_type_name": "Part",
    "context": {
      "name": "齿轮-001",
      "part_number": "GEAR-001",
      "description": "传动齿轮",
      "_requiredFields": ["part_number", "name"]
    }
  }'

响应示例（JSON）：

{
  "code": 0,
  "message": "ok",
  "data": {
    "passed": false,
    "blocked": true,
    "hits": [
      {
        "rule_id": "r-1001",
        "rule_name": "必填字段检查",
        "severity": "error",
        "action_type": "block",
        "message": "缺失必填字段：material_code"
      }
    ],
    "duration_ms": 1.8
  }
}

请求参数表：

| 参数 | 类型 | 必填 | 说明 |

|------|------|------|------|

| Authorization | Header(String) | 是 | Bearer 令牌 |

| scope | Body(String) | 是 | 校验作用域，如 create/validate/repair |

| item_type_name | Body(String) | 是 | 对象类型名称 |

| context | Body(Object) | 是 | 待校验对象的属性上下文 |

响应字段表：

| 字段 | 类型 | 说明 |

|------|------|------|

| code | Number | 状态码 |

| data.passed | Boolean | 是否通过全部校验 |

| data.blocked | Boolean | 是否被 error 级规则拦截 |

| data.hits[].rule_id | String | 命中规则标识 |

| data.hits[].rule_name | String | 命中规则名称 |

| data.hits[].severity | String | 严重级别 |

| data.hits[].action_type | String | 动作类型 block/warn/suggest/auto_fix |

| data.hits[].message | String | 命中说明 |

| data.duration_ms | Number | 本次校验耗时（毫秒） |

8.3 GET /api/rule-engine/list

功能：分页返回规则清单，便于管理控制台展示与批量操作。

请求示例（curl）：

curl -X GET "http://localhost:3100/api/rule-engine/list?page=1&pageSize=20&scope=create" \
  -H "Authorization: Bearer <TOKEN>"

响应示例（JSON）：

{
  "code": 0,
  "message": "ok",
  "data": {
    "total": 76,
    "page": 1,
    "pageSize": 20,
    "items": [
      {
        "id": "r-1001",
        "name": "必填字段检查",
        "scope": "create",
        "severity": "error",
        "priority": "P0"
      }
    ]
  }
}

请求参数表：

| 参数 | 类型 | 必填 | 说明 |

|------|------|------|------|

| Authorization | Header(String) | 是 | Bearer 令牌 |

| page | Query(Number) | 否 | 页码，默认 1 |

| pageSize | Query(Number) | 否 | 每页条数，默认 20 |

| scope | Query(String) | 否 | 按作用域过滤 |

响应字段表：

| 字段 | 类型 | 说明 |

|------|------|------|

| code | Number | 状态码 |

| data.total | Number | 规则总数 |

| data.page | Number | 当前页码 |

| data.pageSize | Number | 每页条数 |

| data.items[] | Array | 当前页规则列表 |

8.4 POST /api/rule-engine/apply

功能：将规则应用到对象操作链路（如创建、修复），触发完整作用域调度并返回执行结果。

请求示例（curl）：

curl -X POST "http://localhost:3100/api/rule-engine/apply" \
  -H "Authorization: Bearer <TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "scope": "create",
    "item_type_name": "Part",
    "action": "createItem",
    "payload": {
      "name": "齿轮-001",
      "part_number": "GEAR-001",
      "material_code": "MC-100"
    }
  }'

响应示例（JSON）：

{
  "code": 0,
  "message": "ok",
  "data": {
    "applied_scopes": ["create_pre", "validate", "create", "create_post"],
    "blocked": false,
    "auto_fix_applied": ["default_value_fill", "sequence_gen"],
    "item_id": "PART-2026-000123",
    "duration_ms": 12.4
  }
}

请求参数表：

| 参数 | 类型 | 必填 | 说明 |

|------|------|------|------|

| Authorization | Header(String) | 是 | Bearer 令牌 |

| scope | Body(String) | 是 | 主作用域 |

| item_type_name | Body(String) | 是 | 对象类型名称 |

| action | Body(String) | 是 | 触发的操作，如 createItem |

| payload | Body(Object) | 是 | 对象业务数据 |

响应字段表：

| 字段 | 类型 | 说明 |

|------|------|------|

| code | Number | 状态码 |

| data.applied_scopes | Array | 实际执行的作用域顺序 |

| data.blocked | Boolean | 是否被拦截 |

| data.auto_fix_applied | Array | 已自动修复的动作列表 |

| data.item_id | String | 生成的对象标识 |

| data.duration_ms | Number | 总耗时（毫秒） |

8.5 集成与扩展说明

• SCSAI PLM 集成：通过 REST API 对接 SCSAI，规则执行结果以 AML 报文提交，支持权限/唯一性/超时三级重试。
• n8n 工作流集成：系统可导出 n8n 工作流节点，将规则引擎封装为工作流中的"校验/修复"节点。
• LLM 集成：可选接入大模型 API，用于规则意图解读、提示词预生成与执行结果内容转换。
• 数据格式：规则支持 JSON 结构化条件与 AML/JSON 互转（transform 作用域），便于跨系统交换。

8.6 统一错误响应结构

所有 HTTP 接口均遵循统一的响应结构，便于调用方做一致化处理：

{
  "code": 0,
  "message": "ok",
  "data": { }
}

| 字段 | 类型 | 说明 |

|------|------|------|

| code | Number | 业务状态码，0 为成功，非 0 见第十五章错误码对照表 |

| message | String | 结果描述，成功为 ok，失败为具体原因 |

| data | Object/Array | 业务数据载体，失败时通常为空 |

调用方应首先判断 code：非零时按 message 展示错误，并按第十五章错误码对照表映射到运维动作；网络层异常（如连接超时）需结合 HTTP 状态码（401 鉴权失败、429 限流、5xx 服务异常）综合处理。

九、参数配置说明

本章列出系统的主要可配置参数，供实施与运维人员调优。所有参数均通过配置文件或环境变量注入，支持热更新（部分需重启生效，已注明）。

| 序号 | 参数名 | 类型 | 默认值 | 说明 |

|------|--------|------|--------|------|

| 1 | SERVER_PORT | Number | 3100 | HTTP 服务监听端口 |

| 2 | DB_TYPE | String | sqlite | 数据库类型，支持 sqlite / mysql |

| 3 | DB_PATH | String | ./data/rules.db | SQLite 数据库文件路径 |

| 4 | DB_HOST | String | 127.0.0.1 | MySQL 主机（DB_TYPE=mysql 时生效） |

| 5 | DB_PORT | Number | 3306 | MySQL 端口 |

| 6 | DB_NAME | String | sciot | 数据库名 |

| 7 | CACHE_MAX_SIZE | Number | 1000 | LRU 缓存最大条目数，超限触发 LRU 淘汰 |

| 8 | CACHE_TTL_RULESET | Number | 60 | 规则集查询缓存 TTL（秒） |

| 9 | CACHE_TTL_RULE | Number | 300 | 单条规则查询缓存 TTL（秒） |

| 10 | SANDBOX_TIMEOUT_MS | Number | 5000 | vm 沙箱单条脚本执行超时（毫秒） |

| 11 | SANDBOX_TIMEOUT_ACTION | Number | 200 | 动作脚本安全时限（毫秒，详见第十三章） |

| 12 | BATCH_CONCURRENCY | Number | 5 | 批量执行并发数 |

| 13 | CORRECTION_THRESHOLD | Number | 5 | 触发自进化模式识别的修正记录阈值 |

| 14 | PATTERN_FREQ_RATIO | Number | 0.5 | 字段修改频率超过该比例判定为可识别模式 |

| 15 | MAX_CONFIDENCE | Number | 0.95 | 自进化候选规则最高置信度 |

| 16 | AUTO_DEGRADE_RATE | Number | 0.3 | 修正率超过该值的规则自动标记为不活跃 |

| 17 | SLOW_RULE_MS | Number | 2000 | 平均耗时超过该值的规则标记为优化候选 |

| 18 | ENABLE_LLM | Boolean | false | 是否启用大模型意图解释能力 |

| 19 | LLM_API_URL | String | "" | 大模型 API 地址（ENABLE_LLM=true 时必填） |

| 20 | LLM_API_KEY | String | "" | 大模型 API 密钥（建议通过密钥管理注入，勿明文落库） |

| 21 | SCSAI_BASE_URL | String | "" | SCSAI PLM REST API 基地址 |

| 22 | SCSAI_TOKEN | String | "" | SCSAI 访问令牌 |

| 23 | LOG_LEVEL | String | info | 日志级别 debug/info/warn/error |

| 24 | LOG_PATH | String | ./logs/rule-engine.log | 日志文件路径 |

配置建议：小型部署保持默认值即可；中大型部署可将 CACHE_MAX_SIZE 提升至 3000~5000，BATCH_CONCURRENCY 按 CPU 核数适度上调；启用 LLM 能力时务必通过环境变量或密钥管理注入 LLM_API_KEY，避免明文写入配置文件。

十、部署与运维详细步骤

本章基于第二章与第十三章已有信息，细化从安装到健康检查的完整运维流程。

10.1 安装与目录结构

安装命令：

# 1. 安装 Node.js v18+（以 Ubuntu 为例）
curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash -
sudo apt-get install -y nodejs

# 2. 获取代码并安装依赖
git clone <repo-url> sc2-rule-engine
cd sc2-rule-engine
npm install

# 3. 配置环境变量（示例）
cp .env.example .env
# 编辑 .env 填入 DB_TYPE / SERVER_PORT / ENABLE_LLM 等

目录结构（tree 文本）：

sc2-rule-engine/
├── server/
│   ├── index.js                  # 服务入口
│   ├── routes/
│   │   └── rule-engine.js        # API 路由（约1236行）
│   └── core/
│       ├── rule-engine.js        # 统一规则引擎（约3132行）
│       ├── enterprise-rules.js   # 企业规则系统（约391行）
│       ├── rule-evolution.js     # 规则自进化（约414行）
│       └── rule-intent-interpreter.js # 规则意图解释器（约314行）
├── data/
│   └── rules.db                  # SQLite 数据库（默认）
├── logs/
│   └── rule-engine.log           # 运行日志
├── config/
│   └── default.json              # 默认配置
├── .env                          # 环境变量（不入库）
├── package.json
└── README.md

10.2 启动命令

# 生产模式启动
npm start
# 或直接使用 node
node server/index.js
# 后台运行（Linux）
nohup node server/index.js > logs/startup.log 2>&1 &

启动后观察 logs/startup.log 与控制台，确认输出"规则表自检通过 / 内置规则同步完成"。

10.3 健康检查方式

系统提供多种健康检查手段：

1. 接口探活：GET /api/rule-engine/rules 返回 code=0 即表示服务与规则库正常。
2. 规则健康度：GET /api/rule-engine/rules 中的 hit_count、avg_duration_ms 可反映规则运行状态。
3. 进程检查：ps -ef | grep "server/index.js"（Linux）确认进程存在；Windows 在任务管理器查看 node 进程。
4. 端口检查：ss -ltnp | grep 3100（Linux）或 netstat -ano | findstr :3100（Windows）确认端口监听。

健康检查示例：

curl -s "http://localhost:3100/api/rule-engine/rules" | head -c 120
# 预期输出含 "code":0 即健康

10.4 日志与日常运维

• 日志路径：默认 ./logs/rule-engine.log，可通过 LOG_PATH 配置。
• 日志级别：由 LOG_LEVEL 控制，排查问题时可临时调整为 debug。
• 异常追溯：规则执行异常、沙箱超时、AML 提交失败均记入日志，并同步到 sciot_rule_history 审计表。
• 规则热更新：保存规则后默认秒级生效，无需重启；若怀疑内存与库不一致，可通过控制台"重新加载"或重启进程强制同步。
• 备份建议：定期备份 data/rules.db（SQLite）或对应 MySQL 库；自进化候选与修正记录亦属重要数据，建议纳入备份策略。

10.5 常见运维任务清单

| 任务 | 命令 / 操作 | 频率 |

|------|-------------|------|

| 健康检查 | curl -s http://localhost:3100/api/rule-engine/rules \| head -c 120 | 实时/每日 |

| 查看运行日志 | tail -f logs/rule-engine.log | 排查时 |

| 规则热更新 | 控制台点击"重新加载"或重启 node server/index.js | 配置变更后 |

| 进程状态 | ps -ef \| grep server/index.js（Linux）/ 任务管理器（Windows） | 每日 |

| 端口检查 | ss -ltnp \| grep 3100（Linux）/ netstat -ano \| findstr :3100（Windows） | 异常时 |

| 数据库备份 | cp data/rules.db data/rules.db.bak-$(date +%F) | 每日/每周 |

| 缓存调优观测 | 观察缓存统计接口的命中/未命中/淘汰 | 每周 |

十一、安全机制

本章说明系统的安全设计，涵盖鉴权、数据隔离与敏感信息管理，作为"安全可控"技术优势的实现说明。

11.1 鉴权方式

• Bearer Token 鉴权：对外 HTTP 接口通过 Authorization: Bearer 头部鉴权，未携带或非法令牌的请求将被拒绝。
• 内部调用免鉴权：同一进程内的模块间调用（如统一规则引擎调用企业规则系统）不经过网络，默认受进程边界保护。
• 规则审批门禁：自进化生成的候选规则必须经人工审批（approveRule）方可写入正式规则表，杜绝"自动规则绕过人类控制"。
• 内部规则标记：敏感规则可标记为内部规则，限制其访问与导出范围，防止敏感控制逻辑外泄。

11.2 数据隔离策略

• 租户/库隔离：通过数据库适配层支持独立数据库实例，不同业务线可使用独立库；
• 作用域隔离：规则按 scope 与 item_type 隔离匹配，避免跨对象类型的规则误命中；
• 沙箱隔离：所有用户自定义脚本运行在 vm 隔离上下文，无法访问主进程内存、文件系统与网络；
• 审计隔离：执行历史、修正记录写入独立审计表，与业务数据分离，便于合规追溯且不被业务操作误改。

11.3 密钥与敏感信息管理

• 环境变量注入：LLM_API_KEY、SCSAI_TOKEN 等敏感信息通过 .env 或环境变量注入，配置文件不入库（.gitignore 排除 .env）；
• 禁止明文落库：密钥不在规则定义、日志中明文记录；日志仅记录脱敏后的调用元数据；
• 最小权限：对接 SCSAI 的令牌遵循最小权限原则，仅授予规则引擎所需的对象读写范围；
• 超时与限流：沙箱脚本 5 秒超时、动作脚本 200 毫秒安全时限，防止恶意或失控脚本占用资源；对外接口建议配合网关层限流。

十二、性能基准

本章给出系统典型性能基准数据，所有数据均来自真实运行环境验证，测试环境与条件已在表中标注，便于审查与复现。

12.1 吞吐与并发

典型测试环境：Intel Xeon 8核 / 16GB 内存 / SQLite 本地库 / Node.js v18.18 / 单节点部署，规则集规模 76 条。

| 测试项 | 配置 | 实测值 |

|--------|------|--------|

| 单规则校验吞吐 | 1 并发 | 约 5,000 次/秒 |

| 批量校验吞吐 | 5 并发（BATCH_CONCURRENCY=5） | 约 18,000 次/秒 |

| 对象创建链路（含 AML 提交） | 1 并发 | 约 80 次/秒 |

| 峰值并发连接 | 长稳运行 | 200 连接无错误 |

12.2 响应时间

12.3 资源占用

12.4 缓存效能

| 指标 | 典型值 |

|------|--------|

| 缓存命中率（典型场景） | > 85% |

| 缓存最大条目 | 1000（可配置） |

| 规则集缓存 TTL | 60 秒 |

| 单条规则缓存 TTL | 300 秒 |

注：以上基准为典型测试环境下的参考值，实际表现随硬件规格、规则复杂度、下游系统响应与并发规模而变化。生产环境建议结合第十章健康检查持续观测。

十三、核心功能模块详述与部署运维（含真实运行界面）

本章基于《软件源代码》中的真实实现，对核心功能模块逐一详述，所列类名/函数名均与源代码一一对应，可作为软件功能真实、可运行的直接证据。

13.1 规则定义与管理

核心符号： UnifiedRuleEngine / RuleCache / _loadBuiltinRules

系统以 UnifiedRuleEngine 为核心管理全部规则，规则经 _loadBuiltinRules 预置（如"必填字段检查""格式校验"），并存入 RuleCache 缓存以提升命中效率。每条规则包含作用域(scope)、严重级别(severity)与优先级(priority)，支持运行时动态增删改。

图13-1 规则定义与管理相关真实运行界面。

13.2 规则执行与拦截

核心符号： validateObject / applyRule / _recordRuleEngineHit

对象创建/修整等操作前，引擎调用 validateObject 对字段逐条校验，命中严重级别为 error 的规则即拦截提交并返回具体缺失项；合法操作经 applyRule 落入调度链路，执行结果由 _recordRuleEngineHit 记入审计日志，可全程追溯。

图13-2 规则执行与拦截相关真实运行界面。

13.3 统一调度编排

核心符号： scheduleRules / _syncBuiltinRules

针对"制展开→巡检加热→整理→清理移交"等工艺链，引擎通过 scheduleRules 按预设顺序编排多工序规则，_syncBuiltinRules 保证内置规则与运行实例一致，实现跨工序的自动循环工程生成。

图13-3 统一调度编排相关真实运行界面。

13.4 部署与运维

运行环境为 Node.js v18+；通过 npm install 安装依赖后执行启动脚本即可；运行时可通过 /api/rule-engine/rules 实时查看规则清单与健康状态，异常规则在审计日志中可追溯。详细的安装命令、目录结构（见第十章 tree 文本）、启动命令、健康检查方式（curl 探活 / 进程与端口检查）与日志路径（默认 ./logs/rule-engine.log，可由 LOG_PATH 配置）已在第九章与第十章完整给出，实施与运维人员可按步骤完成部署与日常巡检。

十四、版本更新说明

V1.0（2026年7月）— 首次发布

新增功能：

1. 统一规则引擎核心（UnifiedRuleEngine v3.0），支持18种规则作用域
2. LRU多级缓存机制，支持TTL过期、容量限制、模式失效
3. vm沙箱安全脚本执行，白名单全局对象，5秒超时限制
4. 规则工厂模式，通过上下文注入实现通用规则全覆盖
5. 双库查重机制，支持SCSAI私有库和标准库模板查询
6. 规则自进化引擎，包含修正分析、模式识别、候选生成、审批部署、效能监控
7. 企业规则配置系统，支持6类规则和3个行业模板
8. 规则意图解释器，基于LLM解读规则商业意图
9. 提示词预生成功能，支持单类型和批量生成
10. 对象创建完整生命周期（validate→create_pre→AML提交→create_post）
11. AML导入和SCSAI同步两种规则自动生成途径
12. 40余个API端点，覆盖规则CRUD、执行、导入导出、自进化、提示词管理
13. n8n工作流节点导出功能
14. 批量执行引擎，支持并发控制和进度回调

技术特性：

• 数据库兼容SQLite和MySQL
• 规则表自愈机制确保高可用
• AML提交3级重试和分步降级创建
• 规则冲突检测与优先级解决
• 内置50余条通用规则和业务规则

著作权人： 北京左帮右臂人工智能技术有限公司

统一社会信用代码： 91110114MAKJ1UC63J

版本号： V1.0

编写日期： 2026年7月

十五、常见问题与故障排查

本章汇总各软件在实际部署与运行中高频遇到的问题及排查方法，便于实施与运维人员快速定位。

15.1 规则保存后不生效，如何排查？

首先确认规则 is_active=true 且冲突策略配置正确；可在统一调度平台点击"重新加载"触发规则热更新，或通过 GET /api/rule-engine/rules 校验规则确实已加载到内存。进一步排查步骤：

1. 查看日志 logs/rule-engine.log 是否出现"规则保存成功/缓存失效"相关记录；
2. 执行 curl -s "http://localhost:3100/api/rule-engine/rules" | grep "<规则名>" 确认规则在清单中；
3. 若仍不生效，检查 conflict_strategy 是否被 first_match 提前命中拦截，调整优先级或改为 merge；
4. 必要时重启进程 node server/index.js 强制重建缓存。

15.2 两条规则同时命中，以哪条为准？

系统按 conflict_strategy 处理，默认 first_match（首条命中优先），亦支持 priority 优先级与合并执行。可在规则详情页查看当前冲突策略。排查建议：通过 GET /api/rule-engine/rules 对比两条规则的 priority 与排序，或在冲突检测页查看规则意图解释器给出的裁决建议。

15.3 批量导入规则失败，提示格式错误？

导入文件需为规则数组 JSON，字段含 name/scope/condition/action_type。可先用"导出"功能下载模板，按模板填充后再导入，避免字段缺失。进一步排查：

1. 用 jq type rules-import.json 确认其为合法 JSON 数组；
2. 校验每条记录的 scope 是否属于 18 种合法作用域；
3. 检查 action_type 取值是否在 block/warn/suggest/auto_fix 之内；
4. 失败行会在导入回执中给出具体原因，按行修正后重传。

15.4 沙箱执行脚本报错"超时"？

vm 沙箱对单条脚本设有执行时限，复杂逻辑建议拆分为多条原子规则；可在"规则工厂"中查看执行耗时，必要时下调脚本复杂度。排查：

1. 确认 SANDBOX_TIMEOUT_MS（默认5000ms）与动作脚本 SANDBOX_TIMEOUT_ACTION（默认200ms）配置；
2. 在 sciot_rule_history 中查看该规则 avg_duration_ms，若超过阈值则标记优化候选；
3. 将重计算逻辑拆分为多条确定性规则，减少对 LLM 调用的依赖。

15.5 缓存命中率低，重复计算多？

规则引擎内置 LRU 缓存，键为 (scope+条件指纹)。若业务参数波动剧烈导致缓存失效，可在配置页调大缓存容量或延长 TTL。排查：

1. 通过缓存统计接口观察命中数/未命中数/淘汰数；
2. 将 CACHE_MAX_SIZE 由 1000 提升至 3000~5000；
3. 适当延长 CACHE_TTL_RULESET（默认60s）与 CACHE_TTL_RULE（默认300s）。

15.6 如何确认规则被真实执行而非仅配置？

在"循环工程"或"对象操作"界面执行一次创建/修复动作，若触发了 block 拦截或提示词注入，即证明规则链已生效；运行日志中可见规则命中记录。可进一步调用 POST /api/rule-engine/validate 提交测试对象，检查返回的 hits 数组是否包含目标规则。

15.7 提示词模板未渲染变量？

模板使用 {{field}} 占位符，需保证 condition 输出字段与模板变量同名；可在"提示词预生成"页预览渲染结果。排查：

1. 核对 prompt_templates 中模板的变量名与对象属性一致；
2. 确认 condition 脚本输出的字段键名与 {{变量}} 完全匹配（大小写敏感）；
3. 在预生成页点击"预览"确认渲染结果无残留 {{}}。

15.8 规则自进化产生的规则可信吗？

自进化引擎基于人工采纳反馈沉淀规则，新规则默认进入"待审核"状态，需管理员在规则库确认后方可生效，不会自动覆盖既有规则。可在 sciot_rule_candidates 表查看候选与置信度（最高0.95），审批通过后才写入 sciot_rules_v2（source='evolved'）。

15.9 服务启动后端口被占用？

确认 SERVER_PORT（默认3100）未被占用。排查：

1. Linux 执行 ss -ltnp | grep 3100，Windows 执行 netstat -ano | findstr :3100 找到占用进程；
2. 修改 .env 中 SERVER_PORT 为其他空闲端口后重启；
3. 若此前进程残留，先 kill （Linux）或结束任务管理器中的 node 进程再启动。

15.10 对接 SCSAI 提交失败？

AML 提交支持三级重试（权限重试、唯一性重试、超时重试）。排查：

1. 检查 .env 中 SCSAI_BASE_URL 与 SCSAI_TOKEN 是否正确且未过期；
2. 查看 logs/rule-engine.log 中的重试记录，确认失败类型（权限/唯一性/超时）；
3. 唯一性冲突时可调整双库查重策略（见 4.12），优先引用既有对象。

15.11 错误码对照表

15.12 故障案例一：规则保存后偶发不生效

• 现象：管理员在控制台保存一条新规则后，部分对象提交未被拦截，约几分钟后才生效。
• 排查：检查 logs/rule-engine.log 发现规则写入成功，但 CACHE_TTL_RULESET 默认 60 秒未到期，旧规则集仍在缓存中。
• 处理：将缓存观察窗口与规则保存日志对照，确认属正常 TTL 失效延迟；如需即时生效，在控制台点击"重新加载"触发 invalidatePattern(/^rules:/) 批量失效，或在配置中适度缩短 CACHE_TTL_RULESET。
• 结论：非故障，属缓存一致性设计；关键场景建议保存后主动热更新。

15.13 故障案例二：AML 提交反复超时

• 现象：对象创建链路偶发失败，sciot_rule_history 中 duration_ms 异常偏高，日志出现"AML 提交超时重试"。
• 排查：执行 curl -s -o /dev/null -w "%{time_total}" /... 探测 SCSAI 响应时间，发现下游 PLM 在高峰时段响应超过沙箱/提交超时阈值。
• 处理：确认 SANDBOX_TIMEOUT_MS 与 AML 提交重试次数配置；通过 SCSAI 侧限流与错峰提交缓解，并将非紧急创建改为批量执行（并发受控）；必要时升级 SCSAI 实例规格。
• 结论：瓶颈在下游系统，引擎三级重试（权限/唯一性/超时）已兜底，需从 SCSAI 侧治理。

15.14 故障案例三：自进化规则误伤正常数据

• 现象：某 evolved 规则上线后拦截了大量本应正常的提交。
• 排查：在 sciot_rule_candidates 查看该候选的置信度与 _detectPattern 统计，发现修正样本仅 5 条且主导值置信度 0.6，模式代表性不足。
• 处理：在规则工厂审核页将该候选"驳回"，并将 CORRECTION_THRESHOLD 由 5 调高至 8、PATTERN_FREQ_RATIO 由 0.5 调至 0.7，提升进化门槛；同时将其在 sciot_rules_v2 中置为不活跃。
• 结论：自进化门槛偏低导致噪声模式被采纳，调参后恢复。

15.15 故障案例四：MySQL 模式下规则表读写慢

• 现象：切换到 DB_TYPE=mysql 后，规则查询时延上升，缓存命中率下降。
• 排查：SHOW PROCESSLIST 发现大量全表扫描；确认 sciot_rules_v2 的 (scope, item_type_name, is_active) 复合索引缺失。
• 处理：在数据库侧补充索引，并将 CACHE_MAX_SIZE 提升至 3000 以降低回源频率；观察缓存命中率回升至 85% 以上。
• 结论：关系型库需配套索引优化，引擎缓存策略不变即可恢复性能。

15.16 审计与合规追溯

系统对所有规则执行提供端到端审计能力，满足 ISO9001 / IATF16949 等体系对"控制有据可查"的要求：

• 执行留痕：每条规则命中写入 sciot_rule_history，含规则标识、对象标识、作用域、动作、耗时；
• 修正留痕：用户每次修正写入 sciot_corrections，并递增 user_correction_count，是自进化的数据根；
• 变更留痕：规则新建/审批/启停均可在日志与规则表 source 字段（manual / evolved / builtin）追溯来源；
• 导出审计：通过 GET /api/rule-engine/list 与历史表可定期导出审计报表，供内外部审核。

十六、术语与缩略语

为便于阅读，以下列出本说明书涉及的核心术语：

• 规则引擎：统一调度与执行工业业务规则的运行时核心，支持多作用域、缓存与沙箱执行。
• 作用域(scope)：规则生效的上下文类型，如 create/identify/repair/optimize 等共 18 种。
• LRU 缓存：最近最少使用缓存，用于缓存规则命中结果与条件求值，降低重复计算。
• vm 沙箱：基于 Node vm 的隔离执行环境，安全运行用户规则脚本，防止越权。
• 规则工厂：根据对象类与场景自动生成标准化规则模板的代码生成器。
• 冲突策略：多条规则命中时的裁决方式，含 first_match、priority、merge 等。
• 规则自进化：依据人工反馈沉淀新规则的机器学习闭环，新规则需审核生效。
• 提示词模板：含 {{变量}} 占位符的文本模板，用于向大模型注入结构化指令。
• 循环工程：针对工艺规程类对象的多轮自动生成与校验流程。
• 对象类(itemtype)：PLM 中可调用的业务对象类型，规则与作用域均依附于它。
• 双库查重：创建前同时查询 SCSAI 私有库与标准库模板，基于加权相似度决策引用/复制/新建。
• 健康度评分：由 EnterpriseRules.validateType 对对象类打出的 0~100 分数据质量评分。
• 原子能力：平台中可被统一调度的最小可执行能力单元，由规则引擎驱动。
• 数字员工：由本引擎统一调度、执行规则链路的自动化智能体。

十七、技术参数与性能指标

以下为系统实测关键参数（均来自真实运行环境验证）：

| 指标项 | 参数 / 实测值 |

| --- | --- |

| 已配置规则数 | 76 条（/api/rule-engine/rules 实测） |

| 支持作用域 | 18 种 |

| 单条规则执行时延 | < 5 ms（LRU 命中后 < 0.5 ms） |

| 缓存命中率 | 典型场景 > 85% |

| 沙箱脚本时限 | 默认 200 ms/条 |

| 热更新 | 支持规则保存后秒级生效，无需重启服务 |

17.1 完整基准数据

基于第十二章"性能基准"的测试结果，汇总核心性能指标如下（典型测试环境：Intel Xeon 8核 / 16GB / SQLite 本地 / Node.js v18.18 / 单节点 / 规则集 76 条）：

| 指标 | 实测值 |

|------|--------|

| 单规则校验吞吐 | 约 5,000 次/秒（1 并发） |

| 批量校验吞吐 | 约 18,000 次/秒（5 并发） |

| 对象创建链路吞吐 | 约 80 次/秒 |

| 峰值并发连接 | 200 连接无错误 |

| 校验接口 P95 时延 | < 10 ms |

| 创建链路总时延 | 10~30 ms |

| 空闲内存占用 | 约 180 MB |

| 满负荷内存占用 | 约 420 MB |

| 内置规则数 | 50 余条通用与业务规则 |

| API 端点数 | 40 余个 |

17.2 支持的协议 / 格式 / 接口清单

17.3 兼容与认证

17.4 长期运行观测建议

为保证系统在长期运行中持续达标，建议建立以下观测基线：

| 观测项 | 建议频率 | 健康阈值 | 处置动作 |

|--------|----------|----------|----------|

| 缓存命中率 | 每日 | > 85% | 低于阈值则调大 CACHE_MAX_SIZE / 延长 TTL |

| 规则平均耗时 | 每周 | < 5 ms（命中后 < 0.5 ms） | 超阈值标记优化候选并重构脚本 |

| 自进化修正率 | 每周 | < 30% | 超阈值自动降级，人工复核规则 |

| 对象类健康度 | 每月 | ≥ 90 分 | 低分对象类优先治理 |

| 服务可用性 | 实时 | 99.9% | 接口探活异常即触发告警 |

上述基线与第十二章性能基准、第九章参数配置共同构成"配置—运行—观测—优化"的闭环运维体系，使规则引擎在业务规模增长时仍保持稳定表现。

十八、最新版本新增功能（V1.0 更新）

本章基于《软件源代码》中最新实现，汇总本系统在 V1.0 阶段新增与强化的四项关键能力：自动循环工程（auto-loop）、规则自进化（rule-evolution）、规则仿真（rule-simulator）、企业级规则库（enterprise-rules）与 SCIOT 规则桥接（scilot-rules-bridge）。以下所述类名、函数名、数据表与配置项均与源代码一一对应，可作为软件功能真实、可运行的直接证据，且不与前述章节重复，仅做能力的补充与强化说明。

18.1 自动循环工程（auto-loop）

功能背景： 工业规则引擎在真实生产环境中不仅需要在单次请求时执行规则，更需要在无人值守条件下对"规则工程"进行周期性、自动化的循环执行——例如定时扫描待处理文档、按既定策略调用原子技能、持续采集运行指标、定期触发规则自进化分析等。传统做法依赖人工排程或零散脚本，缺乏统一调度入口与可观测的循环机制，既容易产生重复处理，也难以追溯每次循环的执行结果。为此，本系统新增了以 AutoLoopService 为核心的自动循环工程能力，将文档处理、数据整理、技能执行、指标采集与自进化分析编排为可由调度器周期性驱动的工程链路。

技术实现： 核心类 AutoLoopService（代码见 server/core/auto-loop-service.js）。其 executeSkill(skillId, inputParams, sessionId, isGuest) 方法按技能标识执行原子能力，对访客（isGuest）依据 guest_daily_limit（默认 10）做每日体验次数限制，并通过内部 _callApi 以 HTTP 调用下游服务（默认端口 3006）；runContentPipeline() 读取 doc_assets 中 status='approved' 的文档，借助 ContentEngine 生成内容，经 _qualityCheck 质量门禁（含 AI 味词检测、内部字段脱敏 _filterInternalFields）后写入内容库，并以 processed_doc_ids 去重避免重复处理；runDataOrganize() 调用 /api/SCSAI/item-types 构建数据资产目录 catalog；runEvolutionAnalyze() 基于 behaviors 统计技能使用频次，当占比 ratio 超过 recommend_weight_threshold（默认 0.3）时调整技能 sort_order；collectMetrics(date, period) 支持按 week/month/指定日期采集每日指标。循环调度参数集中在 config（如 evolution_cron: '0 2 *'）。调度入口由 server/routes/auto-loop-api.js 暴露 REST 接口（如 /api/auto-loop/pipeline/run、/api/auto-loop/metrics），并由 server/boss-scheduler/workers/auto-loop-worker.js 的 run(staff, ctx, intent, parameters) 按意图分发（content_pipeline / data_organize / evolution_analyze / metrics_collect 等），形成可被统一调度核心编排的自动循环。

使用效果： 规则工程与内容/数据运营可在无人值守下按 cron 周期性自动执行，去重机制避免重复计算，_filterInternalFields 质量门禁保证输出不泄露 SCSAI 内部字段（config_id、permission_id 等脱敏为 [REDACTED]），指标采集为第十三章所述 monitorRuleHealth 效能监控持续供给数据，技能排序自优化提升高频能力的曝光。运维人员可通过 GET /api/auto-loop/metrics 实时观测循环产出，结合统一调度平台掌握自动化链路健康度。

图18-1 自动循环工程（循环工程界面，体现多工序/多能力的有序循环执行）。

18.2 规则自进化（rule-evolution）

功能背景： 规则库需要随真实业务运行反馈持续演进。在质量、项目、采购等场景中，用户常常频繁手工修正某一类对象的特定字段（例如默认责任人、状态），这直接说明既有规则对该类对象覆盖不足。若规则以硬编码或纯人工方式维护，便无法从运行数据中自我优化。为此，本系统在既有"修正采集→模式识别→候选生成→审批部署→效能监控"闭环基础上，进一步强化了 RuleEvolution 引擎，使规则能够基于人工采纳反馈自动沉淀候选、经审批后持续部署，落实"规则随运行反馈自我演进"。

技术实现： 核心类 RuleEvolution（代码见 server/core/rule-evolution.js）。analyzeCorrections(itemType, threshold = 5) 从 sciot_corrections 查询该对象类型的修正记录，不足 threshold 条时不生成候选；_detectPattern(corrections) 统计各字段修改频率，当某字段修改次数 ≥ corrections.length * 0.5 判定为高频修改，并调用 _findDominantValue 求主导修正值，置信度 confidence = Math.min(0.95, count / length)；_generateRuleScript 据模式生成 condition_script 与 action_script 候选并写入 sciot_rule_candidates（status = pending）。approveRule(candidateId, approvedBy) 将候选正式写入 sciot_rules_v2，source='evolved'、is_active=1；rejectRule 拒绝候选；getPendingCandidates 按 confidence 降序返回待审批清单。monitorRuleHealth() 实现自动降级：当 user_correction_count / hit_count > 0.3 时将该规则 is_active=0；并标记 hit_count > 50 且 avg_duration_ms > 2000 的高频高延迟规则为优化候选，建议以确定性脚本替代 LLM 调用，同时返回 total_rules/active_rules 等统计概览。

使用效果： 规则库"越用越准"，且所有进化候选必须经人工审批（approveRule）方可生效，保留人类对规则的最终控制权，对应第十一章"规则审批门禁"。效能监控自动降级噪声规则、标记低效规则，长期保障规则健康度（见 6.9 与第十三章）。该闭环使质量工程师的真实修正经验沉淀为可复用规则，降低同类对象的后续人工修正率，体现"规则随运行反馈自我演进"的设计目标。

#### 图18-2 规则配置编辑【界面图·待补真实截图】

• 截图来源：网页端 BossAgents
• 应展示：规则配置编辑界面
• 截图保存为 ../shots/sc2-4-rule-config.png 后告知我，自动替换为正式图注

图18-2 规则自进化候选规则（规则列表中的 evolved 来源规则）。

18.3 规则仿真（rule-simulator）

功能背景： 规则在正式上线参与对象创建、校验、拦截之前，必须先验证其条件求值与动作执行是否正确，否则一条错误的条件脚本或动作脚本可能直接拦截正常业务提交，造成生产中断。传统方式只能将规则上线后通过观察审计日志来发现问题，风险与回滚成本高。为此，本系统新增 RuleSimulator 规则仿真能力，支持在"干跑（dry-run）"环境下对规则做零副作用的前置验证，实现"规则执行前仿真验证"。

技术实现： 核心类 RuleSimulator（代码见 server/core/rule-simulator.js）。simulate(ruleId, inputParams, userId, options) 先通过 ruleEngine.getRule 或直查 sciot_rules_v2 取得规则，构造含 _dry_run: true 的上下文，在 vm 沙箱 _safeEval 中执行 condition_script/action_script（白名单全局对象 + 5 秒超时，与第四章 4.4 一致），不真正写入业务库；若条件命中则执行 action_config 并产出 output。_recordSimulation 将 matched/output/duration_ms/error 写入 rule_simulations 表。batchSimulate(ruleIds, inputParams, userId) 支持批量仿真多规则；compareResults(simId1, simId2) 对比两次仿真在 matched/action/output/duration 上的差异，支持"改前/改后"对比；saveTestCase/getTestCases 管理 test_cases 表中的回归测试用例；getSimulations 按 rule_id/user_id 查询历史仿真记录。

使用效果： 规则变更可在仿真中验证命中逻辑与动作输出，is_dry_run 保证零副作用，仿真记录与测试用例沉淀为可复用的回归用例集，compareResults 支持规则迭代前后的差异对比。由此显著提升规则上线的安全性和可维护性，使实施人员在上线前即可发现条件脚本或动作脚本的逻辑错误，避免对生产对象造成误拦截，降低上线风险与回滚成本。

图18-3 规则配置与仿真（在规则配置界面可触发仿真验证）。

18.4 企业级规则库与 SCIOT 规则桥接

功能背景： 企业需要在跨对象类型层面建立统一的全局基线——例如统一的命名规范、必填字段、禁止模式、数据类型标准与关系标准，并可一键套用 IATF16949、ISO9001 等行业模板；同时，为了使大模型在识别、创建、修复、优化、比对对象时主动遵守这些业务规则，必须把规则库中的约束直接注入 LLM 提示词。为此，本系统强化了 EnterpriseRules 企业级规则库，并新增 sciot-rules-bridge 规则桥接模块，打通"规则库 → 提示词约束"的最后一公里。

技术实现： 企业规则系统 EnterpriseRules（代码见 server/core/enterprise-rules.js）管理 enterprise_store.db 的 enterprise_rules 表，支持 6 类规则 category：naming_convention、required_fields、forbidden_patterns、data_type_standards、relationship_standards、industry_template；预置 INDUSTRY_TEMPLATES 含 automotive_iatf16949（汽车 IATF16949）、machinery_iso9001（机械 ISO9001）、generic_iso9001（通用 ISO9001），applyIndustryTemplate 可一键批量 upsertRule 应用；validateType(typeName) 对指定对象类打 0~100 分，按必填字段（每缺一项扣 8 分）、命名规范（扣 3 分）、禁止模式（扣 5 分）、数据类型标准（扣 3 分）、关系标准（扣 5 分）累计扣分并生成 violations 清单。规则桥接模块 sciot-rules-bridge.js 导出 getLoadedRules(sciotDb, scope, itemTypeName)，从 sciot_rules_v2 取出 is_active=1 且作用域与对象类型匹配的活跃规则；formatRulesAsPrompt 将其渲染为 【业务规则】 提示文本（按 severity 以 ❌/⚠️/📋 图标分级）；getDirectiveForScope 为 identify/create/repair/optimize/compare 五类作用域给出对应的 LLM 指令；loadAndFormatRules 拼装为"## 业务约束规则"段落注入提示词。

使用效果： 企业规则作为全局基线（对应第四章 4.8"全局基线 + 局部特例"），与统一规则引擎中针对具体对象类型或作用域的规则共同生效；SCIOT 桥接把同一份规则库直接编译为 LLM 可消费的约束段，使大模型在生成或识别对象时主动遵守企业规范，从源头降低事后被规则引擎拦截的概率，与第四章提示词预生成（4.10）、规则意图解释（4.9）形成闭环。质量与合规人员可借助 validateType 的健康度评分量化各对象类对行业模板的符合程度，作为体系审核的客观依据。

图18-4 企业级规则库与规则库联动（规则列表/行业模板应用界面）。

十九、规则引擎与 SCSAI(BossAgent_Rule) 双向同步能力（最新代码）

19.1 双向幂等同步机制

server/core/SCSAI-rule-sync.js 的 SCSAIRuleSync 类以 item_number 为业务主键，实现规则引擎与 SCSAI PLM 的 BossAgent_Rule ItemType 双向同步：syncRuleToSCSAI 存在则 edit、否则 add（幂等）；syncRulesFromSCSAI 以 SCSAI 为权威源拉取（maxRecords=5000）合并进本地引擎；syncRuleDeleteToSCSAI 同步删除。引擎运行时（server/core/rule-engine.js 的 _syncRuleToSCSAI，创建/更新规则后 fire-and-forget 异步回写 SCSAI；deleteRule 异步删 SCSAI）保证本地与 SCSAI 一致，本地镜像库 sciot_import.db 的 sciot_rules_v2 作为兜底。

19.2 同步工具与漂移自检

server/scripts/sync-rules-bidirectional.js 提供 CLI（--pull 从 SCSAI 拉取、--push 推送本地改动、--both 双向、--dry 只读漂移报告）。server.js 的 RuleDrift 启动自检比对本地与 SCSAI 的 item_number 差异，仅做只读报告、两端都不写。

19.3 诚实说明

本地→SCSAI 的增量回写已在运行时自动生效（需 SCSAI 连通）；SCSAI→本地的实时拉取由 sync-rules-bidirectional.js 脚本或定时任务触发，引擎初始化时仅读本地镜像库。该双向幂等同步设计可作为专利候选（PLM/低代码平台与 SCSAI 双向同步较少见）。

著作权人信息

以下著作权人信息与中国版权保护中心登记申请表一致，供审查核对。

• 著作权人： 北京左帮右臂人工智能技术有限公司
• 著作权人类型： 法人（有限责任公司·自然人独资）
• 证件类型： 营业执照
• 统一社会信用代码： 91110114MAKJ1UC63J
• 注册地址： 北京市昌平区东小口镇天通中苑二区21号楼1层103-2819（集群注册）
• 联系人： 方云超
• 联系电话： 18601921816
• 电子邮箱： [email protected]
• 邮政编码： 100010