BossAgents企业数字化转型中的“创建”陷阱：你的系统真的统一了吗？
# 企业数字化转型中的“创建”陷阱：你的系统真的统一了吗？
在智能制造和数字化转型的浪潮中，企业投入大量资源建设PLM、ERP和MES系统，却常常陷入一个看似简单、实则致命的盲区——**“创建”对象的路径不统一**。
想象一下：业务员在网页端手动录入一个物料，AI助手自动生成一个BOM结构，工人在小程序上报工创建工单，后台批量导入数据……这些看似独立的操作，背后可能走着**完全不同的技术路径**。结果呢？同一个“物料”，在网页端创建时自动编号、校验规则都生效，在AI对话中创建时却跳过了规则引擎，导致数据不一致、流程断裂。
这不是危言耸听。在真实的生产环境中，许多企业的“创建”入口多达四五个，而真正走完规则引擎完整生命周期的，可能只有不到一半。今天，我们就来揭开这个“创建统一性”的真相。
---
## 规则引擎：系统的大脑，到底长什么样？
要理解问题，先要搞清楚规则引擎是什么。它不是一个神秘的黑盒子，而是一套**可以配置、可扩展的业务规则处理中心**。
### 规则引擎的核心能力
以我们诊断的系统为例，规则引擎（UnifiedRuleEngine）提供了六大统一API：
- **识别（identify）**：判断对象类型
- **修复（repair）**：自动修正数据
- **优化（optimize）**：提升对象质量
- **比对（compare）**：版本差异分析
- **创建（create-item）**：**核心中的核心**，集成了完整的创建生命周期
- **验证（validate）**：数据合规性检查
而所有这些能力，统一由一个叫`CapabilityRuntime`的调度层管理。它的工作流程很简单：**先检查规则，命中就走规则；没命中，就降级到传统AML或AI生成**。
### 规则和提示词存在哪里？
很多人以为规则存在数据库里就完事了。实际上，规则引擎的配置库是一个**分层存储**的系统：
- **sciot_rules_v2**：统一规则表（核心，包含scope、action_script、severity字段）
- **sciot_prompts**：对象级提示词（兼容旧版）
- **sciot_templates**：模板（含llm_fields/auto_fields分类）
- **sciot_rules**：旧规则表（技术债，未完全迁移）
权威设计文档是一份5.8万字的`rules-templates-prompts-system.md`，但文档再详细，也掩盖不了**实际代码和文档之间存在差距**的事实。
### 理想的创建生命周期
一个完整的“创建”操作，应该走以下四步：
1. **validate**：数据校验规则（如必填字段、格式检查）
2. **create_pre**：默认值填充、自动编号、数据预处理（对应SCSAI的onBeforeAdd）
3. **组装AML**：生成最终提交的XML
4. **create_post**：创建后副作用（如触发审批、通知下游）
理想很丰满，现实呢？
---
## 四入口统一了吗？实测给你看
我们系统有四个主要创建入口：**业务页面、AI对话、飞书机器人、小程序/后台导入**。我们逐一实测，结果如下：
| 入口 | 创建路径 | 前段规则(validate/create_pre) | 后段(create_post) | 统一层 |
|---|---|---|---|---|
| **业务页面** | `buildAML()` + `/SCSAI-api/ApplyItem` | ❌ 跳过 | ✅ 执行 | ❌ 绕过CapabilityRuntime |
| **AI对话** | 经ai-agent → CapabilityRuntime | ✅ | ✅ | ✅ |
| **飞书机器人** | 经staff-router → (间接调用) | 待确认 | 待确认 | 部分 |
| **小程序/导入** | 经capabilityRuntime.create() | ✅ | ✅ | ✅ |
### 核心证据：业务页面“绕道”了
我们追踪了`useCapabilityCreate.js`的代码执行路径：
1. 第1671行：`buildAML(mainAmlData,...)` → 组装AML
2. 第1681行：`bomService._SCSAIApiRequest('ApplyItem', mainAml)` → 直接提交到SCSAI
3. 第1964行：`fetch('/api/rule-engine/execute-create-post',...)` → 只补了create_post
**结论：业务页面创建时，跳过了validate和create_pre两个前段规则。** 这意味着：
- 默认值填充不生效
- 自动编号不触发
- 数据校验不执行
而同一个对象，通过AI对话或后台导入创建时，这些规则是完整运行的。**同一个业务对象，不同入口创建，行为不一致。**
### 提示词也有两套
除了创建路径，提示词生成也有两条路：
- **路径A**：服务端预生成（从sciot_prompts表确定性拼接）
- **路径B**：前端PromptBuilder/AmlBuilder动态拼装
两者可能输出不一致，导致AI看到的提示词和前端组装的提示词结构不同。文档自己标注了：“一致性风险中”。
---
## 真问题不是“不能创建”，而是“创建不统一”
有人可能会问：那是不是系统不能创建复杂对象？比如含Item类型属性、复杂关系对象的BOM？
**答案是否定的。** `AmlBuilder.buildAML`覆盖了：
- 普通标量属性
- Item类型属性（正确生成``嵌套
`UnifiedRuleEngine.createItem`同样覆盖全部字段类型。所以**能力是具备的**。
### 真正的三个问题，分层看
**问题A（中风险，已实锤）：业务页面创建跳过前段规则**
这是最直接的问题。业务页面是人工创建的主要入口，却绕过了validate/create_pre。后果就是：同一条对象，经CapabilityRuntime创建（worker/AI）和经业务页面创建，前段处理不一致。
**问题B（低风险，已实锤）：提示词两套生成路径**
服务端预生成和前端动态拼装可能不一致，影响AI对话的准确性。
**问题C（已知债）：旧规则表未完全迁移**
`sciot_import.db`里两套规则表并存，部分用户/模块仍读旧表。这是遗留的技术债。
---
## 从诊断到行动：左帮右臂能做什么？
看到这里，你可能已经意识到：**创建统一性不是一个小bug，而是一个系统架构问题。** 它反映的是：当系统不断演进，多个入口、多种技术栈并存时，如何确保业务规则的一致执行？
这正是**左帮右臂（BossAgents）智能体公司**的核心能力所在。我们不只是诊断问题，更是提供**可落地的统一架构方案**：
1. **创建路径统一化**：将所有创建入口收敛到`CapabilityRuntime`统一层，确保validate/create_pre/create_post完整生命周期执行。无论是网页、AI、飞书还是小程序，走同一条规则路径。
2. **规则配置中心化**：将sciot_rules_v2作为唯一真相源，逐步迁移旧规则表，消除数据不一致。
3. **提示词生成标准化**：统一服务端预生成路径，前端只做展示和交互，不参与逻辑拼装。
4. **全链路监控**：在统一层埋点，实时监控每个创建入口的规则命中率、执行时间、异常情况，让“统一性”可量化、可追踪。
5. **渐进式迁移**：不搞“一刀切”重构，而是通过统一层适配器，逐步将现有入口迁移到新路径，确保业务不中断。
数字化转型的本质，不是上一套新系统，而是**让已有系统协同工作**。创建统一性只是冰山一角，但解决了它，就能避免80%的数据一致性问题。
**左帮右臂，不只是诊断，更是帮你把“统一”落地成代码。**
