规则模板管理系统 — 优化理解文档

Q: 1.1 正确的数据流？

AML文件 (SCIOT/*.xml) │ ├── 导入 → sciot_properties (属性定义) ├── 导入 → sciot_relationships (关系定义) ├── 导入 → sciot_sequences (编号规则) └── 导入 → sciot_methods (客户端方法) │ ▼ 配置层 (人工维护) │ ├── sciot_templates (字段分类: ll

Q: 1.2 关键认知？

| 概念 | 正确理解 | 常见误区 | |------|----------|----------| | AML文件 | 唯一不变的数据源，变更需重新导入 | 手动修改数据库 | | 规则模板 | 人工维护的配置层，决定系统行为 | 认为是代码写死的 | | 提示词 | 可重复生成的产物，不是AI生成的 | 认为是LLM随机生成的 | | 预生成 | 确定性脚本拼接，相同输入→相同输出 | 认为

Q: 2.1 问题1：AML组装引擎使用旧规则表？

现状 ： server/aml-assembly-engine.js 使用 sciot_rules （旧表） server/core/rule-engine.js 使用 sciot_rules_v2 （新表） 两套规则不同步，导致组装行为与规则管理脱节 影响 ： 在RulesAndTemplates.vue中修改的规则不生效 组装失败时无法通过规则引擎排查 修复方案 ： // aml-assemb

Q: 2.2 问题2：StaffCapabilities.vue 直接组装AML？

现状 ： 第1782-1900行直接遍历字段组装AML 使用 propDefMap （后端Schema）判断字段类型 没有使用规则引擎的 createItem 方法 影响 ： 绕过了规则引擎的 validate / create_pre / create_post 流程 内置规则（如自动生成编号）不生效 字段类型判断不准确（ goals 被当成string而非text） 正确做法 ： // 应该调

Q: 2.3 问题3：字段类型判断不一致？

现状 ： 提示词生成使用 templatePropsMap （准确） AML组装使用 propDefMap （不准确，后端Schema） 两者对 goals 的 data_type 认知不一致 修复方案 ： 所有字段类型判断统一使用 templatePropsMap propDefMap 仅用于获取 readonly 等元数据

基于 rules-templates-prompts-system.md 的深入理解和优化建议

更新日期: 2026-05-31

1. 闭环核心理解

1.1 正确的数据流

AML文件 (SCIOT/*.xml)
    │
    ├── 导入 → sciot_properties (属性定义)
    ├── 导入 → sciot_relationships (关系定义)
    ├── 导入 → sciot_sequences (编号规则)
    └── 导入 → sciot_methods (客户端方法)
    │
    ▼
配置层 (人工维护)
    │
    ├── sciot_templates (字段分类: llm_fields / auto_fields)
    ├── sciot_rules_v2 (规则: validate / create_pre / create_post)
    └── sciot_business_prompts (业务系统级提示词)
    │
    ▼
预生成层 (确定性脚本拼接)
    │
    └── POST /api/rule-engine/pregenerate-prompt
        │
        └── prompt_templates (版本化提示词库)
            │
            ├── prompt_type='creation' → 用于Create场景
            ├── prompt_type='identify' → 用于Identify场景
            ├── prompt_type='repair'   → 用于Repair场景
            ├── prompt_type='optimize' → 用于Optimize场景
            └── prompt_type='compare'  → 用于Compare场景
    │
    ▼
消费层 (六大基础能力)
    │
    ├── Create   → 读取creation提示词 + create规则 + 模板字段分类
    ├── Assemble → 读取creation提示词 + assemble规则 + 模板generation_rules
    ├── Repair   → 读取repair提示词   + repair规则   + 模板字段定义
    ├── Optimize → 读取optimize提示词 + optimize规则 + 模板字段定义
    ├── Compare  → 读取compare提示词  + compare规则  + 模板字段定义
    └── Identify → 读取identify提示词 + identify规则 + item_type列表
    │
    ▼
反馈修复 (闭环关键)
    │
    ├── 创建成功 → 规则模板提示词 OK
    ├── 组装失败 → 检查规则模板定义 → 修改 → 重新预生成 → 重试
    ├── 修复不准 → 检查repair规则优先级 → 调整 → 重新预生成
    └── 优化效果差 → 检查optimize规则条件 → 修正 → A/B测试

1.2 关键认知

| 概念 | 正确理解 | 常见误区 |

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

| AML文件 | 唯一不变的数据源，变更需重新导入 | 手动修改数据库 |

| 规则模板 | 人工维护的配置层，决定系统行为 | 认为是代码写死的 |

| 提示词 | 可重复生成的产物，不是AI生成的 | 认为是LLM随机生成的 |

| 预生成 | 确定性脚本拼接，相同输入→相同输出 | 认为是非确定性的 |

| 组装失败 | 很可能是规则模板定义不对 | 认为是代码bug |

2. 当前实现的问题分析

2.1 问题1：AML组装引擎使用旧规则表

现状：

server/aml-assembly-engine.js 使用 sciot_rules（旧表）
server/core/rule-engine.js 使用 sciot_rules_v2（新表）
两套规则不同步，导致组装行为与规则管理脱节

影响：

在RulesAndTemplates.vue中修改的规则不生效
组装失败时无法通过规则引擎排查

修复方案：

// aml-assembly-engine.js 应该调用 UnifiedRuleEngine
const { UnifiedRuleEngine } = require('./core/rule-engine');
const engine = new UnifiedRuleEngine({ db });

// 组装时执行规则
const result = await engine.execute('assemble', {
  item_type: type,
  properties: fieldsData,
  template: templateData
});

2.2 问题2：StaffCapabilities.vue 直接组装AML

现状：

第1782-1900行直接遍历字段组装AML
使用 propDefMap（后端Schema）判断字段类型
没有使用规则引擎的 createItem 方法

影响：

绕过了规则引擎的 validate / create_pre / create_post 流程
内置规则（如自动生成编号）不生效
字段类型判断不准确（goals 被当成string而非text）

正确做法：

// 应该调用规则引擎
createResultRaw = await engine.createItem({
  item_type: 'Project',
  properties: standardData.properties,
  item_properties: standardData.item_properties,
  relationships: standardData.relationships,
  applyAML: async (aml) => {
    // 通过统一代理提交
    return await bomService._arasApiRequest('ApplyItem', aml);
  }
});

2.3 问题3：字段类型判断不一致

现状：

提示词生成使用 templatePropsMap（准确）
AML组装使用 propDefMap（不准确，后端Schema）
两者对 goals 的 data_type 认知不一致

修复方案：

所有字段类型判断统一使用 templatePropsMap
propDefMap 仅用于获取 readonly 等元数据

2.4 问题4：item类型字段处理错误

现状：

wbs_id 是 item 类型，LLM生成对象
预创建逻辑尝试创建WBS Element，但失败
失败后将对象内联到AML，SCSAI拒绝

正确流程：

1. LLM生成 wbs_id: { name: "...", ... }
2. 预创建 WBS Element → 获取 ID
3. 如果预创建成功 → mainValues.wbs_id = "ID字符串"
4. 如果预创建失败 → 跳过该字段（SCSAI会使用默认值）
5. AML组装时 → <wbs_id>ID字符串</wbs_id> 或 省略

3. 正确的组装流程

3.1 理想的数据流

用户输入 "创建项目X"
    │
    ▼
┌─────────────────────────────────────┐
│ 1. 获取Schema和模板                  │
│    GET /api/aml/unified/schema/Project
│    GET /api/sciot/type-template/Project
└─────────────────────────────────────┘
    │
    ▼
┌─────────────────────────────────────┐
│ 2. 获取预生成的提示词                │
│    GET /api/aml/sciot/prompts/Project
│    prompt_type='creation'
└─────────────────────────────────────┘
    │
    ▼
┌─────────────────────────────────────┐
│ 3. 调用LLM生成JSON                   │
│    POST /api/llm/chat               │
│    输入: 提示词 + 用户描述           │
│    输出: { properties, relationships }
└─────────────────────────────────────┘
    │
    ▼
┌─────────────────────────────────────┐
│ 4. 预创建item类型字段                │
│    遍历 properties                  │
│    如果 field.data_type === 'item'  │
│      → 创建嵌套Item                 │
│      → 成功: 替换为ID               │
│      → 失败: 删除该字段（用默认值）  │
└─────────────────────────────────────┘
    │
    ▼
┌─────────────────────────────────────┐
│ 5. 调用规则引擎 createItem           │
│    POST /api/rule-engine/create-item │
│    流程:                             │
│      validate → 校验必填、格式等     │
│      create_pre → 填充默认值、编号   │
│      组装AML → 返回AML文本           │
│      create_post → （提交后处理）    │
└─────────────────────────────────────┘
    │
    ▼
┌─────────────────────────────────────┐
│ 6. 提交AML到SCSAI                     │
│    POST /aras-api/ApplyItem          │
│    输入: 规则引擎返回的AML           │
│    输出: { Item: { id: "..." } }     │
└─────────────────────────────────────┘
    │
    ▼
成功 / 失败

3.2 规则引擎在组装中的角色

| 阶段 | 规则引擎作用 | 输入 | 输出 |

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

| validate | 校验数据完整性 | properties | { blocked: true/false, errors: [] } |

4. 修复优先级

P0 - 立即修复（阻塞问题）

item类型字段处理

预创建失败时不应内联对象到AML
应该跳过该字段，让SCSAI使用默认值

字段类型判断统一

AML组装统一使用 templatePropsMap
不再依赖 propDefMap.data_type

P1 - 重要修复（功能完善）

StaffCapabilities.vue 接入规则引擎

调用 createItem 而非直接组装AML
让 validate / create_pre / create_post 生效

AML组装引擎使用新规则表

废弃 sciot_rules（旧表）
统一使用 sciot_rules_v2 + UnifiedRuleEngine

P2 - 架构优化（长期）

数据库连接单例

创建 SciotDatabase 单例
避免多处独立创建连接

LLMBrain 消除硬编码

预生成所有业务提示词
全部迁移到路径1（规则引擎加载）

5. 故障排查速查表（优化版）

现象	定位层级	检查什么	修复方法
LLM生成字段不对	Layer 2 模板	sciot_templates.llm_fields	调整字段分类 → 重新预生成
必填字段未校验	Layer 3 规则	sciot_rules_v2 scope='validate'	添加/修改校验规则 → 重新预生成
编号未自动生成	Layer 3 规则	sciot_rules_v2 scope='create_pre'	检查action_script → 重新预生成
AML提交失败	Layer 4 提示词/组装	查看实际AML内容	检查字段类型定义 → 修改模板 → 重新预生成
关联对象未创建	Layer 3 规则	sciot_rules_v2 scope='create_post'	添加create_post规则 → 重新预生成
提示词内容过时	Layer 4 提示词	prompt_templates.updated_at	运行 pregenerate-prompt

6. 关键文件关系图

server/
├── core/
│   ├── rule-engine.js          ← 统一规则引擎（核心）
│   │   ├── 规则CRUD
│   │   ├── 规则执行 (execute)
│   │   ├── 对象创建 (createItem)
│   │   └── 内置规则 (builtin-rules)
│   │
│   └── unified-schema.js       ← Schema构建器
│       └── 运行时提示词生成
│
├── routes/
│   ├── rule-engine.js          ← 规则引擎API路由
│   │   ├── /api/rule-engine/rules
│   │   ├── /api/rule-engine/execute/:scope
│   │   ├── /api/rule-engine/create-item
│   │   └── /api/rule-engine/pregenerate-prompt
│   │
│   └── aml.js                  ← SCIOT数据API
│       ├── /api/aml/sciot/types
│       ├── /api/aml/sciot/templates
│       ├── /api/aml/sciot/prompts
│       └── /api/aml/unified/schema/:type
│
└── aml-assembly-engine.js      ← ⚠️ 应接入rule-engine.js

src/
├── views/
│   ├── RulesAndTemplates.vue   ← 规则模板管理UI
│   │   ├── Tab3: 在线规则引擎
│   │   ├── Tab6: 模板库
│   │   └── Tab4: 对象提示词
│   │
│   └── StaffCapabilities.vue   ← ⚠️ 应调用rule-engine/create-item
│       ├── 识别面板
│       ├── 创建面板
│       ├── 修复面板
│       └── ...
│
└── composables/
    └── useRuleEngine.js        ← 前端规则引擎封装

data/
└── sciot_import.db             ← 配置主库
    ├── sciot_rules_v2          ← 统一规则表 ★
    ├── sciot_templates         ← 对象模板表 ★
    ├── prompt_templates        ← 提示词模板库 ★
    ├── sciot_properties        ← 属性定义（从AML导入）
    ├── sciot_relationships     ← 关系定义（从AML导入）
    └── ...

7. 总结

核心原则

AML是源头 - 所有基础数据从AML导入，变更需重新导入
规则模板是配置 - 人工维护，决定系统行为
提示词是产物 - 可重复生成，相同输入→相同输出
组装失败看规则模板 - 不是代码bug，是配置问题
修复后重新预生成 - 修改规则/模板后必须重新预生成提示词

当前状态

✅ 规则引擎核心成熟（2268行）
✅ 规则引擎API完整（22+端点）
✅ 前端规则管理UI就绪
⚠️ AML组装未接入规则引擎（使用旧表）
⚠️ StaffCapabilities.vue 直接组装AML（未调用createItem）
⚠️ 字段类型判断不一致（templatePropsMap vs propDefMap）

下一步行动

修复 item 类型字段处理（预创建失败时跳过）
统一字段类型判断（全部使用 templatePropsMap）
StaffCapabilities.vue 接入规则引擎 createItem
AML组装引擎接入 UnifiedRuleEngine
废弃 sciot_rules（旧表）

文档更新时间: 2026-05-31

规则模板管理系统 — 优化理解文档

规则模板管理系统 — 优化理解文档

1. 闭环核心理解

1.1 正确的数据流

1.2 关键认知

2. 当前实现的问题分析

2.1 问题1：AML组装引擎使用旧规则表

2.2 问题2：StaffCapabilities.vue 直接组装AML

2.3 问题3：字段类型判断不一致

2.4 问题4：item类型字段处理错误

3. 正确的组装流程

3.1 理想的数据流

3.2 规则引擎在组装中的角色

4. 修复优先级

P0 - 立即修复（阻塞问题）

P1 - 重要修复（功能完善）

P2 - 架构优化（长期）

5. 故障排查速查表（优化版）

6. 关键文件关系图

7. 总结

核心原则

当前状态

下一步行动

登录

申请免费使用